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

On 11.01.13, 14:01, Christer Holmberg wrote:
> Hi,
> 
> My understanding of the section 8.3.2 is that the mapping must not change PER DIRECTION, and the text "in any offers or answers" refers to a particular participant.

I wasn't around then so it could very well be that this was the
intention. Currently however there's nothing in the text that directly
supports this and it could be argued that it actually says the exact
opposite thing. Or in other words: the payload type number cannot be
remapped in "any offers and answers for that media stream in that session".

If we want it to meant just "A's offers and answers" then it should be
updated to say that.

Emil

> Regards,
> 
> Christer
> 
> 
> -----Original Message-----
> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of Harald Alvestrand
> Sent: 11. tammikuuta 2013 14:47
> To: mmusic@ietf.org
> Subject: Re: [MMUSIC] Query: payload type collision with offer/answer
> 
> 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.
> 
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
> 

-- 
https://jitsi.org