<div dir="ltr">Well said Mike, I like your point of view.<div><br></div><div>I have to be honest, I didn't know that about IE9.  Not that it matters for my particular case, because we're upgrading to IE11 now anyways, but, it's good to know that no one should be on IE9 for any reason today.</div><div><br></div><div>I take this opportunity to say too, that IE9 is only one of several browsers that could have been used with Finesse, and caused the CPU issue.  See the <a href="https://en.wikipedia.org/wiki/WebSocket#Browser_implementation">Browser implementation</a> section of the WebSockets wikipage for a list of browser which support this feature.  So, in theory, the client could have been on a Cisco unsupported browser other than IE9, and still seen the same issue.</div><div><br></div><div>Actually, I take that back, it looks like <a href="http://caniuse.com/#search=websocket">almost all major browsers support WebSockets</a>.  That doesn't leave a lot of room for choice of browsers that would fail a WebSockets test.  There goes that argument.</div><div><br></div><div>Thanks again for your reply.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, May 12, 2016 at 4:45 PM, Norton, Mike <span dir="ltr"><<a href="mailto:mikenorton@pwsd76.ab.ca" target="_blank">mikenorton@pwsd76.ab.ca</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">





<div lang="EN-CA" link="blue" vlink="purple">
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">When deciding whether to venture into unsupported territory, I think it is worth distinguishing between different types of “unsupported.”<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">One type of “unsupported” is when a vendor says certain pieces must be certain things and at certain versions, but you choose to go
 against their requirement.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">Another type of “unsupported” is when a vendor declares that they are discontinuing all maintenance/development on a certain piece
 and that it must be migrated away from immediately.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">Your situation is both. Cisco says browser must be a certain flavour/version to work with their particular solution, *and* Microsoft
 told EVERYBODY to get off IE9 months ago.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">There are lots of environments where intentionally going “unsupported” is an acceptable risk, but IMO mixing both types of unsupported
 simultaneously is probably asking for trouble in almost all cases.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">-mn<u></u><u></u></span></p>
<p class="MsoNormal"><a name="m_7680300117478443002__MailEndCompose"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"><u></u> <u></u></span></a></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><b><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif">From:</span></b><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif"> cisco-voip [mailto:<a href="mailto:cisco-voip-bounces@puck.nether.net" target="_blank">cisco-voip-bounces@puck.nether.net</a>]
<b>On Behalf Of </b>Anthony Holloway<br>
<b>Sent:</b> May-12-16 10:07 AM<br>
<b>To:</b> Cisco VoIP Group <<a href="mailto:cisco-voip@puck.nether.net" target="_blank">cisco-voip@puck.nether.net</a>><br>
<b>Subject:</b> [cisco-voip] How Important is Running "Supported?"<u></u><u></u></span></p><div><div class="h5">
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<p class="MsoNormal">All,<u></u><u></u></p>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">Over the past 10 years, I have seen a multitude of deployments that were not in a 100% supported configuration.  Most of the time, this simply results in "don't ask, don't tell" and as long as you didn't need TAC support, everything should
 be fine.  I don't necessarily mean UCCX server compatibility with CUCM, but like phone models, firmware, IOS code, gateway models, web browsers, OS, Agent shared lines or LG membership, etc.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">Well, recently I just ran into a non-supported setup, where it caused the server to hit 100% CPU utilization and cause all sorts of problems in the application.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">It was UCCX v11 and using IE9 for Finesse.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">You can read more about the difference in the browser here, if you have access:<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><a href="https://communities.cisco.com/message/215058/" target="_blank">https://communities.cisco.com/message/215058/</a><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">Otherwise the summary is basically this:<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">UCCX v11 introduced a new technology to support Live Data feeds from Finesse to CUIC:
<a href="http://Socket.IO" target="_blank">Socket.IOhttp://socket.io/</a>.  Socket.IO uses <a href="https://en.wikipedia.org/wiki/WebSocket" target="_blank">
HTTP WebSockets</a> to open a single TCP connection from Finesse to UCCX, and then passes all updates to the data via this single connection.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">IE9 lacks the feature to support WebSockets and the Socket.IO software automatically allows older browser clients to
<a href="http://stackoverflow.com/questions/12993704/ie-and-socket-io-compatibility" target="_blank">
fallback to single HTTP GET</a> calls for each data refresh interval.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">This means that instead of having 100 Agents using 1 socket each, for a total of 100 connections that are persistent, you'll end up 100 Agents using hundreds of connections (quickly setup and then closed) throughout the day, resulting in
 what is essentially a DoS attack on the SocketIO service.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">In theory, this would happen with any browser that doesn't support WebSockets.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">So, how important is being in compliance when it comes to what's supported and not supported?  Do you typically bend the rules, or are you rigid and strict?<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
</div>
</div></div></div>
</div>

</blockquote></div><br></div>