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

[Colin Perkins <[e-mail]>]

> On 26 Feb 2016, at 15:53, Paul Kyzivat <[e-mail]> wrote:
> 
> 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.

Yes.

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

That’s one for the signalling to decide.

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

Perhaps, but remember that an RTP session is defined by a shared SSRC space, not by the addresses or ports used, so it depends how 3PCC moves the addresses. 

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

The use is defined by the signalled RTP profile. If an RTP/AVP-derived profile is used, the text in RFC 3551 applies:

   This profile reserves payload type numbers in the range 96-127
   exclusively for dynamic assignment.  Applications SHOULD first use
   values in this range for dynamic payload types.  Those applications
   which need to define more than 32 dynamic payload types MAY bind
   codes below 96, in which case it is RECOMMENDED that unassigned
   payload type numbers be used first.  However, the statically assigned
   payload types are default bindings and MAY be dynamically bound to
   new encodings if needed.  Redefining payload types below 96 may cause
   incorrect operation if an attempt is made to join a session without
   obtaining session description information that defines the dynamic
   payload types.

i.e., the fact that the m= line says RTP/AVP implies that the default static payload type mappings are valid, unless over-ridden by an a=rtpmap: line.

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

Right.

Cheers,
Colin




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