Re: [MMUSIC] Query: payload type collision with offer/answer
Christer Holmberg <christer.holmberg@ericsson.com> Fri, 11 January 2013 14:27 UTC
Return-Path: <christer.holmberg@ericsson.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 5F22C21F8629 for <mmusic@ietfa.amsl.com>; Fri, 11 Jan 2013 06:27:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.189
X-Spam-Level:
X-Spam-Status: No, score=-6.189 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4]
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 pNFR43N3MOgY for <mmusic@ietfa.amsl.com>; Fri, 11 Jan 2013 06:27:22 -0800 (PST)
Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 8063E21F866D for <mmusic@ietf.org>; Fri, 11 Jan 2013 06:27:21 -0800 (PST)
X-AuditID: c1b4fb30-b7f0d6d000007e61-7d-50f02148fea9
Received: from ESESSHC015.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id FD.EA.32353.84120F05; Fri, 11 Jan 2013 15:27:20 +0100 (CET)
Received: from ESESSMB209.ericsson.se ([169.254.9.11]) by ESESSHC015.ericsson.se ([153.88.183.63]) with mapi id 14.02.0318.004; Fri, 11 Jan 2013 15:27:20 +0100
From: Christer Holmberg <christer.holmberg@ericsson.com>
To: Emil Ivov <emcho@jitsi.org>
Thread-Topic: [MMUSIC] Query: payload type collision with offer/answer
Thread-Index: AQHN7p8Mjyk6kI/FLUWFcqXIpB6gmphBmrXl///+PoCAAT/GgIABLNAAgAAUJmD///2RgIAAGoPA
Date: Fri, 11 Jan 2013 14:27:19 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B09BE9D@ESESSMB209.ericsson.se>
References: <50EDC40F.3010501@alvestrand.no> <1.77712513fa3f074cccef@cisco.com> <50EDF490.4000101@alvestrand.no> <50EE0139.8000909@jitsi.org> <50EF0D77.9040000@alum.mit.edu> <50F009CE.9060903@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B09BCBD@ESESSMB209.ericsson.se> <50F018AB.8090305@jitsi.org>
In-Reply-To: <50F018AB.8090305@jitsi.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [153.88.183.16]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrMLMWRmVeSWpSXmKPExsUyM+Jvja6H4ocAgwenVC3W7JzAYnGsr4vN YuryxywOzB5XJlxh9Viy5CeTx/83gQHMUVw2Kak5mWWpRfp2CVwZt740sxcs0Kp4+echcwPj A4UuRg4OCQETidfXfLoYOYFMMYkL99azgdhCAocYJfp2ynQxcgHZixklep+/YAOpZxOwkOj+ pw1SIyIgL9HdtogJxGYWCJa49uAemC0s4Cqx9/8rZogaN4mpZ96wQdhREmt+TWQFsVkEVCU+ 9U4Hi/MKeEu0bZjMCLF3K5PEmh3KIDangKbEhE/tYPWMQLd9P7UGape4xK0n85kgbhaQWLLn PDOELSrx8vE/VghbUWLn2XZmiHodiQW7P7FB2NoSyxa+ZobYKyhxcuYTlgmMYrOQjJ2FpGUW kpZZSFoWMLKsYmTPTczMSS8338QIjJiDW34b7GDcdF/sEKM0B4uSOG+464UAIYH0xJLU7NTU gtSi+KLSnNTiQ4xMHJxSDYyzveScL5s555bJ7dN5vUjoZaJkraqft2ZHpmSQ1LMV/cucM2dM PV35Z0Wum4Hbj2qnPZNOFjqcUTT/dvf275tmDprNNzatmmp+vvhHaW7cvbh1/hJN75OLzgW7 Ttj8PdtHYmN7749jUU8iFDXnXFa8pCmlpyb5zGHFpJvmjoU/v/rHmL44nKvEUpyRaKjFXFSc CAAFi/ZVZgIAAA==
Cc: "mmusic@ietf.org" <mmusic@ietf.org>
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 14:27:23 -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. > > 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
- [MMUSIC] Query: payload type collision with offer… Harald Alvestrand
- Re: [MMUSIC] Query: payload type collision with o… Charles Eckel (eckelcu)
- Re: [MMUSIC] Query: payload type collision with o… Harald Alvestrand
- Re: [MMUSIC] Query: payload type collision with o… Emil Ivov
- Re: [MMUSIC] Query: payload type collision with o… Paul Kyzivat
- Re: [MMUSIC] Query: payload type collision with o… Charles Eckel (eckelcu)
- Re: [MMUSIC] Query: payload type collision with o… Emil Ivov
- Re: [MMUSIC] Query: payload type collision with o… Charles Eckel (eckelcu)
- Re: [MMUSIC] Query: payload type collision with o… Emil Ivov
- Re: [MMUSIC] Query: payload type collision with o… DRAGE, Keith (Keith)
- Re: [MMUSIC] Query: payload type collision with o… Harald Alvestrand
- Re: [MMUSIC] Query: payload type collision with o… Christer Holmberg
- Re: [MMUSIC] Query: payload type collision with o… Emil Ivov
- Re: [MMUSIC] Query: payload type collision with o… Christer Holmberg
- Re: [MMUSIC] Query: payload type collision with o… Charles Eckel (eckelcu)