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

Please see inline.

> -----Original Message-----
> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On
> Behalf Of Emil Ivov
> Sent: Wednesday, January 09, 2013 3:46 PM
> To: Harald Alvestrand
> Cc: mmusic@ietf.org
> Subject: Re: [MMUSIC] Query: payload type collision with offer/answer
> 
> 
> 
> On 09.01.13, 23:52, Harald Alvestrand wrote:
> > On 01/09/2013 10:01 PM, Charles Eckel (eckelcu) wrote:
> >> Please see inline.
> >>
> >>> -----Original Message-----
> >>> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On
> >>> Behalf Of Harald Alvestrand
> >>> Sent: Wednesday, January 09, 2013 11:25 AM
> >>> To: mmusic@ietf.org
> >>> Subject: [MMUSIC] Query: payload type collision with offer/answer
> >>>
> >>> Hello,
> >>> I have encountered an issue, and I'm not sure it's an issue or not. SDP
> >>> wisdom is sought.
> >>>
> >>> Suppose two entities exchange the following offer/answer:
> >>>
> >>> offer from X:
> >>>
> >>> m=video 97
> >>> a=rtpmap:97 foo
> >>>
> >>> answer from Y:
> >>>
> >>> m=video 98
> >>> a=rtpmap:98 foo
> >>>
> >>> It's clear from RFC 3264 that now X must send codec foo with payload
> >>> type 98, and Y must send codec foo with payload type 97. That's not the
> >>> question.
> >>>
> >>> But suppose these are the offer and answer:
> >>>
> >>> offer from X:
> >>>
> >>> m=video 97 98
> >>> a=rtpmap:97 foo
> >>> a=rtpmap:98 bar
> >>>
> >>> answer from Y:
> >>>
> >>> m=video 97 98
> >>> a=rtpmap:97 bar
> >>> a=rtpmap:98 foo
> >>>
> >>> That is, the payload types collide.
> >>>
> >>> It would be possible to write code so that X sends foo with 98 and bar
> >>> with 97, while Y sends foo with 97 and bar with 98. But is it
> >> conformant
> >>> with the specs to do so?
> >>>
> >>> And if this has a clear answer - which paragraph of which RFC makes
> >> this
> >>> clear?
> >>> (Yes, this discussion is triggered from a real world problem.)
> >>
> >> It is recommended to avoid such mismatches when possible, but doing so
> >> may not always be possible. The examples you mention are conformant.
> >> The following text from section 5.1 addresses this:
> >>
> >> For sendrecv RTP
> >> streams, the payload type numbers indicate the value of the payload
> >> type field the offerer expects to receive, and would prefer to send.
> >> However, for sendonly and sendrecv streams, the answer might indicate
> >> different payload type numbers for the same codecs, in which case,
> >> the offerer MUST send with the payload type numbers from the answer.
> >>
> >> Different payload type numbers may be needed in each direction
> >> because of interoperability concerns with H.323.
> > I was reading that text, and it clearly says which ones to use if the
> > payload types are different, but I don't think they clearly address the
> > situation with using the same payload type for two different codecs in
> > different directions.
> >
> > In a multicast or transport relay scenario, this would clearly be
> > untenable, since third parties would not be able to send streams that
> > would be interpreted correctly by the two conflicting endpoints, but in
> > a two-party conversation, it's possible to make this work.
> > I just don't know if it's worth the effort to make it so.
> 
> 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.

I viewed this as being a requirement for all offers or answers sent by A to B, but not necessarily the corresponding answer and offers from B to A. Otherwise, it seems to conflict with the text in section 5.1. That said, I can certainly see where someone else may interpret it differently.

 Cheers,
Charles

> Cheers,
> Emil
> 
> 
> --
> https://jitsi.org
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic