Enable Federation between Cisco Jabber and Microsoft Skype For Business (SFB) Server
Enterprise Voice (EV) is regarded as the primary business communication tool. It's critically important for organizations to have a sound resiliency plan of it. In case of enterprise voice outage, the financial and operational implications on business are huge. Downtime of Enterprise Voice (EV) functionalities has an immediate negative influence on organization. Hence, it makes every possible sense to plan enterprise voice deployment in more sophisticated and resilient manner.
Your voice architecture should ensure that the users continue making and receiving calls even if a major component of the deployment becomes unavailable at some point of time.
Let's look at the hardware and software components which determine a resilient voice architecture. These components must be planned and configured to eliminate any single point of failure in the deployment.
Pool (Skype For Business) Level Failover
You should deploy pairs of Front End pools across two (minimum) geographically dispersed sites. Each site has a Front End pool which is paired with a corresponding Front End pool in the other site. Both sites are active, and the Backup Service provides real-time data replication to keep the pools synchronized. In order to restore SFB services (during a disaster), the SFB pool (and all registered users) can be failed over to the paired pool in same site, or to a pool in another site.
Mediation Pool Level Failover
You should plan to have more than one Mediation Server pools. However, that’s not enough. You should configure voice routes to contain multiple Mediation Server pools for failover purposes. Identify all inbound and outbound routing policies, and make sure that cross-pool policies are configured where necessary. Users hosted on pool S1 should be able to route calls through the Mediation Servers of pool S3 to the PSTN as a last resort. Also, inbound PSTN should be configured to have redundancy to Pool S3 in the event that Pool S1 is unavailable.
Gateway Level Failover
A resilient gateway architecture provides service continuity under following circumstances;
- Hardware and power failure
- Link failure between sites
Hardware and power failure: You should always select a gateway model which provides redundant power supply to minimize failures.
Link failure between sites: The gateway should be configured to re-route incoming calls to a PSTN network in case of link failure.
Also, it’s always advisable to have minimum two gateways per pool. If gateway G1 is unable to route PSTN calls, SFB pool would mark that gateway down. Another gateway G2 will be used henceforth to route all PSTN calls. PSTN call routing would resume via G1 when the trunk lines become available again. During this process users will not have any issue to either place or receive a voice call.
Trunk (SIP, T1, E1) Level Failover
Redundant trunks should be planned at local and geographical level. Depending on requirement and availability, you can also plan (SIP) trunks between New York gateway and Chicago service providers, and vice versa.
For High Availability (HA) purposes you should always plan multiple SIP trunk entry points into an enterprise network. This ensures that calls have alternative routing points during emergency (equipment failure, power cuts, natural disaster etc). Also, you can plan to maintain TDM gateway access to the PSTN for failover purpose.
You can also plan to reroute calls to your already existing TDM gateways when the SIP trunk is not available or overloaded.
Service Provide Level Failover
You should also get T1\E1 trunks from two different service providers, both for least-cost routing opportunities and for redundancy purposes. If one provider is having problems, the other provider's facilities can carry all traffic. Usually, it's easier to implement for outbound traffic but harder (due to DID mapping) for inbound traffic.
From an Architect’s corner
What we discussed above, is a tip of the iceberg. There are many other factors which determine overall health of enterprise voice resiliency. It spans from the hardware to the network to the services. You also need to consider type of site you are planning resiliency for; central or branch.
By the end of day, you need to have a solid logical construct in order to list down organizational requirements. Also, you need to categorize requirements as mandatory or optional. This is the foundation which will help you lay out a resilient enterprise voice system.
The process involves working with various stakeholders (network, voice, security, data centre etc), and incorporating their views (if required).
Your design considerations should have answer of following questions. What if;
- Voice gateway goes down?
- Network adapter of a system (FE, GW, Mediation etc) goes down
- There is power outage at system or site level
- Service provider is unable to route call in a certain location?
- Voice route becomes unavailable?
- Data centre goes down?
- Branch site is unable to connect to the central site?
- SIP based call routing doesn’t work
Depending on a particular project, the list could grow longer!