GCE-TAC Internal Training DOC

Troubleshooting DTMF
By Avinash Sridhar || Kaustubh Inamdar CSE TAC

INDEX
1) Isolating the Issue with DTMF
2) OOB NTE Inband DTMF Issues
I.
INTRODUCTION
II.
DTMF ANALYSIS FROM CUCM TRACES
III.
DTMF TO IVR SYSTEMS LIKE UCCX, UNITY
3) SIP DTMF What to look for ?
4) H323 What to look for ?
5) IP-IP / IP-Analog Gateway DTMF Issues
I.
IP-IP Gateway
II.
IP Analog Gateway
III.
Analyzing in-band DTMF using packet captures
6) MGCP
7) How DTMF can break calls

Isolating the issue with DTMF

To isolate issues with DTMF, we need to determine at which point the DTMF is not being passed across.
Take an example below :
X --- (OOB SCCP)--- CUCM ---(rtp-nte)--- CUBE 1 ---(rtp-nte)--- CUBE 2 ---(rtp-nte)--- IVR System
Say the IVR System is not receiving the DTMF tones pressed by X user. We need to determine where the
DTMF is broken and at which point the failure happens first. Assume we find on CUCM, the OOB band
DTMF being used. MTP is required in such a scenario and if we notice failure in allocation of resource,
we have isolated the problem to be on the CUCM.
If we are analyzing DTMF with 4-5 VOIP devices between source and destination, it is best to to analyze
the DTMF from destination to source side one at a time. In the above eg. I would move from analyzing
CUBE 2 to the CUCM, one at a time to isolate DTMF failure.
I

Check dtmf-relay mechanism on both the voip legs always for every device.
If there is In-Band NTE to Out of Band DTMF (vice versa) conversion happening on CUCM, ensure
MTP Allocation happens without any failures. Most cases, we see Out Of Band to RFC2833 DTMF
Conversion failing due to CUCM failing to allocate MTP correctly. Fixing the MTP can resolve
most DTMF issues.
Check SIP / H.323 Signalling on both legs always to verify which DTMF mechanisms are being
used.

Jotting below the common DTMF mechanisms for SIP, H.323, MGCP respectively :
S
I

SIP-Notify ( Out of Band )

SIP-KPML ( Out of Band )
RTP-NTE ( In Band telephony event)

H245 Signal ( Similar to below, but adds an extra duration field in the H245 message )
H245 Alphanumeric

Out of Band ( Using NTFY messages )

NSE ( RFC 2833 Mechanism - Inband telephony event)
Cisco Proprietary mechanism using payload 121

OOB Inband NTE DTMF Issues

I.

INTRODUCTION

As discussed previously, OOB <-> Inband NTE conversion requires a MTP. DTMF relay by NTE mechanism
is common with SIP Signalling.
C

If the endpoint is a phone, verify the DTMF mechanisms supported by the phone. For eg. most
IP phones support RFC2833 and SCCP Out Of Band DTMF, the 7936 however supports only OOB
DTMF.
In the case of SIP Trunk, always verify the configured DTMF Method / DTMF Signalling
Method on SIP Trunk Configuration page :

Verify the default payload type used for telephony-event under the SIP Profile ( for trunk ), we
can use an alternate value too if needed :

Check in logs/traces what H323 DTMF Signalling is used.

http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/srnd/8x/media.html#wp1055839
http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/srnd/8x/media.html#wp1046314
*It is important to note that DTMF can break calls too by unnecessary allocating MTPs if there is a
mismatch in the DTMF capabilityies between endpoints. We will discuss that in later part of document.

II.

DTMF ANALYSIS FROM CUCM TRACES

AuConnectRequest for two parties:

22:56:25.299 |SIG-MediaManager-(106)::wait_AuConnectRequest, CI(24374238,24374239),

