Bottom line: if you cut over to an IP PBX, and the next day, the CEO tries to close a deal over a phone connection that sounds like a Sprint PCS cell phone at the bottom of a culvert in a remote rural area ... that's bad. And in this economy, who needs more bad?

So ... Everybody who considers buying an IP PBX worries about QoS. But a lot of their worry, it turns out, isn't necessary. The "Sprint phone in a culvert" scenario is rapidly moving out of the realm of the Murphy's-Law-Inevitable, and falling back into the more-remote realm of "things IT managers still wake up screaming about, years later." Just stay on the medication and you'll be fine.

In some cases, residual QoS anxiety is based on out-of-date information: for example, on personal experience with a VoIP product, during an embarassing trade-show demo in 1999. Today, however, PBX makers have this stuff cold. People like Nortel and Avaya and Cisco - falling stock prices or no - still have the revenue of nation-states and thousands of PhDs on staff. Once they embrace a technology, they don't play around; and they don't risk market share and customer goodwill (in some cases, generations of goodwill) by bringing crappy stuff to market (at least, okay - not as a general rule - grin). At present, both Nortel and Avaya (and a host of others) offer a range of IP-capable solutions (Cisco, of course, is "all VoIP, all the time"), and all (except Cisco) counsel conservative buying. IP, restrained to the single-use backplane network of a distributed, softswitch-based PBX like Avaya's MultiVantage, for example, is running over unencumbered copper or fiber, is overprovisioned to the max, and offers no problems to anyone. On the front end, driving legacy digital desksets on twisted pair - such a device is only an improvement (read: cheaper, faster, better, easier to manage) over a classic TDM design.

But if you want to add IP stations, or design an all-VoIP network, these products are ready to go - and their makers stand ready to help. All confirm that today, there are few LANs that can't be certified VoIP Ready, possibly with a few fairly simple software changes. WANs, because they're narrower links, are sometimes a more-vexing problem - but these too can (in most cases) be mastered without throwing off the ROI projections.

And they will not let you ponder this alone. All of the big PBX makers have ramped-up service organizations that send people in, after the close (they'll kill me for saying this, but they'll usually come in before the close, too, if you insist), evaluate your network to a fare-thee-well, make recommendations, help your folks make changes, certify the end result, and then keep watching - for a long time - until you're absolutely sure that a) you're comfortable with how the new PBX and the rest of your infrastructure and applications are working, and b) you're capable of making network changes and managing around new traffic patterns, all by yourself.

Other worries reflect general misunderstanding about what degrades QoS in a typical VoIP implementation. A lot of the writing about QoS has focused more on the nature and requisites of voice-packet-transport, per se, than on how these content-streams coexist with other data-patterns on the LAN. But here, there's help available too. In our own pages, Chris Bajorek (aka "Dr. C") recently completed a long series of articles, examining QoS issues from every angle: covering "operational QoS" (i.e., problems arising from packet loss, jitter, delay, etc., that may not be perceptible as reduced call quality, but may affect the functioning of VoIP infrastructure in other ways, e.g., dropped calls), "perceptual QoS" (i.e., call quality as perceived by human beings, and by automated test equipment and software designed to infer - from network data - what a human being would say about call quality, e.g., MOS, PESQ, etc.), and even what might be called "acute, non-specific QoS" - QoS problems that, while perceptible, tend to be mis-diagnosed by laypeople, and even by engineers. This last category of problem is especially annoying - causing increased hysterical finger-pointing, defensiveness on the part of vendors, and slowing the process of analysis and resolution. An example, here: VoIP calls can sound "echo-y" for lots of reasons - but weirdly, in some cases, it's not because real echo is being introduced into the system (this is a blind alley), but rather because the echo-cancellers are having to retrain frequently because of packet-loss, and go offline while doing so.

