Subject: [clue] Rtp mapping and ssrc and captureID

From: "Duckworth, Mark" <[email-masked]>
Date: Sun, 9 Nov 2014 07:30:39 -0800

I have a couple questions about how the rtp mapping document describes mappings between encodings, media captureID, and ssrc/csrc.

In section 5, the part about meeting the Media-7 requirement, it says in some cases (switched mixer and selective forwarding) the original source of a switched capture can be determined from ssrc or csrc. I don't understand how this is the case. The point is for the receiver (media consumer) to be able to relate rtp packets to the original media capture ID. So even if it has a ssrc value from ssrc or csrc field in RTP header, how does this help? Where does the mapping from ssrc to captureID come from in this case?

Then the document goes on to say how to use new rtp header for captureID for MCC constituent, which I think I understand. But is the document saying sometimes you use this rtp header extension and sometimes you don't need it because ssrc suffices? Can anybody clarify this?

I think the proposed rtp header extension for captureID is intended to be used only for identifying the captureID of  the original capture used for a purely switched MCC, correct?  If so, could we call it "MCC constituent captureID" or something like that which better indicates what it means? Otherwise, just calling it CaptureID makes it sound more broad, like the ID of the MCC itself, or the ID of a simple individual media capture that is not switched.

Mark

---

From: Jonathan Lennox <[email-masked]>
Date: Sun, 9 Nov 2014 23:15:35 +0000

> In section 5, the part about meeting the Media-7 requirement, it says in some cases (switched mixer and selective forwarding) the original source of a switched capture can be determined from ssrc o…

The idea is that the mapping from SSRC (or CSRC) to CaptureID is done by the new RTCP SDES item or header extension, whereas which SSRC or CSRCs are making up the current media is communicated by the normal RTP mechanisms.

This means that communicating the SSRC/CSRC-to-CaptureID mappings isn’t necessarily timing-crucial, and so doesn’t need to be repeated on every switch, so long as the receiver already has all the relevant information.

Currently the header extension flavor of the solution only works for SSRC, so only works for what the rtp topologies update calls a “selective forwarding middlebox", whereas a “switching mixer” would have to use the RTCP item only.  (There isn’t currently any specified way to send a header extension that gives an SDES item for one of the media’s CSRCs.  This might be worth raising with the authors of draft-westerlund-avtext-sdes-hdr-ext, which this solution is meant to be compatible with.)

> I think the proposed rtp header extension for captureID is intended to be used only for identifying the captureID of  the original capture used for a purely switched MCC, correct?  If so, could we…

I agree this might be a better name.

---

From: "Duckworth, Mark" <[email-masked]>
Date: Tue, 11 Nov 2014 12:27:06 -0800

Thanks Jonathan, I think I follow what you are saying.
But I'm still trying to understand that we really have two different ways to associate SSRC values with CLUE captureID, and when each way is used, and if they overlap at all.  Consider the case where BUNDLE is used.  Then there are two different mapping mechanisms in play:

Mechanism 1: Use RTP/RTCP MID SDES item, conveyed in RTCP and RTP header extension as described in BUNDLE sections 10.2 and 13.  This associates an ssrc value with an m line by linking them to the same SDP mid value, which is unique per m line.  The CLUE media consumer also knows the mapping from m line to the CLUE capture ID received for that m line, because the consumer made that mapping itself when it sent the configure message to the provider.  So with all this, both consumer and provider know the association of: CLUE captureID, CLUE encodingID (also SDP label), SDP m line, SDP mid value.  So this seems adequate for handling all media captures that are directly configured into a CLUE encoding (and m line), but not for captures that are constituents of MCCs.

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.

For the case of a "selective forwarding middlebox", for RTP packets it sends for a switched MCC, a single ssrc value can be mapped to a different captureID by each of the above two mechanisms.  The MID SDES item maps the ssrc to the capture ID of the MCC itself.  But the CaptureID SDES item maps the same ssrc value to the capture ID of the original MC that is a constituent of the MCC.  When the middlebox decides to switch the MCC to a different constituent MC, then the MID SDES item maps the mid value to the new ssrc (the receiver always needs this information right away).  The CaptureID SDES item maps the new ssrc to the new original MC capture ID (although the receiver might not need this if it already has this information from when the same MC was previously sent as part of an MCC).

