In the past year and a half that I have been writing this blog, I’ve had my share of highly successful articles and a number of total flops. The unfortunate thing is that I never know how any particular article will fare until it has been out there for a while.
For instance, my top article, Understanding SIP Timer Part I, is one that I never expected to appeal to anyone but the geekiest of geeks yet it pulls in a significant number of new views every day. I guess there are more SIP nerds out there than I realized.
The opposite is also true. I thought that Privacy – The New Currency would be interesting to a lot of folks, but it has only garnered 60 views since I published it in June of 2013.
Along those same lines, my article about why you wouldn’t move to SIP, If it Ain’t Broke, has even less views. I was sure that people would flock to that one, but it turned out to be a real dud.
Clearly, I am not the best judge of what may or may not catch my reader’s interest. Still, since this is just as much for me as it is for you, I write whatever pops into my head and hope that someone finds it worthwhile.
A New Look at an Old Friend
On that note, allow me to move to a topic that I hope falls closer to wildly successful than total flop – DTMF and RFC 2833.
Long time readers may remember that I addressed this topic several months ago in my article DTMF and RFC 2833 / 4733. I think it was a good explanation of a very confusing topic and unlike my missive on privacy, it did quite well for me. However, I now realize that I didn’t say enough. I presented the concepts in high level manner, but left out the gory details. Today, I plan on correcting that.
In my DTMF article, I explained that RFC 2833 defines a separate data stream for tones. So, instead of having those touch tones embedded in the speech path, they are detected and separated out. This saves the recipient from having to employ some form of digital signal processing (DSP) to perform that task.
I also explained that session description protocol (SDP) is used to declare that RFC 2833 will be used by the sender, the recipient, or both parties in a call.
The following is an SDP snippet that demonstrates this declaration:
m=audio 12346 RTP/AVP 101
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
What you didn’t see in my previous article were some real-life examples and that’s what I plan on doing right here and now.
This example of an RFC 2833 stream comes straight from my favorite packet tracing tool – Wireshark.
I want you to pay attention to a few things. First, notice the different protocols involved — Ethernet, IP, UDP, and RTP. Of interest to us, of course, is the RTP portion.
Second, notice how RFC 2833 is expressed within the RTP payload. The parameter Payload type has been set to telephone-event which indicates that this packet contains the representation of DTMF tones.
Finally, the actual DTMF data has been encapsulated into an RTP Event. In this example, the Event ID indicates that the number six has been sent with a Volume of 7 and a Duration of 480 timestamp units.
Measuring duration in timestamp units means that the event began at the instant identified by the RTP timestamp and has so far lasted as long as indicated by the duration parameter. For a sampling rate of 8000 Hz, the duration field can express an event of up to eight seconds.
Volume is expressed in dBm0 that range from 0 to -36 dBm0. Large values denote lower volumes. You do not show the minus sign in RFC 2833, so 7 is really -7.
You should also see the End of Event flag. Here, it is set to False (0). This parameter allows the sender to extend the tone beyond that of the duration field. A value of False tells the recipient that more packets are coming. The final packet sets End of Event to True (1) and will look like this:
At this point, the tone has stopped playing and the application can process it as it sees fit.
Mischief Managed
Does this help? You may never have to work with DTMF transmission at the packet level, but you will encounter it as you shop for an SBC or configure a SIP trunk. For example, if you are an Avaya administrator, you may have seen the parameter DTMF over IP in a SIP Signaling Group. Guess what? This turns support for RFC 2833 on or off for that trunk.
I believe that with these two blog articles, I have now said just about everything I need to say about RFC 2833 / 4733. If you still have questions that require an even deeper dive, I recommend that you download copies of both RFCs and have at them. If nothing else, they are great for those nights when you can’t fall asleep.
Tao, Zen, and Tomorrow 
So, how do you calculate interdigit DTMF ? such as if I dial *8 8887773546. How do I calculate the time between the *8 and the other digits? Pretty sure it has to do with the timestamp units, but I don’t know the formula.
I am sorry to say, but I don’t know the precise answer. As you said, it has to do with timestamps, but I don’t know the details. I took a look at the RFC, but it doesn’t jump out at me.
Hi, this info is very handy, but I´d like to ask you a deeper explanation about FMTP. I have some trouble with a customer’s IVR that is not capable of understand the 2833 events I sent so continues asking for the tones. Customer says the issue is FMTP related, could it be? Thank you in advance.