Lync Server 2010 Response Group Application Frequently Asked Questions

re: Lync Server 2010 Response Group Application Frequently Asked Questions

soder — Wed, 10 Oct 2012 20:24:29 GMT

Jamie: its a matter of pricing. Does the Rev2 phone needs just a slightly faster processor? Or does it need double the clock speed of the Rev1 CPU speed to handle the spike load during RGS call connection procedure? Does the architecture of the phones support the higher clock speed, does such a higher clockspeed CPU actually exist and available on the shelf at the HW vendor?

re: Lync Server 2010 Response Group Application Frequently Asked Questions

Jamie — Tue, 09 Oct 2012 20:06:48 GMT

@Trevor - done :)

re: Lync Server 2010 Response Group Application Frequently Asked Questions

Trevor — Fri, 05 Oct 2012 13:33:16 GMT

@Jamie - Let's talk offline. I'd love to give feedback on this, and much more. Trevor dot Miller @ rlicorp dot com

re: Lync Server 2010 Response Group Application Frequently Asked Questions

Blackberry Playbook Application Development — Fri, 28 Sep 2012 16:42:53 GMT

Thanks for the update, is there any way I can receive an email sent to me when you write a fresh article?

re: Lync Server 2010 Response Group Application Frequently Asked Questions

Jamie Stark — Thu, 27 Sep 2012 18:34:48 GMT

@Trevor - thanks for the feedback.

Simple hunt groups, basic call queuing and such are absolutely the core design goal of Response Groups, no question.

What we have seen from many customers that have brought up the transfer timing from RGS is that they're moving more towards contact center workloads in the continuum…which I can understand – RGS has Speech, comes with a bunch of languages, is included with Lync for no additional cost, etc. For many of them it's working great and solving their needs and for some they wanted to understand what they should expect from RGS.

That’s the primary goal of this article – to ensure everyone deploying RGS understands the specifics regarding sizing, scalability and performance.

With every release we look to both add features and optimize what’s already in there on a few different dimensions. One of those areas we will look at for a future release is absolutely how to optimize transfers in RGS – to be clear, you shouldn’t expect any significant changes in this on Lync Server 2013. Similarly, it wouldn’t help folks if the solution was a new phone model with a higher clock rate CPU, because as you said you want to use the phones you have in place today, which is perfectly reasonable.

In terms of transfer performance, what’s the level that you want to see? Of course today, you should be able to get nearly instant transfers using Lync on a workstation with a USB-connected device….

re: Lync Server 2010 Response Group Application Frequently Asked Questions

Trevor — Thu, 27 Sep 2012 13:58:53 GMT

@Jeff Schertz - I'll concede that "newer" generally equates to "better" and I've seen many-a-posts about the newer devices having no delay with RGS call acceptance. But what about all the "Better Together" functionality that gets lost when you're using a "qualified device" as opposed to a LPE device? How do customers that have already spent $$$ on existing devices justify ANOTHER capital investment just to provide a workaround for a known, and now acknowledged MS limitation? Hint - I know our company won't shell out cash for another device change that "fixes" one problem and creates a myriad of others, and I'd be surprised if the majority of customers would go this route as well.

re: Lync Server 2010 Response Group Application Frequently Asked Questions

Jeff Schertz — Wed, 26 Sep 2012 13:36:55 GMT

In response to the Qualified device's performance 'the newer the device the better the performance' is the hard and fast rule. The brand new Polycom VVX500 has been shown to have zero delay in RGS testing in some environments where in the same exact network location a Lync Phone Edition device was lagging up to 6 seconds for the same call. In fact the VVX phones have a diagnostics menu with CPU and Media load graphs and when answering an RGS call the processor will most often not even spike above 50% for the half second before media is established. Older qualified handsets can perform on par or better than LPE devices, it all comes down to shear horsepower when Early Media is not available for the call.

re: Lync Server 2010 Response Group Application Frequently Asked Questions

Trevor — Wed, 26 Sep 2012 13:35:37 GMT

While I somewhat understand the points here about LPE and the RGS architecture, the underlying issue still seems to be missed by MS. Hunt Groups (non-IVR) are such a simple feature and are a widely used architecture by companies in their telephony environments. While the MS RGS solution is scalable, the overall implementation and performance are horrible, especially for LPE devices (Polycom/HP/Aastra). We've had to use team-call groups to get around this limitation where we can, which is an absolute administrative pain. The frustration is that MS points their fingers at LPE manufacturers for not putting a powerful enough CPU in the LPE devices. LPE manufacturers point their fingers at MS for under-speccing the hardware requirements.

Bottom line MS:

Many companies don't need full-fledged IVR contact centers to meet their needs. Simple hunt groups work just fine. Your design and current stance, however, has completely alienated your customers by simply saying "sorry, suck it up" or "try one of our third-party contact centers". If you can manage to code/architect a product that provides sub-second connection times for P-2-P calls and team-call functionality, why can't you do the same for RGS? Don't get me wrong...I generally love Lync and we have 500 users on it, but RGS performance is the single biggest issue we have with the product, and you need to take that seriously and fix it so that customers whom have spent $$$ on LPE devices can use the product as it was said we could.

re: Lync Server 2010 Response Group Application Frequently Asked Questions

Jamie Stark — Tue, 25 Sep 2012 16:14:13 GMT

@soder - I'll throw the question back - if there was a new rev of Lync Phone Edition designed for Response Group users that cost more, would you buy it?

Most of the customer conversations I've had around this end up netting out in two ways - either a whole lot of agents where the cost of the instrument becomes very relevant, so the lower-cost third party phones end up being more attractive - or users that are casual RGS agents and don't spend the majority of their time on the queue where they're using Lync Phone Edition for their calls because that gives them the Information worker features (calendar, etc.) they want.

Now as you have seen from our earlier updates on both the third party endpoints and Lync Phone Edition, they're each getting revved, from Pin Auth on SNOM to Office 365 on LPE (coming with Lync 2013). That isn't going to stop - the portfolios will continue to broaden and become more feature rich.

re: Lync Server 2010 Response Group Application Frequently Asked Questions

Jamie Stark — Tue, 25 Sep 2012 15:45:19 GMT

@Al - At this point we're not making changes to Lync 2013 to increase the answer time of Response Groups. Generally the way to get more optimized transfer times is to "nail up" a media connection between clients & the call processor - meaning that the clients are never really "off a call", the media processor just switches between the active inbound calls. We don't have this type of architecture in RGS but companies that need highly optimized transfer times can absolutely take advantage of the partner solutions that are available for Lync which are designed for these scenarios, typically big contact centers.