Did you know RFC 4733 had replaced/obsoleted RFC 2833 for DTMF signaling in SIP?

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.

Technorati Tags: DTMF, ietf, sip, standards

Comments

[Shai Berger]

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.

[Dan York]

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