DTMF and RFC 2833 / 4733

Over the past couple of weeks I’ve written two installments on voice codecs (A Cornucopia of Codecs and Codecs Continued).   I mentioned some of the major characteristics of six different codecs and why you might choose one over another.

However, I failed to point out something that is of great importance when making your codec choice.  What do you do about Dual Tone Multi-Frequency (DTMF) touch tones?   This is not something you can ignore because compressed codecs such as G.729 and G.726 will not successfully pass those tones along from sender to receiver.  Does that mean that those codecs aren’t  compatible with your voice mail system and SIP phones?   Absolutely not.  Read on to learn why.

How many of you are old enough to remember rotary telephones?  For better or worse, I certainly am.  In fact, it was all I knew for the first ten or so years of my life.  Heck, we even had a party line for most of my childhood.  Rotary phones used something called pulse dialing.  You put a finger in the numbered hole in a “finger wheel,” pulled that wheel back to the “finger stop” and let go.  During the return rotation, the electrical current of the telephone line would be interrupted in accordance to the number you dialed.  The number one would interrupt 1 time and zero would interrupt the circuit ten times.  The central office would then translate those current interruptions into the dialed telephone number.

DTMF was introduced by AT&T back in 1963 as a way to replace pulse dialing and rotary telephones.  Now, instead of interrupting the electrical current to dial a number, the telephone produced a tone to represent the dialed number.  Actually, it was two tones blended together — thus the Dual Tone part of DTMF.

DTMF has clearly been extended to purposes beyond simply dialing a telephone number.  Interactive Voice Systems (IVR) prompt us for all sorts of things that we answer with button presses.  We log into our voicemail systems and retrieve our messages with DTMF.  If so inclined, you can even play Mary had a Little Lamb using DTMF.

dtmf

DTMF wasn’t a problem with digital and analog telephone systems because they both use a toll quality (64 kilobit, 8000 Hz) audio connection.  The tones and speech easily mixed with one another and tone detection hardware was able to separate the DTMF out for applications that required it.

However, with VoIP and bandwidth concerns came voice compression and different techniques to send a legible voice stream using as little bytes as possible.  This compression and voice encoding techniques wreck havoc on DTMF and render the tones undecipherable by the components that need to detect and act upon them.

Enter RFC 2833.  With RFC 2833 you don’t send those DTMF signals on the same connection that you send your audio conversation.  Instead, you send them out-of-band on their own stream.  This allows you to compress the heck out of the voice without altering the DTMF signals.

Note: Technically, RFC 2833 has been replaced by RFC 4733, but for the most part people still want to call it 2833, so I do, too.

Depending upon the origin of the DTMF signals, they can start out in a separate stream, or that separate stream might be created by stripping the tones out of an audio conversation.  An example of the latter would be a gateway that converts analog to SIP.  Problems can arise from this stripping that need to be considered.  The converter must “hear” the tone before stripping it out and sometimes there is  leakage where the very beginning of the tone makes its way through.  This might cause a voicemail system to “hear” two tones for a single tone.  One would come from the RFC 2833 stream and the other in the voice stream.  Fortunately, conversion hardware is getting better and better and these problems have become less common (albeit a bear to debug when they occur).

So, in terms of SIP, how is this RFC 2833 stream created and managed?  Through Session Description Protocol (SDP), of course.  SDP is used to describe the voice stream (e.g. G.729) and it’s also used to inform the recipient that RFC 2833 is available.  Specifically, it uses something called telephone-event.  Here is an example of an SDP media description that you might see in the body of an Invite message.  Note the format of “0 – 16.”  This represents the ten digits plus *, #, A, B, D, E, and Flash.

m=audio 12346 RTP/AVP 101

a=rtpmap:101 telephone-event/8000

a=fmtp:101 0-16

That’s probably about as much as you really need to understand about RFC 2833 and how it works.  Its purpose is to create a separate stream for DTMF to allow voice codecs to strictly deal with creating the best possible voice stream using the fewest number of bytes.  If you remember that you will be ahead of the game.

Advertisements

