Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. And see here for current known issues.

New Member

Weird MTP issue

All,

Currently I'm running CUBE in my enviroment and we have a weird issue.  Here's my Call Flow first.

PSTN->CUBE->CUCMBE->AA

So when callers come in they will reach the Auto Attendant and have the option to press 1 for dial-by-name, well when they select option 1 they get to the Directory Handler and speak the person they are trying to reach, well when the call begins to transfer it rings the extension for a slight second then it drops. Weird right, well on the SIP trunk between CUCM and CUBE I checked MTP required and saved changes and reset the trunk and attempt the call it works fine, the phone rings normal, and no issues occur. So in my SIP profile that's associated with the SIP trunk I checked the box to insert MTP if needed and unchecked the MTP required on the SIP trunk and the call drops at a slight second.

In the CUBE I've added a  voice class sip profile to see if that corrects it, and it has not..Can someone assist me with this issue?

1 REPLY
New Member

Weird MTP issue

Update...

From the debug we took, the provider was sending back Cause Code 41 (Temporary Network Failure) with no MTP. However the call flow works if you add MTP.


This is most likely is because the MTP will terminate the outbound call leg from an SIP call signalling perspective with the registration address of the MTP. This address is most likely trusted by your carrier and they accept the call.


When you remove the MTP, the originating IP Address is passed along to your carrier. Most carriers use the invite and re-invite information (IP addressing in the URI) to prevent toll fraud. Hence why the use of the MTP allows the call to work.


We tried Address-hiding with no change.


We tried sip profiles and modifying the SIP invite header with some success but you reported that the codec was not correct on the successful call and the quality was poor.


This does not have bearing on the use of MTP as we were using a software MTP on successful calls. This resource will allow for terminating call legs, dtmf mismatch or translation, packetization mismatch or translation but not codec translation. Packet drop is a QOS issue and should look to correcting the dial-peer and/or CUCM to get the call back to a G729r8 call and the issue may improve but we did not look over the QOS configurations so there maybe some room for improvement.


192
Views
0
Helpful
1
Replies
CreatePlease login to create content