[Editor's Note: A complete index to Chris Bajorek's Dr. C columns is available both on www.cConvergence.com/article/CTM20030204S0002 and on Chris's own website, www.ct-labs.com.]

Today, the big reason for anxiety (or so it seems to us, after speaking with many IP PBX makers) is that IP PBX buyers tend to conflate two separate domains of concern in a VoIP implementation, and end up confusing themselves about what's really important. The one, dead-certain thing everybody asked me to remind you is that the LAN and the WAN represent different problems, and require different audit, implementation, and if necessary, amelioration strategies. On most networks, the issues just aren't the same: on the LAN, things are pretty good - most LANs are bandwidth-overprovisioned, so if you can sequester VoIP traffic and limit broadcast contention, you're a happy camper. On the WAN, all those complicated delay, jitter, and other issues come to the fore: usually, a solution can be found by tweaking, bandwidth dedication, or - if all else fails to achieve a good MOS score - by installing traffic-shaping gear and implementing policy on it. The product most mentioned here is Packeteer's (www.packeteer.com) Packet Shaper.

So - the news is generally good. Especially so, we feel (having looked at the stats and "happy end-user" quotes), among early adopters (though, ironically, this may be, to some extent, because the kind of businesses who early consider massive VoIP deployments also tend to be the kind who have their network ducks in a row). At this juncture, I suppose it's bad-natured of me to mention that Cisco itself, the week of 1/14/03, sent out a press release with a picture of John Chambers turning off the last digital PBX on their campus. So don't feel bad if you're not an all-VoIP company, yet.

Now, however, it's time to consider becoming one. If you're interested, you probably know this already: the big change VoIP brings isn't technical, but process-related. Where VoIP is mission-critical, IT needs to be alert to conditions in a way that hasn't been necessary (in some cases) before. They need to be equipped to analyze problems and intervene proactively (where have I heard that, before?). They need to have meaningful answers for end-users. All of which means that, for the first few months, you're going to have to think about process, train, create a playbook, look at logfiles on a more-regular basis, and possibly become friendly with more sophisticated network monitoring systems than you're currently using. Some of these are described below.

Bottom line: if you cut over to an IP PBX, and the next day, the CEO tries to close a deal over a phone connection that sounds like a Sprint PCS cell phone at the bottom of a culvert in a remote rural area ... that's bad. And in this economy, who needs more bad?

So ... Everybody who considers buying an IP PBX worries about QoS. But a lot of their worry, it turns out, isn't necessary. The "Sprint phone in a culvert" scenario is rapidly moving out of the realm of the Murphy's-Law-Inevitable, and falling back into the more-remote realm of "things IT managers still wake up screaming about, years later." Just stay on the medication and you'll be fine.

In some cases, residual QoS anxiety is based on out-of-date information: for example, on personal experience with a VoIP product, during an embarassing trade-show demo in 1999. Today, however, PBX makers have this stuff cold. People like Nortel and Avaya and Cisco - falling stock prices or no - still have the revenue of nation-states and thousands of PhDs on staff. Once they embrace a technology, they don't play around; and they don't risk market share and customer goodwill (in some cases, generations of goodwill) by bringing crappy stuff to market (at least, okay - not as a general rule - grin). At present, both Nortel and Avaya (and a host of others) offer a range of IP-capable solutions (Cisco, of course, is "all VoIP, all the time"), and all (except Cisco) counsel conservative buying. IP, restrained to the single-use backplane network of a distributed, softswitch-based PBX like Avaya's MultiVantage, for example, is running over unencumbered copper or fiber, is overprovisioned to the max, and offers no problems to anyone. On the front end, driving legacy digital desksets on twisted pair - such a device is only an improvement (read: cheaper, faster, better, easier to manage) over a classic TDM design.

But if you want to add IP stations, or design an all-VoIP network, these products are ready to go - and their makers stand ready to help. All confirm that today, there are few LANs that can't be certified VoIP Ready, possibly with a few fairly simple software changes. WANs, because they're narrower links, are sometimes a more-vexing problem - but these too can (in most cases) be mastered without throwing off the ROI projections.

And they will not let you ponder this alone. All of the big PBX makers have ramped-up service organizations that send people in, after the close (they'll kill me for saying this, but they'll usually come in before the close, too, if you insist), evaluate your network to a fare-thee-well, make recommendations, help your folks make changes, certify the end result, and then keep watching - for a long time - until you're absolutely sure that a) you're comfortable with how the new PBX and the rest of your infrastructure and applications are working, and b) you're capable of making network changes and managing around new traffic patterns, all by yourself.

