CUBE not re-transmitting DTMF?

hwong3168 · ‎02-19-2015

Hi,

I am currently trying to get the following setup working:

ITSP -> SIP -> CUBE -> SIP -> CUCM7

The ITSP is g711a with RFC2833 or In-band for DTMF. I've configured on-router transcoding to convert g711a to g711u for the CUBE to CUCM leg of the traffic. Two-way audio is working correctly however I get no DTMF whatsoever.

Test scenario is a call from a SCCP phone to a mobile phone. With debug voip rtp sess name enabled I can see the actual DTMF events from both devices:

Feb 20 05:46:06.374: s=VoIP d=DSP payload 0x65 ssrc 0xF5D sequence 0x11A4 timestamp 0x16D00
Feb 20 05:46:06.374: <<<Rcv> Pt:101 Evt:1 Pkt:09 00 00
Feb 20 05:46:06.374: s=VoIP d=DSP payload 0x65 ssrc 0xF5D sequence 0x11A4 timestamp 0x16D00
Feb 20 05:46:06.374: <<<Rcv> Pt:101 Evt:1 Pkt:09 00 00
Feb 20 05:46:06.394: s=VoIP d=DSP payload 0x65 ssrc 0xF5D sequence 0x11A6 timestamp 0x16D00
Feb 20 05:46:06.394: <<<Rcv> Pt:101 Evt:1 Pkt:09 00 A0

Feb 20 05:46:07.858: <<<Rcv> Pt:101 Evt:2 Pkt:08 01 25
Feb 20 05:46:07.858: s=VoIP d=DSP payload 0x65 ssrc 0x7004D sequence 0x1DAD timestamp 0xAAF82E33
Feb 20 05:46:07.858: <<<Rcv> Pt:101 Evt:2 Pkt:08 01 25
Feb 20 05:46:07.878: s=VoIP d=DSP payload 0x65 ssrc 0x7004D sequence 0x1DAE timestamp 0xAAF82E33
Feb 20 05:46:07.878: <<<Rcv> Pt:101 Evt:2 Pkt:08 01 C5
Feb 20 05:46:07.878: s=VoIP d=DSP payload 0x65 ssrc 0x7004D sequence 0x1DAE timestamp 0xAAF82E33
Feb 20 05:46:07.878: <<<Rcv> Pt:101 Evt:2 Pkt:08 01 C5
Feb 20 05:46:07.898: s=VoIP d=DSP payload 0x65 ssrc 0x7004D sequence 0x1DAF timestamp 0xAAF82E33
Feb 20 05:46:07.898: <<<Rcv> Pt:101 Evt:2 Pkt:08 02 65

"1" was pressed on the phone and "2" was pressed on the mobile. I am not seeing any re-transmission of the packets once it hits CUBE.

I am currently running 12.4(25g), and here are the relevant configuration:

voice service voip
allow-connections h323 to h323
allow-connections h323 to sip
allow-connections sip to h323
allow-connections sip to sip
redirect ip2ip
h323
sip

dial-peer voice 10011 voip
translation-profile outgoing XLATE-OUT
destination-pattern 0999999..
session protocol sipv2
session target ipv4:xxx.xxx.xxx.xxx
dtmf-relay rtp-nte
codec g711ulaw
no vad
!
dial-peer voice 10001 voip
translation-profile outgoing XLATE-IN
destination-pattern 00[23478]........
session protocol sipv2
session target ipv4:xxx.xxx.xxx.xxx
session transport udp
dtmf-relay rtp-nte
codec g711alaw
no vad
!

What am I doing wrong here?

Amit Sharawat · ‎02-19-2015

Hi Hwong,

Could you please collect the following logs from the CUBE for a test call along with calling and called number. I need to check what is negotiated in the SDPs on both the legs.

debug ccsip message

hwong3168 · ‎02-23-2015

Hi,

Log of test call attached.

Calling number is 0388888888

Called number is 0499999999

Amit Sharawat · ‎02-25-2015

Hi Hwong,

Could you please attach the "show run" from the CUBE.

~Amit

hwong3168 · ‎03-04-2015

Hi all,

I've resolved the DTMF issue. The CME telephony-service style of on-board transcoding instead of using CUCM to coordinate was causing the relay issue.

All the CME code has now been removed. Both dial-peers configured to g711a along with the MTP. Turns out CUCM does not even use the transcoder for a IP phone to SIP call (even though the system is g711u native). DTMF tones are one way (outgoing) but it is being relayed properly and is in no way affecting the IVR applications in my network.

I still have problems with CTI route points and their related applications (this does trigger transcoder use), but as it is not the topic of this thread I will start another one.

Chris Deren · ‎02-20-2015

Add "incoming called-number ." to one of your SIP dial-peers as by not having it default H323 dial-peer 0 is being used which engaged different DTMF method.

hwong3168 · ‎02-23-2015

Does it matter? Those 2 SIP dial-peers are the only one I have.