Re: [MMUSIC] (no subject)
Jonathan Rosenberg <jdrosen@dynamicsoft.com> Wed, 13 August 2003 21:21 UTC
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06301 for <mmusic-archive@odin.ietf.org>; Wed, 13 Aug 2003 17:21:27 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19n33G-00011U-N4 for mmusic-archive@odin.ietf.org; Wed, 13 Aug 2003 17:21:02 -0400
Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7DLL2Px003931 for mmusic-archive@odin.ietf.org; Wed, 13 Aug 2003 17:21:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19n33G-00011K-Jl for mmusic-web-archive@optimus.ietf.org; Wed, 13 Aug 2003 17:21:02 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06285 for <mmusic-web-archive@ietf.org>; Wed, 13 Aug 2003 17:20:56 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19n33E-0005A9-00 for mmusic-web-archive@ietf.org; Wed, 13 Aug 2003 17:21:00 -0400
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19n33D-0005A6-00 for mmusic-web-archive@ietf.org; Wed, 13 Aug 2003 17:20:59 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19n33E-00010t-ON; Wed, 13 Aug 2003 17:21:00 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19n339-00010f-9a for mmusic@optimus.ietf.org; Wed, 13 Aug 2003 17:20:55 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06280 for <mmusic@ietf.org>; Wed, 13 Aug 2003 17:20:49 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19n337-0005A2-00 for mmusic@ietf.org; Wed, 13 Aug 2003 17:20:53 -0400
Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19n336-00059s-00 for mmusic@ietf.org; Wed, 13 Aug 2003 17:20:52 -0400
Received: from dynamicsoft.com ([63.113.46.76]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h7DLKI3m003883; Wed, 13 Aug 2003 17:20:18 -0400 (EDT)
Message-ID: <3F3AAB8E.3040502@dynamicsoft.com>
Date: Wed, 13 Aug 2003 17:20:14 -0400
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
Organization: dynamicsoft
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Raman, Sundereshwaran (Sundereshwaran)" <ramsun@avaya.com>
CC: "Hearty, John" <John.Hearty@Level3.com>, mmusic@ietf.org
Subject: Re: [MMUSIC] (no subject)
References: <E51B810754014D4FB52FAB2F188C2652456F41@cof110avexu2.global.avaya.com>
In-Reply-To: <E51B810754014D4FB52FAB2F188C2652456F41@cof110avexu2.global.avaya.com>
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: mmusic-admin@ietf.org
Errors-To: mmusic-admin@ietf.org
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Raman, Sundereshwaran (Sundereshwaran) wrote: > Thanks for your prompt replies. I thought so too after reading the > RFC 3264. The reason for this question was I came across two > vendors who were changing the payload type number when a re-invite > was sent out. Heres the scenario: Session established with 96 as > the payload type number for telephone-event. I send out a RE-INVITE > with no SDP in it. The response from the phone contains a different > payload type number for the telephone event. Are they not supposed > to send the previous agreed upon payload type number? This is allowed. Read carefully below - it says that it IS ok for multiple numbers to be associated with the same codec. In other words, you can use PT 96 for tones, and then later PT 98 for tones. The opposite is NOT allowed. That is, payload type 96 cannot be used first for tones, and then for g.711. -Jonathan R. > -----Original Message----- From: Hearty, John > [mailto:John.Hearty@Level3.com] Sent: Wednesday, August 13, 2003 > 2:49 PM To: Jonathan Rosenberg; Raman, Sundereshwaran > (Sundereshwaran) Cc: mmusic@ietf.org Subject: RE: [MMUSIC] (no > subject) > > > The text calls out the special case of disallowing changing the PT > in the case of RTP. The example was for telephone events. I > suspect you would risk interop problems if you didn't follow the > RTP rule in the text for telephone events, but technically the > example is removing the 96 PT and adding a different PT mapping to > telephone events which the text seems to allow. The rules are for > a particular media stream in the session. It may be safer to use a > whole new media stream for the new PT if you really need to do it > for some reason. > > John Hearty Level3 > > >> -----Original Message----- From: mmusic-admin@ietf.org >> [mailto:mmusic-admin@ietf.org] On Behalf > > Of > >> Jonathan Rosenberg Sent: Wednesday, August 13, 2003 2:39 PM To: >> Raman, Sundereshwaran (Sundereshwaran) Cc: mmusic@ietf.org >> Subject: Re: [MMUSIC] (no subject) >> >> I believe Section 8.3.2 of RFC 3264 directly answers your >> question: >> >> The list of media formats used in the session MAY be changed. To >> do this, the offerer creates a new media description, with the >> list > > of > >> media formats in the "m=" line different from the corresponding > > media > >> stream in the previous SDP. This list MAY include new formats, > > and > >> MAY remove formats present from the previous SDP. 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. >> >> >> This is true for the answerer as well. Thus, in each direction, >> once PT number is bound to a codec, that PT number can not be >> used for a different codec. >> >> -Jonathan R. >> >> Raman, Sundereshwaran (Sundereshwaran) wrote: >> >> >>> I have question related to dynamic payloads. If a session is > > estblished > >>> with a dynamic payload type number mapped to a particular >>> codec, can > > the > >>> number change for the same codec in subsequent offers/answers >>> in the same session? e.g. Lets say a session was established >>> with a dynamic payload type number 96 mapped to >>> telephone-event. Now if a new > > Re-Invite > >>> is sent out, can the response have a different payload type >>> number > > for > >>> the telephone event? >>> >>> Thanks Sundi >>> >>> >> >> -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza >> Chief Technology Officer Parsippany, NJ >> 07054-2711 dynamicsoft jdrosen@dynamicsoft.com >> FAX: (973) 952-5050 http://www.jdrosen.net >> PHONE: (973) 952-5000 http://www.dynamicsoft.com >> >> >> _______________________________________________ mmusic mailing >> list mmusic@ietf.org >> https://www1.ietf.org/mailman/listinfo/mmusic > > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic
- [MMUSIC] (no subject) MR.Michael Onyeze
- [MMUSIC] (no subject) Jayakrishnan Prabhakaran
- [MMUSIC] (no subject) WC-4128
- [MMUSIC] (no subject) michael onyeze
- [MMUSIC] (no subject) Mr. Pakwesi Oduro
- [MMUSIC] (no subject) Raman, Sundereshwaran (Sundereshwaran)
- Re: [MMUSIC] (no subject) Jonathan Rosenberg
- RE: [MMUSIC] (no subject) Hearty, John
- Re: [MMUSIC] (no subject) Jonathan Rosenberg
- Re: [MMUSIC] (no subject) Jonathan Rosenberg
- RE: [MMUSIC] (no subject) Raman, Sundereshwaran (Sundereshwaran)
- RE: [MMUSIC] (no subject) Raman, Sundereshwaran (Sundereshwaran)
- [MMUSIC] (no subject) Daniel Park
- (no subject) Frank Lepera
- (no subject) goya
- (no subject) Zhuang Chao
- [MMUSIC] (no subject) DRAGE, Keith (Keith)
- [MMUSIC] Comments on draft-ejzak-mmusic-data-chan… Paul Kyzivat
- Re: [MMUSIC] Comments on draft-ejzak-mmusic-data-… Makaraju, Maridi Raju (Raju)
- Re: [MMUSIC] Comments on draft-ejzak-mmusic-data-… Paul Kyzivat
- Re: [MMUSIC] Comments on draft-ejzak-mmusic-data-… Makaraju, Maridi Raju (Raju)
- Re: [MMUSIC] Comments on draft-ejzak-mmusic-data-… Paul Kyzivat
- Re: [MMUSIC] Comments on draft-ejzak-mmusic-data-… Makaraju, Maridi Raju (Raju)