According to TAC CM will try to allocate a non-trusted MTP if it fails to allocate a TRP/MTP.
SR: 630004281 in case any Cisco people would like to take a look. On Tue, Apr 22, 2014 at 7:29 PM, Anthony Holloway < [email protected]> wrote: > Wouldn't setting it to false, cause it to not be required, and thus break > your VPN solution when it isn't invoked? > > > On Tue, Apr 22, 2014 at 4:16 PM, Erick Wellnitz > <[email protected]>wrote: > >> 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 >> >> >
_______________________________________________ cisco-voip mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-voip
