Mitel System With Trunk To CUCM DTMF Not Recognized.

Question

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:[email protected]: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:[email protected]>
From: "Laura B." <sip:[email protected]:5060>;tag=Mitel-5000_2312043669-10065
To: 72799 <sip:[email protected]:5060>
Call-ID: 2312043591-10065
CSeq: 1 INVITE
Contact: "Laura B." <sip:[email protected]: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
 5:16 PM
here is 200 ok
 5:16 PM
 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:[email protected]:5060>;tag=Mitel-5000_2312043669-10065
To: 72799 <sip:[email protected]: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:[email protected]>
Remote-Party-ID: <sip:[email protected]>;party=called;screen=no;privacy=off
Contact: <sip:[email protected]: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?

Answer 1

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.