RE: [MMUSIC] (no subject)

"Hearty, John" <John.Hearty@Level3.com> Wed, 13 August 2003 20:51 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 QAA05461 for <mmusic-archive@odin.ietf.org>; Wed, 13 Aug 2003 16:51: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 19n2aE-0007Sc-K3 for mmusic-archive@odin.ietf.org; Wed, 13 Aug 2003 16:51:02 -0400
Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7DKp2QZ028672 for mmusic-archive@odin.ietf.org; Wed, 13 Aug 2003 16:51:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19n2aE-0007SN-GS for mmusic-web-archive@optimus.ietf.org; Wed, 13 Aug 2003 16:51: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 QAA05454 for <mmusic-web-archive@ietf.org>; Wed, 13 Aug 2003 16:50:57 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19n2aC-0004wA-00 for mmusic-web-archive@ietf.org; Wed, 13 Aug 2003 16:51:00 -0400
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19n2aB-0004w7-00 for mmusic-web-archive@ietf.org; Wed, 13 Aug 2003 16:50:59 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19n2aC-0007Ry-KQ; Wed, 13 Aug 2003 16:51:00 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19n2ZN-0007RA-N4 for mmusic@optimus.ietf.org; Wed, 13 Aug 2003 16:50:09 -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 QAA05418 for <mmusic@ietf.org>; Wed, 13 Aug 2003 16:50:04 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19n2ZL-0004va-00 for mmusic@ietf.org; Wed, 13 Aug 2003 16:50:07 -0400
Received: from machine77.level3.com ([209.244.4.106] helo=cc26-01.idc1.level3.com) by ietf-mx with esmtp (Exim 4.12) id 19n2ZK-0004vQ-00 for mmusic@ietf.org; Wed, 13 Aug 2003 16:50:07 -0400
Received: from cc26-01.idc1.level3.com (localhost [127.0.0.1]) by localhost.level3.com (Postfix) with ESMTP id 5688284449; Wed, 13 Aug 2003 20:48:53 +0000 (GMT)
Received: from idc1exc0001.corp.global.level3.com (idc1exc0001.corp.global.level3.com [10.1.7.194]) by cc26-01.idc1.level3.com (Postfix) with SMTP id 76FA3FBABA; Wed, 13 Aug 2003 20:48:43 +0000 (GMT)
Received: from idc1exc0004.corp.global.level3.com ([10.1.8.20]) by idc1exc0001.corp.global.level3.com with Microsoft SMTPSVC(5.0.2195.4905); Wed, 13 Aug 2003 14:48:43 -0600
X-MimeOLE: Produced By Microsoft Exchange V6.0.6470.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [MMUSIC] (no subject)
Date: Wed, 13 Aug 2003 14:48:42 -0600
Message-ID: <3F75233A2E57CC468B35F3B1FAF71EC013A94C@idc1exc0004.corp.global.level3.com>
Thread-Topic: [MMUSIC] (no subject)
Thread-Index: AcNh21wTGt9wWOt7TbSQJ3jNw9nVcgAAEe+Q
From: "Hearty, John" <John.Hearty@Level3.com>
To: Jonathan Rosenberg <jdrosen@dynamicsoft.com>, "Raman, Sundereshwaran (Sundereshwaran)" <ramsun@avaya.com>
Cc: mmusic@ietf.org
X-OriginalArrivalTime: 13 Aug 2003 20:48:43.0252 (UTC) FILETIME=[48703B40:01C361DC]
Content-Transfer-Encoding: quoted-printable
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: quoted-printable
Content-Transfer-Encoding: quoted-printable

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

_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www1.ietf.org/mailman/listinfo/mmusic