SIP DTMF Signalling

Business SIP Providers
Provider Plan Details Monthly Rate *
Vonage Business SIP Trunking
  • One provider & nationwide coverage
  • Easily integrated into your existing infrastructure
  • More uptime, flexibility and disaster recovery options
$25.00
Details
Implementations of the Session Initiation Protocol (SIP) commonly use four methods for signaling digits between user agent servers and user agent clients:
  • DTMF audio tones in the RTP stream (inband). This requires the use of lossless coders, such as µ-law or A-law.
  • Named Telephone Events (NTEs) are specially marked event payloads in the RTP stream (inband). This is the most commonly implemented and the recommended practice. – see: RFC 4733
  • SIP INFO messages (out-of-band)
  • SIP NOTIFY messages (out-of-band)


RFC 4733 (obsoletes RFC 2833) defines signaling for various events:
  • DTMF tones or loop-disconnect signaling (pulse-dialing) for digits
  • fax-related tones
  • standard subscriber line tones
  • country-specific subscriber line tones
  • trunk events


They start out with:

Event Event encoding (decimal)
0--9 0--9
* 10
# 11
A--D 12--15
Flash 16


and go on from there for other events.

From the introduction in the RFC:


This memo defines two payload formats, one for carrying dual-tone multifrequency (DTMF) digits, other line and trunk signals (Section 3), and a second one for general multi-frequency tones in RTP [1] packets (Section 4). Separate RTP payload formats are desirable since low-rate voice codecs cannot be guaranteed to reproduce these tone signals accurately enough for automatic recognition. Defining separate payload formats also permits higher redundancy while maintaining a low bit rate.

The payload formats described here may be useful in at least three applications: DTMF handling for gateways and end systems, as well as "RTP trunks". In the first application, the Internet telephony gateway detects DTMF on the incoming circuits and sends the RTP payload described here instead of regular audio packets. The gateway likely has the necessary digital signal processors and algorithms, as it often needs to detect DTMF, e.g., for two-stage dialing. Having the gateway detect tones relieves the receiving Internet end system from having to do this work and also avoids that low bit-rate codecs like G.723.1 render DTMF tones unintelligible. Secondly, an Internet end system such as an "Internet phone" can emulate DTMF functionality without concerning itself with generating precise tone pairs and without imposing the burden of tone recognition on the receiver.




  • RFC 2833: RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals (Obsolete)
  • RFC 4733: RTP Payload for DTMF Digits, Telephony Tones, and Telephony Signals
  • RFC 4734: Definition of Events for Modem, Fax, and Text Telephony Signals
  • SIP
  • RTP
  • DTMF
  • Asterisk DTMF

Implementations of the Session Initiation Protocol (SIP) commonly use four methods for signaling digits between user agent servers and user agent clients:
  • DTMF audio tones in the RTP stream (inband). This requires the use of lossless coders, such as µ-law or A-law.
  • Named Telephone Events (NTEs) are specially marked event payloads in the RTP stream (inband). This is the most commonly implemented and the recommended practice. – see: RFC 4733
  • SIP INFO messages (out-of-band)
  • SIP NOTIFY messages (out-of-band)


RFC 4733 (obsoletes RFC 2833) defines signaling for various events:
  • DTMF tones or loop-disconnect signaling (pulse-dialing) for digits
  • fax-related tones
  • standard subscriber line tones
  • country-specific subscriber line tones
  • trunk events


They start out with:

Event Event encoding (decimal)
0--9 0--9
* 10
# 11
A--D 12--15
Flash 16


and go on from there for other events.

From the introduction in the RFC:


This memo defines two payload formats, one for carrying dual-tone multifrequency (DTMF) digits, other line and trunk signals (Section 3), and a second one for general multi-frequency tones in RTP [1] packets (Section 4). Separate RTP payload formats are desirable since low-rate voice codecs cannot be guaranteed to reproduce these tone signals accurately enough for automatic recognition. Defining separate payload formats also permits higher redundancy while maintaining a low bit rate.

The payload formats described here may be useful in at least three applications: DTMF handling for gateways and end systems, as well as "RTP trunks". In the first application, the Internet telephony gateway detects DTMF on the incoming circuits and sends the RTP payload described here instead of regular audio packets. The gateway likely has the necessary digital signal processors and algorithms, as it often needs to detect DTMF, e.g., for two-stage dialing. Having the gateway detect tones relieves the receiving Internet end system from having to do this work and also avoids that low bit-rate codecs like G.723.1 render DTMF tones unintelligible. Secondly, an Internet end system such as an "Internet phone" can emulate DTMF functionality without concerning itself with generating precise tone pairs and without imposing the burden of tone recognition on the receiver.




  • RFC 2833: RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals (Obsolete)
  • RFC 4733: RTP Payload for DTMF Digits, Telephony Tones, and Telephony Signals
  • RFC 4734: Definition of Events for Modem, Fax, and Text Telephony Signals
  • SIP
  • RTP
  • DTMF
  • Asterisk DTMF

Created by: oej, Last modification: Fri 07 of Oct, 2016 (14:28 UTC) by khb
Please update this page with new information, just login and click on the "Edit" or "Discussion" tab. Get a free login here: Register Thanks! - Find us on Google+