Re: [MMUSIC] Offer/Answer PT Questions

[Colin Perkins <[e-mail]>]

> On 23 Feb 2016, at 18:04, Christer Holmberg <[e-mail]> wrote:
> 
> Hi,
> 
>>> No objection in principle, but it’s not as simple as “a few network RTTs”:
>>> 
>>> No ambiguity in decoding means that the packets need to have been 
>>> played out, so the codec state for that PT can be discarded. Some 
>>> systems can have large (multi-second) playout buffers.
>>> 
>>> Any packets referring to the old PT also need to be gone. Formats like 
>>> RFC 6354 allow large offsets between streams, referenced by PT (the 
>>> example in Section 5 has a 5.1 second offset).
>> 
>> Thanks for the insight. It helps to ground the discussion.
>> 
>> I'm also interested in hearing if there might be *other* reasons behind the rules as they are written.
>> 
>> The advantage of the current rule is that it is easy to explain, and is sufficient to deal with the problem you describe 
>> above. Unfortunately it is also difficult/impossible to comply with in some cases. If we are to replace it, we need to find 
>> something else to replace it with.
> 
> The current rule may be easy to understand, but it's difficult to understand - and that's what triggered this discussion :)
> 
> So, while we can discuss possible rules/guidelines on when a PT value can be used, I still think we need to answer the first question:
> 
> - If Alice allocates PT=X for codec 1, is Bob allowed to allocate PT=X for codec 2 within the same session? The current text is unclear on that, and I think that is the first question we need to sort out.

RFC 3551 (the RTP/AVP profile), section 3, top of page 7, 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.


I always interpreted that as RTP payload types being per RTP session, not per SSRC. That may, or may not, be consistent with the SDP specifications.

Colin



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