<div dir="ltr">I always turn off LRO. I've had weird issues that are next to impossible to troubleshoot at the application layer and disabling LRO is the solution. I would also recommend that if you are using the 2500 user template that you make sure your callmanagers are using 2 vCPUs when using CCX. I have found the system to be much more reliable and stable with 2 vCPU.<div><br></div><div>Justin</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jun 9, 2015 at 8:40 AM, Ryan Huff <span dir="ltr"><<a href="mailto:ryanhuff@outlook.com" target="_blank">ryanhuff@outlook.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><div dir="ltr">Hi Justin, thank you for your reply.<br><br>CUCM 10.5.2su1 is in the active partition on all nodes (10.5.2.11900-3). <br><br>LRO is interesting; my elastic sky version is 5.5 and according to the DocWiki (<a href="http://docwiki.cisco.com/wiki/Disable_LRO" target="_blank">http://docwiki.cisco.com/wiki/Disable_LRO</a>) it seems to only be an issue with 4.1 and more specifically, with CUCM < 8.6 with ESXi 4.1. I've also seen several UC evangelical sites proclaim that LRO needs to be disabled where ever Virtual Cisco UC runs, versions be damned.<br><br>I'm in pre-flight, so now is definitely the time to power down and knock LRO off.<br><br>I guess I am more interested in the <i>why</i> at this point (plight of an engineer). I suppose this issue (if it is even an issue) will self-heal itself in v11 when CAD is no longer an option, but still plenty of need to support existing CAD.<br><br>This is the first time I used this version mix (UCCX 10.6 | CUCM 10.5.2su1 | CAD), and I haven't ran into this issue before.<br><br>Thanks for any thoughts you put into this.<br><br>-Ryan<br><br><br><div><hr>Date: Tue, 9 Jun 2015 07:41:46 -0400<br>Subject: Re: [cisco-voip] UCCX 10.6 | CUCM 10.5.2 | CAD Extension out of service<br>From: <a href="mailto:jsteinberg@gmail.com" target="_blank">jsteinberg@gmail.com</a><br>To: <a href="mailto:ryanhuff@outlook.com" target="_blank">ryanhuff@outlook.com</a><br>CC: <a href="mailto:cisco-voip@puck.nether.net" target="_blank">cisco-voip@puck.nether.net</a><div><div class="h5"><br><br><p dir="ltr">Are you on UCM 10.5.2su1 ? I haven't seen that issue at all.</p>
<p dir="ltr">Is your VMware LRO disabled ?</p>
<p dir="ltr">Do your UCMs have one or two vCPU ?</p>
<div>On Jun 9, 2015 12:42 AM, "Ryan Huff" <<a href="mailto:ryanhuff@outlook.com" target="_blank">ryanhuff@outlook.com</a>> wrote:<br><blockquote style="border-left:1px #ccc solid;padding-left:1ex">
<div><div dir="ltr">Has anyone been noticing that in this environment (UCCX 10.6 | CUCM 10.5.2 | CAD); extensions will sometimes report as OutOfService (and subsequently cause CAD login issues) when in fact, the phone is registered, associated to the jTAPI/RMCMSubsys user, has CTI Control enabled (and is setup correctly in all other respects)?<br><br>What seems to resolve this issue for me; is to super copy the phone to a fake mac address, delete the original and then re-mac the newly created device. Doing a cluster reboot seems to address this as well.<br><br>This is a new 2 cluster build. Everything about the phone seems to function fine within call manager when CAD is having a login issue. I've changed the addressing mode on the phone (and CTI ports) to ipv4 only, turned JAL off on the phone. Just really odd and not very easy to define.<br><br>I know CAD is near death and Finesse is the future, but I have to support CAD in this scenario.<br><br>Thanks,<br><br>Ryan<br> </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></div></div></div> </div></div>
</blockquote></div><br></div>