Subject: [MMUSIC] DECISION: Unique PT value/codec configuration mapping in a BUNDLE group [WAS: BUNDLE TEXT: De-mux procedures (June 19th)]

From: Christer Holmberg <[email-masked]>
Date: Mon, 24 Jun 2013 10:40:58 +0000

Hi,

Based on the input and discussion, let's see if we can make a couple of decisions :)

Q1: Can we agree that, within a BUNDLE group (including all m- lines associated with the group), any given PT value can only be used for a single codec configuration?

NOTE: If you think we need some clarification text on what "codec configuration" means, or if you think we should use some other wording - feel free to suggest :)

Q2: If we agree on Q1, do we agree that we need EXPLICIT text in BUNDLE, as there are opinions that simply referencing RFC 3550 might not be clear enough?

Regards,

Christer

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Paul Kyzivat
Sent: 20. kesäkuuta 2013 17:33
To: [email-masked]
Subject: Re: [MMUSIC] BUNDLE TEXT: De-mux procedures (June 19th)

On 6/20/13 8:37 AM, Colin Perkins wrote:
> On 20 Jun 2013, at 05:53, Christer Holmberg wrote:
>>>> Using 96 for both Opus and VP8 is flat out illegal according to the RTP specs.
>>>
>>> Agree.
>>
>> So, we DO agree that the usage of the *same* PT value (even if in different m= lines) for different codecs, or different codec configurations, is not allowed.
>>
>> Is there some specific section in some specific RFC that can be referenced to show that?
>
> RFC 3550 Sections 1, 5.1, 12, and 13 make it clear that the mapping is defined per RTP profile (i.e., for RTP/AVP and profiles derived from it). The BUNDLE defines a single RTP session, which operates under a single RTP profile, so must have a single mapping from Payload Type to Payload Formats. RFC 3551 section 3 says:
>
>     ...
>     mechanisms for defining dynamic payload type bindings have been
>     specified in the Session Description Protocol (SDP) and in other
>     protocols such as ITU-T Recommendation H.323/H.245.  These mechanisms
>     associate the registered name of the encoding/payload format, along
>     with any additional required parameters, such as the RTP timestamp
>     clock rate and number of channels, with a payload type number.  This
>     association is effective only for the duration of the RTP session in
>     which the dynamic payload type binding is made.  This association
>     applies only to the RTP session for which it is made, thus the
>     numbers can be re-used for different encodings in different sessions
>     so the number space limitation is avoided.
>
> You'll note that the association is per RTP session, not per SSRC or other subset of the session.

I'm not inclined to argue the details of RTP with an RTP expert!
But just wearing my standards-lawyer hat I read all of the above references, and could not find anything that clearly justified the assertions you make. I read them as clearly stating that the *static* ones are defined for a profile. I guess the key part of the quote above
is: "This association is effective only for the duration of the RTP session". That seems to *bound* the scope of the association, but doesn't explicitly state that it must be unique within that scope.

But maybe that is just a matter of me not reading it right, or of the text not having captured every nuance of the intent.

> If you're looking for a statement that two m= lines in an SDP can't map the same PT value to different things, you're unlikely to find it, since pre-BUNDLE those two m= lines would refer to different RTP sessions, so it would be legal to reuse PT values across m= lines. It's because BUNDLE makes a single RTP session out of several m= lines that you need unique PT mapping across all the m= lines.

Of course. So I think that means its important for bundle to clearly state the requirement, if it is to be a real one.

	Thanks,
	Paul

> Colin
>
>
>>>> The corner case where we're discussing whether one can use the same 
>>>> payload type is if you have two M-lines that both specify VP8, with the same codec parameters - whether they can both use 96, given that it's the same codec.
>>>
>>> Surely yes, but you lose the ability to distinguish the m= line 
>>> based on the PT if you use the same PT (mapped to the exact same 
>>> codec and set of codec parameters) in several m= lines. Some applications care about distinguishing m= lines based on PT values, and so need distinct PT values for every m= line; others don't care, and can use the same PT to represent the same codec across multiple m= lines.
>>
>> Exactly. So, I think it's a good idea to have some text about that in BUNDLE.
>>
>> Regards,
>>
>> Christer
>>
>
>
>

