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 <[email protected]>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 <[email protected]> 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 <[email protected] >> > 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) < >>> [email protected]> 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 <[email protected]> >>>> 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 < >>>> [email protected]> wrote: >>>> >>>>> Super copy identical. >>>>> >>>>> >>>>> On Thu, Apr 17, 2014 at 4:33 PM, Ryan Ratliff (rratliff) < >>>>> [email protected]> wrote: >>>>> >>>>>> 47 = codec mismatch >>>>>> >>>>>> Is it _really_ identical? >>>>>> >>>>>> -Ryan >>>>>> >>>>>> On Apr 17, 2014, at 4:02 PM, Erick Wellnitz <[email protected]> >>>>>> 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 >>>>>> [email protected] >>>>>> https://puck.nether.net/mailman/listinfo/cisco-voip >>>>>> >>>>>> >>>>> >>>> >>>> >>> >>> _______________________________________________ >>> cisco-voip mailing list >>> [email protected] >>> https://puck.nether.net/mailman/listinfo/cisco-voip >>> >>> >> >> _______________________________________________ >> cisco-voip mailing list >> [email protected] >> https://puck.nether.net/mailman/listinfo/cisco-voip >> >> >
_______________________________________________ cisco-voip mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-voip
