cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
54753
Views
25
Helpful
26
Replies

what debug for seeing DTMF tones via CUBE -SIP?

On a 3845 running 12.4 20, the DTMF tones (for menu options) are not getting passed from the PSTN into the network after the call is established.  The router is using CUBE software and passes the call to the PSTN via SIP trunking/SIP server.  The call is established at G729. I'm using debug voip ccapi inout and debug sip messages, but I don't see the digits being passed.

1.  Am I using the right debugs?  If not, which ones do I use?

2.  At G729, are the tones compressed, or are they out of band?

1 Accepted Solution

Accepted Solutions

Then this is all you need to get:

debug voip ccapi inout

debug ccsip all

debug voip rtp sess name

You can look at the 'ccsip all' debug and see where it says 'negotiated dtmf relay' on each leg to ensure that rtp-nte was negotiated, and what payload type was negotiated.

Who is the SIP provider?  If it is Verizon, you need to configure 'dtmf-interworking rtp-nte' configured under 'voice service voip since there are timing issues with thier SBC regarding the RTP-NTE packets.

View solution in original post

26 Replies 26

byrne
Level 1
Level 1

Depends on what you have configured on your voip dial peer that is used to send to your SIP provider.

Most SIP providers support RFC2833 for dtmf relay, on the voip dial peer it would be configured as dtmf-relay rtp-nte.

The debug to see this would be "debug voip rtp session named-event".

Phillip Ratliff
Cisco Employee
Cisco Employee

Depends on the DTMF payload type.  If it's RFC2833 DTMF then they will be a special type of RTP packet sent in-band.  If it is KPML or SIP-Notify DTMF then it would be out-of-band  in SIP messages.

For 2833 DTMF use debug voip rtp session named-event to see the in-band DTMF packets as they hit the router.

Check out http://www.cisco.com/en/US/docs/ios/12_3/sip/configuration/guide/chapter8.html#wp1037760 for examples of OOB DTMF.

Thanks for the response.  Would the call, at some point, go to H323 within the CUBE and get picked up by the debugs I was doing?

d.anthony.hadley wrote:

Thanks for the response.  Would the call, at some point, go to H323 within the CUBE and get picked up by the debugs I was doing?

Only if CM is doing H323 to CUBE.  Then you'd see DTMF via h245-signal from CM, shown with an h245 asn1 debug.

I found that the problem happens when they use G729.  Since the RFC2833 DTMF tones are inband, would G729 compress the tones so that they are not recognized?  Or, could there be something else going on here?  Thanks.

RTP-NTE is not in-band audio.  A lot of people refer to RTP-NTE as in0band, but I think that's a bad way to describe it.  It's in the media path, sure, but

I consider in-band to mean in-the-audio which RTP-NTE isn't since the payload type is different (and the digits are transmitted via data, not g.7xx audio)

Hence, g.729 does not effect RTP-NTE digits in any way.  g.729 would only affect digits that are in the actual audio stream, which won't happen in a CUCM environment unless you invoke a transcoder and have dtmf-relay on one side and not the other.

If you still have DTMF issues, it's a misconfiguration somewhere.  Likely a dial-peer match is incorrect, or the SIP side isn't using PT 101 for RTP-NTE.  Collect:

debug voip rtp sess name

debug h245 asn1

debug h225 asn1

debug cch323 all

debug voip ccapi inout

debug ccsip all

Collect the debugs in the following manner, place a test call, and hit some DTMF:

Router(config)# service sequence
Router(config)# service timestamps debug datetime msec
Router(config)# logging buffered 10000000 7
Router(config)# no logging con
Router(config)# no logging mon
Router(config)# voice iec syslog

Router# term len 0

Router# sh logg

I'm working on setting up another test.  All the dial peers have the dtmf relay rtp-nte command on them.  Could it be a misconfig somewhere else?  I don't have access to the SIP side.  What do I ask about the PT 101 for RTP-NTE?  Would it be in their traces?  Thanks.

debug ccsip mess will show RTP NTE cap in the SDP...something like

m=audio XXX RTP/AVP  101 
a=rtpmap:101 telephone-event/8000

101 is the payload type.  101 is default and can be changed.