_______________________________________________
mmusic mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mmusic

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 24 Jun 2013 10:45:48 +0000

Hi,

Regarding Q2, as Bernard suggested to specify it in draft-ietf-avtcore-multiplex-guidelines, please replace the question with:

Q2: If we agree on Q1, do we agree that we need EXPLICIT text SOMEWHERE, as there are opinions that simply referencing RFC 3550 might not be clear enough?

Regards,

Christer

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Christer Holmberg
Sent: 24. kesäkuuta 2013 13:41
To: Paul Kyzivat; [email-masked]
Subject: [MMUSIC] DECISION: Unique PT value/codec configuration mapping in a BUNDLE group [WAS: BUNDLE TEXT: De-mux procedures (June 19th)]

Hi,

Regards,

Christer

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Paul Kyzivat
Sent: 20. kesäkuuta 2013 17:33
To: [email-masked]
Subject: Re: [MMUSIC] BUNDLE TEXT: De-mux procedures (June 19th)

	Thanks,
	Paul

---

From: Colin Perkins <[email-masked]>
Date: Mon, 24 Jun 2013 12:46:09 +0100

Christer,

For Q1 - I agree. 

For Q2 - I agree that we need explicit text somewhere. 

We might also add an explicit statement that it's okay to use the same PT for the exact same codec confirmation in multiple m= lines, _provided_ you don't want to use the PT values to associate packets with m= lines.

Colin

...

-- 
Colin Perkins
http://csperkins.org/

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 24 Jun 2013 11:55:57 +0000

Hi,

> We might also add an explicit statement that it's okay to use the same PT for the exact same codec confirmation in multiple m= lines, _provided_ you don't want to use the PT values to associate pac…

I left that question out on purpose, because I intend to ask it separately :)

Regards,

Christer

...

-- 
Colin Perkins
http://csperkins.org/

---

From: Colin Perkins <[email-masked]>
Date: Mon, 24 Jun 2013 13:01:38 +0100

> I left that question out on purpose, because I intend to ask it separately :)

In that case, I agree with Q1 and Q2 :-)

-- 
Colin Perkins
http://csperkins.org/

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 24 Jun 2013 11:41:05 -0400

I'll support both Q1 and Q2.

	Thanks,
	Paul

---

From: Mary Barnes <[email-masked]>
Date: Mon, 24 Jun 2013 12:10:32 -0500

I too agree with Q1 and Q2.

Mary.

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 24 Jun 2013 10:11:23 -0700

I agree with this - support both Q1 and the (reformulated) Q2.  
 
> Date: Mon, 24 Jun 2013 11:41:05 -0400
> From: [email-masked]
> To: [email-masked]
> CC: [email-masked]; [email-masked]
> Subject: Re: [MMUSIC] DECISION: Unique PT value/codec configuration mapping in a BUNDLE group [WAS: BUNDLE TEXT: De-mux procedures (June 19th)]
>

---

From: Emil Ivov <[email-masked]>
Date: Mon, 24 Jun 2013 19:11:10 +0200

+1

Emil

-- 
Emil Ivov, Ph.D.                       67000 Strasbourg,
Project Lead                           France
Jitsi
[email-masked]                        PHONE: +33.1.77.62.43.30
https://jitsi.org                       FAX:   +33.1.77.62.47.31

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 24 Jun 2013 18:43:07 +0000

Hi Bernard,

If I understood you correctly, your suggestion was to document the rule in draft-ietf-avtcore-multiplex-guidelines.

As the authors of that draft are most likely reading this, it would be nice to get their input. Formally, of course, the work would have to be done in AVTCORE.

Regards,

Christer

Lähettäjä: Bernard Aboba [mailto:[email-masked]]
Lähetetty: 24. kesäkuuta 2013 20:11
Vastaanottaja: Paul Kyzivat; Colin Perkins
Kopio: [email-masked]; Christer Holmberg
Aihe: RE: [MMUSIC] DECISION: Unique PT value/codec configuration mapping in a BUNDLE group [WAS: BUNDLE TEXT: De-mux procedures (June 19th)]

> From: [email-masked]<mailto:[email-masked]>
> To: [email-masked]<mailto:[email-masked]>
> CC: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>

---

