[cisco-voip] MTP allocation failure - CDDR cause code 47

[Erick Wellnitz]

After collecting traces and sending them off to TAC, we found that the "Fail
Call If Trusted Relay Point Allocation Fails
<https://10.2.146.20/ccmadmin/serviceParamEdit.do?server=63a3b20b-c06e-4957-a9be-9f98feb64114&service=0&showall=true#>[image:
Required Field]"  service parameter was set to true.

It seems to be working properly after changing this to false.


On Fri, Apr 18, 2014 at 11:12 AM, Justin Steinberg <jsteinberg at gmail.com>wrote:

> Any change device mobility could be in play for this user changing the
> device pool/region ?
>
>
> On Fri, Apr 18, 2014 at 11:12 AM, Brian Meade <bmeade90 at vt.edu> wrote:
>
>> There's some scenarios where you do not get a media resource list
>> exhausted alert.  One scenario is where the CCM service has an incorrect
>> count of available resources and you just see the MTP fail to send an
>> OpenReceiveChannelAck or send one saying it failed to open a port.  In that
>> case, CUCM didn't think the media resources were actually exhausted so no
>> alert.
>>
>> We'll need to see CCM traces for one of these calls to see what is
>> actually happening.  Have you tried resetting the MTP?
>>
>> Brian
>>
>>
>> On Fri, Apr 18, 2014 at 10:55 AM, Erick Wellnitz <ewellnitzvoip at gmail.com
>> > wrote:
>>
>>> Ryan,
>>>
>>> When you mention stuck sessions do you mean x number of stuck sessions
>>> preventing further allocation of resources or this particular device has a
>>> stuck session?
>>>
>>> If it were the first scenario, wouldn't I get a media list exhausted
>>> alert from RTMT?
>>>
>>>
>>>
>>>
>>> On Fri, Apr 18, 2014 at 7:36 AM, Ryan Ratliff (rratliff) <
>>> rratliff at cisco.com> wrote:
>>>
>>>>  Stuck sessions on the MTP perhaps or leaked calls in UCM?
>>>>
>>>>  You're going to have to dig into traces to confirm.
>>>>
>>>> -Ryan
>>>>
>>>>  On Apr 17, 2014, at 10:52 PM, Erick Wellnitz <ewellnitzvoip at gmail.com>
>>>> wrote:
>>>>
>>>>  Well, identical except for MAC and description.
>>>>
>>>>  It worked for three days now it fails.  The last successful call
>>>> allocated the MTP without issue.
>>>>
>>>>  I personally tested it a dozen or so times before giving it back to
>>>> the user.
>>>>
>>>>
>>>> On Thu, Apr 17, 2014 at 9:45 PM, Erick Wellnitz <
>>>> ewellnitzvoip at gmail.com> wrote:
>>>>
>>>>> Super copy identical.
>>>>>
>>>>>
>>>>> On Thu, Apr 17, 2014 at 4:33 PM, Ryan Ratliff (rratliff) <
>>>>> rratliff at cisco.com> wrote:
>>>>>
>>>>>> 47 = codec mismatch
>>>>>>
>>>>>> Is it _really_ identical?
>>>>>>
>>>>>> -Ryan
>>>>>>
>>>>>> On Apr 17, 2014, at 4:02 PM, Erick Wellnitz <ewellnitzvoip at gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>> I have a VPN phones configured to use a trused relay point in order
>>>>>> to provide connectivity to other VPN phones.
>>>>>>
>>>>>> One of the phones gets fast busy and traces show MTP allocation
>>>>>> failure.  This was the only phone trying ot utilize this MTP and is
>>>>>> identical to other VPN phones that work as expected.
>>>>>>
>>>>>> Any ideas?
>>>>>>
>>>>>>
>>>>>> Thanks!
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> 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
>>>
>>>
>>
>> _______________________________________________
>> 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/20140422/8eef368d/attachment.html>