Lync Server 2010 Response Group Application Frequently Asked Questions

[NextHop_Team]

First published on TECHNET on Sep 24, 2012

The Response Group application in Lync Server 2010 provides for treatment, queuing, and routing of inbound calls. This powerful Lync Server application allows incoming calls to be routed to groups of agents using hunt groups or interactive voice response (IVR) questions and answers. As Lync Server 2010 Enterprise Voice deployments continue, we’re excited to see that customers are using Response Groups to assume existing call management requirements of legacy IP-PBX systems, as well as to address new use scenarios.

When customers scale their deployments, we receive numerous questions regarding best practices and expectations for Response Groups. This article is a collection of these frequently asked questions. We hope it provides you with the baseline information you need to efficiently add Response Groups to your Lync Server 2010 deployment. If we can provide more clarity or information, please leave your questions in the comments section below.

Authors : Jamie Stark, Microsoft Senior Product Manager and Sasa Juratovic , Microsoft Senior Program Manager

Publication date : September 24, 2012

Product versions : Lync Server 2010

What is the expected call transfer time for the Response Group application?

The Microsoft Lync Product Group performed lab tests to capture call transfer time for calls coming from the PSTN. The results are as follows:

• Lync 2010 desktop client using USB audio devices Optimized for Lync Server 2010 – observer transfer time was 1-2 seconds.


• Third party IP phone devices - observed transfer time was 2-6 seconds (device type dependent).


• Lync 2010 Phone Edition devices - observed transfer time was 6 seconds.

Table 1. Response Group call transfer times for calls from the PSTN.

Certified Device Class	Phone Model	Firmware Version	Transfer time for a call from a PSTN to connect to a Response Group agent (in seconds)*
Lync 2010	Lync client using approved USB devices	4.0.7577.4087	1-2
IP desk phones qualified for Lync Server 2010	Snom 300, 370 & 821; Polycom VVX500; Polycom SIP 650	Varies by Manufacturer	2-6 (depending on type of device)**
IP desk phones optimized for Lync Server 2010	Lync Phone Edition	4.0.7577.4066	6

* Assumes all Lync clients and servers are updated to the current, commercially available versions with cumulative updates applied.

** The performance of all qualified IP desk phones is not equal. Some devices perform in the 2 - 3 second range and some are in the 4 - 6 second range.

Response Group application transfer times depend on a number of environmental conditions, such as network conditions, client and server hardware used, and the type of clients and devices used. As a result, every implementation will differ and call transfer times will vary.

Lastly, we can say it a thousand times, but I’ll just say it once here and a few more times below … you should perform testing in your own pre-production lab environment to make sure that the solution fits your needs – on performance, network usage, scale, and so forth.

We want a sub one-second transfer time — is that possible with Response Group application?

The Response Group application was designed to fill the gap between the requirements of an enterprise IP-PBX and a contact center. It was not designed to replace a contact center solution – therefore it’s not designed to deliver transfer times to any Lync client below one second transfer time. The Response Group application should not be used in deployments where sub one-second transfer times are required – instead contact one of our contact center partners .

We are considering using Delegation and/or Team Call functionality. Can Lync 2010 Delegation and/or Team Calls be used instead of Response Group application?

These capabilities are designed for different use cases –Team Calling was designed to address the Group Call Pickup requirements for small teams. Neither Delegation and/or Team Calls can offer Response Group application functionality, like speech recognition enabled call treatment. Delegation and/or Team Calls may be sufficient to meet the needs of your organization. Examine the functionality and scale requirements to determine which feature set makes sense for your organization.

For help with the Response Group functionality decisions see Response Group Application .

For help with Response Group scale decisions see Capacity Planning for Response Group .

I’ve heard that delegation transfer time can take longer than expected under certain circumstances.

There are reports of connection time delays in delegation scenarios where IP desk phones are used. Actual transfer times depend on multiple factors. Be sure to test the Response Group application in your pre-production environment to make sure it performs as expected. Be sure you’re using the latest cumulative updates for both the server and the clients.

I’ve heard that Response Group application has not been designed for traditional call center solution. Can you comment on the design decision triggers that separate the two?

The Response Group application doesn’t have all the advanced functionalities, such as supervisor support, real time monitoring of statistics, and detailed reporting, that are required in call center solutions. Customers should assess the functionalities of the Response Group application to decide if the feature set meets their needs. If you decide your needs are better served by a call center solution, there are numerous Microsoft partners developing contact center solutions on top of Lync.

Assuming the Response Group application meet your functionality requirements; scalability is another important consideration factor. The Response Group application should not be used if your scalability requirements, for any given Lync Server 2010 Enterprise Edition pool or Lync Server 2010 Standard Edition server, exceed any metric from the Response Group user model. See Capacity Planning for Lync for detailed information on capacity planning requirements.

I’ve heard that interactive voice response (IVR) workflows or hunt groups, using text-to-speech, have an impact on Response Group application scalability? Is that true?

Both IVR and text-to-speech are complex operations that require additional resources. Because of these requirements interactive voice response (IVR) workflows or hunt groups using text-to-speech have an impact on Response Group application scalability.

The user model for the number of hunt groups and number of IVR groups (that use speech recognition) hosted by an Enterprise Edition pool or Standard Edition server is documented in the Capacity Planning for Response Group .

I see the Response Group application user model, but I am not sure if I am interpreting it correctly. Can you clarify?

The Response Group application user model is based on Microsoft’s internal testing and should be used as a basis or starting point for your own capacity planning. If you look at the Response Group application user model and focus on one of the two columns - either per Enterprise Edition pool or per Standard Edition server. Each column represents maximum number of various metrics that one can use and still stay within supported limits.

