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

From: Harald Alvestrand <[email-masked]>
Date: Wed, 09 Jan 2013 20:25:03 +0100

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.)

                    Harald

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Wed, 9 Jan 2013 21:01:41 +0000

Please see inline.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Harald Alvestrand
> Sent: Wednesday, January 09, 2013 11:25 AM
> To: [email-masked]
> Subject: [MMUSIC] Query: payload type collision with offer/answer
> 
> Hello,

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.

That said there are additional requirements placed on payload type usage by some codecs, such as SVC.

Cheers,
Charles

>                     Harald
> 
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic

---

From: Harald Alvestrand <[email-masked]>
Date: Wed, 09 Jan 2013 23:52:00 +0100

On 01/09/2013 10:01 PM, Charles Eckel (eckelcu) wrote:
> 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
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.

---

From: Emil Ivov <[email-masked]>
Date: Thu, 10 Jan 2013 00:46:01 +0100

> 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.

Cheers,
Emil

-- 
https://jitsi.org

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 10 Jan 2013 13:50:31 -0500

To the best of my memory the issue Harald has raised is a new one. I 
don't think it has never been discussed on any of the lists I have been 
following since 2002.

More inline.

>> I just don't know if it's worth the effort to make it so.

You are right that these arguments work differently for unicast and 
multicast. I don't recall (I think it was before my time) how much 
thought was given to multicast in 3264. (It doesn't seem to be very 
much. And I think the O/A discussions in new additions to SDP rarely 
consider it at all.)

>     codec, so that an updated offer could also use payload type number 72

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.

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.

	Thanks,
	Paul

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Thu, 10 Jan 2013 23:22:58 +0000

Please see inline.

> Behalf Of Emil Ivov
> Sent: Wednesday, January 09, 2013 3:46 PM
> To: Harald Alvestrand
> Cc: [email-masked]
> Subject: Re: [MMUSIC] Query: payload type collision with offer/answer
> 
> 
> 

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

---

From: Emil Ivov <[email-masked]>
Date: Fri, 11 Jan 2013 00:37:29 +0100

On Jan 11, 2013 12:23 AM, "Charles Eckel (eckelcu)" <[email-masked]>
wrote:
> > >>> From: [email-masked] [mailto:mmusic-bounces@ietforg] On
> 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

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Thu, 10 Jan 2013 23:47:40 +0000

> Sent: Thursday, January 10, 2013 3:37 PM
> To: Charles Eckel (eckelcu)
> Cc: mmusic

This part:

 
Cheers,
Charles

---

From: Emil Ivov <[email-masked]>
Date: Fri, 11 Jan 2013 00:54:43 +0100

On Jan 11, 2013 12:48 AM, "Charles Eckel (eckelcu)" <[email-masked]>
wrote:
> > > > >>> type 98, and Y must send codec foo with payload type 97. That's
not
> > the
> > > > >>> And if this has a clear answer - which paragraph of which RFC
makes
> > > > >> this

This part just says the PT numbers can be different in the offer and the
answer. It doesn't say they can be the same as other PT numbers that were
assigned to other formats, which is what section 8.3.2 prohibits.

This is the reason I was seeing 8.3.2 more as a completion rather than a
contradiction.

Emil
--sent from my mobile

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Fri, 11 Jan 2013 13:33:48 +0100

At least to attempt to answer the history question here relating to multicast, my understanding is that the authors of RFC 2543 (the original SIP), did make attempts to cover multicast, but this was abandoned (although existing RFC 2543 material was not removed) when RFC 3261 was produced.

RFC 3264 was a new document at the time RFC 3261 was produced and therefore my understanding was that it was designed to cover unicast only, because SIP, as defined in RFC 3261, was the user of offer/answer.

Keith

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Paul Kyzivat
> Sent: 10 January 2013 18:51
> To: [email-masked]

---

From: Harald Alvestrand <[email-masked]>
Date: Fri, 11 Jan 2013 13:47:10 +0100

On 01/10/2013 07:50 PM, Paul Kyzivat wrote:
> 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.
>
> 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:
>
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.
>
Seems like a conclusion.

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 11 Jan 2013 13:01:02 +0000

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.

Regards,

Christer

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Harald Alvestrand
Sent: 11. tammikuuta 2013 14:47
To: [email-masked]
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
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:

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

Seems like a conclusion.

---

From: Emil Ivov <[email-masked]>
Date: Fri, 11 Jan 2013 14:50:35 +0100

> 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

-- 
https://jitsi.org

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 11 Jan 2013 14:27:19 +0000

Hi,

> 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

>> 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:
>>
>> 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.
>> 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.
> 

--
https://jitsi.org

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Fri, 11 Jan 2013 17:24:01 +0000

> Sent: Friday, January 11, 2013 4:47 AM
> To: [email-masked]

Agreed, this would be a useful clarification to add as an update to RFC 3264.

Cheers,
Charles