So am I describing these mechanisms and scenarios correctly?
If I have it right so far, then I think BUNDLE has a problem with "selective forwarding middlebox" when the same source is sent for two different m lines at the same time.  But that is probably a topic for the mmusic list, does anybody know if that has already been discussed?

Thanks for helping me understand.

Mark

> -----Original Message-----
> From: Jonathan Lennox [mailto:[email-masked]]
> Sent: Sunday, November 09, 2014 1:16 PM
> To: Duckworth, Mark
> Cc: [email-masked]
> Subject: Re: [clue] Rtp mapping and ssrc and captureID
> 
> 
> > I have a couple questions about how the rtp mapping document describes
> mappings between encodings, media captureID, and ssrc/csrc.
> >
> > In section 5, the part about meeting the Media-7 requirement, it says in
> some cases (switched mixer and selective forwarding) the original source of a
> switched capture can be determined from ssrc or csrc. I don't understand
> how this is the case. The point is for the receiver (media consumer) to be
> able to relate rtp packets to the original media capture ID. So even if it has a
> ssrc value from ssrc or csrc field in RTP header, how does this help? Where
> does the mapping from ssrc to captureID come from in this case?
> 
> The idea is that the mapping from SSRC (or CSRC) to CaptureID is done by the
> new RTCP SDES item or header extension, whereas which SSRC or CSRCs are
> making up the current media is communicated by the normal RTP
> mechanisms.
> 
> This means that communicating the SSRC/CSRC-to-CaptureID mappings isn't
> necessarily timing-crucial, and so doesn't need to be repeated on every
> switch, so long as the receiver already has all the relevant information.
> 
> Currently the header extension flavor of the solution only works for SSRC, so
> only works for what the rtp topologies update calls a "selective forwarding
> middlebox", whereas a "switching mixer" would have to use the RTCP item
> only.  (There isn't currently any specified way to send a header extension
> that gives an SDES item for one of the media's CSRCs.  This might be worth
> raising with the authors of draft-westerlund-avtext-sdes-hdr-ext, which this
> solution is meant to be compatible with.)
> 
> > Then the document goes on to say how to use new rtp header for
> captureID for MCC constituent, which I think I understand. But is the
> document saying sometimes you use this rtp header extension and
> sometimes you don't need it because ssrc suffices? Can anybody clarify this?
> >
> > I think the proposed rtp header extension for captureID is intended to be
> used only for identifying the captureID of  the original capture used for a
> purely switched MCC, correct?  If so, could we call it "MCC constituent
> captureID" or something like that which better indicates what it means?
> Otherwise, just calling it CaptureID makes it sound more broad, like the ID of
> the MCC itself, or the ID of a simple individual media capture that is not
> switched.
>

---

From: Jonathan Lennox <[email-masked]>
Date: Tue, 11 Nov 2014 22:55:25 +0000

This is correct.  The configured capture is always determined by its mapping to the encoding.  Encodings are determined by the mid if you’re using bundle, or the RTP session (5-tuple) if not.  Both of these are as specified in MMUSIC.

The CaptureID SDES item is only used for components of an MCC.

BUNDLE indeed does not currently allow a single SSRC to be mapped to more than one m-line — this precludes the same source being used for more than one encoding.  In the case when you want to send the same media for more than one capture, you’ll have to duplicate the media and re-map at least one SSRC.

I believe this issue is going to be discussed in MMUSIC this week when BUNDLE is discussed, so if you think this is a problem, come there to discuss it...

---

From: Christian Groves <[email-masked]>
Date: Wed, 12 Nov 2014 15:15:07 +1100

A further question related to requirement 5:

    Media-5: It must be possible for a source to be placed into a MCC
    even if the source is a "late joiner", i.e. was added to the
    conference after the receiver requested the MCC.

