Re: [MMUSIC] Offer/Answer PT Questions - text proposal

[Colin Perkins <[e-mail]>]

> On 25 Feb 2016, at 23:53, Paul Kyzivat <[e-mail]> wrote:
> 
> On 2/25/16 6:19 PM, Colin Perkins wrote:
>> Hi,
>> 
>>> On 25 Feb 2016, at 14:17, Christer Holmberg <[e-mail]> wrote:
>>> 
>>> Hi,
>>> 
>>> I put together some text:
>>> 
>>> "The scope of a mapping from a particular dynamic payload type number to a codec
>>> (or codec configuration) is for a given RTP media flow direction within a session.
>> 
>> I think this conflicts with various RTP-related RFCs and drafts, although whether this conflict causes practical problems is unclear. RFC 3551 indicates that the binding between RTP payload type and RTP payload format is per RTP session, not per sender within an RTP session:
>> 
>>    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.
>> 
>> (note: reuse in different sessions, not different participants within a session) and:
> 
> Does a sendrecv m-line established via O/A create one or two RTP sessions?

One, since RTP sessions are defined by shared SSRC space, not directionality of media.

> If one, then it seems this conflicts with 3264 allowing the two ends to use different PTs for the same codec configuration.

That depends exactly what 3264 allows: if the two ends use different payload types to refer to the same codec, that’s okay; but if the two ends use the same payload type to refer to different codecs, that problematic.

> It always seemed to me that the original intent was to require the same PT number on both ends (perhaps because of what you quote), and that allowing the two ends to be different was an afterthought. If so, it may be that rfc3551 should have been updated.
> 
> Is there any *technical* difficulty when the two ends use different PTs? (E.g. does it screw up rtcp reports?)

Using different payload types to refer to the same codec is wasteful, but not harmful.

Allowing different senders to use the same payload type to refer to different codecs is problematic. It makes the payload type to codec mapping depend on the SSRC, but SSRCs can change without signalling. 

> We are starting to get to the meat of the issue. The question is: what needs to be fixed?
> 
> 	Thanks,
> 	Paul
> 
> _______________________________________________
> mmusic mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmusic



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