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
