CUBE DTMF Issues

Ryan Gunn · ‎08-11-2012

Hi,

I am having issues with DTMF on a CUBE running SIP. I see the send and recv DTMF events in the debugs but CVP/VXML is not recognizing them.

Here is the Call Flow.

Note: The VXML Gateway is co-resident with the CUBE

AT&T --> ACME Packet --> CISCO CUBE --> CVP/VXML

When calling our test number I get the VXML prompts, but it does not respond to the DTMF digits. I am no DTMF master by any means, but I did see this in the SDP information in the SIP debug.

From the AT&T/ACME side they are advertising payload type 100.

This is on the CUBE. INVITE from the ACME device

Received:

INVITE sip:000004153571057@10.251.125.7:5060;transport=tcp SIP/2.0

Via: SIP/2.0/TCP 10.251.125.10:5060;branch=z9hG4bKp17a1n20d8t0lhsit6a0.1

MIME-Version: 1.0

Supported: 100rel, timer

Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER

Accept: application/sdp

Accept: application/isup

Accept: application/dtmf

Accept: application/dtmf-relay

Accept: multipart/mixed

Privacy: none

P-Asserted-Identity: sip:6515877753@10.251.125.10

From: sip:6515877753@10.251.125.10:12377;tag=91897815896212_c1b05.1.2.1328540005065.0_612_1942

To: sip:8884575821@10.251.125.7:5060

Call-ID: 9780393124487073 - FROM ACME@135.44.230.14

Max-Forwards: 65

CSeq: 2 INVITE

Content-Type: application/sdp

Content-Length: 321

Contact: <sip:10.251.125.10:5060;transport=tcp>

Min-SE: 1800

v=0

o=Sonus_UAC 1104153114 27014 IN IP4 10.251.125.10

s=SIP Media Capabilities

c=IN IP4 10.251.125.10

t=0 0

m=audio 16480 RTP/AVP 18 0 110 100

a=rtpmap:18 G729/8000

a=fmtp:18 annexb=no

a=rtpmap:0 PCMU/8000

a=rtpmap:110 G726-32/8000

a=rtpmap:100 telephone-event/8000

a=fmtp:100 0-15

a=sendrecv

a=maxptime:30

----------------------------------------------------------------------------------------

All of the internal invites from the CUBE, CVP and VXML show payload type of 101

v=0

o=CiscoSystemsSIP-GW-UserAgent 6907 75 IN IP4 10.251.125.7

s=SIP Call

c=IN IP4 10.251.125.7

t=0 0

m=audio 30856 RTP/AVP 18 0 101

c=IN IP4 10.251.125.7

a=rtpmap:18 G729/8000

a=fmtp:18 annexb=no

a=rtpmap:0 PCMU/8000

a=rtpmap:101 telephone-event/8000

a=fmtp:101 0-15

Attached is the show run from the CUBE and debugs from a call.

Karthik Sivaram · ‎08-12-2012

hi Ryan ,

The CUBE is using 101 payload type as this is default for NTE ( which you have set specifically

under the dial-peers with command "dtmf-relay rtp-nte")

As dynamic payload interworking is enabled by default on the CUBE. In this mode, CUBE will perform the interworking from 100 to 101 and vice versa.

Use the command "asymmetric payload full" in your configuration, CUBE will be on pass thru mode i.e. dynamic payload types are passed across from one call leg to other leg and no payload-type interworking is done at CUBE.

You can read more about this in this link :

http://www.cisco.com/en/US/docs/ios/ios_xe/voice_cube_-_ent/configuration/guide/vb_10022_xe.pdf

Hope this helps!

Regards,

Karthik

Ryan Gunn · ‎08-13-2012

Thanks for the Reply Karthik.

I implemented the commands, but that did not work for me.

I did find the issue though. They were missing the Call.user.microapp.input_type variable set to D in the ICM script. I added that in and its working now.

Robert Lake · ‎03-04-2014

That fixed my DTMF issue, thanks!