Subject: [clue] Clarifications for rtp-mapping ClientID, and questions

From: "Duckworth, Mark" <[email-masked]>
Date: Mon, 3 Oct 2016 20:27:36 +0000

I have a proposed change to section 5, to replace the single paragraph with
the following:

=================== 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.

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 <need to fill this in with something that says the previous single MC
is no longer there>.

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

I think this new text is just clarifying the intent of the rtp-mapping-08
version.

I left the placeholder text in the last sentence because I don't know what
we should do for this case. As a more concrete example, suppose the media
provider advertises it can send an MCC with between 1 and 4 MCs in it at any
given time. And suppose it advertises MC1, MC2, MC3, MC4, MC5, etc. Then
when it sends just MC1 in the MCC, it uses this header extension to
associate MC1 with the MC. Then later it decides to send a composed image of
MC1, MC2, MC4, and MC5. Now what? The consumer wants to know that MC1 is no
longer the only MC in the MCC. But there is no way for the provider to say
it is sending MC1, MC2, MC4, and MC5. Could there be some reserved value in
the RTP Header extension to mean "no CaptureID is indicated"?

CaptureID format - It looks like this document allows for a 2 byte capture
ID to put in the RTP header and the SDES item. But the CLUE data model says
a captureID is of type "xs:ID" which is really a text string. There seems to
be a mismatch here. Am I missing something?

Mark

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 3 Oct 2016 17:24:46 -0400

After reading this I have a question:

Suppose the media provider is switching an MCC from content that 
includes single source media capture to a composition of multiple 
captures, then what (if anything) does it send as a capttureID? If it 
doesn't send anything, then won't the recipient think it is still 
receiving the prior single MC?

	Thanks,
	Paul

On 10/3/16 4:27 PM, Duckworth, Mark wrote:
> I have a proposed change to section 5, to replace the single paragraph
> with the following:
>
>
>
> 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.
>
>
>
> 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.
>
>
>
> 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 <need to fill this in with something that says the previous
> single MC is no longer there>.
>
> I think this new text is just clarifying the intent of the
> rtp-mapping-08 version.
>
>
>
> I left the placeholder text in the last sentence because I don’t know
> what we should do for this case. As a more concrete example, suppose the
> media provider advertises it can send an MCC with between 1 and 4 MCs in
> it at any given time. And suppose it advertises MC1, MC2, MC3, MC4, MC5,
> etc. Then when it sends just MC1 in the MCC, it uses this header
> extension to associate MC1 with the MC. Then later it decides to send a
> composed image of MC1, MC2, MC4, and MC5. Now what? The consumer wants
> to know that MC1 is no longer the only MC in the MCC. But there is no
> way for the provider to say it is sending MC1, MC2, MC4, and MC5. Could
> there be some reserved value in the RTP Header extension to mean “no
> CaptureID is indicated”?
>
>
>
> CaptureID format – It looks like this document allows for a 2 byte
> capture ID to put in the RTP header and the SDES item. But the CLUE data
> model says a captureID is of type “xs:ID” which is really a text string.
> There seems to be a mismatch here. Am I missing something?
>
>
>
> Mark
>
>
>
>
>
>
>
> _______________________________________________
> clue mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/clue
>

---

From: "Duckworth, Mark" <[email-masked]>
Date: Mon, 3 Oct 2016 23:15:55 +0000

Hi Paul,
That is exactly the question I was asking. Maybe my wording wasn't clear,
but that is the question to answer in order to fill in the placeholder text
in the brackets "< need to fill this in with something that says the
previous single MC is no longer there >" below.

I was hoping Jonathan or Roni would have an idea.

Mark

> -----Original Message-----
> From: clue [mailto:[email-masked]] On Behalf Of Paul Kyzivat
> Sent: Monday, October 03, 2016 5:25 PM
> To: [email-masked]
> Subject: Re: [clue] Clarifications for rtp-mapping ClientID, and questions
> 
> > allowing the consumer to use the original source MC's attributes like
> > the spatial information.
> >
> >
> >
> > provider MUST NOT send any of the MCs' captureIDs using this
> mechanism.
> >
> >
> >
> > I left the placeholder text in the last sentence because I don't know
> > there be some reserved value in the RTP Header extension to mean "no
> > CaptureID is indicated"?
> >
> >
> >
> > CaptureID format - It looks like this document allows for a 2 byte
> > model says a captureID is of type "xs:ID" which is really a text string.

---

From: Jonathan Lennox <[email-masked]>
Date: Tue, 4 Oct 2016 15:43:06 +0000

> On Oct 3, 2016, at 7:15 PM, Duckworth, Mark <[email-masked]> wrote:
> 
> Hi Paul,

Hm, yes, this is a good point.

