Partager via

Understanding Lync Response Group

  • Article

Before starting to give some clarity on the Response Group itself I want to get clear on the terms I might use: Response Group Service and Response Group Application. They mean and are referencing exactly the same service "RTCRGS". Response Group Service (RGS) is how they were call in Office Communication Server R2 and Response Group Application (RGA) is the official name for Lync Server. If I confuse you by using RGS or RGA that is my fault but really it does mean the same thingJ.

Now that we agree on the terminology, let me give you a very short explanation of the purpose of this service: create and manage response group(s) to route and queue incoming call to agents (or any Sip Uri).

If you play a bit with OCSLogger (tool to collect traces from Lync components, available when you install Lync Server) you will notice two main components for RGS call handling:  RgsHostingFramework and RgsMatchMakingService.

From this traces we can extract the logical behind the response group engine.
Basically the hosting framework will handle the incoming call and decide if it needs to transfer the call to the match making service. The match making service will decide to which agents he can transfer the call to.

Without getting too much in details, this is what is going when a call hit a RG:

Hosting Framework:

  • 1. Handle the incoming call , create a new instance of a workflow
  • 2. The workflow will then:
  • i. Make some checks to see if it can accept the call
  • ii. Find the appropriate workflow
  • iii. Play the welcome prompt using TTS or default music.
  • iv. Validate the hours of business are open
  • v. Validate that there is no holiday
  • vi. Depending on the workflow type, run the IVR (Interactive Voice Response)
  • vii. Send to match making service

The link you should look at between Hosting Framework and Match Making service is the CallID.

Match Making Service (MMS):

  • 1. Validate to be the active MMS otherwise send to the active one
  • 2. Find the appropriate queue (multiple queues can serve on workflow)
  • 3. Get the correct agent group
  • 4. Find available and eligible agent(s), depending on the routing method (parallel, longest idle, serial or attendant).
  • 5. Send the collection of available agent back to the call handler to execute the transfer.

At this point the agent will receive the SIP Invite from the user (transferred by the response group).

 

I hope this brief overview clarify a bit how the Response Group Application service is working. Along future posting here I will go more in details about each steps (how to configure, how to manage and how to read the traces and understand problems).

Thanks for reading!
Ahmet