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: sip-implementors@lists.cs.columbia.edu
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
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

_______________________________________________
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

Reply via email to