capCount(12,1), mcNodeId(0,0), xferMode(4,16), reConnectType(0), mrid (0, 0) IFCreated(0 0) proIns(0
0), AC(0,0) party1DTMF(1 1 0 0 0) party2DTMF(1 2 101 1 0),reConnFlag=0, connType(3,3),
IFHand(0,0),MTP(0,0),MRGL(,) videoCap(0 0), mmCallType(0),FS(0,0) IpAddrMode(0 0) aPid(1, 57, 50),
bPid(1, 74, 101) EOType(0 2) MOHAnnConnType(0 0)|1,100,63,1.26116^10.106.114.80^*

Look at party1DTMF and party2DTMF and figure out if MTP is needed. If CUCM finds out that
either party can negotiate a common capability, it will not allocate MTP. In the above case since
party 1 supports only OOB and party 2 supports In-Band, MTP will come into picture.

Alternatively it is also possible that every call uses a MTP if the MTP Required option is
checked on SIP Trunk. From above, we would see MTP(0,2) if party 2 had the checkbox ticked.
Use the below link to familiarize with the enum values from partyDTMF parameter :
http://zed.cisco.com/confluence/display/CCM/How+to+Tell+if+an+MTP+is+being+allocated+due+to+DT
MF+requirements

Determining SIP Trunk DTMF Caps :

20:02:17.441 |SIP DTMF Info: mLocalDtmfCaps...UNSOL=1, KPML=1, Inband=0(0)

mEndppointsDtmfCaps...UNSOL=0, KPML=0, Inband=1(101) mDefaultTelephonyEvent=101,
mDtmfPreference=1, mMtpAllocated=1|*^*^*
mDefaultTelephonyEvent : Configured under SIP Profile
mLocalDtmfCaps : Local side DTMF Capabilities, in this case only KPML and OOB is supported.
mEndppointsDtmfCaps : Caps of endpoint
The mEndppointsDtmfCaps would get updated once we know the capabilities of the other side of the
SIP Trunk ie. When we get a response from other side with their DTMF capabilities in the SDP.
Another message that is quite helpful is :
20:02:06.981 |setLocalDtmfCaps: supportedDTMFMethod=1, mWantDtmfReception=1,
mPeersWantDtmfReceptionFlag=1, mDtmfPreference=1|*^*^*
supportedDTMFMethod = 1  OOB
supportedDTMFMethod=2  RFC2833
supportedDTMFMethod=3  RFC2833_OOB

H.323 :

Check the H245 userInfoRequest message that goes out / comes in. CUCM by default uses H.245 Signal
for outbound DTMF signaling, eg.
15:22:54.492 |
H245ASN - TtPid=(7413) -Outgoing #66273 -value MultimediaSystemControlMessage ::= indication :
userInput : signal :
{
signalType "5",
duration 100
}
|*^*^*

If we were to use alphanumeric mode, we wouldnt see the duration field in the above message and
the userInput would be alphanumeric .

Checking for MTP allocation :

If MTP is getting allocated due to DTMF, look for the following line that is generally printed by
MediaManager:
20:02:17.442 |DET-MediaManager-(111)::isMTPNeededForMismatchOrConfig,
MTPNeededDueToDTMFCapMismatch(2833/OOB) mtpinsertionReason=1
dtmfMTPSide=2|1,100,63,1.26950^10.106.114.80^*
If we are facing trouble with MTP Allocation, the follow links are very helpful :
https://techzone.cisco.com/t5/Media-Resources/Understanding-AllocateMtpResourceErr/ta-p/135106
https://techzone.cisco.com/t5/General/MTPNeededForDTMF-Enum-Values-in-SDI/ta-p/65620
https://techzone.cisco.com/t5/General/Understanding-DTMF-negotiation-from-SDI-CCM-traces/tap/37759
https://techzone.cisco.com/t5/Media-Resources/Media-Resource-Manager-FAQs/ta-p/53520

Checking flow of DTMF Tones in traces :

