[SIPForum-discussion] Regarding Sending DTMF over RTP

Shrivastava, Keshav (Keshav) kshrivastava at avaya.com
Sun Aug 28 21:37:07 UTC 2011


Hi,

 

This is one of the old Questions that I am trying to search an answer.
Please help. 

 

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,

Keshav Shrivastava

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://sipforum.org/pipermail/discussion/attachments/20110828/6b4fcf05/attachment-0002.html>


More information about the discussion mailing list