Re: [MMUSIC] (no subject)

[Jonathan Rosenberg <[e-mail]>]

RFC 3264 is issued and done, and what you are proposing would change 
that behavior. I dont see the benefit of doing that. Changing PT 
numbers is sometimes necessary for synchronization of other changes. 
Normally I wouldn't expect it to change randomly.

-Jonathan R.

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

-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Technology Officer                    Parsippany, NJ 07054-2711
dynamicsoft
[e-mail]                     FAX:   [phone]
http://www.jdrosen.net                      PHONE: [phone]
http://www.dynamicsoft.com


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