06-08-2016 03:05 AM - edited 03-17-2019 07:09 AM
Hello,
DTMF isn't working for incoming PSTN calls.
Here is the call flow:
PSTN -> ISR 4321 --H323--> CUCM --SIP--> IVR 3rd party server
The SIP trunk is configured with a MRGL containing MTP ressources (MTP ressource on GW and MTP ressources on CUCM). The DTMF Signaling Method parameter is set to OOB and RFC 2833.
I can see that a MTP is needed due to a DTMF missmatch on the logs:
|DET-MediaManager-(3189)::isMTPNeededForMismatchOrConfig, MTPNeededDueToDTMFCapMismatch(2833/OOB) mtpinsertionReason=1 dtmfMTPSide=2
But it seems there is a issue when the MTP ressource is selected:
|AppInfo |MediaTerminationPointControl(5)::SendMTPResourceErrToSender - ERROR AllocateMtpResourceReq failed -- Ci=39575083, errBitset=0x1
|SdlSig |AllocateMtpResourceErr |resource_rsvp |MediaResourceCdpc(2,100,141,56) |MediaTerminationPointControl(2,100,139,5) |2,100,14,24958.2^172.16.101.2^Port 45410
You can find attached the SDL logs (calling number 00634379492, called number : 6840 translated to 8400).
Thank you for your help.
Thomas.
Solved! Go to Solution.
06-08-2016 05:37 AM
Hi Thomas,
I'm glad it works now. So just to summarize for people that might find this subject in future two things were changed.
- SIP trunk was set to "No Preference"
- H323 Dial-peer on VG was set to Alphanumeric only
Leszek
06-08-2016 03:53 AM
Hi Thomas,
The error message you quoted is while allocating one MTP, but if there is an error in allocating the MTP, the CUCM will try the remaining MTP resources in the list.
As I could see, the below MTP resource is allocated successfully in the later part of trace for the same call (MTP allocation Ci=39575083)
03197789.015 |11:29:48.166 |AppInfo |MediaTerminationPointControl(1)::logResourceStatusinTrace -- Device Name=MTP_MOH1 ResourceAvailable=24 ResourceUsed=0
03197789.016 |11:29:48.166 |AppInfo |MediaTerminationPointControl(1)::handleMtpDeviceFound ConversationId=33558453 CI=39575083 Allocated resource=1 Device Capability = 57
03197789.017 |11:29:48.166 |AppInfo |MediaTerminationPointControl(1)::incActiveCounter - Count=1
03197789.018 |11:29:48.166 |AppInfo |MediaTerminationPointControl(1)::decAvailableCounter - Count=1
03197789.019 |11:29:48.166 |AppInfo |MediaTerminationPointControl(1)::logResourceStatusinTrace -- Device Name=MTP_MOH1 ResourceAvailable=23 ResourceUsed=1
03197791.001 |11:29:48.166 |AppInfo |MediaResourceManager::waiting_MrmAllocateMtpResourceRes - CI=39575083 deviceName=MTP_MOH1 deviceCap=57 count=1
03197791.002 |11:29:48.166 |AppInfo |MRM::updateMtpCounter devName=MTP_MOH1, countChange=1
03197791.003 |11:29:48.166 |AppInfo |MRM::updateXcodeCounter devName=MTP_MOH1, countChange=1
You need to check the logs further along with the gateway debugs/captures to troubleshoot further.
HTH
Rajan
06-08-2016 04:15 AM
Hello,
Thank you both for your answer.
Manish,
I did what you told me (codec pass-through on the IOS based MTP and reset the SIP trunk associated with the MRGL) but I have the same problem. The MTP ressource is only associated to the SIP trunk, do I also have to associate it with the H323 gateway?
Rajan,
What kind of debug do you recommend?
Thomas.
06-08-2016 04:43 AM
Can you apply the MRGL with IOS MTP on h323 gateway, reset it and test again.
Manish
06-08-2016 04:54 AM
I cannot do it now because there are too much active calls.
06-08-2016 03:59 AM
Hi Thomas,
It appears that the issue is because of CUCM not allocating a passthru capable MTP based on the following snippet from the trace:
03197775.001 |11:29:48.163 |AppInfo |waiting_MrmAllocateMtpResourceReq: If pt cap is requested , try to allocate rtcp pt capable mtp
If you have an IOS based MTP configured for passthru then add that to the MRG and try again after resetting the gateway / trunk.
HTH
Manish
06-08-2016 04:25 AM
Hi Thomas,
Can you set DTMF Method on the SIP trunk to "No Preference". Cause from what I can see it's setup to require both OOB and RFC2833 at the same time. An it negotiates only 2833:
My DTMF (config=4 support=2
Which translates to
Configured: PreferBoth - requires both DTMF methods
Supported: RFC2833 - only 2833 is negotiated.
What we wanto to have is that any negotiated method will be used which requires setting to "No Preference".
Leszek
06-08-2016 04:40 AM
06-08-2016 05:23 AM
Edited:
Sorry i was looking at wrong call in traces
06-08-2016 05:33 AM
Thanks Leszek, it works!
I'm affraid not to understand why it works now.
Now the DTMF signals are carried as H.245 messages and before they were carried in RTP stream.
We use SRTP, maybe it was the cause of the issue?
Thomas.
06-08-2016 05:37 AM
Hi Thomas,
I'm glad it works now. So just to summarize for people that might find this subject in future two things were changed.
- SIP trunk was set to "No Preference"
- H323 Dial-peer on VG was set to Alphanumeric only
Leszek
06-08-2016 05:44 AM
(+5) to Leszek.
Thomas,
Can you mark this thread as answered so that other people will find it useful when they search.
Thanks,
Rajan
06-08-2016 05:43 AM
Hi Thomas,
DTMF method for
So the DTMF has to be sent as OOB always.
http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/srnd/9x/uc9x/media.html
06-08-2016 06:17 AM
Thank you everyone for your help.
Have a good day.
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: