DTMF tones - How to know if they're coming to router or not?

[blackswans]

Hi all,

We have a CME router with a CUE module on it. We have an IVR on CUE. When they call us from outside they drop to IVR. But when it tells dial your extension, when they dial nothing happens. It didnot recognize the digits they dial. But it was working a day ago. So how can I see with the debugs if the DTMF tones are coming to router or not?

Thanks

[Evgeniy.Suvorov]

http://www.cisco.com/en/US/docs/routers/access/1700/1751/software/configuration/guide/Debug.html

Sample Display

The following output shows the call setup indicated and accepted by the router:

router# debug voip ccapi inout

cc_api_call_setup_ind (vdbPtr=0x60BFB530, callInfo={called=, calling=, fdest=0},

callID=0x60BFAEB8)

cc_process_call_setup_ind (event=0x60B68478)

sess_appl: ev(14), cid(1), disp(0)

ccCallSetContext (callID=0x1, context=0x60A7B094)

ccCallSetPeer (callID=0x1, peer=0x60C0A868, voice_peer_tag=2, encapType=1,

dest-pat=14085231001, answer=)

ccCallSetupAck (callID=0x1)

The following output shows the caller entering DTMF digits until a dial-peer is matched:

cc_api_call_digit (vdbPtr=0x60BFB530, callID=0x1, digit=4, mode=0)

sess_appl: ev(8), cid(1), disp(0)

ssa: cid(1)st(0)oldst(0)cfid(-1)csize(0)in(1)fDest(0)

cc_api_call_digit (vdbPtr=0x60BFB530, callID=0x1, digit=1, mode=0)

sess_appl: ev(8), cid(1), disp(0)

ssa: cid(1)st(0)oldst(0)cfid(-1)csize(0)in(1)fDest(0)

cc_api_call_digit (vdbPtr=0x60BFB530, callID=0x1, digit=0, mode=0)

sess_appl: ev(8), cid(1), disp(0)

ssa: cid(1)st(0)oldst(0)cfid(-1)csize(0)in(1)fDest(0)

cc_api_call_digit (vdbPtr=0x60BFB530, callID=0x1, digit=0, mode=0)

sess_appl: ev(8), cid(1), disp(0)

ssa: cid(1)st(0)oldst(0)cfid(-1)csize(0)in(1)fDest(0)

cc_api_call_digit (vdbPtr=0x60BFB530, callID=0x1, digit=1, mode=0)

sess_appl: ev(8), cid(1), disp(0)

ssa: cid(1)st(0)oldst(0)cfid(-1)csize(0)in(1)fDest(0)

ccCallProceeding (callID=0x1, prog_ind=0x0)

ssaSetupPeer cid(1), destPat(14085241001), matched(8), prefix(), peer(60C0E710)

The following output shows the call setup over the IP network to the remote router:

ccCallSetupRequest (peer=0x60C0E710, dest=, params=0x60A7B0A8 mode=0, *callID=0x60B6C110)

ccIFCallSetupRequest: (vdbPtr=0x60B6C5D4, dest=, callParams={called=14085241001,

calling=14085231001, fdest=0, voice_peer_tag=104}, mode=0x0)

ccCallSetContext (callID=0x2, context=0x60A7B2A8)

[Nicholas Matthews]

Hi,

Depends on your DTMF method.

For RFC 2833/rtp-nte enable this debug:

debug voip rtp session named

For SIP Notify use this debug:

debug ccsip messages

For H245 alphanumeric or signal:

debug h245 asn1

For analog ports, use the CCAPI information posted above. The debug in the command lookup seems to be from an older version of IOS, it may not look like this anymore. Regardless, it has lots of lines saying things like 'digit' - very easy to spot.

All of this is probably for nothing, because the more likely problem are these things:

1) Matching wrong incoming dial peer

2) Matching wrong outbound dial peer

3) Do not have dtmf configured on outbound dial peer

4) Do not have the matching DTMF method defined in CUE.

for 1+2, debug voip dial peer.

for 3, make sure you have sip-notify or rtp-nte configured on outgoing dial peer.

for 4, make sure in CUE 'show ccn sub sip' shows your configured DTMF method.

hth,

nick

[virverma]

Few more debugs you can try..

deb mgcp pack

deb voip hpi com

deb voip hpi det

deb voip hpi not

deb voip hpi resp

deb voip vtsp session

deb voip vtsp tone

These debugs can be very verbose/intense on the gateway and should not be allowed

to print to console/monitor or they could negatively impact service.

[Nicholas Matthews]

debug mgcp packet is the only one I forgot to put in there.

For the love of all that is holy, do not use the hpi/vtsp debugs. They are only going to print out 100 extra lines of something you will use in ccapi inout.

I debug some very heavy voice stuff, and I am forced to use hpi/vtsp possibly once or twice a month. These debugs only make things harder to debug. If you know what you're looking for, you do not need these debugs.

hth,

nick