A zero-length SDES item is syntactically valid in RFC 3550, as far as I can tell.  I’ll ask on the AVTCore list what people think of using that to mean “no applicable value for this SDES item.”

---

From: Jonathan Lennox <[email-masked]>
Date: Tue, 4 Oct 2016 15:49:33 +0000

> On Oct 4, 2016, at 11:43 AM, Jonathan Lennox <[email-masked]> wrote:
> 
> 

Hm, on a slight amount of further reflection, while that could potentially work for SDES items and for the two-byte form of header extensions, it won't for the one-byte form (which doesn’t allow zero-length values).  I suspect one-byte header extensions will be the preferred form, so that’s a bad outcome.

Maybe we need to reserve a special value for CaptureID, perhaps “-”, to mean “no applicable value”.  Any problems with reserving that value?

---

From: "Duckworth, Mark" <[email-masked]>
Date: Tue, 4 Oct 2016 15:53:33 +0000

Mark

> From: Jonathan Lennox [mailto:[email-masked]]
> Sent: Tuesday, October 04, 2016 11:50 AM
> To: Duckworth, Mark <[email-masked]>
> Cc: Paul Kyzivat <[email-masked]>; [email-masked]
> > A zero-length SDES item is syntactically valid in RFC 3550, as far as I can tell.
> I’ll ask on the AVTCore list what people think of using that to mean “no
> applicable value for this SDES item.”
> 
> Hm, on a slight amount of further reflection, while that could potentially
> work for SDES items and for the two-byte form of header extensions, it
> won't for the one-byte form (which doesn’t allow zero-length values).  I
> suspect one-byte header extensions will be the preferred form, so that’s a
> bad outcome.
> 
> Maybe we need to reserve a special value for CaptureID, perhaps “-”, to
> mean “no applicable value”.  Any problems with reserving that value?
> 
> >> Mark
> >>
> >>>> 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.
> >>>>
> >>>>
> >>>>
> >>>> composed image of MC1, MC2, MC4, and MC5. Now what? The
> consumer
> >>> wants

---

From: Jonathan Lennox <[email-masked]>
Date: Tue, 4 Oct 2016 16:06:30 +0000

> On Oct 4, 2016, at 11:53 AM, Duckworth, Mark <[email-masked]> wrote:
> 

No, SDES items are a text string.

RTP header extensions have two syntactic forms, often referred to as the “one-byte form” (four bits type and four bits length), and the “two-byte form” (eight bits type and eight bits length).  The one-byte form can encode items 1 through 16 bytes long; the two-byte form 0 through 255.

I think the document’s use of the two-byte form is just meant to be illustrative, but on reflection it’s confusing, and there’s no reason you couldn’t use the one-byte form as well for short CaptureID values.  (We also should be referencing RFC 7941.)  That’s something to be fixed in the next revision.

Since CaptureID is indeed xs:ID, that’s good — it means that the single dash isn’t a valid capture ID, so it will indeed be a good “no applicable value” semantic.

---

From: "Duckworth, Mark" <[email-masked]>
Date: Tue, 4 Oct 2016 16:53:17 +0000

Thanks, I _was_ missing something! Now it makes sense.
I will send another email with my updated proposed text for section 5. I agree the value "-" should work meaning "no applicable value".

Jonathan, will you update sections 5.1 and 5.2? The formatting of the grids showing the bytes looks off in a few ways - top row of bit numbering is not aligned, vertical separate bars not aligned, Len-1 should be Length, I think.

Mark

> Sent: Tuesday, October 04, 2016 12:07 PM
> RTP header extensions have two syntactic forms, often referred to as the
> “one-byte form” (four bits type and four bits length), and the “two-byte
> form” (eight bits type and eight bits length).  The one-byte form can encode
> items 1 through 16 bytes long; the two-byte form 0 through 255.
> 
> I think the document’s use of the two-byte form is just meant to be
> illustrative, but on reflection it’s confusing, and there’s no reason you
> couldn’t use the one-byte form as well for short CaptureID values.  (We also
> should be referencing RFC 7941.)  That’s something to be fixed in the next
> revision.
> 
> Since CaptureID is indeed xs:ID, that’s good — it means that the single dash
> isn’t a valid capture ID, so it will indeed be a good “no applicable value”
> semantic.
> 
> >
> > Mark
> >
> >>>>>> For a MCC which can represent multiple switched MCs there is a
> need
> >> to
> >>>>>> This mapping temporarily associates the SSRC of the MCC stream
> with
> >> the
> >>>>>> MCC. This mapping cannot be used for the composed case where
> more
> >>>>> than
> >>>>>> If there is only one MC in the MCC then the media provider MUST
> send
> >> the
> >>>>>> what we should do for this case. As a more concrete example,
> suppose
> >> the