Other worries reflect general misunderstanding about what degrades QoS in a typical VoIP implementation. A lot of the writing about QoS has focused more on the nature and requisites of voice-packet-transport, per se, than on how these content-streams coexist with other data-patterns on the LAN. But here, there's help available too. In our own pages, Chris Bajorek (aka "Dr. C") recently completed a long series of articles, examining QoS issues from every angle: covering "operational QoS" (i.e., problems arising from packet loss, jitter, delay, etc., that may not be perceptible as reduced call quality, but may affect the functioning of VoIP infrastructure in other ways, e.g., dropped calls), "perceptual QoS" (i.e., call quality as perceived by human beings, and by automated test equipment and software designed to infer - from network data - what a human being would say about call quality, e.g., MOS, PESQ, etc.), and even what might be called "acute, non-specific QoS" - QoS problems that, while perceptible, tend to be mis-diagnosed by laypeople, and even by engineers. This last category of problem is especially annoying - causing increased hysterical finger-pointing, defensiveness on the part of vendors, and slowing the process of analysis and resolution. An example, here: VoIP calls can sound "echo-y" for lots of reasons - but weirdly, in some cases, it's not because real echo is being introduced into the system (this is a blind alley), but rather because the echo-cancellers are having to retrain frequently because of packet-loss, and go offline while doing so.

Editor's Note: A complete index to Chris Bajorek's Dr. C columns is available both on www.cConvergence.com/article/CTM20030204S0002 and on Chris's own website, www.ct-labs.com.

Today, the big reason for anxiety (or so it seems to us, after speaking with many IP PBX makers) is that IP PBX buyers tend to conflate two separate domains of concern in a VoIP implementation, and end up confusing themselves about what's really important. The one, dead-certain thing everybody asked me to remind you is that the LAN and the WAN represent different problems, and require different audit, implementation, and if necessary, amelioration strategies. On most networks, the issues just aren't the same: on the LAN, things are pretty good - most LANs are bandwidth-overprovisioned, so if you can sequester VoIP traffic and limit broadcast contention, you're a happy camper. On the WAN, all those complicated delay, jitter, and other issues come to the fore: usually, a solution can be found by tweaking, bandwidth dedication, or - if all else fails to achieve a good MOS score - by installing traffic-shaping gear and implementing policy on it. The product most mentioned here is Packeteer's (www.packeteer.com) Packet Shaper.

So - the news is generally good. Especially so, we feel (having looked at the stats and "happy end-user" quotes), among early adopters (though, ironically, this may be, to some extent, because the kind of businesses who early consider massive VoIP deployments also tend to be the kind who have their network ducks in a row). At this juncture, I suppose it's bad-natured of me to mention that Cisco itself, the week of 1/14/03, sent out a press release with a picture of John Chambers turning off the last digital PBX on their campus. So don't feel bad if you're not an all-VoIP company, yet.

Now, however, it's time to consider becoming one. If you're interested, you probably know this already: the big change VoIP brings isn't technical, but process-related. Where VoIP is mission-critical, IT needs to be alert to conditions in a way that hasn't been necessary (in some cases) before. They need to be equipped to analyze problems and intervene proactively (where have I heard that, before?). They need to have meaningful answers for end-users. All of which means that, for the first few months, you're going to have to think about process, train, create a playbook, look at logfiles on a more-regular basis, and possibly become friendly with more sophisticated network monitoring systems than you're currently using. Some of these are described below.