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

[Erick Wellnitz]

The entire scenario is the phone worked for several weeks via VPN.  It
stopped working so the user brought it back for us to troubleshoot.  These
are non-technical users which I'm not excited about but I digress.

Plugged it into the internet GW at the office and it worked perfect.  Sent
it back to the user and it worked for 3 days.

The users don't have access to change anything in the system but we have
way too many people with admin access that I suppose someone could be
changing this phone without realizing it.

I'm out of the office until Monday. I'll check the MTP and review the
traces then.


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/20140418/211f8316/attachment.html>