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

"DRAGE, Keith (Keith)" <keith.drage@alcatel-lucent.com> Fri, 11 January 2013 12:33 UTC

Return-Path: <keith.drage@alcatel-lucent.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44FB321F88B5 for <mmusic@ietfa.amsl.com>; Fri, 11 Jan 2013 04:33:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -109.649
X-Spam-Level:
X-Spam-Status: No, score=-109.649 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KA4Zm2rjwefd for <mmusic@ietfa.amsl.com>; Fri, 11 Jan 2013 04:33:54 -0800 (PST)
Received: from smail6.alcatel.fr (smail6.alcatel.fr [64.208.49.42]) by ietfa.amsl.com (Postfix) with ESMTP id 25C7421F881A for <mmusic@ietf.org>; Fri, 11 Jan 2013 04:33:53 -0800 (PST)
Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail6.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id r0BCXosK002526 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 11 Jan 2013 13:33:50 +0100
Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.46]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Fri, 11 Jan 2013 13:33:50 +0100
From: "DRAGE, Keith (Keith)" <keith.drage@alcatel-lucent.com>
To: Paul Kyzivat <pkyzivat@alum.mit.edu>, "mmusic@ietf.org" <mmusic@ietf.org>
Date: Fri, 11 Jan 2013 13:33:48 +0100
Thread-Topic: [MMUSIC] Query: payload type collision with offer/answer
Thread-Index: Ac3vY2b8mQzP5R7vThKdh4cDjDdB6wAktUlw
Message-ID: <EDC0A1AE77C57744B664A310A0B23AE20D745EEC51@FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com>
References: <50EDC40F.3010501@alvestrand.no> <1.77712513fa3f074cccef@cisco.com> <50EDF490.4000101@alvestrand.no> <50EE0139.8000909@jitsi.org> <50EF0D77.9040000@alum.mit.edu>
In-Reply-To: <50EF0D77.9040000@alum.mit.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.69 on 155.132.188.84
Subject: Re: [MMUSIC] Query: payload type collision with offer/answer
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 11 Jan 2013 12:33:55 -0000

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

> -----Original Message-----
> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf
> Of Paul Kyzivat
> Sent: 10 January 2013 18:51
> To: mmusic@ietf.org
> Subject: Re: [MMUSIC] Query: payload type collision with offer/answer
> 
> 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.
> 
> On 1/9/13 6:46 PM, Emil Ivov wrote:
> >
> >
> > 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.
> 
> 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.)
> 
> > 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.
> 
> 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
> 
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic