Re: [MMUSIC] Offer/Answer PT Questions

[Christer Holmberg <[e-mail]>]

Hi Colin,

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

Q1: Then my next question is: when is the BINDING created? Is a binding created once a user has indicated (in an offer or answer) a PT/codec mapping - no matter if the other endpoint will use the same codec to begin with, or PT value for that codec?

Example #1:
----------------

Alice offers:

PT 100: (AMR-WB)
PT 111: (VP8)

Bob answers:

PT 111: (VP8)

Q2: Now, eventhough did not indicate support of AMR-WR, the BINDING between PT 100 and AMR-WR has still been created, and neither Alice or Bob is allowed to re-use PT 100 for anything else within the session?


Example #2:
----------------

Alice offers:

PT 100: (AMR-WB)

Bob answers:

PT 111: (AMR-WB)


Q3: Now, two bindings have been created: one binding between PT 100 and AMR-WB, and one binding between PT 111 and AMR-WB. After this, neither Alice or Bob is allowed to re-use PT 100 or PT 111 for anything else within the session?

Q4: HOWEVER, even if Bob indicated PT 111 and AMR-WB, I assume Bob would still be allowed to indicate PT 100 and AMR-WB, as it does not conflict with the existing binding?


Regards,

Christer






Regards,

Christer