Skype for Business and Sonus–Remote Site Survivability (an alternative approach)

When deploying Skype for Business to medium sized organisations, the main challenges tend to be around how to ensure that remote sites adjacent to the main headquarters remain online for as long as possible in the event of an infrastructure failure. If you follow the Skype for Business architecture, you will know that the best practice is to deploy some hardware to remote sites that warrant it. Whether the requirement is down to user count, or a business critical process mandates a remote site’s availability service level agreement, this is often a battle between affordability and best practice. We Skype consultants will always peddle best practice recommendations to our customers, because we know they work, and more importantly, we know that the solution is backed by both Microsoft, and other hardware / software vendors. This results in our customer’s receiving the best possible after care service, a supported topology and upgrade path, ensuring the integrity of the complete product lifecycle is maintained.

However, for some customer’s, best practice deployments can be beyond the affordable reach of the business. For instance, a 50 employee company wanting Enterprise Voice High Availability with DR resilience would not be able to realistically afford this type of topology. Sure there are now alternatives, such as Cloud PBX with Skype for Business Online, but even this has it’s own set of requirements, restrictions and costs.

Digressing slightly from the purpose of this post, imagine 50 users subscribed to Cloud PBX (let’s do the minimum subscription level to remove the E5 value) all have Skype for Business Online Plan 2 at $5.50 per user per month. Add in Cloud PBX at $6.00 per user per month, then $12.00 per user per month for a national calling plan = $23.50 per user per month / $282 per user per year / $14,100 total company spend per year before tax. Over a 5-year TCO plan this is a $70,500 investment. On-premises 5-year comparative, $25,000 in server infrastructure, $6,000 in Skype for Business licensing, $7,000 in other Microsoft licensing (CALs, OS’s etc.), 20 x SIP Channel subscription with 3,000 minutes per month $12,000, other hardware SBC’s etc. $5,000 , totals = $55,000. Add on to this hardware warranty support and a level of application support, then the two options are evenly matched.

Comparing cloud to on-premises, there is only one real winner in the end, the cloud. Why? You can’t beat the convenience of the cloud, scale-up / down as you like, infinite capacity and service at your fingertips, plus Microsoft and other providers will eventually force your hand to adopt the cloud, whether it be by cost or feature. So you might as well accept it now, the future is cloud, the end…, – get over it! LOL.

However, there will be some companies out there, large or small that going cloud only for their enterprise voice, is simply not an option for one reason or another. Within this category, there will inevitably be a subset of companies that have to watch the purse strings. This post is for these companies.

Imagine, one of these companies is the same 50 employee business. Now imagine that the company has two sites, Headquarters, and a Customer Servicing Center. 35 employees are located permanently at Headquarters, while 15 employees are located at the customer servicing center. The customer servicing center is responsible for handling all inbound and outbound customer service queries and is critical to the success and operation of the business. The customer servicing center inbound calls are handled by Skype for Business Response Groups and all Enterprise Voice functionality is provided by a Standard Edition Front End server connected to a Sonus SBC 1000 located at Headquarters. Between Headquarters and the customer servicing center there is a 20MBps WAN link.

The company conducts a review of their business continuity plan, and decide that this WAN link poses significant risk to their operations if the WAN link went offline. As part of the mitigation action plan, the company allocates a modest budget of $10,000 to provide a suitable solution to the problem (sounds like a Microsoft exam question this Smile). What would you recommend in this scenario (comment below if you want)?

Let’s take a look at the best practice approach to this scenario. Using the information provided by the business review, we determine that the customer servicing center is the cornerstone of the company’s operation. If that is the case, then there is an argument to simply move the Skype for Business servers and SBC from headquarters to the customer servicing center. However, this reverses the problem for headquarter employees. In addition, there is not enough capacity at the customer servicing center to locate the physical infrastructure without investment beyond the budget allocated. Next, we look at the possibility of installing a Survivable Branch Appliance. Whilst this would give user DDI’s a level of voice availability to the PSTN, if the WAN link went down, inbound voice from the Response Group service would also fail. What about a Survivable Branch Server? We would still require an SBC which is located at headquarters and also the Response Group Service is not part of an SBS deployment.

So we are stuffed right? Perhaps.. perhaps not. The ideal solution here would be to deploy a Standard Edition Skype for Business Front End server to the customer servicing center site with a local SBC and PSTN breakout. Migrate the Response Groups over to the new front end, and migrate the inbound help PSTN lines to the branch site. Let’s explore this option

Server Cost


SBC Cost


SIP Trunk Cost


Skype Licensing


SIP Licensing




Using this option we can see we are over budget by $3,000. While this is not a massive amount, remember this is an additional 30% on top of the original budget. You could go back to the business and negotiate a budget extension, you could work with suppliers in an attempt to shave some costs. However, if all options fail to reach an adequate outcome, we must now look for alternatives.

Breaking the requirements down, we determine that the need for an on-premises Skype for Business Front End server at the customer servicing center is absolute. We cannot avoid it, as we need to migrate the response groups to this local server. In order to protect against the WAN link failure, we must also deploy a writeable domain controller to the same site. We are able to procure 2 x <vendor neutral> servers with a quad core processor and 32GB RAM for $2,500 per unit. Adding this to our budget shopping list we can see that we need to shave a substantial portion of hardware / licensing. The most likely candidate to be removed would be the SBC. However, without it, the customer servicing center would still be offline in the event of the WAN link failing, so all this would be for nothing.

