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

I too agree with Q1 and Q2.

Mary.

On Mon, Jun 24, 2013 at 5:40 AM, Christer Holmberg
<christer.holmberg@ericsson.com> wrote:
>
> 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: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of Paul Kyzivat
> Sent: 20. kesäkuuta 2013 17:33
> To: mmusic@ietf.org
> 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
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic