For the last 6 months I have been delivering a number of global contact centers based on Skype for Business and Anywhere365. The journey has been long and at some points painful, but we have got there and everyone is happy! Along the journey I have learnt a lot, cried a lot and laughed a lot! Now I am going to share with you some information that will help you decide if your Skype for Business deployment can cope with Anywhere365.
Firstly, Anywhere365 is one of only a few native Skype for Business contact centers. Do not get confused between this and contact center vendors who say they integrate with Skype for Business! To help you understand the meaning:
- NATIVE means that the application uses Skype for Business Server functionality and APIs such as UCMA to build the contact center software. This means that it will use SfB Server components and media to deliver the functionality as well as baked in support of the Skype for Business client application.
- INTEGRATED usually means that the contact center has an endpoint(s) registered in Skype for Business that takes the call away from the native components into their own system and deliver this back to the agent maybe to the Skype for Business client by itself, maybe a dedicated agent application, or the Skype client with the aid of a plugin.
There are positives and negatives for each, and this post is not about pitching one over the other.
As a result of being a native contact center, Anywhere365 of course leverages a lot of what Skype for Business has to offer in order to create those special contact center communication scenarios. To begin with Anywhere365 hooks into Skype for Business as a trusted application. As a trusted application, it requires trusted application endpoints. These endpoints act as the route in and out of the Anywhere 365 application and Skype for Business.
Another fundamental aspect is that Anywhere365 does not have its own media engine. In other words, it cannot control media paths, transcoding, media establishment etc. It is oblivious to that. Instead Anywhere365 leverages the conferencing service on the Skype for Business Front End Servers to connect the caller to the agent. This means that Anywhere365 is only part of the SIP signaling loop between caller and agent and as a result, requires less server resources that integrated contact centers.
So How Does a Conversation Work?
When a caller places a call to the contact center, they are calling the LineURI that is assigned to the trusted application endpoint attached to the contact center application. At this point all Skype for Business has done is routed the SIP signaling through to Anywhere365. Anywhere365 will accept the SIP INVITE sent to it and then send a signal back to Skype for Business to create a conference. Once the conference is created, Anywhere365 invites the caller to join that conference. The conference is hosted on the front end pool that the Anywhere365 server is paired to by the trusted application pool.
As soon as the caller is placed into the conference, Anwhere365 will play the welcome and queue messages to the caller within the conference. When you look at the logs, you will see that during these messages temporary SIP URIs join the conference to play the messages or hold music and remove themselves when no longer needed. Once the caller is in a position to be connected to an agent, Anywhere365 hunts an agent based on presence (and other parameters) and once an agent has been found they are invited to join the conference that the caller is in.
As you can see, conference performance is of paramount importance to Anywhere365. A well performing AVMCU will create and join the caller to the conference in about half a second when done programmatically. In layman’s terms this is approx. half an ring. If you call an Anywhere365 contact center you hear multiple rings before hearing the first message, or the call being accepted, then more than likely you have a problem with your conferencing service. Similarly if it takes a noticeably long time for messages to play then this could also be related to conferencing service performance issues.
Luckily there are a few things that you can do to eliminate other possibilities:
- Assign a conferencing policy to every endpoint you create for your contact center. This includes the main, hunting and other system endpoints you may create. Why? Well Anywhere will use a random endpoint to create the conference. If that endpoint does not have a conferencing policy, then the conference creation can fail, then another endpoint is tried etc. etc. resulting in delays.
- The conferencing policy must have the following parameters set; –AllowAnonymousUsersToDialOut $True, –AllowAnonymousParticipantsInMeetings $True, –AllowExternalUsersToRecordMeeting $True (if you want audio recording), –AllowNonEnterpriseVoiceUsersToDialOut $True. If these are not set in the conferencing policy, some random things will happen, usually resulting in performance issues of a varied kind.
- Assign each endpoint an appropriate dial plan and voice policy too if you want dial out to work via the contact center.
Before installing Anywhere365 and trying to use it, you need to spend some time understanding your environment and your current performance across all components and modalities. Luckily Microsoft have invested a lot of time and effort producing performance benchmarking tools such as Key Health Indicators and the Stress Test Tool (often ignored due to complexity and time). These should absolutely be run to establish a baseline of your current performance as underlying issues could be amplified as soon as contact center workloads are placed on the environment.
Next you need to work out whether your conferencing servers (front ends) can handle the expected number of contact center conferences above the normal number currently consumed. This will help you decide whether you need a separate front end pool for your contact centers or not.
Calculating Conference Availability
To calculate this accurately, you need access to the Skype for Business Monitoring and reporting database. Your aim here is to produce a report containing the number of conferences on the pool over the course of a normal working week. For Example,
Once you have the numbers, you can establish an average number of conferences for each pool per day. In my example above the averages look like this:
|Average Per Day||248||773||622|
From the report you also need to establish the average number of conference participants and also the average conference duration in minutes
|Average Number of Participants||5||15||5|
|Average Conference Duration (minutes)||31||35||31|
Now you have this base information, you can now start working out your concurrent conferences per pool. We can do this by first calculating the total average talk time per day, (AVERAGE DURATION x AVERAGE NUMBER OF CONFERENCES ON POOL) e.g. For UK that’s 35 x 773 = 27055 minutes.
Next, the working day for the UK is 8 hours, so we can deduct from the reporting that these conferences took part over the course of an 8 hour window. So we need to find out the concurrency. For that we need to find out how many conferences are taking place every second. This can be achieved by (AVERAGE TOTAL TALK TIME PER DAY / WORKING DAY) / 60 In the UK’s example that’s (27055/8) / 60 = 57 concurrent conferences.
Once this has been calculated we are closer to finding out the available capacity. The theoretical maximum number of conferences on a front end pool is calculated by the total number of conferencing users in a pool at any one time. The theoretical limit is 3,996 users in a 12-node pool, or 333 per front end server. But as not everyone has 12-node front end servers and conference consumption is hugely different between companies, the calculation between conferencing users and total number of conferences per pool can vary massively. For instance if your average participation in conferences is 3 users, then you have 111 conferences available per FE. However, if your average participation is 12, then you only have 27 conferences available per server!
In the UK example here, I have an average participation of 15 users per conference. The UK pool is a 3-node FE Pool. So using the logic applied we can calculate that each Front End has a capacity of 22 x 15 person conferences per server, resulting in a pool maximum of 66 x 15 person conferences
Now how are these conferences divided? We can calculate we have 57 simultaneous conferences going on, so (SIMULTANEOUS CONFERENCES / NUMBER OF SERVERS IN POOL) e.g. 57 / 3 = 19 conferences per server
To find the total number of conferencing users per pool you need to multiply the average number of participants by the number of simultaneous conferences taking place (AVERAGE NUMBER OF PARTICIPANTS x NUMBER OF SIMULTANEOUS CONFERENCES) e.g. 15 x 57 = 855 in the UK example
Next, you need to find calculate the distribution of these conference users over the number of servers in the FE pool (NUMBER OF CONFERENCING USERS / NUMBER OF FE SERVERS IN POOL) e.g. 855 / 3 = 285 in the UK example based on a 3-node FE pool. So the UK has 48 conferencing users available per server or 144 available conferencing users in the pool.
So the baseline result for Anywhere 365 conference availability for the UK is as follows:
- 144 x conferencing users available in the pool
- 6 x 15 person conferences available in the pool
Calculate the Predicted Anywhere365 Conference Consumption
In this example we are limited by the number of available conferences being 6. However, it is likely that contact center calls are only going to have 3 participants at any one time (caller, agent and system endpoint). So if we multiply the 6 available conferences by 15 (number of users) then we can see that we could have a further 90 x 1 person conferences instead of 6 x 15 person conferences. Divide 90 by 3 and we can subdivide those 6 x 15 person conferences into 30 x 3 person Anywhere365 available conferences.
So now we have a potential upper limit of 30 Anywhere365 conferences available for the UK pool. But we aren’t finished yet!
From the contact center design, you need to know the expected average call duration of inbound and outbound calls combined, for example 4 minutes. On top of that you need to calculate the average hold time and the time required to play messages to the user, because the conference begins on acceptance of the call, not when the agent begins to talk! So the calculation is (AVERAGE TALK TIME+AVERAGE WAIT TIME+AVERAGE SYSTEM TIME) e.g. for the UK pool we estimate in this example 4 minutes of actual talk time, 3 minutes of wait time and 2 minutes of messages (welcome, IVR, busy etc.) i.e. 4+3+2 = 9 minutes
We also need to know how many calls are expected per day across all contact centers deployed on the same Anywhere365 pool. In this example we will assume that there will be 300 calls per day across all UCCs.
So now we can do the same calculations to predict the Anywhere365 conference consumption.
1) Calculate average total conference duration over the course of the day = 300 calls per day * 9 minute duration = 2700 minutes total conference time
2) Calculate the total number of simultaneous Anywhere365 conferences at any time = (2700 / 8)/60 = 6 conferences per second
3) Calculate the total number of conferencing users per simultaneous conference = 6*3 = 18 (subtract 18 from 144 = 126 conferencing users left in the pool)
4) Subtract the number of expected conferences from the available Anywhere365 conferences = 30 – 6 = 24 remaining Anywhere365 conferences in the pool
From this we can summarise that the existing front end pool in the UK can support the expected conference workload without adding capacity or dedicating a conferencing pool to just Anywhere365 workloads. Keep the metric under the potential limit and you should be within optimum performance ranges.
I hope this helps you calculate your capacity when deploying Anywhere365.