Technology, as an industry, has a pretty consistent history of creating better ways of doing things, but not completely thinking solutions through fully the first time. I’m not talking about natural product evolution. I’m talking about releasing products or solutions that claim to achieve a goal, but really only get 80% (best case, usually) there. In my opinion, the first iPhone was a great example. The design was great, but the functionality was not ideal.

When the first iPhone came out, I predicted (incorrectly) that it wouldn’t be successful. I stated that four things would hinder its adoption: the lack of a high-speed data connection to the mobile network (3G), the lack of a physical keyboard, the inability to send multimedia messages, and the inability for third party application developers to create native applications. (Remember, the first iPhone was only capable of using “web applications.” That meant that a constant connection to the Internet was required to use an application. For those of us who traveled, the prospect of doing that while flying was nil. (WiFi in the air wasn’t around.) Ouch.

In my defense, three of the four problems I noted were quickly rectified. (Even though Steve Jobs felt that all but one [faster network speed] were pointless.) The lone holdout was the virtual keyboard, which seems to be much less of an issue than I predicted. (And, in fact, has generated a new comedic life of its own by replacing typos with inappropriate words.) So, I wasn’t wrong about the reasons, but certainly wrong about the market acceptance. I had miscalculated Apple’s willingness to backtrack on their “firm” decisions made about two of the four issues (web applications, and multimedia sending/receiving).

This brings me to another innovative technology that hasn’t really endeared itself to the market it seeks, voice over Internet protocol (VoIP). For well over a hundred years, the basic technology behind telephone calls between two locations was relatively unchanged. You picked up a phone, a microphone picked up your voice, it converted the vibrations on a diaphragm inside the microphone to electronic pulses, and those traveled to a receiver on the other end, which essentially reversed the process. (A diaphragm vibrated to recreate a voice.) The intervening technologies to manage this changed pretty significantly over that time–going from copper lines along railroad tracks, then buried, and then to a local “point of presence (POP)” that ultimately terminated in the homes of millions. The signals themselves changed from the electronic pulses over those wires (amplified many times along the way–hello static), to digital representations (electronic circuits converted the voice to a digital format) going through the same copper wires, and then–ultimately–converted them to light pulses that could travel further, and without interference–goodbye static. (For those of you that looked at my simplistic representation of the evolution of voice telecommunications and said, “duh,” my apologies. I really am going somewhere with this.)

What remained throughout this history was a focus on reliability. (Not from the start, of course, but time quickly moved it in that direction.) I can remember some pretty bad storms when I was growing up in the Midwest. We would lose power to our home for hours. But we could always depend on the telephone. It always had dial tone. Well, maybe not always, but it was failing less than the electricity. In fact, there are many phrases that were spawned from the reliability of “Ma Bell’s” phone system. “As reliable as dial tone” and “Carrier grade” come to mind.

Why bother with this history of telecommunications, and disclaimer that technology has a history of migrating to usable products/solutions? It’s a good baseline that I’ll use to compare VoIP implementations. Unlike traditional voice communications, VoIP has not followed the close path of reliability. Even vendors that have been leaders in their industry for years (Avaya / Cisco) seem to have challenges when working with VoIP solutions. At one point in my career, we’d completed our first implementation of Cisco’s VoIP solution in a new office. It seemed like a right-sized solution. We selected a vendor (Cisco) that was known for reliability, network expertise, and had a good support organization. It seemed like a safe path. The only wildcard was the new technology (VoIP).

When we had phone issues in the past, they were pretty straight forward. It was either the phone, the wire, or the central switch. Fix any one of those three, and the problem was solved. Not so with VoIP. For example, there were numerous times that the conference room phones would stop working. They had all of the requisite lights, but the buttons failed to respond. So, essentially, they were dead. The fix? Unplug the phone and plug it back in. Done.

But, that wasn’t an actual fix, that was a way to get it work until it stopped working again. It’s anyone’s guess what the actual fix was, as the problems persisted until we replaced the phone system. This was in the space of 4 years. Not good.

This is where the path diverges from “old school voice solutions.” Instead of fixing one of the three points noted above (phone, wire, switch), we now had to look at firmware versions on the phone and phone system–and upgrade where appropriate. We also had to look at the network switches, routers, and configurations of all of these things. And, unlike prior voice communication solutions, it wasn’t simply a matter of narrowing it down. Sometimes, firmware (software) on one device didn’t work correctly with firmware on another device. Seriously. I mean, really, all people really wanted to do was press a button, get dial tone, dial, and talk. And, in the past, that would have been pretty straightforward. Again, not so much with VoIP.

This is really where I get to the point of VoIP not being for thin-skinned technologies. I have numerous examples of the complexities involved with a pretty straight forward VoIP implementation:

  • Network engineering issues. Remember Max Headroom? He was an 80s character that had speech that would become distorted (garbled) as he talked. (As did his own video representation.) If everything isn’t working correctly with VoIP, this is pretty common. I’ve been on a number of calls where words were clipped, there were chirps, and various other voice anomalies. What can cause this? Well, too much local network traffic, and the lack of a properly configured QoS environment. What’s QoS, you ask? Hold on, that’s next. The point here is that it is crucial that the data network to which a VoIP solution interacts must have a very, very well engineered plan to foster success. If it doesn’t you’ll get called email messages.
  • QoS configuration issues. QoS, also known as Quality of Service, is a way of prioritizing network communications within a data network. Think of it as a traffic cop of network traffic. For example, let’s say you have offices connected, and they all share one data network. (Very common.) If someone is sending a large file from one office to another, that has a very real capability of “clogging” the network. (Especially if the network is poorly engineered.) If, at the same time, someone is making a VoIP call between the same two offices, that data traffic is competing with the large file transfer. Ugly things happen. Garbled voice. Echoes. Delayed voice. Or, in the most extreme, the call just drops. The whole point of QoS in this scenario is to let the network know that any voice data (traffic) has priority over any other traffic. (If configured this way.) This is a simple explanation, but it is more or less relevant.
  • Device incompatibilities. With legacy phone systems, the phones were generally made by the same vendor as the switch to which they connected. This generally resulted in things that worked well. In VoIP implementations, this “rule” may not be in place. It’s entirely possible to buy a generic VoIP phone, and connect it to a name brand switch. But, although there are standards that both the switch and phone should follow, the interpretation of these standards can sometimes cause issues. Think Apple/Microsoft. One of Steve Jobs’ reasons for not licensing Apple’s current operating system (OS X) is that he had a strong belief that the harmony between the operating system and hardware was so closely aligned, introducing foreign hardware would cause issues. Microsoft’s Windows operating system helped validate this assertion. When Windows systems crash, it is usually because of an incompatibility between the hardware and the operating system. (Introduced through a driver, or, just bad hardware.) And before anyone asks, I am a “Mac guy.” And, yes, they are better than Windows machines.
  • Lousy software. Yes, that’s right. As VoIP has gained in popularity, the number of “home-brew” solutions has grown. Place a pretty wrapper on a rotten apple, there’s still a rotten apple inside. Good marketing doesn’t mean the product is good. As a child, I remember a lot of good marketing for Chrysler’s “K” cars. Do a web-search on that; you’ll see my point. Lee was a master of marketing.

These are just a few of the problems one can see with a VoIP implementation. And I do mean, just a few. Take each of these, and understand that it can be one, or all, of them causing problems, and the order of magnitude of the problems becomes clear. Yes? Okay, so, everything has problems. Sure. Though that’s a bit of an over simplification, the point is taken. Why, then, do I assert that VoIP isn’t for thin-skinned technologies? Simply, unless everything is perfect (Tell me how often that happens!), the technologists are going to get hate mail. Really. And I’m not talking about the garden variety of “Gosh, I wish you guys could get this fixed.” hate mail. I’m talking, “You guys are a bunch of monkeys, and you’re sinking my livelihood!!!” hate mail.

Remember in the beginning of this where I said that reliability was synonymous with voice communication? Well, that isn’t a given with VoIP. What that means is that one is battling with a perception that voice should always be available, be perfect, and never impede progress. If only. Here are some examples I’ve personally seen with some VoIP implementations gone awry (and angered many because their expectations didn’t match the implementation’s capabilities):

  • The CEO is on a conference call with the board of directors, talking about a potential acquisition. The meeting is heated. Suddenly, her voice starts to echo on the other end of the call. “Damn it…damn it…damn it…damn it! We…we…we…we…need…need…need…” Then, nothing. The call dropped. Cause? A poor QoS implementation, and the desire of someone in Marketing to transfer a video to a colleague in another office.
  • A phone-based sales team picks up the phone when it rings, but they cannot hear the person on the other end. Likewise, when they get voice mail messages, the messages cannot be understood—Max has paid a visit. When they call out, they get error tones. Concurrently, none of them are making their sales quotas. Who’s to blame? The voice problems, of course. They conclude that they would be making their quota if they didn’t have these problems. Cause? An incompatibility with the VoIP gateway and the telecommunication provider’s lines. (Signaling, more specifically.)
  • Someone in an office needs help, due to a health issue. A colleague picks up the phone and dials “911.” The first responders are summoned, and show up in about ten minutes…in a different city and state. Cause? An early version of the VoIP software isn’t location aware, and therefore uses the location of the primary VoIP switch—which is two thousand miles away from the medical emergency. (This had a good ending, by the way. But it wasn’t without drama.)
  • A CEO of a company talks to his IT leader and says, “I think it would be really great if our next phone system will allow us to actually talk with our customers.” Cause? The IT leader being in the wrong place, at the wrong time, with the CEO.

There are plenty of good implementations of VoIP, of course. This blog entry isn’t meant to say that VoIP is a bad thing. It is, like it or not, the way voice communications will be handled in the future. Even wireless carriers (AT&T, Verizon, Sprint, etc.) are going to implement a type of handset-enabled VoIP on their networks, which will replace the cellular calls as we know them today. (This technology is known as VoLTE, and will begin rolling out this year on some carriers.) But, unless someone is sticking with a traditional vendor whom has lived voice for the last 50+ years (like Avaya) there are risks that need to be taken into account. Even if a traditional vendor is utilized, there is still that pesky issue of network engineering, network compatibility with devices, etc.

So, if you’re planning on implementing a VoIP solution in a company that thinks voice communications are kind of important, be especially diligent on the front-end of the process, and make sure you have the right solution, people, and tools in place. Otherwise, your inbox may help you see the darker side of humanity.