VoIP signals the final victory of packets over circuits, of statistical multiplexing over time-division multiplexing in the WAN.

But even though VoIP products now line store shelves, the technology has a long way to go before it will blanket the enterprise (see "VoIP in the Enterprise" at www.networkcomputing.com/918/918f1.html). In the short term, it's a safe bet for wide-area links, but proceed with caution if you're thinking about adoption at the campus level. Actual deployment in a network requires tight control, along with healthy provisioning, of every link and intermediate node. Moreover, it will be some time before the average PC replaces the telephone.

We've examined standards-based VoIP implementations to show you how you can improve conditions for successful deployment in the enterprise. We'll also describe what you should look for when examining products--and how you can roll them out with minimum pain.

Are We There Yet? H.323 is the standard of choice for VoIP. Actually a collection of related standards (see "The H.323 Family," at right), H.323 was first accepted by the ITU-T in 1996. Given the range of products that already claim some compliance with the standard, it has a substantial lead on competing approaches. Although the IETF is still debating a couple of alternative standards, the market is far ahead with H.323. And the 1998 adoption of H.323 version 2 should produce products worthy of serious consideration, though most are not yet fully version 2-compliant, and nearly all implementations are missing optional but critical components.

Security (H.235) is specified as an optional component in H.323 version 2. Authentication, encryption, integrity and nonrepudiation are all available, though products need not offer any security to be considered compliant. But deploying VoIP without security is a major step backward for most organizations because it's remarkably easy to eavesdrop on conversations wherever packets pass. A protocol analyzer such as RADCom's AudioPro-PrismLite combination can automatically detect VoIP traffic streams and even play them back as audio files.

The H.450 series of standards provides advanced call-management services including transfer and forwarding (busy, no reply, unconditional and deflection), and a mechanism for other services. Without these, the standard functions found in any PBX can't be supported between vendors.

Another critical--but optional--component of H.323 installations is the gatekeeper function. A gatekeeper controls access to the network for H.323 endpoints. It provides essential protection for the network, preventing it from being overloaded with voice (and video) calls. The gatekeeper also provides address translation, bandwidth management services, call management and signaling, and overall system control. Despite its optional status, a gatekeeper is a must for real system management. In its absence, all calls are peer-to-peer; instead of receiving a "busy" signal, endpoints just submit packets to the network and hope for the best. In the process, audio packets can flood network devices.

Gatekeeper functions often are built into gateways, virtual PBXes and multipoint control units (devices that can create audio- and videoconferences), or even H.323 endpoints. H.323's Registration/Admissions/Status (RAS) protocol provides methods for endpoints to discover and register with the gatekeeper. Under H.323 version 2, network endpoints must use the gatekeeper if it is present. Despite this, most endpoint products don't operate properly with gatekeepers, even though they may claim compliance with version 2.

Because H.323 is a multilayered standard that is both complex and ambiguous, vendors have chosen to conduct interoperability tests via the International Multimedia Teleconferencing Consortium (www.imtc.org). Unfortunately, the IMTC does not publish the results of its interoperability sessions, but many vendors have publicly announced some level of collaboration.