Each sends using the value specified by the other end, and expects to
receive the value it specified.
Paul
Rockson Li (zhengyli) wrote:
> Yes it represents the UA's intended RTP payload type for SENDING or
> RECEIVING RTP.
> And you are correct you don't have to make use of the same value.
> However, I think it's strongly recommended to use same value.
>
> Please refer to RFC3264 p9
>
> In the case of RTP, if a particular codec was referenced with a
> specific payload type number in the offer, that same payload type
> number SHOULD be used for that codec in the answer.
>
> FYI
> -Rockson
>
> -----Original Message-----
> From: Greg Dykes [mailto:[EMAIL PROTECTED]
> Sent: Monday, September 29, 2008 10:28 AM
> To: Rockson Li (zhengyli)
> Cc: [email protected]
> Subject: Re: [Sip-implementors] RFC 2833 Telephone-Event RTP Payload
> Type
>
> My question really is about the actual usage of a numeric payload type
> indicator. The assumption with my question is that both SIP UAs are
> negotiating the same "telephone-event' RTP payload. As I understand each
> SIP UA can specify their own payload type indicator (96-127) which
> represents a specific, static "telephone-event" RFC 2833 RTP payload. In
> other words, they don't have to make use of the same value. So am I
> correct in saying that each SIP UA can indeed make use of a different
> payload type indicator in the dynamic range of 96-127?
> And if so does this value represent the UA's intended RTP payload type
> for SENDING or RECEIVING RTP?
>
> Thanks,
>
> - Greg
>
>
> On Sep 28, 2008, at 8:00 AM, Rockson Li (zhengyli) wrote:
>
>> Greg,
>>
>> Payload Type negotiated will be used as RTP PT in RTP packet.
>> And if you use named events in RFC2833, the events supported are
>> negotiated.
>>
>> Regards,
>> -Rockson
>>
>> -----Original Message-----
>> From: [EMAIL PROTECTED]
>> [mailto:[EMAIL PROTECTED] On Behalf Of
>> Greg Dykes
>> Sent: Saturday, September 27, 2008 11:26 AM
>> To: [email protected]
>> Subject: [Sip-implementors] RFC 2833 Telephone-Event RTP Payload Type
>>
>> I'm trying to nail down my understanding of how the RFC 2833 DTMF
>> Telephone-event RTP Payload Type is "negotiated". If I understand
>> correctly, it's really NOT negotiated at all.
>> I understand that static payload types, such as voice codecs (e.g.,
>> PCMA, PCMU) are indeed negotiated. So my question then is with DTMF
>> payload types.
>>
>> From my reading, it appears that a call request INVITE sender
>> specifies a supported RFC 2833 DTMF RTP payload type by defining this
>> RTP payload type with the specific 'telephone-event' rtpmap attribute
>> in the SDP and by including a mapped payload type value (of the
>> sender's choice) in the dynamic range (96-127) within the audio media
>> stream 'm' line. As I understand, the SDP answerer can then respond to
>
>> this request with its own custom mapped payload type value as long as
>> it also defines the DTMF payload type with the specific 'telephone-
>> event' rtpmap attribute in the SDP.
>>
>> So my question is what exactly does the RTP payload type number stand
>> for within the confines of RFC 2833 & DTMF and the SIP UA which
>> specifies the specific payload type number? Is this the payload type
>> used by UA 1 (for example) to indicate which 8 bit number the SIP UA's
>
>> peer (UA 2) is to use in the 7 bit RTP "Payload Type" header when
>> sending DTMF (RFC 2833) to the UA 1? Again as I understand, each UA
>> doesn't have to specify the same RTP payload type number for RFC 2833
>> DTMF to flow between the UAs. It appears two distinct payload types
>> can be used in a single session - one traveling from UA 1 to UA2 and
>> another from UA 2 to UA 1.
>>
>> Can someone confirm this understanding and correct any wrong
>> assumptions?
>>
>> Thanks,
>>
>> - Greg
>> _______________________________________________
>> Sip-implementors mailing list
>> [email protected]
>> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>
>
> _______________________________________________
> Sip-implementors mailing list
> [email protected]
> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
