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
