SIP DTMF Signalling - voip-info.org

SIP DTMF Signalling - voip-info.org

There are 3 common ways of sending DTMF on SIP calls:

- SIP INFO packets

- As specially marked events in the RTP stream

- As normal audio tones in the RTP stream with no special coding or markers.

RFC-2833 defines signalling for various events:

- DTMF tones

- Fax-related tones

- Standard subscriber line tones

- Country-specific subscriber line tones

- Trunk events

NTE means Named Telephony Events. These are the events and their encoding:

Event (0-9) - encoded as 0-9 decimal

Event (*) - encoded as 10 decimal

Event (#) - encoded as 11 decimal

Event (A-D) - encoded as 12-15 decimal

Event (Flash) - encoded as 16 decimal

Etc...

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.