Digit going OOB  SIP Trunk  RFC2833 : In this case, we will see the digit going as a ccUserInfoReq to
SIPCdpc, following which it will get passed on to SIPInterface as SIPOutgoingDTMFTone. Since MTP is
involved in this call, this signal is then passed from SIP Layer to the MediaTerminationPointControl as
MXOutgoingDTMFTone. Eg.
001512705 |2012/10/21 22:19:21.477 |100 |SdlSig |CcUserInfoReq
|active
|SIPCdpc(1,100,74,113)
|SIPD(1,100,73,14)
|1,100,13,1622.731^10.106.117.57^SEP0004F2E3889A |[R:N-H:0,N:0,L:0,V:0,Z:0,D:0] CI=24374275

CI.branch=0 isDtmf=T isTone=F tone=0 duration=0 PortToPort=0 isFeat=F isMTPPassThru2833=F

featType=0 TTLFlag=F TTLCount=0
001512706 |2012/10/21 22:19:21.477 |100 |SdlSig |SIPOutgoingDTMFTone
|sessionEstablished
|SIPInterface(1,100,68,64)
|SIPCdpc(1,100,74,113)
|1,100,13,1622.731^10.106.117.57^SEP0004F2E3889A |[R:N-H:0,N:0,L:0,V:0,Z:0,D:0] tone=3
isMTPPassingThru2833=F
001512707 |2012/10/21 22:19:21.477 |100 |SdlSig |MXOutgoingDTMFTone
|interfacesEstablished
|MediaExchange(1,100,135,118) |SIPInterface(1,100,68,64)
|1,100,13,1622.731^10.106.117.57^SEP0004F2E3889A |[R:N-H:0,N:0,L:0,V:0,Z:0,D:0] tone=3 CI=0
confId=158815141 passthruPartyID=0xb676ea50 isMTPPassingThru2833=F
Only once the signal hits MediaTerminationPointControl, can we confirm that tone has gone all the way
to the MTP. This MTP would convert the tone to in-band and send it out.
In case the tone is incoming, the exact reverse would be seen in traces.
In SDI, for the same sequence of above events we would see :
22:19:21.477 |//SIP/SIPCdpc(1,74,113)/ci=24374275/ccbId=26893/scbId=0/star_CcUserInfoReq:
Outbound DTMF method selected is 2. Digit=3 and
isMTPPassingThru2833=0|1,100,13,1622.731^10.106.117.57^SEP0004F2E3889A
22:19:21.477 |//SIP/SIPCdpc(1,74,113)/ci=24374275/ccbId=26893/scbId=0/sendDtmfVia2833: sending
sipOutgoingDTMFTone Tone 3 for digit 3.|1,100,13,1622.731^10.106.117.57^SEP0004F2E3889A
22:19:21.477 |MediaTerminationPointControl(10)::star_MediaExchangeOutgoingDTMFTone tone=3,
conferenceID=16777223, passthruID=16777396 |1,100,13,1622.731^10.106.117.57^SEP0004F2E3889A
The Outbound DTMF metod selected gives us a good idea about DTMF Selection too. Here are the
corresponding enums for that:
num SelectedMethod
{
SIPDTMF_NONE = 0,
SIPDTMF_2833NOMTP,
SIPDTMF_2833MTP,
SIPDTMF_KPML,
SIPDTMF_UNSOL,
SIPDTMF_KPML_2833NOMTP,
SIPDTMF_KPML_2833MTP
};
Digit going RFC2833 In-Band  MTP  H245 Signal :
Here after digit comes in band to MTP, it gets converted to OOB, and here is what we will see in SDI :
15:22:56.178 |StationInit: (0000001) StationNotifyDtmfToneMessage tone=9 conferenceID=16785297,
passthruID=16793046|1,100,56,1.24292838^10.108.13.8^MTP_2
15:22:56.179 |

H245ASN - TtPid=(7413) -Outgoing #66274 -value MultimediaSystemControlMessage ::= indication :

userInput : signal :
{
signalType "9",
duration 100
}
|*^*^*

S
I

012306471 |2012/12/27 15:22:56.178 |100 |SdlSig |StationNotifyDtmfTone

