The dance of DTMF, SIP & RFC 2833 – An introduction

Edit 16th September 2015: Please note that 3CX Phone System only works with MS Exchange Server 2013 and 2013 SP1

DTMF (dual tone multi frequency) is the signal to the phone company that you generate when you press an ordinary telephone’s touch keys. In the United States, it’s known as a “Touchtone” phone. DTMF has generally replaced loop disconnect (“pulse”) dialling. With DTMF, each key you press on your phone generates two tones of specific frequencies. So that a voice can’t imitate the tones, one tone is generated from a high-frequency group of tones and the other from a low frequency group. DTMF tones are very much an analog thing, but are still necessary when making phone calls, for example to traverse an auto attendant

DTMF delivery options in SIP

With in a VoIP conversation, DMTF tones are delivered either in-band (as a beep), or out-of-band via SIP or RTP signaling messages. 3CX Phone System supports both

In-band

Incoming stream delivers DTMF signals in-audio independently of codecs – in this case the 3CX Phone System Media Server listens to the audio stream, and will detect DTMF signals.

  1. Delivery to DR or VM: Efficiency of DTMF detection depends on audio quality. Dropped packets will also reduce audio quality.
  2. Delivery to some external party (typically via gateway or provider): DTMF strokes are recognized from the in-audio stream, and delivered to the external party in 2 forms – in-audio (leaving audio content unchanged) and additionally via RFC2833.
  3. Delivery to MS Exchange 2007 IVR: DTMF strokes are recognized from the in-audio stream, and delivered to the external party in 2 forms – in-audio (leaving audio content unchanged) and additionally via RFC2833. Please note that since MS Exchange 2007 IVR does not provide in-audio recognition, it will only use RFC2833 delivery mechanism.

Out-of-band

Incoming stream delivers DTMF signals out-of-audio using either SIP-INFO or RFC-2833 mechanism, independently of codecs – in this case the DTMF signals are sent separately from the actual audio stream.

  1. Delivery to DR or VM: These are passed through as received.
  2. Delivery to some external party (typically via gateway or provider): These are passed through as received. The external party must support the corresponding delivery mechanism if DTMF strokes are to be recognized. Effectively this means that if DTMF is received with SIP-INFO, it is forwarded also as SIP-INFO. If your VoIP Provider requires RFC2833 DTMF delivery, then it will be necessary to ensure all SIP Phones are configured to deliver DTMF using RFC2833.
  3. Delivery to MS Exchange 2007 IVR: These are passed through as received.

Note: SIP-INFO is not recommended for DTMF delivery, since it cannot deliver strokes synchronously with the audio stream, introducing timing artifacts (mainly because it’s delivered using SIP, which is not a real-time mechanism for delivering media). It is very common for public services to NOT support SIP INFO, and it seems unlikely that such services will improve support for this delivery mechanism.

Further information about SIP, SDP

Liked this article?


Get notified of new articles
or share
You might also be interested in: