Subject: Re: [clue] I-D Action: draft-ietf-clue-rtp-mapping-08.txt

From: Jonathan Lennox <[email-masked]>
Date: Fri, 2 Sep 2016 14:55:48 +0000

Colin Perkins had a number of comments on the CLUE RTP mapping draft, which he submitted during the WGLC.  Roni and I met with him in Berlin to discuss his comments, and we decided to submit a revised I-D to address them.

Unfortunately, Paul missed that these comments hadn’t been addressed, so he submitted the document for PubReq.  I let him know afterwards that we were still anticipating submitting another draft, and I think he tried to withdraw the PubReq, but apparently the datatracker isn’t really set up to easily allow this.

The result of our discussion with Colin in Berlin was the realization that a large portion of the CLUE RTP mapping draft wasn’t appropriate for a final specification — much of the text was intended as argumentative, during the course of the design work, and so now that the discussions have finished and we’ve reached consensus it’s distracting and confusing, especially since much of the terminology it used was different than the terminology the IETF eventually converged on.

This latest draft is intended to drop most of the argumentative text, while leaving (with minor edits and clarifications) all the normative text and a reasonable amount of background.  (It’s possible we got this wrong, though.)

I hope that clears the situation up.

> On Aug 29, 2016, at 1:14 PM, Alissa Cooper <[email-masked]> wrote:
> 
> 
>> On Aug 27, 2016, at 10:56 AM, Paul Kyzivat <[email-masked]> wrote:
>> 
>> I'd appreciate an explanation for the changes in the new version. Looking at the diff, it appears that the draft has been gutted. I am guessing this reflects discussions held in Berlin.
> 
> I was not aware of any such discussions so would appreciate an explanation as well. The pub req was based on the -07 and I had started my AD review on the -07.
> 
> Alissa
> 
>> 
>> 	Thanks,
>> 	Paul
>> 
>> On 8/27/16 8:58 AM, [email-masked] wrote:
>>> 
>>> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>>> This draft is a work item of the ControLling mUltiple streams for tElepresence of the IETF.
>>> 
>>>       Title           : Mapping RTP streams to CLUE Media Captures
>>>       Authors         : Roni Even
>>>                         Jonathan Lennox
>>> 	Filename        : draft-ietf-clue-rtp-mapping-08.txt
>>> 	Pages           : 13
>>> 	Date            : 2016-08-27
>>> 
>>> Abstract:
>>>  This document describes how the Real Time transport Protocol (RTP) is
>>>  used in the context of the CLUE protocol.  It also describes the
>>>  mechanisms and recommended practice for mapping RTP media streams
>>>  defined in SDP to CLUE Media Captures.
>>> 
>>> 
>>> The IETF datatracker status page for this draft is:
>>> https://datatracker.ietf.org/doc/draft-ietf-clue-rtp-mapping/
>>> 
>>> There's also a htmlized version available at:
>>> https://tools.ietf.org/html/draft-ietf-clue-rtp-mapping-08
>>> 
>>> A diff from the previous version is available at:
>>> https://www.ietf.org/rfcdiff?url2=draft-ietf-clue-rtp-mapping-08
>>> 
>>> 
>>> Please note that it may take a couple of minutes from the time of submission
>>> until the htmlized version and diff are available at tools.ietf.org.
>>> 
>>> Internet-Drafts are also available by anonymous FTP at:
>>> ftp://ftp.ietf.org/internet-drafts/
>>> 
>>> _______________________________________________
>>> clue mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/clue
>>> 
>> 
>> _______________________________________________
>> clue mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/clue
> 
> _______________________________________________
> clue mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/clue
>

---

From: Alissa Cooper <[email-masked]>
Date: Fri, 2 Sep 2016 11:32:40 -0400

> On Sep 2, 2016, at 10:55 AM, Jonathan Lennox <[email-masked]> wrote:
> 

Thanks!

Paul, do you expect to re-review and possibly edit the shepherd write-up?

Alissa

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 2 Sep 2016 12:30:11 -0400

> Paul, do you expect to re-review and possibly edit the shepherd write-up?

Definitely. Once I am clear that the intended revisions are complete.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 2 Sep 2016 12:32:40 -0400