|waiting
|MediaTerminationPointControl(1,100,127,1) |StationInit(1,100,56,1)
|1,100,56,1.24292838^10.108.13.8^MTP_2 |[R:N-H:0,N:0,L:0,V:0,Z:0,D:0] Tone=9
ConferenceID=16785297 PassthruPartyID=16793046
012306473 |2012/12/27 15:22:56.178 |100 |SdlSig |MXIncomingDTMFTone
|sessionEstablished
|MTPAgenaInterface(1,100,225,49)
|MediaTerminationPointControl(1,100,127,1) |1,100,56,1.24292838^10.108.13.8^MTP_2 |[R:NH:0,N:0,L:0,V:0,Z:0,D:0] tone=9 confId=16785297 passthruPartyID=1003dd6 isMTPPassingThru2833=F
012306484 |2012/12/27 15:22:56.178 |100 |SdlSig |CcUserInfoReq
|active10
|H225Cdpc(1,100,184,8367)
|H225D(1,100,183,1)
|1,100,56,1.24292838^10.108.13.8^MTP_2 |[R:N-H:0,N:0,L:0,V:0,Z:0,D:0] CI=20332846 CI.branch=0
isDtmf=T isTone=F tone=0 duration=0 PortToPort=0 isFeat=F isMTPPassThru2833=F featType=0
TTLFlag=F TTLCount=0
012306488 |2012/12/27 15:22:56.179 |100 |SdlSig |SMH245UserInputIndication
|wait
|H245Handler(1,100,29,1)
|TranslateAndTransport(1,100,21,7413)
|1,100,56,1.24292838^10.108.13.8^MTP_2 |[T:N-H:0,N:0,L:0,V:0,Z:0,D:0]
*Note that the above MTP was allocated by an incoming SIP Trunk due to the DTMF mismatch. 5-6 lines
of SDL have been omitted to indicate key events.*
III.

DTMF TO IVR SYSTEMS LIKE UCCX, Unity :

In the case of UCCX, since a CTI Routepoint is involved, the DTMF will always go Out Of Band to the
system. So if incoming leg is using RFC2833, MTP is mandatory to get DTMF working. The below
documentation explains this :
http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/srnd/8x/media.html#wp1233309
You may also refer Abhirams Techzone document that explains this pretty neatly :
https://techzone.cisco.com/t5/Call-Routing-and-Agent-Control/How-DTMF-works-in-UCCX-and-whendoes-an-MTP-have-to-be-used/ta-p/156316
In the case of Unity and Unity Connection, please refer the below links :
http://www.cisco.com/en/US/docs/voice_ip_comm/unity/tsp/release/notes/tsp811rn.html
http://www.cisco.com/en/US/docs/voice_ip_comm/connection/8x/gui_reference/guide/8xcucgrg120.h
tml

SIP DTMF What to look for ?

Identify types of DTMF mechanism supported on the SIP leg, there can be 2-3 types of DTMF
methods supported by an endpoint too.

CUCM will choose the DTMF on the SIP Trunk based on configured DTMF Signalling Method as
mentioned earlier.

1) SIP KPML ( OOB ) :

Supported only by Cisco Devices.

Cisco SIP Phones use KPML based DTMF.
For KPML DTMF, subscription is necessary by either endpoint for KPML DTMF via SIP SUBSCRIBE
message. Once the Subscription-State is active, we will see KPML DTMF go across as below
when digits are relayed :

