A Networker Blog.-

When carrying them on the SIP Network you could probably see the following methods of conveying these tones across:

1.- Inband:

DTMF are sent using the same RTP stream  as the media is using, and can be heard by carries in a session. Compression Codecs such as G.729 and G.723 may make tones unintelligible so it really works on better codecs like G.711

http://quequero.org/DTMF_decoding#DTMF_decoding_a_naive_approach

2.- RCF 2833:

(config)#dial-peer voice 100 voip

(config-dial-peer)#dtmf-relay ?

…

rtp-nte RTP Named Telephone Event RFC 2833

this is an out of band method that takes DTMF out of the RTP Stream, this means that the DTMF codes works even if the voice stream is compressed. This packets travelling out of band of RTP, hold events that can be understood by UA and regenerated, DTMF-related named events within the  telephone-event payload format.  http://www.ietf.org/rfc/rfc2833.txt

(config-dial-peer)#voice-class sip dtmf-relay force rtp-nte

A hidden command that forces the  “voice-class sip dtmf-relay force rtp-nte” DTMF relay negotiation to rtp-nte and It’s only necessary if the other side doesn’t advertise rtp-nte.

output from deb ccsip media -

000373: Dec  4 02:11:45.727: //55/18EBD6C48068/SIP/Media/sipSPIUpdCallWithSdpInfo:
Stream type             : voice+dtmf
Media line              : 1
State                   : STREAM_ADDING (2)
Callid                  : -1
Negotiated Codec        : g711ulaw, bytes :160
Nego. Codec payload     : 0 (tx), 0 (rx)
Negotiated DTMF relay   : rtp-nte
Negotiated NTE payload  : 101 (tx), 101 (rx)
Negotiated CN payload   : 0
Media Srce Addr/Port    : 10.0.1.5:0
Media Dest Addr/Port    : 192.168.21.31:20424
000374: Dec  4 02:11:45.727: //55/18EBD6C48068/SIP/Info/sipSPIHandleInviteMedia:
Negotiated Codec       : g711ulaw, bytes :160
Preferred Codec        : g711ulaw, bytes :160
Preferred  DTMF relay 1 : 6
Preferred  DTMF relay 2 : 0
Negotiated DTMF relay   : 6
Preferred and Negotiated NTE payloads: 101 101
Preferred and Negotiated NSE payloads: 100 100
Preferred and Negotiated Modem Relay: 0 0
Preferred and Negotiated Modem Relay GwXid: 1 0

output from debug voip rtp session named-event will show digit 5 sent in 7 packets -

Feb 06 10:03:00.910:          Pt:101    Evt:5       Pkt:04 00 00  <Snd>>>
Feb 06 10:03:00.910:          Pt:101    Evt:5       Pkt:04 00 00  <Snd>>>
Feb 06 10:03:00.910:          Pt:101    Evt:5       Pkt:04 00 00  <Snd>>>
Feb 06 10:03:00.910:          Pt:101    Evt:5       Pkt:04 01 90  <Snd>>>
Feb 06 10:03:00.910:          Pt:101    Evt:5       Pkt:84 03 20  <Snd>>>
Feb 06 10:03:00.910:          Pt:101    Evt:5       Pkt:84 03 20  <Snd>>>
Feb 06 10:03:00.910:          Pt:101    Evt:5       Pkt:84 03 20  <Snd>>>

The first packet says that it is the start of a new NTE digit because it does not have the endbit set .

The second and third packets are repeats of the first packet for redundancy.

The fourth packet is a refresh packet with a duration of 50ms (0×0190 = 400 samples * 1sec / 8000 samples).

The fifth packet is the endbit packet (84) with a duration of 100ms (0×0320 = 800 samples * 1sec / 8000 samples).

The sixth and seventh packets are redundant packets for packet five.

in this RFC more events are defined, like for example: Fax related tones, Standard subscriber and Country Specific line tones and Trunk Events

This http://www.rfc-editor.org/rfc/rfc4733.txt supersedes RFC  2833, since  devices do not have to support every tone and event there is, they just simply advertise what they DO support when setting up a a connection

3.- SIP INFO: http://www.faqs.org/rfcs/rfc2976.html

This method is used to carry session control information along the SIP Signaling path during an existing session. SIP info can carry the digits you type without changing the characteristics of the SIP Session.

(config)#dial-peer voice 100 voip
(config-dial-peer)#session proto sip
(config-dial-peer)#dtmf-relay ?
cisco-rtp          Cisco Proprietary RTP
h245-alphanumeric  DTMF Relay via H245 Alphanumeric IE
h245-signal        DTMF Relay via H245 Signal IE
rtp-nte            RTP Named Telephone Event RFC 2833
sip-kpml           DTMF Relay via KPML over SIP SUBCRIBE/NOTIFY
sip-notify         DTMF Relay via SIP NOTIFY messages

you can not configure Cisco SIP-INFO to generate requests for DTMF tones, since this method is Considered Harmful based on http://tools.ietf.org/html/draft-rosenberg-sip-info-harmful-00

The SIP INFO Method for DTMF Tone Generation feature is always enabled, and is invoked when a SIP INFO message is received with DTMF relay content. This feature is related to the SIP NOTIFY-Basec Out-of-Band DTMF Relay Support feature, which provides the ability for an application to be notified about DTMF events using SIP NOTIFY messages. Together, the two features provide a mechanism to both send and receive DTMF digits along the signaling path.