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

[Paul Kyzivat <[e-mail]>]

Colin,

Thanks for the clarifications. My knowledge of RTP is scant. (I'm 
gradually learning through osmosis.)

More inline.

On 2/26/16 4:39 AM, Colin Perkins wrote:
>> 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.

OK. I thought that would be the answer, but was just checking.

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

OK. That helps clarify what needs to be done.

So it means that we have to say that the appearance of a PT in an offer 
or answer binds it to the corresponding codec configuration for the 
duration of the RTP session. An answerer can still choose to use a 
different PT for the same codec configuration. But he can't use a PT 
that has already been bound.

Can we require a sender to honor the preference of the recipient in this 
regard? (For two-participant sessions - the kind we are usually setting 
up with O/A.)

But an important point to this is that this binding is scoped by the RTP 
session, not the SIP (or O/A) session. So when the RTP session changes 
(because the addr/port changes at one of the ends) then old bindings no 
longer need to be preserved.

And *that* solves the 3pcc problem, since in the 3pcc cases that matter 
the RTP session will change.

As a side question, how do the predefined PTs fit into this? My guess is 
that the predefined PTs are *not* implicitly bound. They still must be 
bound by appearing in an offer or answer. And then they are only bound 
to their default codec configuration if there is no explicit rtpmap for 
the PT.

ISTM this is starting to be clarified. But I think it is going to take 
quite a bit of careful writing to properly specify this.

	Thanks,
	Paul

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