Received:
NOTIFY sip:10.75.63.5:5060;transport=tcp SIP/2.0
Date: Tue, 20 Oct 2009 12:58:44 GMT
From: <sip:1034@10.75.63.75>;tag=b600ae1f-74c0-44e4-9eff-fdfb36b7d7b7-24549383
Event: kpml
Content-Length: 336
User-Agent: Cisco-CUCM6.1
To: <sip:119@10.75.63.5>;tag=A7EF92FC-1DB1
Contact: <sip:1034@10.75.63.75:5060;transport=tcp>
Content-Type: application/kpml-response+xml
// INDICATING KPML
Call-ID: 489b4580-add1b400-9-4b3f4b0a@10.75.63.75
Subscription-State: active;expires=7198
Via: SIP/2.0/TCP 10.75.63.75:5060;branch=z9hG4bK323a9c70a1
CSeq: 103 NOTIFY
Max-Forwards: 70
<?xml version="1.0" encoding="UTF-8" ?>
<kpml-response xmlns="urn:ietf:params:xml:ns:kpml-response"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:ietf:params:xml:ns:kpmlresponse kpml-response.xsd" code="200" digits="5" forced_flush="false" suppressed="false" tag="dtmf"
text="Success" version="1.0"/>
Sent:
SIP/2.0 200 OK
Via: SIP/2.0/TCP 10.75.63.75:5060;branch=z9hG4bK323a9c70a1
From: <sip:1034@10.75.63.75>;tag=b600ae1f-74c0-44e4-9eff-fdfb36b7d7b7-24549383
To: <sip:119@10.75.63.5>;tag=A7EF92FC-1DB1
Date: Wed, 20 Oct 2010 10:22:34 GMT
Call-ID: 489b4580-add1b400-9-4b3f4b0a@10.75.63.75
CSeq: 103 NOTIFY

2) SIP-NOTIFY ( OOB ) :

Similar to KPML DTMF, except :

o We wont see a SUBSCRIBE happening for NOTIFY mechanism.
o We cannot see the XML content of digits that are pressed.
Third party SIP Devices can use this mechanism to transmit DTMF.

An eg.
Received:
NOTIFY sip:10.75.63.5:5060 SIP/2.0
Date: Tue, 20 Oct 2009 13:00:43 GMT
From: <sip:1034@10.75.63.75>;tag=b600ae1f-74c0-44e4-9eff-fdfb36b7d7b7-24549385
Event: telephone-event
Content-Length: 4
User-Agent: Cisco-CUCM6.1
To: <sip:119@10.75.63.5>;tag=A7F15BC8-E1B
Contact: <sip:10.75.63.75:5060>
Content-Type: audio/telephone-event
// INDICATING TELEPHONY EVENT
Call-ID: 8e580e00-add1b475-a-4b3f4b0a@10.75.63.75
Subscription-State: active
Via: SIP/2.0/UDP 10.75.63.75:5060;branch=z9hG4bK38336558a4
CSeq: 102 NOTIFY
Max-Forwards: 70
*Oct 20 10:24:33.093: //-1/xxxxxxxxxxxx/SIP/Msg/sipDisplayBinaryData:
Receiving: Binary Message Body
*Oct 20 10:24:33.093: Content-Type: audio/telephone-event
05 00 01 F4
*Oct 20 10:24:33.093: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Sent:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 10.75.63.75:5060;branch=z9hG4bK38336558a4

3) RFC2833 Based ( RTP-NTE ) :

In-Band
Commonly used payload is 101. This can be altered in CUCM using SIP Profiles or in CUBE by
changing payload type under dial-peers.

Under SDP, look for the payload 101 that generally comes and check if it corresponds to telephoneevent. Eg.
SIP/2.0 183 Session Progress
Via: SIP/2.0/TCP 10.106.117.2:5060;branch=z9hG4bK967f5d700c
From: <sip:3011@10.106.117.2>;tag=26893~d3934981-803b-459e-8641-e9ed9faae81e-24374275
To: <sip:999@10.106.114.80>;tag=71902~44c5f4f6-28dc-48ec-9e85-9428f04621ed-30501601
Date: Mon, 22 Oct 2012 05:19:01 GMT
Call-ID: fbcf5600-841d745-6f-2756a0a@10.106.117.2

CSeq: 101 INVITE

Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY
Allow-Events: presence
Supported: X-cisco-srtp-fallback
Supported: Geolocation
P-Asserted-Identity: <sip:999@10.106.114.80>
Remote-Party-ID: <sip:999@10.106.114.80>;party=called;screen=yes;privacy=off
Contact: <sip:999@10.106.114.80:5060;transport=tcp>
Content-Type: application/sdp
Content-Length: 473
v=0
o=CiscoSystemsCCM-SIP 2000 1 IN IP4 10.106.114.80
s=SIP Call
c=IN IP4 10.106.114.120
b=TIAS:64000
b=AS:64
t=0 0
m=audio 22204 RTP/AVP 0 8 116 18 101 // Payload 101 corresponding to telephone-event below
a=rtpmap:0 PCMU/8000
a=ptime:20
a=rtpmap:8 PCMA/8000
a=ptime:20
a=rtpmap:116 iLBC/8000
a=ptime:20
a=maxptime:20
a=fmtp:116 mode=20
a=rtpmap:18 G729/8000
a=ptime:20
a=fmtp:18 annexb=no
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15