> This latest draft is intended to drop most of the argumentative text, while leaving (with minor edits and clarifications) all the normative text and a reasonable amount of background.  (It’s possib…

Thanks for the context. In my first reading of the diffs it appeared to 
me that significant functionality had been dropped. But I will read it 
again. Maybe I just misunderstood.

	Thanks,
	Paul

---

From: "Roni Even" <[email-masked]>
Date: Sun, 4 Sep 2016 00:38:22 +0300

Hi Paul,
The idea was to try not to repeat text from other referenced document and to take out some of the text that described some discussion that is not relevant to the RTP mapping for CLUE
Roni 

> -----Original Message-----
> From: clue [mailto:[email-masked]] On Behalf Of Paul Kyzivat
> Sent: Friday, September 02, 2016 7:33 PM
> To: Jonathan Lennox; Alissa Cooper
> Cc: [email-masked]
> Subject: Re: [clue] I-D Action: draft-ietf-clue-rtp-mapping-08.txt
> 
> > Colin Perkins had a number of comments on the CLUE RTP mapping draft,
> which he submitted during the WGLC.  Roni and I met with him in Berlin to
> discuss his comments, and we decided to submit a revised I-D to address
> them.
> >
> > Unfortunately, Paul missed that these comments hadn’t been addressed,
> so he submitted the document for PubReq.  I let him know afterwards that
> we were still anticipating submitting another draft, and I think he tried to
> withdraw the PubReq, but apparently the datatracker isn’t really set up to
> easily allow this.
> >
> > The result of our discussion with Colin in Berlin was the realization that a
> large portion of the CLUE RTP mapping draft wasn’t appropriate for a final
> specification — much of the text was intended as argumentative, during the
> course of the design work, and so now that the discussions have finished and
> we’ve reached consensus it’s distracting and confusing, especially since
> much of the terminology it used was different than the terminology the IETF
> eventually converged on.
> >
> > This latest draft is intended to drop most of the argumentative text,
> > while leaving (with minor edits and clarifications) all the normative
> > text and a reasonable amount of background.  (It’s possible we got
> > this wrong, though.)
> 
> Thanks for the context. In my first reading of the diffs it appeared to me that
> significant functionality had been dropped. But I will read it again. Maybe I
> just misunderstood.
> 
> 	Thanks,
> 	Paul
> 
> >>> I'd appreciate an explanation for the changes in the new version.
> Looking at the diff, it appears that the draft has been gutted. I am guessing
> this reflects discussions held in Berlin.
> >>
> >> I was not aware of any such discussions so would appreciate an
> explanation as well. The pub req was based on the -07 and I had started my
> AD review on the -07.
> >>
> >> Alissa
> >>
> >>>
> >>> 	Thanks,
> >>> 	Paul
> >>>
> >>>>  This document describes how the Real Time transport Protocol (RTP)
> >>>> is  used in the context of the CLUE protocol.  It also describes
> >>>> the  mechanisms and recommended practice for mapping RTP media
> >>>> streams  defined in SDP to CLUE Media Captures.
> >>>>
> >>>>
> >>>> Please note that it may take a couple of minutes from the time of
> >>>> submission until the htmlized version and diff are available at
> tools.ietf.org.
> >>>>

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 6 Sep 2016 15:10:43 -0400

Roni & Jonathan,

> again. Maybe I just misunderstood.

OK, I read it again. Now I can be more specific about what is bothering 
me. (Note that I'm discussing changes between -07 and -08. So it is 
necessary to have both in front of you (or the diff) to make sense of 
these comments.)

* Section 3:

The change from -07 removes the discussion of there being two major 
RTP/RTCP behaviors. Does that mean we have lost one or both of these?

* Section 4:

Here again two distinct behaviors were previously broken out, and that 
has now been removed. I thought those alternatives were important. Have 
we lost one of those?

And then we have also lost:

    In either of the above two cases, the MCU/Mixer may create an
    advertisement with a virtual room capture scene (i.e., with Multiple
    Content Captures).

    isAlternately the MCU/Mixer can relay all the capture scenes from all
    advertisements to all consumers.  This means that the advertisement
    will include multiple capture scenes, each representing a separate
    TelePresence room with its own coordinate system.

While this will remain true even if it is not mentioned, I thought it 
was an important conceptual difference that was worth highlighting, 
since one or the other may not occur to some readers.

* Sections 4.3 & 4.4 (in -7):

These two sections (Static Mapping and Dynamic Mapping) were 
elaborations of the stuff I mentioned above. So my same questions apply.

This distinction was a *big deal*, with some participants implementing 
one and some the other in their video conferencing products.

* Sections 4.2 and 5 (in -7):

I guess you all decided we no longer needed to carry the history of how 
we got where we ended up. It disturbs me to lose this history, but I 
understand it can be distracting. So I reluctantly accept this.

	Thanks,
	Paul

---

From: "Roni Even" <[email-masked]>
Date: Sun, 11 Sep 2016 21:08:20 +0300

Paul,
The issue of static and dynamic mapping was reflecting the discussion
between Jonathan Lennox and me. It was based on the different supported
topologies and after talking with Colin Perkins it was clear that it was
confusing terminology and there was need to have it in this document and
just reference the AVTcore topologies supported by CLUE. 
We tried to make the document simpler and this is the result

Roni 

> Sent: Tuesday, September 06, 2016 10:11 PM
> To: [email-masked]
> > Thanks for the context. In my first reading of the diffs it appeared
> > to me that significant functionality had been dropped. But I will read
> > it again. Maybe I just misunderstood.
> 
me.
> (Note that I'm discussing changes between -07 and -08. So it is necessary
to
> have both in front of you (or the diff) to make sense of these comments.)
> 
> * Section 3:
> 
> Here again two distinct behaviors were previously broken out, and that has
> now been removed. I thought those alternatives were important. Have we
> lost one of those?
> 
> While this will remain true even if it is not mentioned, I thought it was
an
> important conceptual difference that was worth highlighting, since one or
> the other may not occur to some readers.
> 
> This distinction was a *big deal*, with some participants implementing one
> and some the other in their video conferencing products.
> 
> I guess you all decided we no longer needed to carry the history of how we
> got where we ended up. It disturbs me to lose this history, but I
understand it
> can be distracting. So I reluctantly accept this.
> 
> 	Thanks,
> 	Paul
>

---

From: "Duckworth, Mark" <[email-masked]>
Date: Mon, 12 Sep 2016 22:07:26 +0000

I'm also concerned we are losing some important information in this recent
change. I found the old section 5 "Application to CLUE Media Requirements"
particularly useful.

For me, the most important information in the RTP mapping document is how to
associate all these different things with each other:
- SSRC/CSRC
- SDP m-line (which is a CLUE encoding)
- Clue capture ID for directly configured media captures (MC or MCC)
- Clue capture ID for constituents of MCC (for both switched and composed
cases)

I went back to old email here:
https://mailarchive.ietf.org/arch/msg/clue/qFfSNIzFuNtqqlGbxx1W5dXLik4

I'm not sure anymore if the RTP mapping document clearly describes the
different cases discussed in that email. I think it should, and I thought it
did, but I'm not so sure anymore.

I think this part is not at all clear (from the referenced email):

> Mechanism 2: Use RTP/RTCP CaptureID SDES item, conveyed in RTCP and RTP
header extension as described in clue-rtp-mapping section 6.  This gives a
direct mapping between an ssrc value and a captureID.  This mechanism is
intended to be used only for Clue media captures that are constituents of an
MCC.  This could apply to an MCC that is switched or composed.
> 
> For the case of a "switching mixer", the ssrc value in RTP packets stays
the same over time for a given m line and CLUE encoding.  This is true for
single MC encoded directly, and also for an MCC.  For an MCC, the ssrc value
associated with the MCC captureID stays constant.  But the value(s) in RTP
CSRC field change as switching occurs.  So the MID SDES item maps to a
constant ssrc value even when switching occurs.  The CaptureID SDES item
(conveyed in RTCP) maps the MCC constituent capture IDs to the values that
appear in RTP CSRC field.  These mappings don't change, but the media
provider should send the mapping information whenever an individual MC is
switched into an MCC for the first time.  The CaptureID RTP header extension
does not apply for this case, it can be conveyed only in RTCP.

I think it would help if we took some information from that old email and
added it into RTP mapping doc. Or can anybody show me how it really is clear
already, or if the old email is actually mistaken?

Mark

> From: clue [mailto:[email-masked]] On Behalf Of Roni Even
> Sent: Sunday, September 11, 2016 2:08 PM
> To: 'Paul Kyzivat' <[email-masked]>; [email-masked]
> Cc: 'Jonathan Lennox' <[email-masked]>
has
> > While this will remain true even if it is not mentioned, I thought it
was
> > This distinction was a *big deal*, with some participants implementing
one
> > I guess you all decided we no longer needed to carry the history of how
we

---

From: "Roni Even" <[email-masked]>
Date: Wed, 14 Sep 2016 19:19:28 +0300

Hi Mark,
The reason we took the information out because it is described in other
documents like the RTP topologies for SSRC/CSRC or the CLUE signaling
document for the SDP mapping. We reference these documents and did not see
any need to repeat information

Roni

> From: Duckworth, Mark [mailto:[email-masked]]
> Sent: Tuesday, September 13, 2016 1:07 AM
> To: Roni Even; 'Paul Kyzivat'
> Cc: 'Jonathan Lennox'; [email-masked]
> Subject: RE: [clue] I-D Action: draft-ietf-clue-rtp-mapping-08.txt
>

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 14 Sep 2016 12:40:20 -0400

> We tried to make the document simpler and this is the result

IIUC you are saying that the change in the text has not altered the 
functionality. Is that right?

	Thanks,
	Paul

---

From: "Duckworth, Mark" <[email-masked]>
Date: Wed, 14 Sep 2016 17:03:54 +0000

Hi Roni,

I agree the parts about mapping ssrc/csrc to m-lines and CLUE encodings is
described in other RTP documents and CLUE signaling document. So I am okay
with that part.

However, I think some information about the meaning and usage of the Capture
ID SDES item and RTP Header is missing.

1. Capture ID SDES and RTP Header is intended to be used only for
constituent captures within an MCC.
   1.a - I previously suggested changing the name to "MCC Constituent
Capture ID", and Jonathan agreed. I still think this is a good idea.

2. An MCC can include more than 1 constituent capture at a time. The Capture
ID SDES item is intended to be used for any number of simultaneous
constituent captures. This means it can be used for the composed case as
well as the pure switching case. The document implies (to me) it can be used
only for the switching case.

3. For the composed case, the RTP Header extension is not used, because that
won't map the capture ID to CSRC values. Instead, for the composed case,
only the RTCP SDES mechanism can be used to map the Capture ID to values
that appear in the MCC packets' CSRC list. This allows the media consumer to
identify the original media captures that are composed into the MCC.

I think Jonathan agreed to all this on the list
https://mailarchive.ietf.org/arch/msg/clue/qFfSNIzFuNtqqlGbxx1W5dXLik4

If you agree, I could suggest specific changes to the document to make this
clear.

Mark

> From: Roni Even [mailto:[email-masked]]
> Sent: Wednesday, September 14, 2016 12:19 PM
> To: Duckworth, Mark <[email-masked]>; 'Paul Kyzivat'
> <[email-masked]>
> Cc: 'Jonathan Lennox' <[email-masked]>; [email-masked]
> > different cases discussed in that email. I think it should, and I
thought
> it
> > intended to be used only for Clue media captures that are constituents
of
> > > >     isAlternately the MCU/Mixer can relay all the capture scenes
from
> > all
> > > > important conceptual difference that was worth highlighting, since
one
> > or

---

From: "Roni Even" <[email-masked]>
Date: Wed, 14 Sep 2016 20:17:16 +0300

Hi Paul,
This is correct, no change in functionality.
Roni

> From: Paul Kyzivat [mailto:[email-masked]]
> Sent: Wednesday, September 14, 2016 7:40 PM
> To: Roni Even; [email-masked]
> Cc: 'Jonathan Lennox'
> > between Jonathan Lennox and me. It was based on the different
> > supported topologies and after talking with Colin Perkins it was clear
> > that it was confusing terminology and there was need to have it in
> > this document and just reference the AVTcore topologies supported by
> CLUE.
> >>> to me that significant functionality had been dropped. But I will
> >>> read it again. Maybe I just misunderstood.
> >>
> >> Here again two distinct behaviors were previously broken out, and
> >> that has now been removed. I thought those alternatives were
> >> important. Have we lost one of those?
> >>
> >> one or the other may not occur to some readers.
> >>
> >> This distinction was a *big deal*, with some participants
> >> implementing one and some the other in their video conferencing
> products.
> >>
> >> I guess you all decided we no longer needed to carry the history of
> >> how we got where we ended up. It disturbs me to lose this history,
> >> but I
> > understand it

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 14 Sep 2016 15:27:58 -0400

Given the substantial changes and the subsequent discussion I think 
another WGLC is warranted for this.

	Thanks,
	Paul

On 9/14/16 1:03 PM, Duckworth, Mark wrote:
>> supported
> that
> implementing
>> how

---

From: "Roni Even" <[email-masked]>
Date: Tue, 20 Sep 2016 16:14:37 +0300

Hi Paul,
Can you start the new WGLC
Roni

> Sent: Wednesday, September 14, 2016 10:28 PM
> To: Duckworth, Mark; Roni Even
another
> WGLC is warranted for this.
> 
> 	Thanks,
> 	Paul
> 
> > I agree the parts about mapping ssrc/csrc to m-lines and CLUE
> > encodings is described in other RTP documents and CLUE signaling
> > document. So I am okay with that part.
> >
> > However, I think some information about the meaning and usage of the
> > Capture ID SDES item and RTP Header is missing.
> >
> > 2. An MCC can include more than 1 constituent capture at a time. The
> > Capture ID SDES item is intended to be used for any number of
> > simultaneous constituent captures. This means it can be used for the
> > composed case as well as the pure switching case. The document implies
> > (to me) it can be used only for the switching case.
> >
> > 3. For the composed case, the RTP Header extension is not used,
> > because that won't map the capture ID to CSRC values. Instead, for the
> > composed case, only the RTCP SDES mechanism can be used to map the
> > Capture ID to values that appear in the MCC packets' CSRC list. This
> > allows the media consumer to identify the original media captures that
are
> composed into the MCC.
> > If you agree, I could suggest specific changes to the document to make
> > this clear.
> >
> > Mark
> >
> >> The reason we took the information out because it is described in
> >> other documents like the RTP topologies for SSRC/CSRC or the CLUE
> >> signaling document for the SDP mapping. We reference these documents
> >> and did not see any need to repeat information
> >>
> >> Roni
> >>
> >>> For me, the most important information in the RTP mapping document
> >>> is how to associate all these different things with each other:
> >>> - SSRC/CSRC
> >>> I'm not sure anymore if the RTP mapping document clearly describes
> >>> the different cases discussed in that email. I think it should, and
> >>> I
> > thought
> >> it
> >>>> Mechanism 2: Use RTP/RTCP CaptureID SDES item, conveyed in RTCP
> and
> >>> RTP
> >>> header extension as described in clue-rtp-mapping section 6.  This
> >>> gives
> > a
> >>> direct mapping between an ssrc value and a captureID.  This
> >>> mechanism is intended to be used only for Clue media captures that
> >>> are constituents
> > of
> >> an
> >>> the same over time for a given m line and CLUE encoding.  This is
> >>> true
> > for
> >>> single MC encoded directly, and also for an MCC.  For an MCC, the
> >>> ssrc
> >> value
> >>> associated with the MCC captureID stays constant.  But the value(s)
> >>> in
> > RTP
> >>> CSRC field change as switching occurs.  So the MID SDES item maps to
> >>> a constant ssrc value even when switching occurs.  The CaptureID
> >>> SDES item (conveyed in RTCP) maps the MCC constituent capture IDs to
> >>> the values
> >> that
> >>> appear in RTP CSRC field.  These mappings don't change, but the
> >>> media provider should send the mapping information whenever an
> >>> individual MC
> >> is
> >>> I think it would help if we took some information from that old
> >>> email
> > and
> >>> added it into RTP mapping doc. Or can anybody show me how it really
> >>> is clear already, or if the old email is actually mistaken?
> >>>
> >>> Mark
> >>>
> >>>> The issue of static and dynamic mapping was reflecting the
> >>>> discussion between Jonathan Lennox and me. It was based on the
> >>>> different
> >> supported
> >>>> topologies and after talking with Colin Perkins it was clear that
> >>>> it
> > was
> >>>> confusing terminology and there was need to have it in this
> >>>> document
> >> and
> >>>>> The change from -07 removes the discussion of there being two
> >>>>> major RTP/RTCP behaviors. Does that mean we have lost one or both
> >>>>> of
> >> these?
> >>>>>
> >>>>> * Section 4:
> >>>>>
> >>>>> now been removed. I thought those alternatives were important.
> >>>>> Have
> >>> we
> >>>>> lost one of those?
> >>>>>

---

From: Jonathan Lennox <[email-masked]>
Date: Wed, 21 Sep 2016 15:32:29 +0000

Hi, Mark —

These seem like good changes to me.  Sorry, I’d lost track of our previous discussion.

I’m not sure how useful the constituent capture ID is for composed MCCs, as opposed to switched ones, since the geometry information is only going to be meaningful for switched MCCs.  But it’s still useful informationally, and putting it in the CSRCs’ SDESes is the right thing to do.

If you could suggest text that’d be great.

> On Sep 14, 2016, at 1:03 PM, Duckworth, Mark <[email-masked]> wrote:
> 
> Hi Roni,
>

---

From: "Duckworth, Mark" <[email-masked]>
Date: Mon, 26 Sep 2016 21:56:04 +0000

Hi Jonathan and Roni,

I thought some more about the MCC composed case, where there are two or more MCs in the MCC. I think trying to use this CaptureID RTP Header and SDES item has problems for that case, so maybe it is better to just drop it. I agree with Jonathan that "I’m not sure how useful the constituent capture ID is for composed MCCs".

The problem I see is about associating the original contributing CaptureIDs to SSRC/CSRC values. When using the RTP header extension, we are associating one contributing original CaptureID with the SSRC of the MCC stream. This is different than associating the captureID to a CSRC that might appear in the same RTP packet. This works well for the switched case (as opposed to composed) because it is direct and doesn't rely on any CSRC. Some topologies might not even be using CSRCs.

If we also use this SDES item to map CaptureIDs to CSRCs that appear within an MCC packet, that is a different sort of mapping. Those CSRC values would be associated with the original constituent MCs, not the MCC. So we would be using this captureID mapping mechanism to map it to two different types of things. That doesn't seem right to me. It gets more complicated if the composed case happens to include only one CSRC at some point, then what do you map the CaptureID to? The CSRC value, or the SSRC value, or both?

So anyway, now I'm proposing this mechanism can be used only for the switched MCC case. This is closer to how the rtp mapping document is already written.

I still will have some small suggestions for clarifying text in the document. I can send that later, after the group agrees whether or not to support the composed case with this, or just the pure switched case.

Mark

> From: Jonathan Lennox [mailto:[email-masked]]
> Sent: Wednesday, September 21, 2016 11:32 AM
> To: Duckworth, Mark <[email-masked]>
> Cc: Roni Even <[email-masked]>; Paul Kyzivat
> <[email-masked]>; [email-masked]
> I’m not sure how useful the constituent capture ID is for composed MCCs, as
> opposed to switched ones, since the geometry information is only going to
> be meaningful for switched MCCs.  But it’s still useful informationally, and
> putting it in the CSRCs’ SDESes is the right thing to do.
> 
> Capture
> >> document for the SDP mapping. We reference these documents and did
> not
> >> see
> >>> provider should send the mapping information whenever an individual
> MC
> >> is

---

From: Christian Groves <[email-masked]>
Date: Tue, 27 Sep 2016 16:01:13 +1000

Hello Mark,

What about the switched composed case where the endpoint switches 
between composed captures? We should probably explicitly mention this as 
its discussed in the framework.

Regards, Christian

---

From: "Duckworth, Mark" <[email-masked]>
Date: Tue, 27 Sep 2016 12:42:17 +0000

Hi Christian,
I'm not sure I know what you are talking about.
If you mean a case described in framework section 7.2.1.1 such as:

"When MaxCaptures is set to <= to the number of Captures in the MCC this is
a switched and composed case. The Capture Encoding may contain media
switched between any number (up to the MaxCaptures) of composed sources. "

Then I'm suggesting when the MCC stream, at the moment, is composed from
more than one MC then we can't use the CaptureID RTP Header or SDES item to
identify those MCs.

Mark

> From: clue [mailto:[email-masked]] On Behalf Of Christian Groves
> Sent: Tuesday, September 27, 2016 2:01 AM
> To: [email-masked]
> > I thought some more about the MCC composed case, where there are two
> or more MCs in the MCC. I think trying to use this CaptureID RTP Header
and
> SDES item has problems for that case, so maybe it is better to just drop
it. I
> agree with Jonathan that "I'm not sure how useful the constituent capture
ID
> is for composed MCCs".
> >
> > The problem I see is about associating the original contributing
CaptureIDs
> to SSRC/CSRC values. When using the RTP header extension, we are
> associating one contributing original CaptureID with the SSRC of the MCC
> stream. This is different than associating the captureID to a CSRC that
might
> appear in the same RTP packet. This works well for the switched case (as
> opposed to composed) because it is direct and doesn't rely on any CSRC.
> Some topologies might not even be using CSRCs.
> >
> > If we also use this SDES item to map CaptureIDs to CSRCs that appear
> within an MCC packet, that is a different sort of mapping. Those CSRC
values
> would be associated with the original constituent MCs, not the MCC. So we
> would be using this captureID mapping mechanism to map it to two different
> types of things. That doesn't seem right to me. It gets more complicated
if
> the composed case happens to include only one CSRC at some point, then
> what do you map the CaptureID to? The CSRC value, or the SSRC value, or
> both?
> >
> > So anyway, now I'm proposing this mechanism can be used only for the
> switched MCC case. This is closer to how the rtp mapping document is
> already written.
> >
> > I still will have some small suggestions for clarifying text in the
document. I
> can send that later, after the group agrees whether or not to support the
> composed case with this, or just the pure switched case.
> >
> > Mark
> >
> >> Hi, Mark -
> >> These seem like good changes to me.  Sorry, I'd lost track of our
previous
> >> discussion.
> >>
> >> I'm not sure how useful the constituent capture ID is for composed
MCCs,
> as
> >> be meaningful for switched MCCs.  But it's still useful
informationally, and
> >> putting it in the CSRCs' SDESes is the right thing to do.
> >>
> >> If you could suggest text that'd be great.
> >>
encodings
> >>> well as the pure switching case. The document implies (to me) it can
be
> >> used
> because
> >>> that appear in the MCC packets' CSRC list. This allows the media
> consumer
> >> to
> this
other
> >>>>> For me, the most important information in the RTP mapping
> document is
> >>>>> how to
> the
> mechanism
true
ssrc
in
> >>>>> (conveyed in RTCP) maps the MCC constituent capture IDs to the
> values
> >>>> that
> media
email
> >>>>> clear
> discussion
it
> major

---

From: Christian Groves <[email-masked]>
Date: Wed, 28 Sep 2016 09:33:38 +1000

Hello Mark,

Yes that what I'm referring to. So in that case even though the stream 
would be switched because the constituent part are composed then 
CaptureID RTP Header wouldn't be used?

Regards, Christian

---

From: "Duckworth, Mark" <[email-masked]>
Date: Wed, 28 Sep 2016 02:38:40 +0000

Christian, I am still not quite following you. Do you mean there is a case where the composed capture has a CaptureID of its own, separate from the MCC CaptureID?
Mark

-------- Original message --------
From: Christian Groves <[email-masked]>
Date:09/27/2016 19:33 (GMT-05:00)
To: "Duckworth, Mark" <[email-masked]>
Cc: [email-masked]
Subject: Re: [clue] I-D Action: draft-ietf-clue-rtp-mapping-08.txt

Hello Mark,

Regards, Christian

---

From: Christian Groves <[email-masked]>
Date: Wed, 28 Sep 2016 13:40:58 +1000

Hello Mark,

The CLUE framework in section 7.2.1.1 basically indicates 3 
configurations: switched, composed and switched composed. What I'm 
saying is that if you're proposing on updating text in 
draft-ietf-clue-rtp-mapping to say it should be clear that its only for 
the switched case. The switched composed case wouldn't use CaptureID RTP 
Header or SDES either.

Regards, Christian

On 28/09/2016 12:38 PM, Duckworth, Mark wrote:
> Christian, I am still not quite following you. Do you mean there is a 
> case where the composed capture has a CaptureID of its own, separate 
> from the MCC CaptureID?
> Mark
>
>
> >>>> opposed to switched ones, since the geometry information is only 
> going
> >> to
> >>>>> described in other RTP documents and CLUE signaling document. So 
> I am
> >>>> okay
> >>>>> with that part.
> >>>>>
> >>>>> constituent captures. This means it can be used for the composed 
> case
> >> as
> >>>>>>> I'm also concerned we are losing some important information in 
> this
> >>>>> recent
> >>>>>>>> For the case of a "switching mixer", the ssrc value in RTP 
> packets
> >>>>> stays
> >>>>>>> constant ssrc value even when switching occurs.  The CaptureID 
> SDES
> >>>> item
> >>>>>>>>> While this will remain true even if it is not mentioned, I 
> thought
> >>>>> it
> >>>>>>> was
> >>>>>>>> an
> >>>>>>>>> elaborations of the stuff I mentioned above. So my same 
> questions
> >>>>>> apply.