Widening the view of this project, you realise that the headquarters has 1GBps connection to their ISP network, the SBC has an interface configured on this network that is used to connect to the ITSP and PSTN for enterprise voice calling. Exploring this a little further it could be possible to connect the new mediation server in the customer servicing center to this interface over a “third party” WAN connection i.e. the internet… Providing budget estimates, show that obtaining a 40MBps internet connection locally is relatively cheap at $30 per month. Let’s take a look at how our budget shopping list is now shaping up

Server Cost


Skype Licensing


Internet Cost




So we now have a plan within budget. But lets first qualify what we are suggesting technically. Proving connectivity through to the SBC at headquarters over a public internet connection returns a positive result. Now that we know we are able to reach this interface from a non corporate network we can start to provide our solution with some substance. Next we need to understand a bit about how SIP and media works, especially around NAT. NAT is where the source address of the sending / or receiving computer sits behind a firewall that masks the computer’s real identity (IP Address) and a data packet must pass from one computer to the other. As the packet passes through the firewall it “traverses” the NAT table on the firewall device. The firewall holds the list of private IP addresses within it’s trusted network domain and therefore is able to successfully route the data packet to the intended destination based on a number of parameters such as source address and destination port / protocol.

How does this relate to SIP? SIP generally is a robust messaging protocol and can handle NAT without modifying the messages sent within the protocol as the transport mechanism for SIP is TCP (usually) which is able to traverse NAT. However, the problem comes when establishing media using SDP, or Session Description Protocol. SDP offers what it calls candidates to peers (and other information such as supported codecs) in order to establish a media stream. However, the candidate IP list is built from the configuration within the UC platform e.g. Skype Mediation Server IP address. In this example the SDP candidate list would list the private IP address of the customer servicing center mediation server as a possible candidate for media establishment. Obviously, this would be a problem because media establishment will fail as you cannot route between a public IP and private IP without NAT.

To get around this, some firewalls support “a thing” called SIP ALG, or SIP Application Layer Gateway. SIP ALG effectively inspects VoIP packets and modifies the contents, replacing the private IPs listed as media candidates with the public IP of the firewall to get around this problem. If you are lucky and your firewall supports this feature, great. if not, then can we do anything the other side of the link i.e. the SBC side? There sure is.

For the following, I am assuming that you know your way around a Sonus SBC. If you don’t I suggest you read my 5 part series on how to set one up here

First we need to create a new signalling group and sip server table for the public route to the mediation server.

  1. If you look at the Sonus Signalling Group, you will notice an option to detect inbound NAT traversal


  2. This is what we need to leverage. When we enable it we realise that a Qualified prefix table is required
  3. Under the SIP navigation branch within the Sonus administration panel, you will notice a section for NAT Qualified Prefix Tables. Create a new table here:


  4. Next add the private IP address of the customer services center mediation server to the prefix table
  5. Create SIP Server table for your public mediation, using the public IP of your mediation server, port and protocol (I recommend that you use TLS with required encryption for this)
  6. Next create the signalling group. In the first part we are going to add the signalling group to the existing route between the PSTN and the Skype servers at Headquarters. Then set the sip server table to the branch table created in Step 5
  7. Now apply the Qualified NAT prefix table to the signalling group
  8. Add in the listen port of 5067, protocol as TLS and select the correct TLS profile. Add the public IP of the branch mediation server to the lists of federated IPs and save the group
  9. Next we want to make a transformation rule that will identify the called number of the response group for the customer servicing center e.g. +441279891001. Create a transformation rule to match the specific RGS number
  10. Next we need to create a route within the PSTN to Skype routing table. Note, that if your PSTN to Skype route is already performing a pass-through untouched or global normalization of any number, the route to the branch site must be reordered to be first route in the table. Create a route entry selecting the transformation rule created in step 9 and add the destination signalling group of the branch site
  11. Reorder if necessary
  12. Next you will need to add the public IP of the Sonus SBC to the Skype topology for the remote customer servicing center site as a IP/PSTN Gateway, and configure the Trunk port of 5067 and TLS as the protocol.
  13. After publishing the topology, you will need to ensure that the mediation server uses the local internet route for this address. A simple trace route should identify the correct gateway. if not add in a static route default route to use the local gateway.
  14. Migrate your response groups over to the branch front end server.
  15. After this has been done, inbound calls should be routed directly to the customer servicing center mediation / front end server
  16. Outbound calls will still go via the WAN link, so in order to resolve that add in the additional route to the SBC to your local voice policies as a backup route.

So what do you get here, what does it solve?

  • The customer servicing center response groups are hosted locally and in the event of a WAN link outage, the agents or response groups are not affected
  • Incoming calls from the PSTN are routed to the customer services center directly from the SBC at the headquarters using a public connection and not the WAN link
  • Agents are able to place calls to the PSTN using the WAN link as their primary route, but have a backup route over the public network in case of a WAN link outage

So in effect, you have a level of survivability as long as the network connectivity remains between the ITSP and the Sonus SBC at headquarters. It may not be best practice, but it is the best solution the company can afford. Ultimately, there are a variety of ways in which this scenario can be addressed, I favoured this one for the simplicity of it, and because I like using Sonus Smile

Finally, this example is a hypothetical scenario to show the power of Sonus with Skype for Business. It is not a real world working example and tested at high level within a controlled environment. Although tested working I encourage you to be careful in considering this in a production environment without conducting your own testing beforehand.

One thought on “Skype for Business and Sonus–Remote Site Survivability (an alternative approach)

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s