Subject: [clue] Updated clarification for rtp-mapping ClientID

From: "Duckworth, Mark" <[email-masked]>
Date: Thu, 6 Oct 2016 00:38:21 +0000

Thanks Jonathan for the suggestion and clarifications. Here is my updated
proposal for new text for section 5. This proposed text would replace the
existing text in the section.

=================== begin proposed change =====================

5. MCC Constituent CaptureID definition

For a MCC which can represent multiple switched MCs there is a need to know
which MC is represented in the current RTP stream at any given time. This
requires a mapping from the MCC RTP stream to the constituent MC. In order
to address this mapping this document defines an RTP header extension and
SDES item that includes the captureID of the original MC, allowing the
consumer to use the original source MC's attributes like the spatial
information.

This mapping temporarily associates the SSRC of the MCC stream with the
captureID of the single original MC that is currently switched into the MCC.
This mapping cannot be used for the composed case where more than one
original MC is composed into the MCC simultaneously.

If there is only one MC in the MCC then the media provider MUST send the
captureID of the current constituent MC in the RTP header and as a RTCP SDES
message. When the media provider switches the MC it sends within an MCC, it
MUST send the captureID value for the MC just switched into the MCC.

If there are more than one MC composed into the MCC then the media provider
MUST NOT send any of the MCs' captureIDs using this mechanism.

If the media provider sends the captureID of a single MC switched into an
MCC, then later sends a composed stream of multiple MCs in the same MCC, it
MUST send the special value "-", a single dash character, as the captureID
RTP header and SDES message. The single dash character indicates there is no
applicable value for the MCC constituent CaptureID. The media consumer
interprets this as meaning any previous captureID value in this RTP header
no longer applies. The single dash character is not a legal captureID value,
so there is no possibility of confusing it with an actual captureID.

=================== end proposed change =====================

Mark

---

From: Christian Groves <[email-masked]>
Date: Fri, 7 Oct 2016 15:41:29 +1100

Sounds OK.

Regards, Christian

On 6/10/2016 11:38 AM, Duckworth, Mark wrote:
>
> Thanks Jonathan for the suggestion and clarifications. Here is my 
> updated proposal for new text for section 5. This proposed text would 
> replace the existing text in the section.
>
> For a MCC which can represent multiple switched MCs there is a need to 
> know which MC is represented in the current RTP stream at any given 
> time. This requires a mapping from the MCC RTP stream to the 
> constituent MC. In order to address this mapping this document defines 
> an RTP header extension and SDES item that includes the captureID of 
> the original MC, allowing the consumer to use the original source MC’s 
> attributes like the spatial information.
>
> This mapping temporarily associates the SSRC of the MCC stream with 
> the captureID of the single original MC that is currently switched 
> into the MCC. This mapping cannot be used for the composed case where 
> more than one original MC is composed into the MCC simultaneously.
>
> If there is only one MC in the MCC then the media provider MUST send 
> the captureID of the current constituent MC in the RTP header and as a 
> RTCP SDES message. When the media provider switches the MC it sends 
> within an MCC, it MUST send the captureID value for the MC just 
> switched into the MCC.
>
> If there are more than one MC composed into the MCC then the media 
> provider MUST NOT send any of the MCs’ captureIDs using this mechanism.
>
> If the media provider sends the captureID of a single MC switched into 
> an MCC, then later sends a composed stream of multiple MCs in the same 
> MCC, it MUST send the special value “-“, a single dash character, as 
> the captureID RTP header and SDES message. The single dash character 
> indicates there is no applicable value for the MCC constituent 
> CaptureID. The media consumer interprets this as meaning any previous 
> captureID value in this RTP header no longer applies. The single dash 
> character is not a legal captureID value, so there is no possibility 
> of confusing it with an actual captureID.
>
> _______________________________________________
> clue mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/clue

---

From: "Roni Even" <[email-masked]>
Date: Thu, 20 Oct 2016 20:31:24 +0300

Hi,

I will update the document with this text

Thanks

Roni

From: clue [mailto:[email-masked]] On Behalf Of Duckworth, Mark
Sent: Thursday, October 06, 2016 3:38 AM
To: Jonathan Lennox; [email-masked]'
Subject: [clue] Updated clarification for rtp-mapping ClientID

Mark