Re: [MMUSIC] Query: payload type collision with offer/answer

[Harald Alvestrand <[e-mail]>]

On 01/10/2013 07:50 PM, Paul Kyzivat wrote:
>
>> Well there's also section 8.3.2 in 3264. The section is about updating
>> offers but it seems like the text explicitly prohibits remapping payload
>> types in any scenarios:
>>
>>     However, in the
>>     case of RTP, the mapping from a particular dynamic payload type
>>     number to a particular codec within that media stream MUST NOT 
>> change
>>     for the duration of a session.  For example, if A generates an offer
>>     with G.711 assigned to dynamic payload type number 46, payload type
>>     number 46 MUST refer to G.711 from that point forward in any offers
>>     or answers for that media stream within the session. However, it is
>>     acceptable for multiple payload type numbers to be mapped to the 
>> same
>>     codec, so that an updated offer could also use payload type 
>> number 72
>>     for G.711.
>
> The language above is underspecified.
>
> It is my impression that the intent of this language was to ensure 
> there is no ambiguity in the meaning of a payload type. Since the 
> exchange of the SDP is not synchronized with the flow of RTP, if you 
> were to send a new SDP that changed the mapping for a payload type, 
> then the result would be almost certainly to interpret some media 
> packets according to the wrong mapping.
>
> But this argument is only about packets flowing in one direction. It 
> isn't a valid argument for requiring the payload types to be 
> consistent in the two directions. And its not clear to me that it even 
> intended that this language apply to both directions. It could be 
> clarified as follows:
>
>                               ...  For example, if A generates an offer
>    with G.711 assigned to dynamic payload type number 46, payload type
>    number 46 MUST refer to G.711 from that point forward in any offers
>    or answers ***by A*** for that media stream within the session.  ...
>
> Interpreting it to apply to both directions brings it in conflict with 
> the language elsewhere that permits it to be different in the two 
> directions.
More than one number for one codec is explicitly permitted.
More than one codec for one number in a single direction is clearly 
impossible.
More than one codec for one number in a single RTP session..... that's 
the question.

If one were to go with textual analysis, this would hinge on the meaning 
of "for that media stream" - which again hinges on whether a media 
stream is unidirectional or bidirectional.

RFC 3264's definition:

       Media Stream: From RTSP [8], a media stream is a single media
          instance, e.g., an audio stream or a video stream as well as a
          single whiteboard or shared application group.  In SDP, a media
          stream is described by an "m=" line and its associated
          attributes.

which points back to RFC 2326:

    (Media) stream:
           A single media instance, e.g., an audio stream or a video
           stream as well as a single whiteboard or shared application
           group. When using RTP, a stream consists of all RTP and RTCP
           packets created by a source within an RTP session. This is
           equivalent to the definition of a DSM-CC stream([5]).

So if we believe these definitions, there's no prohibition on reusing 
the payload type.
Definitely nice to clarify in a 3264bis.

>
> The use of different mappings in each direction has been discussed 
> over the years, though I couldn't point you to where. IIRC one of the 
> reasons had to do with gatewaying to other protocols. But I can't 
> offer any details.
>
> Bottom line: IMO, in the weird case Harald described X ought to follow 
> Postel's Law and accept the answer from Y. But for the same reason I 
> would strongly discourage implementations from acting as Y did.
>
Seems like a conclusion.