From: Harald Alvestrand <[email-masked]>
Date: Tue, 25 Jun 2013 13:37:29 +0200

> Q1: Can we agree that, within a BUNDLE group (including all m- lines associated with the group), any given PT value can only be used for a single codec configuration?

Yes, I agree with Q1.

> NOTE: If you think we need some clarification text on what "codec configuration" means, or if you think we should use some other wording - feel free to suggest :)

I believe "codec configuration" should be defined as the content of the 
a=rtpmap and a=fmtp lines, since those are the lines that are defined in 
payload registrations.
I think it's uncontroversial to declare those two items as part of codec 
configuration. It's far less clear that there are other uncontroversial 
items.

> Q2: If we agree on Q1, do we agree that we need EXPLICIT text in BUNDLE, as there are opinions that simply referencing RFC 3550 might not be clear enough?

Explicit text is better. If it is informative explicit text that points 
to normative explicit text elsewhere, that's fine too - but some text 
should be in BUNDLE, and be explicit.

---

From: "Hutton, Andrew" <[email-masked]>
Date: Tue, 25 Jun 2013 12:45:22 +0000

+1

Andy

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Emil Ivov
> Sent: 24 June 2013 18:11
> To: Mary Barnes
> Cc: [email-masked]; Paul Kyzivat; Christer Holmberg
> Subject: Re: [MMUSIC] DECISION: Unique PT value/codec configuration
> mapping in a BUNDLE group [WAS: BUNDLE TEXT: De-mux procedures (June
> 19th)]
> 
> +1
> 
> Emil
> 
> >> Q1: Can we agree that, within a BUNDLE group (including all m- lines
> associated with the group), any given PT value can only be used for a
> single codec configuration?
> >>
> >> NOTE: If you think we need some clarification text on what "codec
> configuration" means, or if you think we should use some other wording
> - feel free to suggest :)
> >>
> >>
> >>
> >> Q2: If we agree on Q1, do we agree that we need EXPLICIT text in
> BUNDLE, as there are opinions that simply referencing RFC 3550 might
> not be clear enough?
> >>
> >>
> >> Regards,
> >>
> >> Christer
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>>> So, we DO agree that the usage of the *same* PT value (even if in
> different m= lines) for different codecs, or different codec
> configurations, is not allowed.
> >>>>
> >>> RFC 3550 Sections 1, 5.1, 12, and 13 make it clear that the mapping
> is defined per RTP profile (i.e., for RTP/AVP and profiles derived from
> it). The BUNDLE defines a single RTP session, which operates under a
> single RTP profile, so must have a single mapping from Payload Type to
> Payload Formats. RFC 3551 section 3 says:
> >>>
> >>>     ...
> >> But just wearing my standards-lawyer hat I read all of the above
> references, and could not find anything that clearly justified the
> assertions you make. I read them as clearly stating that the *static*
> ones are defined for a profile. I guess the key part of the quote above
> >> is: "This association is effective only for the duration of the RTP
> session". That seems to *bound* the scope of the association, but
> doesn't explicitly state that it must be unique within that scope.
> >>
> >> But maybe that is just a matter of me not reading it right, or of
> the text not having captured every nuance of the intent.
> >>
> >>> If you're looking for a statement that two m= lines in an SDP can't
> map the same PT value to different things, you're unlikely to find it,
> since pre-BUNDLE those two m= lines would refer to different RTP
> sessions, so it would be legal to reuse PT values across m= lines. It's
> because BUNDLE makes a single RTP session out of several m= lines that
> you need unique PT mapping across all the m= lines.
> >>
> >> Of course. So I think that means its important for bundle to clearly
> state the requirement, if it is to be a real one.
> >>
> >>         Thanks,
> >>         Paul
> >>
> >>> Colin
> >>>
> >>>
> >>>>>> payload type is if you have two M-lines that both specify VP8,
> with the same codec parameters - whether they can both use 96, given
> that it's the same codec.
> >>>>>
> >>>>> codec and set of codec parameters) in several m= lines. Some
> applications care about distinguishing m= lines based on PT values, and
> so need distinct PT values for every m= line; others don't care, and
> can use the same PT to represent the same codec across multiple m=
> lines.
> >>>>

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 25 Jun 2013 10:20:31 -0700

Yes.