VoIP networks continue to be deployed at a rapid pace, and VoIP vendors and service providers continue to add new functionality. Because vendor support for each protocol differs and companies have varying business requirements, it is very likely that VoIP networks will continue to be made up of multiple protocols.

Having various protocols gives customers the flexibility that they need to connect services from multiple carriers. Using standards, even multiple standards, still simplifies deployment of multivendor endpoints and increases options for network management and provisioning.

As companies expand their networks, they are faced with choices about how to interconnect segments using differing VoIP protocols. These choices often fall into one of three categories:

• Translation through Time Division Multiplexing (TDM): In this model, a company uses either TDM equipment or VoIP gateways to translate from one protocol domain to another. The benefits of this model are that it can be used today. The downside is that it introduces latency into the VoIP network and involves yet another protocol translation (VoIP no. 1 <—> TDM <—> VoIP no. 2). This model is usually considered as a short-term solution until IP–based protocol translators are available.

• Single Protocol Architecture: In this model, a company moves all its VoIP devices and services to a single protocol, simplifying the network as a whole. The downside to this approach is that it might not be possible to migrate existing equipment to support the new protocol, a situation that can limit the company's ability to take advantage of some existing services. In addition, it limits the potential connectivity to other networks that are using other VoIP signaling protocols.

• Protocol Translation: In this model, a company uses IP–based protocol translators to interconnect two or more VoIP protocol domains. IP translators allow a company to retain the flexibility of using multiple VoIP protocols, do not introduce the delay problems that additional TDM interconnections do, and do not require a wholesale replacement or swap of existing equipment.

The downside to this approach is that there is no standard for protocol translation, so not all VoIP protocol translators are exactly the same. Although the IETF has attempted to define a model for translating H.323 to SIP, it involves more than just building a protocol-translation box.

As shown in Table 1, although protocols are somewhat similar, they do have some differences. Vendors of protocol translators need in-depth knowledge of all the protocols being used in the VoIP network, and they must be aware of how various VoIP components utilize different aspects of the protocol.

For example, H.323 and SIP can send dual-tone multifrequency (DTMF) digits in either the signaling path or the media path (via RTP). But H.323 mandates only that the H.245 signaling path be used, and SIP does not specify how DTMF should be carried. This means that SIP devices could be sending DTMF in the media path (RFC 2833), and H.323 devices could be sending DTMF in the signaling path (H.245). If the VoIP protocol translator cannot properly recognize both the signaling path and the media path, then it might not function properly.

	H.323	SIP	MGCP/H.248/MEGACO
Standards Body	ITU	IETF	MGCP/MEGACO—IETF;H.248—ITU
Architecture	Distributed	Distributed	Centralized
Current Version	H.323v4	RFC2543-bis07	MGCP 1.0, Megaco, H.248
Call control	Gatekeeper	Proxy/Redirect Server	Call agent/media gateway controller
Endpoints	Gateway, terminal	User agent	Media gateway
Signaling Transport	Transmission Control Protocol (TCP) or User Datagram Protocol (UDP)	TCP or UDP	MGCP—UDP;Megaco/H.248—both
Multimedia capable	Yes	Yes	Yes
DTMF–relay transport	H.245 (signaling) or RFC 2833 (media)	RFC 2833 (media) or INFO (signaling)	Signaling or RFC 2833 (media)
Fax–relay transport	T.38	T.38	T.38
Supplemental services	Provided by endpoints or call control	Provided by endpoints or call control	Provided by call agent

Table 1. Details of VoIP Products