There will always be unknowns – the serpents in paradise – but through careful planning you can minimize their impact.
There is a serpent in every paradise.
Have truer words ever been spoken? Show me a seemingly perfect situation and I will show you its flaws.
No, I am not a pessimistic person. Rather, I am a practical optimist. I embrace the joys of life while keeping one eye open for the tough stuff. However, since this is a blog about communications, I will stick to the technical aspects of my outlook. Someone else can tackle the sociological facets.
Blind optimism can be the downfall of any project. If you start out expecting perfection, you will quickly be disappointed. Even worse, being unprepared for complications will lead to unexpected downtime, user dissatisfaction, lost money, lost time, and even lost jobs.
There are a number of gotchas when it comes to rolling out unified communications, and over the course of this post, I would like to address a few of the high runners. Be aware that I won't catch them all and you will need to practice your own due diligence. In the words of Donald Rumsfeld:
There are known knowns. These are things we know that we know. There are known unknowns. That is to say, there are things that we know we don't know. But there are also unknown unknowns. There are things we don't know we don't know.
Or in the even more convoluted words of Andrew Prokop, "We don't know what we don't know and we don't know that we don't know it."
Piece Parts
Let's start with the fact that most enterprise systems are a collection of many smaller systems. These might be physically and/or logically different from one another.
The most common physical difference is separate communications systems. In a single enterprise, you might have one vendor's system at the core and any number of different vendors' products out at the remote locations. This typically wasn't intentional, but came about when different business units made their own IT directions. It can also happen through the acquisition of other companies and inheriting their communications decisions. The result is that there is little consistency throughout an organization.
Logical differences occur even when you've chosen a single vendor's system at the core and the branches. Here you have to look at factors such as network connectivity, vintages, and communications adjuncts. You might have a large data pipe to your core, but a branch office may only realize 512kbps of bandwidth. Issues also arise when an organization has the latest and greatest hardware and software for some users while others carry on with relics from the past.
In the end, it doesn't matter if you are looking at physical or logical differences. You need to divide your enterprise into separate chunks that allow the distinct requirements of one chunk to interface with the distinct requirements of another chunk.
Different vendors tackle this in their own unique ways, but you can safely put those techniques into the bucket that I will call network regions. A network region is a logical group of IP elements that share common characteristics and resources. These include:
• Bandwidth
• Location
• Codec sets
• IP Address ranges
By placing users into well-planned network regions you can manage how a user in one region communicates with a user in a different region. For example, network capacity might allow high bandwidth codecs such as G.722 to be used intra-region, but restrict inter-region communications to the lower bandwidth G.729. Network regions can also direct 9-1-1 calls out a set of trunks local to that region.
The point is that by assigning different sets of capabilities throughout the enterprise, you can avoid bottlenecks, mismatches, inefficient use of scarce resources, and in the case of 9-1-1, avoidable deaths. In other words, comprehensive network regions help an enterprise create well-defined (i.e. known) call paths.
We Just Can't Seem to Rid Ourselves of the Old Technologies
No matter how far we advance in the arena of IP communications, we continue to rely on technologies invented over 100 years ago. Do you think I am exaggerating? Just pick up a phone. Do you hear that sound? It's called dial tone and was introduced to the world in 1908. Would you also believe that fax can trace its roots back to 1846? Heck, that's even older than I am.
The point here is that you need to account for these older technologies that seemingly won't go away. For instance, if you were to base your entire organization on the G.729 codec you would quickly find that faxes can no longer be sent or received. That's because G.729 is in a class of codecs called vocoders (short for voice encoder), and vocoders only process human speech. I don't know about you, but the whistles and screeches of a fax signal don't sound like anyone I know.
Don't worry, though. There are ways to solve these problems. In the case of fax, you can try fax pass-through using G.711 or opt for the more reliable T.38. Just don't let the question of "Will fax work?" turn into "Holy moly, fax no longer works."
The same can be said for other ancient technologies. You may need to consider installing gateways or provisioning different protocols for these antiques (possibly using network regions). Most importantly, you need to think before you take your first step. This is not the time for guesswork.
Learn to Adapt
The last unknown I want to discuss today are the liberties that people have taken with the so-called standards. Specifically, I want to spend a little time on variations in Session Initiation Protocol (SIP).
SIP is owned and maintained by the International Engineering Taskforce (IETF). The IETF is the organization that brings us Internet technologies such as DNS and HTTP. In other words, they are well established as a standards body and produce quality documents with input from all the major players in the industry.
Still, even though Avaya and Cisco are active members of the IETF, the way that one of them implements SIP may not be the way that the other implements SIP. There can even be differences when it comes to SIP carriers. Each one has the potential to be ever so slightly different from the next.
This is where Adaptation comes in. Adaptation allows you to sit in the middle of a SIP transaction and make it look one way for the sender and another way for the recipient. Through adaptation, Avaya can talk to Cisco and Cisco can talk to Avaya, and neither one is aware that someone is messing with their SIP messages.
There are a number of places where adaptation can live, but for the most part, it becomes the responsibility of a session border controller (SBC) or a session management server. It may even take place in both devices as long as neither one steps on the toes of the other. The goal is that they do their jobs unobtrusively, adding little to no delay to call flows.
Mischief Managed
The main takeaway is that there will always be unknowns – the serpents in paradise – but through careful planning you can minimize their impact. Think before you commit, buy, or rollout that IP phone. You may not catch every problem before it rises up to bite you, but by having the right solutions in place, much of the pain can be easily soothed.
There will always be the unknown unknowns, and knowing that they exist may prevent the serpents from taking over your unified communications paradise.
