Subject: Re: [MMUSIC] (no subject)

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 13 Aug 2003 17:20:14 -0400

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:[email-masked]] Sent: Wednesday, August 13, 2003
> 2:49 PM To: Jonathan Rosenberg; Raman, Sundereshwaran
> (Sundereshwaran) Cc: [email-masked] 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: [email-masked]
>> [mailto:[email-masked]] On Behalf
> 
> Of
> 
>> Jonathan Rosenberg Sent: Wednesday, August 13, 2003 2:39 PM To:
>> Raman, Sundereshwaran (Sundereshwaran) Cc: [email-masked] 
>> 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 [email-masked]
>> FAX:   (973) 952-5050 http://www.jdrosen.net
>> PHONE: (973) 952-5000 http://www.dynamicsoft.com
>> 
>> 
>> _______________________________________________ mmusic mailing
>> list [email-masked] 
>> https://www1.ietf.org/mailman/listinfo/mmusic
> 
> 

-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Technology Officer                    Parsippany, NJ 07054-2711
dynamicsoft
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

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

---

From: "Raman, Sundereshwaran (Sundereshwaran)" <[email-masked]>
Date: Wed, 13 Aug 2003 15:11:47 -0600

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?  

Thanks
Sundi

-----Original Message-----
From: Hearty, John [mailto:[email-masked]]
Sent: Wednesday, August 13, 2003 2:49 PM
To: Jonathan Rosenberg; Raman, Sundereshwaran (Sundereshwaran)
Cc: [email-masked]
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: [email-masked] [mailto:[email-masked]] On Behalf
Of
> Jonathan Rosenberg
> Sent: Wednesday, August 13, 2003 2:39 PM
> To: Raman, Sundereshwaran (Sundereshwaran)
> Cc: [email-masked]
> 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
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
offer
type
offers
is
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.
> 
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
> > Thanks
> > Sundi