10-05-2010 07:44 AM - edited 03-16-2019 01:10 AM
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?
Solved! Go to Solution.
10-06-2010 01:52 PM
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.
10-05-2010 08:26 AM
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".
10-05-2010 08:31 AM
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.
10-05-2010 01:06 PM
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?
10-05-2010 01:49 PM
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.
10-06-2010 09:09 AM
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.
10-06-2010 09:13 AM
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
10-06-2010 09:54 AM
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.
10-06-2010 10:06 AM
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
10-06-2010 10:22 AM
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.
10-06-2010 11:00 AM
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
10-06-2010 11:11 AM
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 ?
10-06-2010 01:47 PM
All the call legs are SIP.
10-06-2010 01:52 PM
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.
10-26-2010 12:12 PM
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: <<
Thanks for all the help and responses.
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: