cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2340
Views
5
Helpful
13
Replies

DTMF issue with incoming calls from H323 GW to SIP Trunk

Thomas P
Level 1
Level 1

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.

1 Accepted Solution

Accepted Solutions

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

View solution in original post

13 Replies 13

Rajan
VIP Alumni
VIP Alumni

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

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.

Can you apply the MRGL with IOS MTP on h323 gateway, reset it and test again.

Manish

I cannot do it now because there are too much active calls.

Manish Gogna
Cisco Employee
Cisco Employee

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

Leszek Wojnarski
Cisco Employee
Cisco Employee

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

Hello,

The DTMF method has been set to "No Preference" and the trunk has been reset but I have same issue.

You can find the SDL traces attached (calling number 00634379492, called number : 6840 translated to 8400).

Thomas.

Edited:

Sorry i was looking at wrong call in traces

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.

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

(+5) to Leszek. 

Thomas,

Can you mark this thread as answered so that other people will find it useful when they search.

Thanks,

Rajan

Hi Thomas,

DTMF method for RTP NTE is not supported with H323 gateway and CUCM  as per SRND CUCM.

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

Thomas P
Level 1
Level 1

Thank you everyone for your help.

Have a good day.

Getting Started

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: