Who Sets the Standards for VoIP?
Successful technology relies on standards—but the world contains dozens of standards organizations. Which ones most influence the development of packet-based telephony? What backgrounds and influences do they bring to their work?

Why TCP/IP Is not Sufficient for VoIP
With traditional telephone systems, once a 'path through the network' has been established to make a connection, it remains stable and predictable for the duration of the call. Not so for the Internet. So, what makes an 'unreliable' TCP/IP network able to carry voice traffic?

Understanding H.323—Part I: History and Architecture
Designed by the ITU-T to facilitate voice and other multimedia communications over packet-based networks, H.323 defines a system that encompasses several quite different types of components—and requires a host of additional protocols to make everything work.

Understanding H.323—Part II: Protocols Supporting Terminals
The key ITU-T protocol supporting voice over IP is H.323. A look at its terminal functionality (only one of four major areas) reveals no fewer than seven standards-based protocol components that work under this 'umbrella' protocol.

Understanding H.323—Part III: Signaling
The communications—such as on/off-hook, dialtone, and busy signal—that set up and terminate calls on the PSTN are replaced by a complex set of protocols and procedures in the packet-based H.323 world.

Understanding H.323—Part IV: Testing System Interoperability
The quirky evolution path taken by H.323 and related standards makes for some serious implementation challenges. Fortunately, there are tools to help.

Understanding SIP—Part I: History and Architecture
Reflecting the IETF's pragmatic development mind-set, and built on other well-known protocols such as HTTP and SMTP, SIP is viewed by many as fundamentally simpler than H.323.

Understanding SIP—Part II: Protocol Capabilities
As a robust client/server application modeled on familiar IETF protocols, such as SMTP and HTTP, SIP would seem to have a simple, clearly defined role in a suite of IP tools. However, a number of variables add complexity to SIP's operation.

Understanding SIP—Part III: Message Formats
Like HTTP, SIP operation is based on a request/response model. Like SMTP, each SIP message is headed by an email-address-like identifier. A series of methods and Status Codes specify purposes and procedures.

Understanding SIP—Part IV: Describing the SIP Session
In setting up a voice or video session, SIP transmits a detailed 'description' of the session using—you guessed it—a bevy of subsidiary protocols, such as SAP and SDP. Read all about it.

Understanding SIP—Part V: SIP Signaling
Signaling—setting up a call connection and the parameters around that connection—is much more straightforward with SIP than with the H.323 protocol family.

Understanding SIP—Part VI: Testing SIP Interoperability
Despite its status as a standard, some compatability problems exist for SIP. Fortunately for IT managers, a number of resources exist for testing a resolving these issues.

Do You Hear What I Hear?—Part I: Defining Quality of Service
Governmental regulation of a granted monopoly—the PSTN—made for an extremely reliable telephone network. Can VoIP deliver the same?

Do You Hear What I Hear?—Part II: Defining Key Transmission Impairments
Due to its connectionless architecture, an IP network creates its own built-in obstacles to the smooth transmission of sequential data such as voice and video.

Do You Hear What I Hear?—Part III: Dealing with Latency
Latency and echo are inevitable in VoIP, but they can be compensated for. Engineering constructs such as the 'delay budget' help keep these problems under control.

Do You Hear What I Hear?—Part IV: Measuring “Toll Quality”
Vendors of VoIP systems often refer to "toll quality" as a lofty performance standard to which their products adhere. Is this a term with precise meaning? Yes and no.

Do You Hear What I Hear?—Part V: Integrated Services
This mother of all QoS solutions tracks flows, schedules packets, and generally manages network resources to ensure adequate bandwidth for the services running at any given time.

Do You Hear What I Hear?—Part VI: Resource Reservation Protocol
The Resource Reservation Protocol—RSVP for short—is akin to the police traffic-directing detail that keeps a motorcade route open and trouble free.

Do You Hear What I Hear?—Part VII: Differentiated Services
The Differentiated Services architecture is a built-in feature of the Internet protocol that allows the coding of traffic streams for special treatment.

Do You Hear What I Hear?—Part VIII: Multiprotocol Label Switching
By encapsulating routing information for an entire group of packets, MPLS cuts down on the processing a router must do to get a packet flow to the right destination.

Do You Hear What I Hear?—Part IX: Queuing Solutions for QoS
Data packets will have to line up for processing at various points as they move from source to destination. Schema for assigning priority to different classes of traffic help manage data flows.

Putting it all Together—Part I: VoIP Network Design
The design of an adequately provisioned voice/data network begins with careful usage measurement. Fortunately, there are tools to help.

Putting it all Together—Part II: Implementation Tips
In preparing to actually implement a VoIP solution, you need to clearly understand your goals and marshal all the necessary resources.

Putting it all Together—Part III: Implementation Tips, continued
Some careful analysis of cost-related issues will help keep VoIP implementation free from unpleasant financial surprises.

Putting it all Together—Part IV: Implementation Tips, concluded
Coming down the home stretch of VoIP deployment, a check-list of seemingly minor issues can make the difference between success and . . . headaches.

Voice Codecs: the tale of the Secret Decoder Ring
Codecs—which convert your voice's analog vibrations to digital signals—balance sound quality with bandwidth usage. Be sure to pick the right one(s).

Softswitches—Part I: Getting there from here
The softswitch--in essence, a complex piece of software running on a computer--replaces generations of electro-mechanical equipment. It also brings its own idiosyncracies.

Softswitches—Part II: Functional planes of the softswitch architecture
To aid in standardizing the design of software switching equipment, the International Packet Communications Consortium has devised a schema that describes the entire complex functionality.

Softswitches—Part III: The Media Gateway Controller
Core of the Call Control and Signaling plane, the MGC is responsible for setting up and dismantling the end-to-end network connections necessary to support phone calls.