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

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.

I agree the text could be more clear.

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