In the case of raw in-band DTMF, the payload will not be mentioned and the DTMF will be sent within
the voice stream. Generally, the DTMF tone must be of duration 100-250 ms, else Telco might not
recognize it.
*Refer previous section on what to look for traces in SIP Stack*

H323 What to look for ?

When DTMF originates from CUCM, H245 Signal is used.

From gateway side, the dtmf can originate as either H245 Alphanumeric or Signal based on what
is configured in the dial peers. Signal takes precedence however over alphanumeric.
CUCM supports only Out-of-Band DTMF mechanism for H323, however note that for gateways /
CUBE, it is possible to use in-band RFC2833 mechanism too for DTMF. Take the eg. of CUBE < -- >
CUBE scenario. For RFC2833 support of H323 device, look for something like this in the TCS :

Capability receiveRTPAudioTelephonyEventCapability :
{
dynamicRTPPayloadType 101
audioTelephoneEvent "0-16
}
Here is an eg. of DTMF using H245 Signal :
10/20/2009 20:00:38.320 CCM|H245ASN - TtPid=(1,100,14,1) -Incoming -value
MultimediaSystemControlMessage ::= indication : userInput : signal :
{
signalType "2",
duration 4000,
rtp
{
timestamp 3245215934,
logicalChannelNumber 1
}
Below is an eg. for DTMF using Alphanumeric mode :
10/20/2009 20:15:52.066 CCM|H245ASN - TtPid=(1,100,14,4) -Incoming -value
MultimediaSystemControlMessage ::= indication : userInput : alphanumeric : "4"
Troubleshoot checkpoints :

Check DTMF Relay configured at every endpoint and verify at which point the DTMF breaks or
tones dont pass through.
Again, take care of in-band to OOB conversion and use previous chapter to check if MTP gets
selected when needed.

IP-IP / IP-Analog Gateway DTMF Issues

1) IP IP Gateway :
I find the 3 tables below very helpful for DTMF interworking :
SIP < - > SIP
IN LEG

OUT LEG

NOTIFY

NOTIFY

RFC2833

RFC2833

NOTIFY

RFC2833

Voice inband

RFC2833

IN LEG

OUT LEG

KPML

KPML

H245alphanumeric

H245alphanumeric

H245-signal

H245-signal

RFC2833

RFC2833

H323 < - > SIP

IN LEG

OUT LEG

H245alphanumeric

RFC2833

H245alphanumeric

NOTIFY

H245-signal

RFC2833

H245-signal

NOTIFY

Voice inband

RFC2833

RFC2833

NOTIFY

H245alphanumeric

RFC2833

H245-signal

RFC2833

RFC2833

RFC2833

Voice inband

RFC2833

H245-alpha

KPML

H245-Signal

KPML

H323 < - > H323

*Text in GREEN implies transcoder is required*

Key Debugs :

Debug voip ccapi inout

Debug h245 asn1
Debug ccsip messages
Debug voip dspapi inout
Debug voip hpi inout
Debug voip rtp session named-events

Eg. for Checking if DTMF goes through perfectly :

Ccapi layer :

Dec 27 20:24:19.104: //73918/xxxxxxxxxxxx/CCAPI/cc_api_call_digit_begin:

Consume mask is not set. Relaying Digit 4 to dstCallId 0x120BF
Dec 27 20:24:19.204: //73918/xxxxxxxxxxxx/CCAPI/cc_api_call_digit_end:
Consume mask is not set. Relaying Digit 4 to dstCallId 0x120BF

