<div dir="ltr"><div>According to TAC CM will try to allocate a non-trusted MTP if it fails to allocate a TRP/MTP.</div><div> </div><div>SR: 630004281 in case any Cisco people would like to take a look.</div><div> </div></div>
<div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Apr 22, 2014 at 7:29 PM, Anthony Holloway <span dir="ltr"><<a href="mailto:avholloway+cisco-voip@gmail.com" target="_blank">avholloway+cisco-voip@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Wouldn't setting it to false, cause it to not be required, and thus break your VPN solution when it isn't invoked?</div>
<div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Apr 22, 2014 at 4:16 PM, Erick Wellnitz <span dir="ltr"><<a href="mailto:ewellnitzvoip@gmail.com" target="_blank">ewellnitzvoip@gmail.com</a>></span> wrote:<br>
<blockquote style="margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid" class="gmail_quote"><div dir="ltr"><div><font color="#000000">After collecting traces and sending them off to TAC, we found that the "</font><a href="https://10.2.146.20/ccmadmin/serviceParamEdit.do?server=63a3b20b-c06e-4957-a9be-9f98feb64114&service=0&showall=true#" name="1458bfd1fe9791cd_1458b4f1b569920c_1458b4b040b39782_FailCallIfTRPAllocationFails" target="_blank"><font color="#000000">Fail Call If Trusted Relay Point Allocation
Fails </font></a><font color="#000000"><img alt="Required Field" src="https://10.2.146.20/ccmadmin/themes/VtgBlaf/required.gif">" service parameter was set to true. </font></div><div><font color="#000000"></font> </div>
<div><font color="#000000">It seems to be working properly after changing this to false.</font></div></div><div><div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Apr 18, 2014 at 11:12 AM, Justin Steinberg <span dir="ltr"><<a href="mailto:jsteinberg@gmail.com" target="_blank">jsteinberg@gmail.com</a>></span> wrote:<br>
<blockquote style="margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid" class="gmail_quote"><div dir="ltr">Any change device mobility could be in play for this user changing the device pool/region ?<br>
</div><div class="gmail_extra">
<br><br><div class="gmail_quote">On Fri, Apr 18, 2014 at 11:12 AM, Brian Meade <span dir="ltr"><<a href="mailto:bmeade90@vt.edu" target="_blank">bmeade90@vt.edu</a>></span> wrote:<br>
<blockquote style="margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid" class="gmail_quote"><div dir="ltr">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.<div>
<br></div><div>We'll need to see CCM traces for one of these calls to see what is actually happening. Have you tried resetting the MTP?</div><span><font color="#888888"><div><br></div><div>Brian</div>
</font></span></div><div><div><div class="gmail_extra"><br><br><div class="gmail_quote">
On Fri, Apr 18, 2014 at 10:55 AM, Erick Wellnitz <span dir="ltr"><<a href="mailto:ewellnitzvoip@gmail.com" target="_blank">ewellnitzvoip@gmail.com</a>></span> wrote:<br><blockquote style="margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid" class="gmail_quote">
<div dir="ltr"><div>Ryan,</div><div><br></div><div>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?</div><div>
<br></div><div>If it were the first scenario, wouldn't I get a media list exhausted alert from RTMT? </div><div><br></div><div><br></div></div><div><div><div class="gmail_extra"><br><br><div class="gmail_quote">
On Fri, Apr 18, 2014 at 7:36 AM, Ryan Ratliff (rratliff) <span dir="ltr"><<a href="mailto:rratliff@cisco.com" target="_blank">rratliff@cisco.com</a>></span> wrote:<br>
<blockquote style="margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid" class="gmail_quote">
<div style="word-wrap:break-word">
Stuck sessions on the MTP perhaps or leaked calls in UCM?
<div><br>
</div>
<div>You're going to have to dig into traces to confirm.</div>
<div><br>
<div>-Ryan </div>
<br>
<div>
<div>On Apr 17, 2014, at 10:52 PM, Erick Wellnitz <<a href="mailto:ewellnitzvoip@gmail.com" target="_blank">ewellnitzvoip@gmail.com</a>> wrote:</div>
<br>
<div>
<div dir="ltr">
<div>Well, identical except for MAC and description. </div>
<div><br>
</div>
<div>It worked for three days now it fails. The last successful call allocated the MTP without issue. </div>
<div><br>
</div>
<div>I personally tested it a dozen or so times before giving it back to the user.</div>
</div>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">On Thu, Apr 17, 2014 at 9:45 PM, Erick Wellnitz <span dir="ltr">
<<a href="mailto:ewellnitzvoip@gmail.com" target="_blank">ewellnitzvoip@gmail.com</a>></span> wrote:<br>
<blockquote style="margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid" class="gmail_quote">
<div dir="ltr">Super copy identical.<br>
</div>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">On Thu, Apr 17, 2014 at 4:33 PM, Ryan Ratliff (rratliff)
<span dir="ltr"><<a href="mailto:rratliff@cisco.com" target="_blank">rratliff@cisco.com</a>></span> wrote:<br>
<blockquote style="margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid" class="gmail_quote">
47 = codec mismatch<br>
<br>
Is it _really_ identical?<br>
<br>
-Ryan<br>
<br>
On Apr 17, 2014, at 4:02 PM, Erick Wellnitz <<a href="mailto:ewellnitzvoip@gmail.com" target="_blank">ewellnitzvoip@gmail.com</a>> wrote:<br>
<br>
I have a VPN phones configured to use a trused relay point in order to provide connectivity to other VPN phones.<br>
<br>
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.<br>
<br>
Any ideas?<br>
<br>
<br>
Thanks!<br>
<br>
<br>
_______________________________________________<br>
cisco-voip mailing list<br>
<a href="mailto:cisco-voip@puck.nether.net" target="_blank">cisco-voip@puck.nether.net</a><br>
<a href="https://puck.nether.net/mailman/listinfo/cisco-voip" target="_blank">https://puck.nether.net/mailman/listinfo/cisco-voip</a><br>
<br>
</blockquote>
</div>
<br>
</div>
</blockquote>
</div>
<br>
</div>
</div>
</div>
<br>
</div>
</div>
</blockquote></div><br></div>
</div></div><br>_______________________________________________<br>
cisco-voip mailing list<br>
<a href="mailto:cisco-voip@puck.nether.net" target="_blank">cisco-voip@puck.nether.net</a><br>
<a href="https://puck.nether.net/mailman/listinfo/cisco-voip" target="_blank">https://puck.nether.net/mailman/listinfo/cisco-voip</a><br>
<br></blockquote></div><br></div>
</div></div><br>_______________________________________________<br>
cisco-voip mailing list<br>
<a href="mailto:cisco-voip@puck.nether.net" target="_blank">cisco-voip@puck.nether.net</a><br>
<a href="https://puck.nether.net/mailman/listinfo/cisco-voip" target="_blank">https://puck.nether.net/mailman/listinfo/cisco-voip</a><br>
<br></blockquote></div><br></div>
</blockquote></div><br></div>
</div></div><br>_______________________________________________<br>
cisco-voip mailing list<br>
<a href="mailto:cisco-voip@puck.nether.net" target="_blank">cisco-voip@puck.nether.net</a><br>
<a href="https://puck.nether.net/mailman/listinfo/cisco-voip" target="_blank">https://puck.nether.net/mailman/listinfo/cisco-voip</a><br>
<br></blockquote></div><br></div>
</blockquote></div><br></div>