[cisco-voip] Weird MTP issues

[Mike Lydick]

You left out a few details of the call flow? I thought I would add some
details for the group

PSTN(Internet SIP Trunk)->CUBE->CUCMBE->AA->PSTN(Your SIP Provider)

>From the debug we took, your 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 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.

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.

Mike


Best Regards,

Mike Lydick



On Mon, Aug 12, 2013 at 12:48 PM, Kenneth Hayes <kennethwhayes at gmail.com>wrote:

> If you like we can setup a webex.
>
> Sent from my iPhone
>
> On Aug 12, 2013, at 12:43 PM, Peter Slow <peter.slow at gmail.com> wrote:
>
> > sounds interesting,  I could take a look =)
> >
> > take the MTP back out and get traces of the call failing the way it
> > was originally... Also, "debug ccsip mess" from the CUBE. ,,,And make
> > sure the CCM traces are set to detailed and that the options in both
> > columns are all enabled except the two labeled "SIP register'
> > somethingorother and skinny keepalive, please =)
> >
> > -Pete
> >
> > On Sun, Aug 11, 2013 at 8:47 PM, Kenneth Hayes <kennethwhayes at gmail.com>
> wrote:
> >> 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?
> >> _______________________________________________
> >> cisco-voip mailing list
> >> cisco-voip at puck.nether.net
> >> https://puck.nether.net/mailman/listinfo/cisco-voip
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20130812/9be2ba7d/attachment.html>