Call disconnecting in CME after pickup

[ctsvoiceteam]

hello champs,

 Call got disconnecting immediately after answering the call in CME, this is happend only when call is came through SIP trunk, below is the set up

CUCM -> SIP Trunk->CME

when we make a call from CUCM  to CME this is happend, but when we make the call from CME to CUCM its fine. here i attached the debug ccsip messege,

please help guys.

[Gregory Brunn]

At first it sounds like a codec issue and your 850 cause code on the bye is 172, which I have seen be codec issues before however in your delay offer sip .65 send g722 and you get an ack back with g722 as well.

Can you post you same debug from the working call.

[ctsvoiceteam]

Hi brunn,

will provide the same by tommrw. however i attached the show run (CME) and debug with sip early offer

[Ayodeji Okanlawon]

Looks like this call is sent to a sccp phone on ccme. The sdp negotiation from cucm includes dtmf relay for rtp nte while the ccme doesn't offer that. 

You can try changing the dtmf setting on cucm sip trunk to use "no preference " instead of rfc2833/rtp-nte

[ctsvoiceteam]

hi ayodeji,

dtmf settings under sip trunk is No preference only, however i attached the show run and debug with early offer as well.

[Ayodeji Okanlawon · Accepted solution]

We need to address a few things here. Based on your coniguration, I do not see any inbound dial-peer that is matched for the call from CUCM. Please add the following. I have used dial-peer 10 because I see that it is free on your gateway. Please change if you want to to any other dial-peer

dial-peer voice 10 voip
 description ***** inbound dial-peer from cucm *****
incoming called 6....$
 session protocol sipv2
 voice-class codec 1
 dtmf-relay rtp-nte sip-notify sip-kpml
 no vad

I have added a few OOB DTMF relay on this dial-peer, I am sure the SCCP phones support one of these.

If this doesn't work..please do the following and attach the logs here

conf t:

service sequence-numbers
service timestamps debug datetime localtime msec
logging buffered 10000000 debug
no logging console
no logging monitor
default logging rate-limit
default logging queue-limit

Then..

<Enable debugs, then test again.>

debug ccsip all

debug voip dialpeer inout

<Enable session capture to txt file in terminal program.> (such as Putty)


then do the ff:

terminal length 0
show logging

[Gregory Brunn]

Ayodeji ,

I have seen issues where dtmf relay doesn't match and you just don't get dtmf digits sent.  For my knowledge can you show me or given me an answer as it why dtmf  relay methods need to match in your SDP exchange.

[Ayodeji Okanlawon]

Hi Greg,

With DTMF its a case of understanding what each party wants to support or negotiate. As you are aware there are different DTMF methods and its important that both parties have a common ground on how they want to transport DTMF.

Here is a detailed document I wrote on this subject. Have a read through and we can discuss more

https://supportforums.cisco.com/t5/collaboration-voice-and-video/understanding-dtmf-negotiation-and-troubleshooting-on-sip-trunks/ta-p/3152511

[Gregory Brunn]

Awesome document on dtmf relay and great debug outputs! Made sure to rate as helpful.  Want I am missing here is the important of DTMF-relay in call establishment.  Do they actually have to match in order for audio to even set up.  We are clearly getting the number that was dialed in our SIP debugs and the call signaling makes it as the call disconnects when the user picks up.  So in my mind dtmf is important post call establishment for any additional inputs but as far as call setup I didn't think it was a huge deal.  Also per your doc if there is a mismatch CUCM should be able to invoked a MTP to bridge the gap, correct?  

[Ayodeji Okanlawon]

CUCM will attempt to allocate an MTP and the call will either fail or be allowed depending on this service parameter

[Gregory Brunn]

Awesome, Good to know!  So if in the case of this ticket if they toggled this field to not fail to mtp was not allocated the call would complete but additional dtmf would not work between the two devices, correct?

[Ayodeji Okanlawon]

That is indeed correct. This is the default value on CUCM. But this issue we are looking at is on CCME

[Gregory Brunn]

The call is going from CUCM to CME in the description. The other way work from CME to CUCM. So in the second chase CUCM fails to invoke a mtp on its call leg and allows the call. But in the first case  CME can't allocate an MTP it automatically  and instead fails the call?  Am I stating that correctly? Seems like odd default behavior to have built into CME, but not CUCM.

[Ayodeji Okanlawon]

You are right. CCME cant allocate MTP automatically

++ From the excerpt of the logs, it seems that CCME tries to invoke a dsp but fails..++

Oct 17 05:20:41: %DSMP-3-DSPALARM: Alarm on DSP : status=0x0 message=0x0 text=N
Oct 17 05:20:41: %VOICE_IEC-3-GW: VTSP: Internal Error (DSP alarm): IEC=1.1.182.9.27.10 on callID 120254 GUID=DD6C53000001000000012B140BE119AC

[ctsvoiceteam]

Boooooooooommmmmmmmmmm, thanks a lot ayodeji. it worked, however i have a query, in non working case i could see that dtmf is "101 telephone-event/8000" in invite and 200 OK, then how you identified that its a DTMF mismatch?

invite (with sdp)

m=audio 29576 RTP/AVP 9 0 8 116 18 101
a=rtpmap:9 G722/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:116 iLBC/8000
a=maxptime:60
a=fmtp:116 mode=20
a=rtpmap:18 G729/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15

200 OK 

v=0
o=CiscoSystemsSIP-GW-UserAgent 1624 2969 IN IP4 192.168.60.65
s=SIP Call
c=IN IP4 192.168.60.65
t=0 0
m=audio 23590 RTP/AVP 9 101
c=IN IP4 192.168.60.65
a=rtpmap:9 G722/8000
a=fmtp:9 bitrate=64
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16