H245 :

Dec 27 20:24:19.104: H245 MSC INCOMING PDU ::=

value MultimediaSystemControlMessage ::= indication : userInput : signal :
{
signalType "4"
duration 100
}
If alphanumeric is used, you will see alphanumeric printed in the userInput field. We will not see the
duration field either.

Dspapi inout :

1179339: Jan 4 19:14:54.022: //76521/80C95100BB13/DSPAPI/[0/1:2]/dsp_voice_digit_begin:

Digit=8
Type=0, Playout mode=0, Start=0, End=0
1179340: Jan 4 19:14:54.122: //76521/80C95100BB13/DSPAPI/[0/1:2]/dsp_voice_digit_end:
Duration=100(ms)
1179341: Jan 4 19:14:54.382: //76521/80C95100BB13/DSPAPI/[0/1:2]/dsp_voice_digit_begin:
Digit=2
Type=0, Playout mode=0, Start=0, End=0
1179342: Jan 4 19:14:54.482: //76521/80C95100BB13/DSPAPI/[0/1:2]/dsp_voice_digit_end:
Duration=100(ms)

Rtp session named-events :

*Oct 20 10:47:36.205:
s=VoIP d=DSP payload 0x65 ssrc 0x68E sequence 0xD59 timestamp 0x442A0
*Oct 20 10:47:36.205: <<<Rcv> Pt:101 Evt:8
Pkt:08 03 20
*Oct 20 11:34:11.377:
s=DSP d=VoIP payload 0x65 ssrc 0x1C16 sequence 0x6EEB timestamp 0x8448C481
*Oct 20 11:34:11.377:
Pt:101 Evt:8
Pkt:03 00 00 <Snd>>>

The output from "debug voip rtp session named-event" will show the digit sent in 7 packets:
Feb 06 10:03:00.910:
Feb 06 10:03:00.910:
Feb 06 10:03:00.910:
Feb 06 10:03:00.910:
Feb 06 10:03:00.910:
Feb 06 10:03:00.910:
Feb 06 10:03:00.910:

Pt:101
Pt:101
Pt:101
Pt:101
Pt:101
Pt:101
Pt:101

Evt:5
Evt:5
Evt:5
Evt:5
Evt:5
Evt:5
Evt:5

Pkt:04 00 00
Pkt:04 00 00
Pkt:04 00 00
Pkt:04 01 90
Pkt:84 03 20
Pkt:84 03 20
Pkt:84 03 20

<Snd>>>
<Snd>>>
<Snd>>>
<Snd>>>
<Snd>>>
<Snd>>>
<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 (00190 = 400 samples * 1sec /
8000 samples). The number of refresh packets can vary depending on the amount of time the
digit is pressed.
The fifth packet is the endbit packet (84) with a duration of 100ms (00320 = 800 samples * 1sec
/ 8000 samples).
The sixth and seventh packets are redundant packets for packet five.

Sample Capture indicating RFC 2833 events from a phone

The following command on gateway too helps determine the DTMF negotiated 
Avi#show call active voice | in Dtmf
tx_DtmfRelay=inband-voice
Take following into consideration too :

In the cases of RFC2833 OOB DTMF, the dtmf tones are sent twice. To avoid this we configure
digit-drop along with dtmf-relay rtp-nte digit-drop and ensure the dtmf tones are not sent
twic e ( out of band and in-band ) . The in-band digit gets dropped using this command.
For Voice In-band to RFC2833, take care of transcoder allocation. You can use the following
debugs to troubleshoot transcoder allocation :
o Show sccp connections
o Show sccp connection detail
o Debug sccp all
o Debug ephone detail
Ensure the inband voice leg is always configured for g711 codec, however for RTP-NTE this
restriction doesnt apply.
SPI Leg

SPI Leg

Notes

G711a/u + dtmf
inband

G711a/u + rtpnte

Supported; only dtmf

xcoding

G711a/u + dtmf
inband

G729r8 + rtpnte

Supported; both dtmf

and audio xoding are
involved.

