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

[Emil Ivov <[e-mail]>]

+1

Emil

On Mon, Jun 24, 2013 at 7:10 PM, Mary Barnes <[e-mail]> wrote:
> I too agree with Q1 and Q2.
>
> Mary.
>
> On Mon, Jun 24, 2013 at 5:40 AM, Christer Holmberg
> <[e-mail]> 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: [e-mail] [mailto:[e-mail]] On Behalf Of Paul Kyzivat
>> Sent: 20. kesäkuuta 2013 17:33
>> To: [e-mail]
>> 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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/mmusic
>> _______________________________________________
>> mmusic mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/mmusic
> _______________________________________________
> mmusic mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmusic



-- 
Emil Ivov, Ph.D.                       67000 Strasbourg,
Project Lead                           France
Jitsi
[e-mail]                        PHONE: [phone]
https://jitsi.org                       FAX:   [phone]