RE: [MMUSIC] (no subject)

Just a thought. I think its good to be flexible in having multiple payload number for the same codec. But telephone-event is a special codec type. It will be lot more easier if once a session is established with a particular payload number for the telephone-event, the same payload number is used for subsequent offers/answers. This will particularly be beneficial to the PBX world as many PBX features rely on the tones and if it keeps on changing then lot more work needs to be done. I would appreciate your views on this.

Thanks
Sundi

-----Original Message-----
From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]
Sent: Wednesday, August 13, 2003 3:20 PM
To: Raman, Sundereshwaran (Sundereshwaran)
Cc: Hearty, John; mmusic@ietf.org
Subject: Re: [MMUSIC] (no subject)

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