New call routing features in Office 365

As christmas sneaks up on us, we have received new call routing features in our Office 365 subscription. The new call routing features are both auto attendant and call queues.

Auto Attendant news:
Just in time for the holidays a new holiday scheduling feature has been released. This gives us the opportunity to schedule a holiday period and greeting.

1. Name the holiday set, e.g. Closed for christmas
2. Define what the callers should hear, options are a TTS prompt or upload an audio file
3. Define what should happen after the announcement, options are disconnect or redirect call to either a person in the company, a call queue or an auto attendant
4. Define when should be activated start and end date and time (half-hour interval only, minutes 00 and 30). You can have multiple schedules
5. Save and add to AA.

This feature is easy to implement and maintain for the office admins, but we still face an issue with the half-hour interval for business hours.

Call Queue news:

A new call distribution has been released, serial routing. This setting will route a call in the queue to the first agent in the grouplist, if this agent is not available then route to the second agent in the group etc. 

1. The new Serial routing option
2. List of groups of agents, the groups can be Office 365 groups, distribution lists or mail-enabled security groups

This feature improves the call queue usability for many organizations, but we still face a limitation of 50 agents per call queue.

Queue timeout has been made more granular, instead of just a number of minutes we now also have an option of seconds (0, 15, 30 or 45) which should be sufficient for most organizations.

When the queue time has been exceeded, the call is either disconnected or forwarded to a person in the company, a call queue or an auto attendant.

Last, but not least, it is worth to bring to attention the mobile app, which is now able to receive a call from a call queue, at least on my Android powered device.

This is from the log file of my mobile app:

Change SIP URI of a response group

A customer wanted me to change the SIP uri of a response group workflow. This is not an option using the Response Group Configuration Tool, so what you must do is delete the existing workflow and create a new with the same parameters, the workflow Name is a unique identifier.

This is not what I wanted, so I turned to Powershell.

Tried:
$wf = Get-CsRgsWorkflow | where-object {$_.Name -eq "RGS test"}
$wf.primaryuri = 'sip:testrgs@sip.dom'
Set-CsRgsWorkflow $wf
But this was, kind of expected, not possible. You cannot change the primary uri of a Response Group Workflow...

Off course I can, I just need to figure out how.

In the backend database of the frontend pool hosting the RGS application, there is a database RGSDYN, I have blogged about that previously here: https://uctales.blogspot.dk/2016/02/response-group-agent-state.html, this database contains all dynamic data on e.g. agents logged in state. There is also a RGSCONFIG database, this database contains all RGS configuration.

Going to SQL Server Management Studio and opening a query window and entered this query:
use rgsconfig
go
Select Name,PrimaryUri from Workflows where PrimaryUri like 'sip:rgstest%'
Shows the Name and SIP uri of the RGS test workflow.

Changing the SIP uri of the workflow using SSMS, from sip:rgstest@sip.dom to sip:testrgs@sip.dom.
use rgsconfig
go
update Workflows
set PrimaryUri = 'sip:testrgs@sip.dom'
where PrimaryUri = 'sip:rgstest@sip.dom'

Now we have changed the SIP uri of the workflow, but this is not enough, we must also change SIP uri and proxy address of the application contact object i Active Directory.

To find the application contact, we go to Powershell again and searches for the endpoints.
Get-CsApplicationEndpoint | Where-Object {$_.sipaddress -like "sip:testrgs*"}
This cmdlet returns the application endpoint identity, which we need to locate the AD object itself.



Go to ADSIedit.msc and open the configuration store -> Services -> RTC service -> Application Contacts and edit the object attributes msRTCSIP-PrimaryUserAddress to sip:testrgs@sip.dom and proxyAddresses to sip:testrgs@sip.dom

Tested workflow and everything works nicely. Job done.

Disclaimer: Editing the database entries and AD objects for Application Contacts, might lead to an undesirable state, unrecoverable failures, unsupported solution or smelly feet. Please only do this at your own risk and if you know what you are doing and are able to recover from these risks.

Response group agent state or how to check RGS agent state

A client recently had an issue with a response group (RGS) queue, where the call came nicely into the queue, but the call was not presented to the agents.

A small query into the Skype4B backend database gave us the answer: The agent were not logged into the RGS.

select T1.Name, T3.DisplayName, T4.[State] 
from [rgsconfig].dbo.AgentGroups as T1
join rgsconfig.dbo.AgentGroupsToAgentsMap as T2
on T1.ID = T2.AgentGroupId 
join rgsconfig.dbo.Agents as T3
on T2.AgentId = T3.ID
left join rgsdyn.dbo.AgentGroupSignInStates as T4
on (T2.AgentGroupId = T4.GroupId and T2.AgentId = T4.AgentId)
where T4.[State] in (0,1) and T1.Name like 'servicedesk 1%'
group by T1.Name,T1.ID,T3.DisplayName,T3.ID,T4.[State]

Gave us a nice little list of the users:

State 0 = not logged in
State 1 = logged in
If the user is not in the list, the user has never signed into the response group.

We can see that there are no users active in Servicedesk 1. line group, so this explains why no calls are presented to the agents