<div dir="ltr">You left out a few details of the call flow? I thought I would add some details for the group<div><br></div><div><span style="font-family:arial,sans-serif;font-size:13px">PSTN(Internet SIP Trunk)->CUBE->CUCMBE->AA->PSTN(Your SIP Provider)</span><br>
</div><div><span style="font-family:arial,sans-serif;font-size:13px"><br></span></div><div><span style="font-family:arial,sans-serif;font-size:13px">From the debug we took, your provider was sending back Cause Code 41 (Temporary Network Failure) with no MTP. </span><span style="font-family:arial,sans-serif">However the call flow works if you add MTP.</span></div>
<div><font face="arial, sans-serif"><br></font></div><div><font face="arial, sans-serif">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. </font></div>
<div><font face="arial, sans-serif"><br></font></div><div><font face="arial, sans-serif">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.</font></div>
<div><font face="arial, sans-serif"><br></font></div><div><font face="arial, sans-serif">We tried Address-hiding with no change. </font></div><div><font face="arial, sans-serif"><br></font></div><div><font face="arial, sans-serif">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. </font></div>
<div><font face="arial, sans-serif"><br></font></div><div><font face="arial, sans-serif">This does not have bearing on the use of MTP as you 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.</font></div>
<div><font face="arial, sans-serif"><br></font></div><div><font face="arial, sans-serif">I think you are close to resolution. Either provide a software (IOS) mtp for the call volume we discussed or if you the the SIP profiles are working just should look to getting calls back to g729r8 and possible review the QoS policy end-to-end.</font></div>
<div><font face="arial, sans-serif"><br></font></div><div><font face="arial, sans-serif">Mike</font></div><div><br></div></div><div class="gmail_extra"><br clear="all"><div>Best Regards,<br><br>Mike Lydick<br><br></div>
<br><br><div class="gmail_quote">On Mon, Aug 12, 2013 at 12:48 PM, Kenneth Hayes <span dir="ltr"><<a href="mailto:kennethwhayes@gmail.com" target="_blank">kennethwhayes@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
If you like we can setup a webex.<br>
<br>
Sent from my iPhone<br>
<div class="HOEnZb"><div class="h5"><br>
On Aug 12, 2013, at 12:43 PM, Peter Slow <<a href="mailto:peter.slow@gmail.com">peter.slow@gmail.com</a>> wrote:<br>
<br>
> sounds interesting, I could take a look =)<br>
><br>
> take the MTP back out and get traces of the call failing the way it<br>
> was originally... Also, "debug ccsip mess" from the CUBE. ,,,And make<br>
> sure the CCM traces are set to detailed and that the options in both<br>
> columns are all enabled except the two labeled "SIP register'<br>
> somethingorother and skinny keepalive, please =)<br>
><br>
> -Pete<br>
><br>
> On Sun, Aug 11, 2013 at 8:47 PM, Kenneth Hayes <<a href="mailto:kennethwhayes@gmail.com">kennethwhayes@gmail.com</a>> wrote:<br>
>> All,<br>
>><br>
>><br>
>><br>
>> Currently I'm running CUBE in my enviroment and we have a weird issue.<br>
>> Here's my Call Flow first.<br>
>><br>
>><br>
>><br>
>> PSTN->CUBE->CUCMBE->AA<br>
>><br>
>><br>
>><br>
>> So when callers come in they will reach the Auto Attendant and have<br>
>> the option to press 1 for dial-by-name, well when they select option 1<br>
>> they get to the Directory Handler and speak the person they are trying<br>
>> to reach, well when the call begins to transfer it rings the extension<br>
>> for a slight second then it drops. Weird right, well on the SIP trunk<br>
>> between CUCM and CUBE I checked MTP required and saved changes and<br>
>> reset the trunk and attempt the call it works fine, the phone rings<br>
>> normal, and no issues occur. So in my SIP profile that's associated<br>
>> with the SIP trunk I checked the box to insert MTP if needed and<br>
>> unchecked the MTP required on the SIP trunk and the call drops at a<br>
>> slight second.<br>
>><br>
>><br>
>><br>
>> In the CUBE I've added a voice class sip profile to see if that<br>
>> corrects it, and it has not. Can someone assist me with this issue?<br>
>> _______________________________________________<br>
>> cisco-voip mailing list<br>
>> <a href="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</a><br>
>> <a href="https://puck.nether.net/mailman/listinfo/cisco-voip" target="_blank">https://puck.nether.net/mailman/listinfo/cisco-voip</a><br>
_______________________________________________<br>
cisco-voip mailing list<br>
<a href="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</a><br>
<a href="https://puck.nether.net/mailman/listinfo/cisco-voip" target="_blank">https://puck.nether.net/mailman/listinfo/cisco-voip</a><br>
</div></div></blockquote></div><br></div>