The Scenario
As part of a greenfield Lync 2013 deployment, the client requested to have a Response Group Service (RGS) workflow answer a phone call, offer various options, one of which was to redirect out to the company directory – in this case, Exchange 2013. We got the first parts done without issues, but the “redirect out to the company directory” part just killed us. No matter what we did, we either got nowhere, or the call would just drop. Not good.
After some searching, I found bits and pieces that enabled a Lync 2013 Response Group (interactive) to have an option to drop to the company directory. In theory, this should have been pretty easy. Fellow MVP Brian Ricks has a write up that will get us started. Then take a look at this TechNet forum thread. Parts here, parts there. Put enough together, and we have a solution.
The Solution
Assuming you already have the Exchange Auto Attendant setup in Lync as a contact object with a valid DID, The overall flow is: you need a user, a group, a queue, and then the workflow with the queue as the selection. The queue must have a group which must have a member, although the user will never login and the queue will never get to the point of trying to contact the group because we are going to set the queue to go straight to the AA. The group, the queue, and the workflow all need to be homed on the same application server (pool). RGS is specific to a pool.
Create a RGS Group with at least one member – I used a dummy account enabled for EV but with no DID. It won’t matter too much, as you will see in a bit, the group member will never be used. But, you need to have a group with a member.
Dummy user
RGS group
Now that we have an RGS group and with our dummy user, we need to create an RGS queue that has that group as the target.
Create a Queue.
Now, set the queue as follows:
Note that the queue “enable time out” is unchecked. We did enable the “queue overflow” with a maximum call count of ZERO. This results in a queue that immediately takes the call action of “forward to SIP address” which in our case is the Exchange UM AA contact object “ExUMAA” – this is why the dummy user is not used – the queue gets no farther than this action.
Create the workflow – for our purpose, we had an interactive with several choices, one of which was to drop out to the company directory (read Exchange Auto Attendant).
If you have multiple pools, make sure you select the same pool as the group and queue. When the website opens, in the “Create a New Workflow” you can select either – we are using the interactive selection.
Make sure that you know what the SIP address of the group is that will receive the calls.This is important to the functioning of the RGS workflow as a whole, but unimportant to our little slice of functionality. We will however, be using this SIP address in a bit. This SIP address will exist as a CsApplicationEndpoint – and will not exist until you create it with the process of creating the workflow. You will also need a valid DiD (if you want this to be accessible from PSTN) or extension (if this is an internal only thing). Either way, the TEL is entered as E.164. (+11234567890 format).
Glossing over the configuration of the rest of the RGS workflow, let’s move onto the selection process for the interaction we want. If you are interested in learning RGS creation, here is the official guidance.
Here is the relevant section of the workflow creation. We used “Response 3” – but it could be on any of the four available.
Notice that the queue selected is the one we created, with the group and the dummy user that will never get used.
The logic is this: The caller lands on the RGS, and if they select option 3, the RGS looks into the workflow and redirects the caller to the queue. But the queue is set to zero calls and redirects to the SIP of the Exchange AA. Wala!
Assign the workflow SIP to the Dial Plan.
But, at this point, the entire construction still won’t work. We need ONE more item – we need the RGS to be able to talk to Exchange. To accomplish this, we need to assign the CSApplicationEndPoint (from above) to a user voice policy that belongs to the dial plan that is being used with Exchange. This authorizes the RGS to communicate with Exchange. To do this, open the Lync Management Shell. Once you get there, this is the command string you are looking for:
Get-CsApplicationEndpoint sip:<RGS_SIP_Address>| Grant-CsVoicePolicy -PolicyName <VOICE_POLICY_NAME>
Happy RGS’ing to you!
Summary
To allow a Lync RGS to redirect to an Exchange Auto Attendant, we created a dummy user, added that user to an RGS group, create a queue with our group as the member; the queue was configured to immediately forward to a SIP address; then we created an interactive RGS workflow with one of options set to redirect to our queue with the group and the dummy user. Finally, we granted the SIP URI of the RGS workflow a user level voice policy to connect the RGS workflow to the Dial Plan.
YMMV
No comments:
Post a Comment