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

29 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.

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 )

Twitter picture

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

Facebook photo

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

Google+ photo

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

Connecting to %s

%d bloggers like this: