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

On Jan 11, 2013 12:23 AM, "Charles Eckel (eckelcu)" <eckelcu@cisco.com>
wrote:
>
> 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@ietforg] 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.

Well, it does say: "from that point forward in _any_ offers or answers"

> Otherwise, it seems to conflict with the text in section 5.1.

Mmm ... which part of 5.1?

To me it just seems like a completion (admittedly, somewhat out of place).

> That said, I can certainly see where someone else may interpret it
> differently.

Agreed. Definitely 3264bis material.

Cheers,
Emil

--sent from my mobile
>
> Cheers,
> Charles
>
> > Cheers,
> > Emil
> >
> >
> > --
> > https://jitsi.org
> > _______________________________________________
> > 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