Some key takeaways are:

• You should never increase interactive voice response (IVR) groups beyond 200 for any given pool.


• You can increase hunt groups beyond 400, if the sum of hunt groups and IVR groups for any given pool is less than 600 (if you need to support more you need to deploy additional pools).


• You should never have more than 1,200 agents on a given pool (if you need to support more, you need to deploy additional pools).


• You should not exceed any metric published in the Response Group application user model .

Here are some examples:

Example 1 : Lync Server 2010 Enterprise Edition pool (with 8 Front End Servers) hosts Response Group application with 400 hunt groups, 200 IVR groups, 1,200 active agents, 16 incoming calls per second, and 480 concurrent calls connected to IVR or music-on-hold. While this is a supported application model, your environment is almost certainly different from the ones Microsoft has tested, be sure to validate with your own testing.

Example 2 : Lync Server 2010 Enterprise Edition pool (with 8 Front End Servers) hosts Response Group application with 600 hunt groups, no IVR groups, 1,200 active agents, 16 incoming calls per second, and 480 concurrent calls connected to music-on-hold. This is a supported application model.

You can look at IVR groups as enhanced hunt groups for the purpose of capacity and scalability planning. While one should never increase number of IVR groups beyond 200, it is within the model to increase the number of hunt groups beyond 400, provided the number of IVR groups is less than 200, and combining all hunt groups and IVR groups together, doesn’t exceed 600. For example, while it is OK to have 450 hunt groups and 150 IVR groups, having 450 hunt groups and 200 IVR groups exceeds the model. Further, one should never have more than 200 IVR groups even when number of hunt groups is below 400.

Example 3: To meet Response Group application scalability requirements, the customer has decided to deploy eight Enterprise Edition pools. This is supported as long as each pool doesn’t exceed any metric number from our user model .

Example 4 : To meet Response Group application scalability requirements, the customer decides to deploy two Enterprise Edition pools, and six Standard Edition servers. This is supported as long as each pool and Standard Edition server doesn’t exceed any metric from our user model .

Example 5 : Lync Server 2010 Standard Edition server hosts Response Group application with 400 hunt groups, 200 IVR groups, 1200 active agents, 2 incoming calls per second, and 60 concurrent calls connected to IVR or music-on-hold. This is a supported application model.

I am aware of the recommendations for running Lync Server 2010 in a virtual environment. What is the impact of virtualization on Response Group application scalability numbers? Please clarify?

The recommendations for running Lync Server 2010 in a virtual environment are documented in Running in a Virtualized Environment . The Response Group application user model for physical servers is documented in Capacity Planning for Response Group .

If you plan to virtualize your Enterprise Edition pool or Standard Edition server, deploying the Response Group application in a virtual topology is supported. When the Response Group application is deployed in a virtual environment, the user model numbers are reduced by 50%.

Example 1 : Lync Server 2010 Enterprise Edition pools (with 8 Front End Servers) running in virtual environment can support up to 8 incoming calls per second (instead of 16 when running on physical), 240 concurrent calls connected to interactive voice response or music-on-hold (instead of 480 when running on physical), 200 hunt groups (instead of 400 when running on physical), and so forth.

Does Microsoft provide any tools to help me with Lync Server 2010 stress and performance testing?

Definitely. The Microsoft Lync Server 2010 Stress and Performance Tool includes a set of utilities that simplify capacity planning for Microsoft Lync Server 2010 communications software. Customers should always validate their deployment plans in a pre-production environment with Microsoft Lync Server 2010 Stress and Performance Tool, regardless of Response Group application use. You can download Lync Server 2010 Stress and Performance Tools from Lync Server 2010, Stress and Performance Tool .

In addition, for voice and other workload planning purposes use the Lync 2010 Bandwidth Calculator to help plan the impact of media flows on your network topology.

I understand that the number of active agents per Enterprise Edition pool or Standard Edition server is one of the metrics I should consider when planning for Response Group application scalability. Can you provide some more details?

Formal agents are considered active when they manually sign in to the Response Group application web sign in page. Informal agents are considered active when they login to the Lync client, because they are automatically signed in to their Response Groups when they login.

To insure that you don’t exceed maximum number of active agents (described in the capacity planning guidance ) formulate your plan based on a worst case scenario when all formal and informal agents are active.

For example, with a requirement that translates into an Enterprise Edition pool with 400 hunt groups:

Example 1 : Each hunt group is associated with a different Response Group application queue, but each queue is associated with the same agent group comprised of three agents. The total number of possible active agents on this Enterprise Edition pool is three (1 agent group x 3 unique agents in that group).

Example 2: Each hunt group is associated with a different Response Group application queue and each queue is associated with a different agent group. Each agent group has three unique users (each user is a member of exactly one agent group). The total number of possible active agents on this Enterprise Edition pool is 1,200 (400 agent groups x 3 unique agents per group).

Example 3 : Each hunt group is associated with one or more Response Group application queues and each queue is associated with one or more agent group. All agent groups have 50 unique users in total. The total number of possible active agents on this Enterprise Edition pool is 50.

To count the total number of possibly active agents on a given Enterprise Edition pool or Standard Edition server, look at all agent groups associated with Response Group application queues on the same Enterprise Edition pool or Standard Edition server and count the unique agents that are members of these agent groups.

Lync Server Resources

• Lync Server 2010 Documentation Library


• DrRez blog


• NextHop blog


• Lync Server and Communications Server resources

We Want to Hear from You

• Fan us on Facebook


• Follow us on Twitter


• Send us e-mail