Facts are funny things. Consider the egg. It wasn't that long ago when all the so-called nutritional experts told everyone to limit their consumption out of fear of raising cholesterol levels. Lo and behold, it turns out they were wrong and eating eggs actually helps lower the amount of bad cholesterol the body produces. Go figure.
Of course, you didn't come here to read about dietary guidelines. You came here to read about trends in communications. Well, facts can be pretty malleable there, too. Case in point is the notion of branch office survivability.
The Survivable Branch Office
Since the early to mid-2000s, I have been consistent in how I designed a survivable branch office. My best-practices solution consisted of one or more gateway, a call processor, and some local trunks. During normal operations, the branch office relied on the enterprise's main processor for all call processing activity and the remote processor would sit idle until the primary system died or the WAN connection went down. The gateways would then attach themselves to the local processor and calls would resume.
While there is technically nothing wrong with this configuration, the cost can be quite high for a branch with a small number of users. Companies that weren't willing to pay the price were driven to less optimal solutions.
Mobility is the New Survivability
There are times when this hardware-centric approach to branch survivability is still the best option, but the fact is that we now have choices. With the advent of SIP, enterprises are free to move away from this one-size-fits-all mentality. Large branches can choose to deploy survivable processors and local trunks, while smaller offices can skinny things down to nothing more than a network and remote SIP endpoints. In fact, the physical telephones at the smallest branch can be the same as the ones used by much larger branches or even the main site. There is no need to settle for less based on the number of users at a location.
On a sunny day, those telephones continue to draw call processing features from the core site across the company's WAN. From a user's perspective, there is nothing new here.
When a disaster strikes the core system or WAN connection, users lose the ability to use their desk telephone, but SIP can deliver the same telephony features on a 4G/LTE connected device. For instance, I am an Avaya user and my iPhone and iPad run Avaya SIP soft clients that provide me the same telephony functionality as my 9641 physical telephone. I can dial the same digits to call coworkers or outside numbers, and people call me with the same number as my desk phone. The only difference is the device I hold in my hand and how it connects back to the main site.
Not only can these SIP soft clients make and receive telephone calls, but they also have access to all sorts of unified communications functionality. They can send instant messages, make video calls, and create and join conference calls. They even have access to voice mail.
Transitioning back to normal operations after a failure is totally seamless. As soon as the core system is available again, the desk phones re-register. At that point, users can choose to stay on their mobile devices or return to the comfort of an old-fashioned handset.
Of course, you don't need a WAN failure to use those mobile soft phones. SIP allows the same user to simultaneously register against multiple devices. Users decide which device makes sense at any given point in time.
Cloud-Based Business Continuity
Another option that is becoming increasingly popular is to add elements of cloud communications as part of a comprehensive business continuity strategy. Instead of going headfirst into the cloud, you dip your toes into the water for key people, groups, or remote branches. Perhaps you provide cloud communications to your first responders and key management personnel. Perhaps you give critical departments standby cloud resources. The point is that this isn't a full-blown rollout to the entire company, but only to a select few and only for times of great need.
Cloud communications for business continuity works like this: Prior to the disaster, you identify the people that require enterprise communications during the time of failure. These people are configured as users on your cloud system and install SIP communications software on their PCs and smart devices. They don't actually use the software at this point in time. It's simply there waiting to be told to do something.
Next, you configure SIP trunks with the numbers you intend to use during a disaster. These trunks are "wired" and provisioned at the carrier and cloud levels, but are not activated.
When a disaster occurs, the accounts are activated and the users start up their soft clients. Within a matter of seconds, they can communicate with their coworkers. Next, your carrier is informed of the disaster and the SIP trunks are activated. Depending upon the carrier, this might require a few minutes or a few hours. Once the trunks have been activated, your cloud users are able to call out and the outside world is able to call in.
Like the SIP users in my previous option, these cloud users have access to a full range of multimedia communications features during the outage. In fact, they may even have more functionality in disaster mode than their normal communications system supplies.
The users and trunks remain active for as long as they are needed and once the disaster is over, the cloud resources return to their dormant state and the users reconnect to their premises-based system. It's that simple.
Just the Facts
I learn something new nearly every day and I am not afraid to change my mind. Some branches require a full-blown hardware solution, while a growing number of branches can get by with nothing more than software on the mobile devices their employees already bring to work. The key is to analyze a company's needs and present them with the best fit.
And that's a fact.
Andrew Prokop writes about all things unified communications on his popular blog, SIP Adventures.
Follow Andrew Prokop on Twitter and LinkedIn!
@ajprokop
Andrew Prokop on LinkedIn