deb voip rtp session named-event   will show you rfc2833 packets with PT=101 for dtmf events/digits.

HTH,

DK

Your H323 dial-peer should have 'dtmf-relay h245-alpha' confiugred on it, not rtp-nte.

Make sure calls from CUCM via H323 to CUBE match the right inbound dial-peer, which should be an H323 dial-peer.  Verify with 'sh call active voice br' and look at the pid: for the first leg for that (or run debug voip ccapi inout).  If you're matching a SIP peer on the inbound leg when the call comes in from H323, you need to correct your dial-peer matching.

EDIT: Although I'm not sure if you are using H323 or SIP to CM.

These are the dial peers in and out that the call is hitting.  Do I need the 'dtmf-relay h245-alpha' command on both of these?  Almost all of the calls use these two dial peers, according to the 'sho call active voice brief' and they are sip call legs.  There are no h323 call legs.

This is the dial peer it's hitting on the way in according to the debug 'voip ccapi inout'

017203: Oct  5 09:25:06 EDT:
   Incoming Dial-peer=101, Progress Indication=NULL(0), Calling IE Present=TRUE,
   Source Trkgrp Route Label=, Target Trkgrp Route Label=, CLID Transparent=FALSE), Call Id=

dial-peer voice 101 voip
description from CUCM
session protocol sipv2
incoming called-number ^001T
dtmf-relay rtp-nte digit-drop
fax rate disable
fax protocol none
no vad

This is the outgoing dial peer according to the debug


017218: Oct  5 09:25:06 EDT:
   Destination=, Calling IE Present=TRUE, Mode=0,
   Outgoing Dial-peer=100, Params=0x73E5D890, Progress Indication=NULL(0)


dial-peer voice 100 voip
description outbound voice to SIP
translation-profile outgoing strip
destination-pattern ^001T
voice-class sip options-ping 90
voice-class sip early-offer forced
session protocol sipv2
session target ipv4:X.X.X.X:5535
dtmf-relay rtp-nte
fax protocol none
no vad

Hmm...not clear if you are using h323 or  SIP between cube and ccm ?

If its SIP, the dialpeers look good. If h323, you'd add  dtmf-relay h245-alpha h245-sig

to the dialpeer towards CCM.

What do u see for negotiated dtmf-relay in show call active voice and show sip call ?

All the call legs are SIP.

Then this is all you need to get:

debug voip ccapi inout

debug ccsip all

debug voip rtp sess name

You can look at the 'ccsip all' debug and see where it says 'negotiated dtmf relay' on each leg to ensure that rtp-nte was negotiated, and what payload type was negotiated.

Who is the SIP provider?  If it is Verizon, you need to configure 'dtmf-interworking rtp-nte' configured under 'voice service voip since there are timing issues with thier SBC regarding the RTP-NTE packets.

I saw the DTMF in the debug.   In this case, I was looking for a number 9.  You'll see it in the debug below.  It was a call from the network, through a CUBE router, into the telco (Verizon) SIP cloud.  The user on the outside would hit the 9 button to triger an option.  This was seen from both my side (network side) and the SIP side.  Debug was on the CUBE.

Look for "Relaying Digit 9 to dstCallId"

066011: Oct 11 14:19:03 EDT: //-1/xxxxxxxxxxxx/SIP/Info/ccsip_process_sipspi_queue_event: ccsip_spi_get_msg_type returned: 3 for event 15
066012: Oct 11 14:19:03 EDT: //1454496/xxxxxxxxxxxx/CCAPI/cc_api_call_digit_begin:
   Consume mask is not set. Relaying Digit 9 to dstCallId 0x16319F
066013: Oct 11 14:19:03 EDT: //1454496/xxxxxxxxxxxx/CCAPI/cc_relay_digit_begin_for_3way_conference:
   Check DTMF relay digit begin for 3way conf
066014: Oct 11 14:19:03 EDT:          s=VoIP d=DSP payload 0x65 ssrc 0x301AAA14 sequence 0x5B2 timestamp 0x3193F4
066015: Oct 11 14:19:03 EDT:  << Pt:101    Evt:9       Pkt:0A 01 40

Thanks for all the help and responses.

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: