Mitel System With Trunk To CUCM DTMF Not Recognized.

Jay Schulze · ‎07-02-2014

Hello,

Not sure if this is correct forum but maybe someone has seen this. Overview is that DTMF is not being recognized by CVP from the greeting. Call flow is such.

Mitel 5000 --siptrunk---CUCM9---siptrunk---CVP9

Currently the DTMF type on all trunks is RFC2833. And verified the Mitel is RFC as well. I think the problem is that for payload Mitel is sending 96. But on the Cisco CUCM the trunks are using the default of 101 for both the trunk to Mitel and CVP. Here is the invite in from Mitel you can see it sends payload of 96.

INVITE sip:72799@10.38.246.136:5060 SIP/2.0
Via: SIP/2.0/UDP 10.254.20.32:5060;branch=z9hG4bK2312043656-10065
Max-Forwards: 70
Allow: NOTIFY,REGISTER,REFER,SUBSCRIBE,INVITE,ACK,OPTIONS,CANCEL,BYE
User-Agent: Mitel-5000-ICP-5.1.0.56
P-Asserted-Identity: "Laura B." <sip:10129@10.254.20.32>
From: "Laura B." <sip:10129@10.254.20.32:5060>;tag=Mitel-5000_2312043669-10065
To: 72799 <sip:72799@10.38.246.136:5060>
Call-ID: 2312043591-10065
CSeq: 1 INVITE
Contact: "Laura B." <sip:10129@10.254.20.32:5060>
Content-Type: application/sdp
Content-Length: 266
v=0
o=Mitel-5000-ICP 169457268 1404250460 IN IP4 10.254.20.31
s=SIP Call
c=IN IP4 10.254.20.31
t=0 0
m=audio 6770 RTP/AVP 0 8 96
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:96 telephone-event/8000
a=ptime:20
a=maxptime:30
a=cdsc:1 image udptl t38

here is 200 ok


	5:16 PM

Jay Schulze:

SIP/2.0 200 OK
Via: SIP/2.0/UDP 10.254.20.32:5060;branch=z9hG4bK2312043656-10065
From: "." <sip:10129@10.254.20.32:5060>;tag=Mitel-5000_2312043669-10065
To: 72799 <sip:72799@10.38.246.136:5060>;tag=10585346~dfbf10b3-6c69-4443-852f-cbf609935a6f-42551743
Date: Tue, 01 Jul 2014 21:34:24 GMT
Call-ID: 2312043591-10065
CSeq: 1 INVITE
Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY
Allow-Events: presence, kpml
Supported: replaces
Supported: X-cisco-srtp-fallback
Supported: Geolocation
P-Preferred-Identity: <sip:00011172799@10.38.246.136>
Remote-Party-ID: <sip:00011172799@10.38.246.136>;party=called;screen=no;privacy=off
Contact: <sip:72799@10.38.246.136:5060>
Content-Type: application/sdp
Content-Length: 238
v=0
o=CiscoSystemsCCM-SIP 10585346 1 IN IP4 10.38.246.136
s=SIP Call
c=IN IP4 10.38.246.166
b=TIAS:64000
b=AS:64
t=0 0
m=audio 23956 RTP/AVP 0 96
a=rtpmap:0 PCMU/8000
a=ptime:20
a=rtpmap:96 telephone-event/8000
a=fmtp:96 0-15

This is the invite over to CVP. Still sending 96. I'm pretty sure I can fix this by setting the payload type to 96 on both trunks on CUCM. I was able to test with it afterhours. After reading through Mitel docs there is no way to change payload type on their side. The question is really would there be anything else this could maybe break on the CVP side?

Ayodeji Okanlawon · ‎07-02-2014

I am almost certain that there is nothing that doing this will break either on cvp or cucm. Within cisco IOS gateways payload 96 is used for fax relay, since there is no gateway in your setup you should be good to make the change

Please rate all useful posts

Jay Schulze · ‎07-02-2014

Yeah I'm with you. I can't see anything it would break either. There is a cube however for other call flows that ingress on the cube and then use that same trunk to CVP. Lucky there is no faxing over this so only other thing I can think it would affect is DTMF for other call flows. If it does affect anything.

Jay Schulze · ‎07-03-2014

Well that did not work. What I found was it was going through 96 all the way to CVP. However when CVP returned a label to the VXML. The VXML sent back the 200 OK with 101.

If I changed the the rtp payload-type nte 96 on the VXML dial-peer it did work. However it broke any other call flow to CVP from being able to recognize DTMF.

I wonder if this is some type of bug on VXML. Because it was my understanding by having the command 'asymmetric payload full' under SIP. It would pass the payload type from one call leg to the other.

Ayodeji Okanlawon · ‎07-03-2014

It looks like the issue is that the VXML gateway at some point in the call flow still sends the default rtp-nte payload type as 101. My understanding of CVP and VXML is quite limited, hence you might need to open a TAC case on this

Please rate all useful posts