37 comments

  1. Short and informative article, thanks Andrew

    1. Thanks! I do these in my spare time and I am happy to hear that they are making a difference.

  2. Is SIP INFO message used for DTMF ?

    1. That approach is frowned upon. There may be a few holdouts, but just about everyone has moved to RFC 2833/4733.

  3. The mention “a=fmtp:101 0-15” does not include the Flash event. I just run into this by tracking some interoperability problems between asterisk (0-16 with Flash) and cisco (0-15)

    1. You are correct and I fixed the text. Thanks for noticing it and commenting.

  4. Sayam · · Reply

    Hi Andrew,

    When we are dialing the verizon conferencing bridge number and when dialing the passcode it is detecting two tones for a single tone. Please comment.

    1. It’s hard for me to know what is happening here. Are you using SIP trunks? It could be a problem on your end, inside the carrier, or inside the conference bridge itself.

  5. David · · Reply

    Great article Andrew, and praise to your effort in your blog – it has much to admire. I was wondering if youre recolection of a rotary phone is accurate? Doesn’t dialing zero invokes ten pulses? 🙂 Anyways keep up the great work!

    1. You are correct, David, and I fixed the article. I clearly wasn’t thinking when I typed that!

  6. Thank you for the explination. Very well written.

  7. hi andrew ..good basic outline ..it would be grea you cover DTMF interworking .You deal with these a lot when working with carriers .the capabilities of the SBCS also pose a challenge when we do interworking

    1. I’ll put it on the list. 🙂

  8. RiverIntoSea · · Reply

    Thanks for the great work Andrew !

  9. Thomas Brahe · · Reply

    Hi Andrew
    I want to get clarified if this DTMF issue is related to the carrier or the PBX.
    When calling from cellphones on LTG/4G networks and reaches the IVR on the PBX, I can see from the wireshark traces that it uses HD Voice 16000khz, and what I learned from google is that it simply kills the dtmf tones, but if you call from 2G networks and landlines the dtmf works perfect and comes in 8000khz.
    So from my point of view, it looks like the SIP carrier just choose to use HD Voice on all calls that comes from their own network.
    The PBX uses RFC2833 and the carrier also uses RFC2833. But in my opionion it is the carrier that need to change the format ? Agree ?

    1. So, the tones are stripped, but it doesn’t send a 2833 stream containing the digits? If so, that’s not right.

      1. Could be a simple routing change to fix. I would love to solve. PCAPs could be relative if the event is not seen but heard is important.
        Does a routing change(s) make any difference, Likely it will.
        Can the caller hear the sound of the tone when they press the button?

  10. I would like to know the difference between rtpmap: 127 telephone-event and rtpmap: 101 telephone-event and which of the two is in band.

    Thank.

    1. Both are dynamic payload types and both are out-of-band. Are you seeing those types on the same system or different systems?

      1. I’m seeing in different systems, from a call from a SIP trunk to the PSTN.

        what happens is that I have a problem with calls that have rtpmap: 127 telephone-event not being completed and if you have rtpmp: 101-event telephone calls if completed.

        I could help me what would be the difference?

  11. Vineeth · · Reply

    If DtmfRelay is Enabled, Does it mean that RFC2833 is enforced ?

    1. As far as I know, they are not related.

  12. Mark N · · Reply

    Hello Andrew I’m always confused when People say 2833 is OOB. Correct me if I’m wrong but the DTMF is technically in-band, but the DTMF payload is out of band? So the DTMF is audible but it is just using a different payload type that is outside of the dynamically negotiated UDP/RTP ports the rest of the audio uses.

    To me SIP info would be a true OOB protocol. I believe if you listen to the audio with a Wireshark you will just hear pauses because the DTMF is signaled between the two endpoints and not passed through the RTP stream like 2833.

    Am I correct in my thinking?

    1. With 2833, the DTMF will be stripped out of the audio stream. It will only be represented by the separate RTP stream.

  13. Mihajlo Lakicevic · · Reply

    Dear Andrew,
    Thank you very much for the article, I love it.
    I will definitely read even other SIP articles you wrote!

    By the way I have a question of course 🙂
    I am trying to initiate DTMF Hook-Flash Relay on Patton Gateway 4112 with 2x FX-O.
    I changed the template on Yealink phone T46G as: features.dtmf.dtmf_flash = 1
    to enable thafeatrendt u a programed letter “E“ under the phones speed key.

    I did setup the Patton VoIP profile to do the RTP relay and the results are positive but not complete:
    14:50:54 CC > [EP IF_SIP-00b0f948/active] Invoke service: User Input Update (Duration: 100)
    14:50:54 CFXO > [EP IF_FXO_0] State ACTIVE, event USER INFO UPDATE
    14:50:54 DP > FXO-00/00: signal(Dtmf/ToneUpdate-Signal)
    14:50:54 RTP > [02000021] RTCP TX (SR) Timestamp=1639671230
    14:50:54 RTP > [02000021] Local TX-Info: packets=1657, octets=265120
    14:50:54 RTP > [02000021] Local RX-Info: packets=1661, octets=265760, lost=20, jitter=11, since last=0mS
    14:50:54 TDM > [DSP 0xf7fd48] Dtmf playing stopped notify.
    14:50:55 Dejit > [0xf80028] INFO : Packet loss is 1/94 (18/1697)
    14:50:57 DP > RTP-00/0021: getStatistics(00020900)
    14:50:57 CC > [EP IF_SIP-00b0f948/active] Set call-leg property: Quality-Of-Service -> MOS 1.00, RTP, G.711 u-law (20ms), Local: Rx 1820 pkts, 291200 bytes, 96 lost, jitter 698 ms, Tx 1816 pkts, 290560 bytes, rtt 0 ms, Remote: Rx 0 pkts, 0 bytes, 0 lost, jitter 0 ms, Tx 0 pkts, 0 bytes, rtt 0 ms
    14:50:58 RTP > [00f65590] Rx Nte: Pt: 101 Time: 296409 M: 1
    14:50:58 NTE > [00f65b00] Rx: Event start: flash
    14:50:58 RTP > Termination [2000021] Dtmf to application !
    14:50:58 DP > RTP-00/0021: event(DTMF/Tone-Event ‘!’)
    14:50:58 NTE > Scheduler: Register element 0x00f65b00
    14:50:58 NTE > Scheduler: Registered new element: 00f65b00
    14:50:58 Dejit > Flushing
    14:50:58 CC > [EP IF_SIP-00b0f948/active] Invoke service: User Input: ! (Duration: 2000)
    14:50:58 CFXO > [EP IF_FXO_0] State ACTIVE, event USER INFO
    14:50:58 CFXO > [EP IF_FXO_0] Sending user input to terminal: ! (2000 ms)
    14:50:58 FXO > [fxo 0 0 0/fxo 0] Dispatching event ‘ApplFlashHook’ in state ‘OffHook’
    14:50:58 FXO > [fxo 0 0 0/fxo 0] Action ‘Start Flash-Hook-Timer’ ( 100ms )
    14:50:58 FXO > [fxo 0 0 0/fxo 0] Action ‘Flash-Hook’
    14:50:58 FXO > [0 0] Driver: Setting port state to ‘OnHook’
    14:50:58 FXO > [fxo 0 0 0/fxo 0] Transition ‘OffHook’ -> ‘FlashHook’
    14:50:58 RTP > [02000021] Rx packet loss detected (1 packets)
    14:50:58 RTP > [00f65590] Rx Nte: Pt: 101 Time: 296409 M: 0
    14:50:58 RTP > [02000021] Rx packet loss detected (1 packets)
    14:50:58 RTP > [00f65590] Rx Nte: Pt: 101 Time: 296409 M: 0
    14:50:58 RTP > [02000021] Rx packet loss detected (1 packets)
    14:50:58 RTP > [00f65590] Rx Nte: Pt: 101 Time: 296409 M: 0
    14:50:58 RTP > [02000021] Rx packet loss detected (1 packets)
    14:50:58 RTP > [00f65590] Rx Nte: Pt: 101 Time: 296409 M: 0
    14:50:58 FXO > [fxo 0 0 0/fxo 0] Dispatching event ‘Timeout’ in state ‘FlashHook’
    14:50:58 FXO > [fxo 0 0 0/fxo 0] Action ‘Off-Hook’
    14:50:58 FXO > [0 0] Driver: Setting port state to ‘OffHook’
    14:50:58 FXO > [fxo 0 0 0/fxo 0] Transition ‘FlashHook’ -> ‘OffHook’
    14:50:58 RTP > [02000021] Rx packet loss detected (1 packets)
    14:50:58 RTP > [00f65590] Rx Nte: Pt: 101 Time: 296409 M: 0
    14:50:58 RTP > [00f65590] Rx Nte: Pt: 101 Time: 296409 M: 0
    14:50:58 RTP > [00f65590] Rx Nte: Pt: 101 Time: 296409 M: 0
    14:50:58 NTE > Scheduler: Add to unregister list 0x00f65b00
    14:50:58 NTE > Scheduler: Unregistered element: 00f65b00
    14:50:58 NTE > [00f65b00] Rx: Event stop: flash Duration [ms]: 100
    14:50:58 RTP > Termination [2000021] Dtmf update to application.
    14:50:58 DP > RTP-00/0021: event(DTMF/ToneUpdate-Event)
    14:50:58 NTE > [00f65b00] Rx: Unregister notify.
    14:50:58 NTE > Scheduler: Unregister element 0x00f65b00
    14:50:58 CC > [EP IF_SIP-00b0f948/active] Invoke service: User Input Update (Duration: 100)
    14:50:58 CFXO > [EP IF_FXO_0] State ACTIVE, event USER INFO UPDATE
    14:50:58 DP > FXO-00/00: signal(Dtmf/ToneUpdate-Signal)
    14:50:58 RTP > [02000021] Rx packet loss detected (3 packets)
    14:50:58 SIP_TR> [STACK] < 479 Stack: from 172.16.0.100
    INFO sip:103@172.16.3.90:5060;transport=udp SIP/2.0
    Via: SIP/2.0/UDP 172.16.0.100:5060;branch=z9hG4bK-524287-1—bd67357cf315fa15;rport
    Max-Forwards: 70
    Contact:
    To: “Trunk 3”;tag=bc2bd326f1
    From: ;tag=7c0f9955
    Call-ID: 41d8a485ee194d01
    CSeq: 14 INFO
    Content-Type: application/dtmf-relay
    User-Agent: 3CXPhoneSystem 15.0.60903.0 (60821)
    Content-Length: 25

    Signal=16
    Duration=300

    14:50:58 SIP_SI> [EP IF_SIP-00b0f948 SES 0x13e2c68] [EP IF_SIP-00b0f948 SES 0x13e2c68] [EP IF_SIP-00b0f948 SES 0x13e2c68] DTMF-Signal=16, Duration=300
    14:50:58 SIP_SI> [EP IF_SIP-00b0f948 SES 0x13e2c68] Update packet for destination: 172.16.0.100:5060
    14:50:58 SIP_SI> [EP IF_SIP-00b0f948 SES 0x13e2c68] —————————————————
    14:50:58 SIP_SI> [EP IF_SIP-00b0f948 SES 0x13e2c68] Updating Traffic-Class : local-default
    14:50:58 SIP_SI> [EP IF_SIP-00b0f948 SES 0x13e2c68] Update invite transaction timeout : 32
    14:50:58 SIP_SI> [EP IF_SIP-00b0f948 SES 0x13e2c68] Update non-invite transaction timeout : 32
    14:50:58 SIP_SI> [EP IF_SIP-00b0f948 SES 0x13e2c68] Updating Local UDP Address : 172.16.3.90:5060
    14:50:58 SIP_SI> [EP IF_SIP-00b0f948 SES 0x13e2c68 SDP] Updating Datapath Controllers : 172.16.3.90
    14:50:58 SIP_TR> [STACK] > 398 Stack: to 172.16.0.100
    SIP/2.0 200 OK
    Via: SIP/2.0/UDP 172.16.0.100:5060;branch=z9hG4bK-524287-1—bd67357cf315fa15;rport=5060;received=172.16.0.100
    From: ;tag=7c0f9955
    To: “Trunk 3”;tag=bc2bd326f1
    Call-ID: 41d8a485ee194d01
    CSeq: 14 INFO
    Server: Patton SN4112 JO EUI 00A0BA0BEA75 R6.9 2016-12-27 H323 SIP FXS FXO M5T SIP Stack/4.2.14.18
    Content-Length: 0

    14:50:59 RTP > [02000021] RTCP TX (SR) Timestamp=1639676230
    14:50:59 RTP > [02000021] Local TX-Info: packets=1907, octets=305120
    14:50:59 RTP > [02000021] Local RX-Info: packets=1911, octets=305760, lost=8, jitter=9, since last=0mS
    14:51:00 Dejit > [0xf80028] INFO : Packet loss is 1/102 (19/1950)
    14:51:02 RTP > [00f65590] Rx Nte: Pt: 101 Time: 327457 M: 1
    14:51:02 NTE > [00f65b00] Rx: Event start: flash
    14:51:02 RTP > Termination [2000021] Dtmf to application !
    14:51:02 DP > RTP-00/0021: event(DTMF/Tone-Event ‘!’)
    14:51:02 NTE > Scheduler: Register element 0x00f65b00
    14:51:02 NTE > Scheduler: Registered new element: 00f65b00
    14:51:02 Dejit > Flushing
    14:51:02 CC > [EP IF_SIP-00b0f948/active] Invoke service: User Input: ! (Duration: 2000)
    14:51:02 CFXO > [EP IF_FXO_0] State ACTIVE, event USER INFO
    14:51:02 CFXO > [EP IF_FXO_0] Sending user input to terminal: ! (2000 ms)
    14:51:02 FXO > [fxo 0 0 0/fxo 0] Dispatching event ‘ApplFlashHook’ in state ‘OffHook’
    14:51:02 FXO > [fxo 0 0 0/fxo 0] Action ‘Start Flash-Hook-Timer’ ( 100ms )
    14:51:02 FXO > [fxo 0 0 0/fxo 0] Action ‘Flash-Hook’
    14:51:02 FXO > [0 0] Driver: Setting port state to ‘OnHook’
    14:51:02 FXO > [fxo 0 0 0/fxo 0] Transition ‘OffHook’ -> ‘FlashHook’
    14:51:02 RTP > [02000021] Rx packet loss detected (1 packets)
    14:51:02 RTP > [00f65590] Rx Nte: Pt: 101 Time: 327457 M: 0
    14:51:02 RTP > [02000021] Rx packet loss detected (1 packets)
    14:51:02 RTP > [00f65590] Rx Nte: Pt: 101 Time: 327457 M: 0
    14:51:02 RTP > [02000021] Rx packet loss detected (1 packets)
    14:51:02 RTP > [00f65590] Rx Nte: Pt: 101 Time: 327457 M: 0
    14:51:02 RTP > [02000021] Rx packet loss detected (1 packets)
    14:51:02 RTP > [00f65590] Rx Nte: Pt: 101 Time: 327457 M: 0
    14:51:02 FXO > [fxo 0 0 0/fxo 0] Dispatching event ‘Timeout’ in state ‘FlashHook’
    14:51:02 FXO > [fxo 0 0 0/fxo 0] Action ‘Off-Hook’
    14:51:02 FXO > [0 0] Driver: Setting port state to ‘OffHook’
    14:51:02 FXO > [fxo 0 0 0/fxo 0] Transition ‘FlashHook’ -> ‘OffHook’
    14:51:02 SIP_TR> [STACK] < 479 Stack: from 172.16.0.100
    INFO sip:103@172.16.3.90:5060;transport=udp SIP/2.0
    Via: SIP/2.0/UDP 172.16.0.100:5060;branch=z9hG4bK-524287-1—691e8b382a3a7d5c;rport
    Max-Forwards: 70
    Contact:
    To: “Trunk 3”;tag=bc2bd326f1
    From: ;tag=7c0f9955
    Call-ID: 41d8a485ee194d01
    CSeq: 15 INFO
    Content-Type: application/dtmf-relay
    User-Agent: 3CXPhoneSystem 15.0.60903.0 (60821)
    Content-Length: 25

    So my question is:
    How we can adjust the time on:
    Action ‘Start Flash-Hook-Timer’ ( 100ms )
    from 100ms to other value like 150ms (motofs PBXes) or 650ms (for Panasonic)?

    I appreciate any help!

    Best

    Mihajlo

  14. very simple and to the point well written thank you Andrew

  15. Hi Andrew, can you please explain to me the difference between payload type: telephone-event-101 and payload type: DynamicRTP-Type-101 ?? I have a current fault where telephone event tones work but Dynamic ones do not. Struggling to find out exactly what the difference is. Thanks, Tony

  16. What if you see a=fmtp:101 0-15 and not a=fmtp:101 0-16. What would the 0-15 represent ?

    Thanks

    1. That was previously discussed in this article’s comments.

    2. AJ, a=fmtp:101 0-15 would represent DTMF digits 0-9, * # and A, B, C, D, in most pbx systems today the ABCD buttons are no longer used but still are accounted for in a numerical order since they are still used by other systems that may connect to the pbx such as two-way radios etc. Hope this helps.

  17. how to find out where dtmf (rfc2833) is lost in Cisco ASA 5510? Sip provider is sending them, Samsung officeserv 7200 is set to receive them, but they never arrive.

  18. hi there,

    im working with a Patton SN4971/1E24V in Florida, and i keep having the issue that callers from different providers when they hit the IVR no input is detected even if the caller actually press any option, keeping the call in an loop while the message replays.

    Right now im using Rfc2833 with codec G.711u – G.711a would it make sense to change to inband?

    1. Someone should do a SIP trace to see if the 2833 digits are coming through.

  19. David Hasemore · · Reply

    Hi Andrew,

    Firstly an excellent read – very clear and informative!

    We have a voice network using SIP and TDM, however most of our customer base is SIP. I’ve come across a fault (might not be a fault) with one of our customers DTMF requirements. Basically we interconnect to them with SIP, they use a packet service profile which contains G711a and 2833 for DTMF relay whereas as on our side only G711a with default Inband for DTMF.

    During call set up I can see both offerings in their SDP profile, see below.

    m=audio 6562 RTP/AVP 8 101 18 0
    a=rtpmap:8 PCMA/8000
    a=rtpmap:101 telephone-event/8000
    a=fmtp:101 0-15

    Our responding SDP in a 180 ringing message will only show

    m=audio 50680 RTP/AVP 8
    a=rtpmap:8 PCMA/8000

    This is to be expected as per negotiation.

    When the call establishes, and the customer send DTMF digits I can hear these in media traces, however it would appear that only the 1st digit is recognised by the far end and then all subsequent digits are ignored.

    I was advised that without 2833 enabled on our side all DTMF digits would be accepted via G711 inband, in other words rtpmap 101 would not be used and the method would fall back to inband.
    But that doesn’t appear to be case here.

    Would you be able to shed any light on this? It’s either behaving correctly because it isn’t possible to fall back or I have a fault on my hands.

    Look forward to our reply.

    Regards,
    David

    1. Without 2833 the DTMF digits will be send as audio tones and if I am understanding you correctly, that is exactly what is occurring. 2833 would allow them to be sent as digital representations in a separate RTP stream.

      1. David Hasemore · ·

        Thanks for the prompt reply Andrew.

        I understand that the digits would be transmitted as audio tones in the same RTP path as speech without 2833.

        My query is more to do with how DTMF is resolved during negotiation when one end point does not support 2833, as per the scenario above.
        The fault I described above seems to only occur when there is a mis-match of 2833. I would’ve thought that the endpoints would settle on g711 inband as they are a matched codec

  20. If 2833 is not accepted nor advertised by the receiving end, then G.711 should be used. From what you wrote, it appears to be used, but the receiving end is not able to properly handle it.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

w

Connecting to %s

%d bloggers like this: