Did you know that RFC 4733 replaced/obsoleted RFC 2833? I just learned this myself through a SIP Forum mailing list exchange the other day. For those not aware, RFC 2833 and now 4733 define methods of carrying DTMF signals (and other similar signaling) in RTP streams separate from the main audio component of the RTP stream. A typical example of use might be where you were using a highly-compressed audio codec for audio between two SIP endpoints where the high degree of compression might make it challenging for the DTMF tones to be correctly interpreted on the receiving end. Using “RFC 2833 compliant” signaling, the sending SIP endpoint would send those DTMF tones as separate packets within the RTP stream.
My key takeaway from learning about RFC 4733 is that we should really be talking about “RFC 4733 compliant” signaling… but given that the industry is really only now starting to really talk about “RFC 2822 compliant” signaling, I’m not sure I expect to see that happening anytime soon.
Anyway, here’s the abstract from RFC 4733 – you can naturally read the rest of the document to understand more:
This memo describes how to carry dual-tone multifrequency (DTMF) signalling, other tone signals, and telephony events in RTP packets. It obsoletes RFC 2833.
This memo captures and expands upon the basic framework defined in RFC 2833, but retains only the most basic event codes. It sets up an IANA registry to which other event code assignments may be added. Companion documents add event codes to this registry relating to modem, fax, text telephony, and channel-associated signalling events. The remainder of the event codes defined in RFC 2833 are conditionally reserved in case other documents revive their use.
This document provides a number of clarifications to the original document. However, it specifically differs from RFC 2833 by removing the requirement that all compliant implementations support the DTMF events. Instead, compliant implementations taking part in out-of-band negotiations of media stream content indicate what events they support. This memo adds three new procedures to the RFC 2833 framework: subdivision of long events into segments, reporting of multiple events in a single packet, and the concept and reporting of state events.
Dan,
I was under the assumption that the industry was trying to move towards making all DTMF out-of-band. (since that way you avoid issues with compression and codecs.)
But it seems like this revision is going the wrong way and reducing the pressure to do that?
“removing the requirement that all compliant implementations support the DTMF events”
Someone should really set a deadline for switching off in-band DTMF, like the FCC did on switching off analog tv.
Shai, Thanks for the comment. As far as I am aware, the general move of the “industry” (however you define that) *is* to move toward DTMF being “out-of-band” as it is here in RFC 2833 and 4733.
I don’t know precisely why this change was made, but I’m going to guess it is because the authors of RFC 4733 are intending the signaling mechanism to be able to be used for *more* than just DTMF. If you are then using the signaling for something else, it may not make sense to then *require* that the endpoints support DTMF if they would in fact never send DTMF.
Again, that’s just my interpretation based on a basic reading of the doc.
Thanks for the comment,
Dan
Jeffrey, I’m afraid that I don’t know the answer to that one as you are getting down into details of SIP with which I personally have not directly worked. My suggestion would be to perhaps join the sip-implementors list and ask the question there: https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
PING:
TITLE: SIP, RFC4733, RFC2833, and You
BLOG NAME: The VoIP Weblog
Chances are, if youve used a regular landline phone, youve made a call into a system where you have to press keys on your numeric keypad in order to reach your intended party (e.g. dialing an extension, trying to get…
Hi,
I would like to know the differences in RFC2833 and RFC4733. I have a voice stack (Software) which supports RFC2833, what are the changes that I need to make in the voice stack to support RFC4733. Can anybody please put some light on this.
Thanks,
Kalpesh
Dan, I have question in regards to section 2.5.1.4. What happens if the end duration continues to increment in the last 3 e-bits sent? From reading the RFC, it doesn’t clearly state that the duration can’t increment, but i see in table 5 that the duration event stays the same for each end bit that is sent. If the event duration does increment, would this be a violaton of the RFC?