Just to clarify, is this describing the case where the RTP source 
relates to an existing individual MC related to an MCC? or is this a new 
individual MC related to an MCC?

Regards, Christian

On 10/11/2014 2:30 AM, Duckworth, Mark wrote:
> In section 5, the part about meeting the Media-7 requirement, it says 
> in some cases (switched mixer and selective forwarding) the original 
> source of a switched capture can be determined from ssrc or csrc. I 
> don't understand how this is the case. The point is for the receiver 
> (media consumer) to be able to relate rtp packets to the original 
> media capture ID. So even if it has a ssrc value from ssrc or csrc 
> field in RTP header, how does this help? Where does the mapping from 
> ssrc to captureID come from in this case?
>
> I think the proposed rtp header extension for captureID is intended to 
> be used only for identifying the captureID of  the original capture 
> used for a purely switched MCC, correct?  If so, could we call it "MCC 
> constituent captureID" or something like that which better indicates 
> what it means? Otherwise, just calling it CaptureID makes it sound 
> more broad, like the ID of the MCC itself, or the ID of a simple 
> individual media capture that is not switched.
>
> Mark
>
>
> _______________________________________________
> clue mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/clue

---

From: "Duckworth, Mark" <[email-masked]>
Date: Wed, 12 Nov 2014 11:00:04 -0800

I was interpreting it to mean a new individual MC that did not exist in the advertisement the receiver based the configure on.
Mark

> From: clue [mailto:[email-masked]] On Behalf Of Christian Groves
> Sent: Tuesday, November 11, 2014 6:15 PM
> To: [email-masked]

---

From: Jonathan Lennox <[email-masked]>
Date: Wed, 12 Nov 2014 19:16:36 +0000

I’m not sure what you’re asking?  What this is talking about is the case where the receiver requested an MCC, and the original capture being put in the MC is new to the conference since the latest configure/advertisement.

On Nov 11, 2014, at 6:15 PM, Christian Groves <[email-masked]> wrote:

> Just to clarify, is this describing the case where the RTP source relates to an existing individual MC related to an MCC? or is this a new individual MC related to an MCC?
> 
> Regards, Christian
> 
>

---

From: "Duckworth, Mark" <[email-masked]>
Date: Wed, 12 Nov 2014 11:49:34 -0800

Jonathan, should that be "... the original capture being put in the _MCC_ is new ..."?
I think this is consistent with my earlier response to Christian's question.
Mark

> From: clue [mailto:[email-masked]] On Behalf Of Jonathan Lennox
> Sent: Wednesday, November 12, 2014 9:17 AM
> To: Christian Groves
> Cc: [email-masked]
> I'm not sure what you're asking?  What this is talking about is the case where
> the receiver requested an MCC, and the original capture being put in the MC
> is new to the conference since the latest configure/advertisement.
> 
> > Just to clarify, is this describing the case where the RTP source relates to an
> existing individual MC related to an MCC? or is this a new individual MC
> related to an MCC?
> >
> > Regards, Christian
> >
> >

---

From: Jonathan Lennox <[email-masked]>
Date: Wed, 12 Nov 2014 19:53:39 +0000

Right, yes. I agree with your earlier response.

Suggestions for better wording for the requirements in the RTP Usage draft are welcome…I tried to update them all to current Clue terminology, but think they could still all be a lot clearer.

---

From: Christian Groves <[email-masked]>
Date: Thu, 13 Nov 2014 11:24:16 +1100

When reading the requirement it could be interpreted that the source was 
added to the existing MCC and becomes part of the media stream without 
additional CLUE signalling. Also media-5 isn't mentioned in the CLUE 
section which further suggests no relation to CLUE.

With the clarification it's clear it gets added as part of normal CLUE 
signalling. How does this wording sound?

Media-5: It must be possible for a new source to be placed into an 
Advertised MCC even if the source is a "late joiner", i.e. the MCC was 
previously Advertised and added to the conference after the receiver 
requested the MCC.

Regards, Christian