G711a/u + dtmf
inband

G726 + rtp-nte

Not supported; audio

xcoding will fail

G729r8 + dtmf
inband

G729r8 + rtpnte

Not Supported;
inband dtmf is
supported only for
g711

2) IP Analog Gateway :
Troubleshooting Checkpoints :
Use PCM Captures on voice-port / dsp to check if corresponding dtmf tones are heard or sent,
you may use the following guide for taking / analyzing PCM Captures :
https://techzone.cisco.com/t5/Analog-TDM-Gateway/Taking-PCM-Captures-on-Voice-Gateways/tap/46190

Ensure dtmf tones are passed correctly from analog  voip, voip  analog side correctly. Use
the voip methods described in previous section to troubleshoot.
On gateway we can use the following debug to verify digit being passed successfully :
o Debug voip vtsp all
o Debug vpm signal

3) Analyzing in band DTMF using packet captures :

After taking a packet capture, open the capture file using Wireshark.
Navigate to
.
Click on

.
Two streams will be displayed, select the direction of stream that we need to analyze, either
voip to Service Provider or vice versa.
Select Analyze  Click Player.
Decode the stream and check if we can hear the DTMF Tones.
T

We can also save the audio file by clicking on Save Payload in the RTP Stream Analysis window.
Select file format as .au or raw inband.

Two good tools to analyze PCM Captures :

Cool Edit Pro  http://www.adobe.com/special/products/audition/syntrillium.html

Audacity  http://audacity.sourceforge.net/

MGCP
In most scenarios, customers use OOB mechanism for MGCP DTMF, which is configured as mgcp dtmfrelay out-of-band on gateway. The DTMF digits are relayed across as RQNT from call-agent to gateway .
Here is an eg. :
*May 5 11:42:17.480: MGCP Packet received from 10.10.10.10:2427--->
RQNT 858 S1/DS1-0/31@HQ-1E1-2811 MGCP 0.1
X: 1f
R: D/[0-9ABCD*#]
S: D/8
Q: process,loop
<--The S package indicates the signal going across, in this case it would be 8. R package indicates the
requested events for DTMF : 0 9, A , B, C, D, *, #.
The D that we see is the digit map and is the same for digit collection or DTMF.
In case the DTMF is detected by gateway, it signals the call agent by sending a NTFY message as follows :
01/11/2013 16:11:34.927 CCM|MGCPHandler received msg from: 10.3.38.2
NTFY 782043944 S0/SU0/DS1-0/2@usirvn-rtrvoip-1D.aaitg.com MGCP 0.1
N: ca@10.3.24.7:2427
X: 2
O: D/3
Troubleshooting checkpoints :

Run debug mgcp packets to check if digit goes across to other end.
There is a possibility that DTMF goes via RFC2833 too, verify if mgcp dtmf-relay nse is
configured on gateway side.
PCM Captures on voice ports help isolating DTMF issues on voice ports in case there are issues
with Service Provider.

Very rarely we see circumstances where customers deploy DTMF relay as Cisco that uses payload 121.
Prefer avoiding this DTMF mechanism during troubleshooting and would straight away suggest to test
using OOB or RFC2833 mechanism for further isolation.

How DTMF can break calls

DTMF can break calls in scenarios where a MTP / transcoder gets allocated during a dtmf mismatch.

We might face unnecessary MTP allocation due to a DTMF mismatch on CUCM, if MTP allocation
fails there is a possibility the call might disconnect. As an alternative we can set the Fail call if
MTP Allocation fails to False to ensure call still progresses after MTP allocation failure.
Normals calls might work, but there might be an issue at times when a conference is initiated.
The conference bridge generally supports only OOB DTMF and hence if the incoming leg uses
RFC2833, MTP will be allocated for every leg with the CFB.
Unecessary allocation of transcoder on CUBE due to DTMF can create wastage of resources and
break calls too.
Also take into consideration calls that go to CTI Route Points as they negotiate only OOB DTMF.
If the incoming leg can support OOB DTMF, always configure OOB else we will bring MTP
resources into picture.