Packetizer Logo

H.323 Version 4 - Overview

Many new enhancements have been introduced into the market-leading VoIP protocol H.323. Version 4 will be approved November 17, 2000 and contains enhancements in a number of important areas, including reliability, scalability, and flexibility. New features will help facilitate more scalable Gateway and MCU solutions to meet the growing market requirements. H.323 has been the undisputed leader in voice, video, and data conferencing on packet networks, and Version 4 makes strides to keep H.323 ahead of the competition.

Gateway Decomposition

Recognizing the need to build larger, more scalable gateway solutions for carrier solutions, the ITU-T SG16 worked jointly with the IETF to produce the new Recommendation H.248, which describes the protocol between the Media Gateway Controller (MGC) and the Media Gateway (MG). To support this "decomposition" of the Gateway, H.323 contains a new section that describes some of the various architectural designs that may be achieved by decomposing the Gateway into the separate MGC and MG.

In addition, text exists to explain how the other protocols utilized within the H.323 system may be utilized in order to produce a complete system. Considering the various needs of enterprises, service providers, and equipment suppliers, H.323 discusses Access and Trunking Gateways as used in both the services provider and enterprise markets and suggests possible ways of dealing with FAS and CAS signaling.

Multiplexed Stream Transmission

One weakness with the current usage of RTP is difficulty in synchronizing the separate audio and video streams. Version 4 now includes an optional procedure which allows both video and audio to be multiplexed in a single stream. This will assist endpoints in syncronizing video and audio so that presentation to the user looks more natural.

Supplementary Services

One of the most important features of a VoIP protocol is its ability to provide services to the service provider and end users. H.323 has a rich set of mechanisms to provide supplementary services. Version 4 introduces a few more which strengthen the protocol in this regard. In addition to the new Annexes K and L and the new H.450.x documents (described below), there is a new section in the main body that attempts to "tie it all together" so that the reader can better understand when and where to apply specific service models.

Annex K/H.323

The new Annex K describes a means of providing HTTP-based control for H.323 devices. With this Annex, service providers have the ability to display web pages to the user with meaningful content that ties into the H.323 systems. In essence, it is a third party call control mechanism that utilizes a separate HTTP connection for control. This should not be confused with the simple ability to redirect a user to a web page-- something that H.323 has been able to do since Version 2. Rather, this is a new "service creation" environment, which is unlike anything described to date. In addition, because the procedures for HTTP-based do not need standardization, new features may be introduced without the delay introduced by any formal standardization process.

Annex L/H.323

Annex L provides a new "stimulus-based" control mechanism for H.323. With Annex L, an H.323 device may communicate with a feature server to provide the user with various services. The H.323 endpoint may possess some intelligence, but some intelligence may reside only in the feature server or multiple feature servers. Annex L builds on the strengths of the "package" concept introduced in H.248, so the feature possibilities are numerous. More importantly, because anyone may define and publish package specifications, new features may be introduced without the delay introduced by any formal standardization process.

H.450.8 - Name Identification Service

H.450.8 builds upon H.323 "caller identification" procedures by providing a standard means of conveying user identification data to the remote endpoint.

H.450.9 - Call Completion

This new supplementary service definition provides a standard means of allowing calls to complete when the user is either busy or there is no answer.

H.450.10 - Call Offer

This service allows a calling endpoint to offer a call to a busy called endpoint, so that the call will complete once the busy user accepts the call.

H.450.11 - Call Intrusion

This service allows a calling endpoint to interrupt an existing call between two endpoints.

Additive Registrations

One weakness that previous versions of H.323 had was the inability of a large device, such a Gateway or MCU, which possessed hundreds or thousands of alias addresses, to register those addresses with the Gatekeeper. The problem was quite simple: the size limitation of a UDP packet just prevented that from happening. Version 4 gets around this problem with a new concept called "Additive Registrations". In essence, an endpoint may register with a Gatekeeper and provide an initial list of aliases, but then may follow the RRQ with additional RRQs in order to provide the Gatekeeper with a complete list of alias addresses.

Alternate Gatekeepers

One of the most important aspects of any telephony system is "uptime". Customers do not want to be without phone service and service providers do not want a loss in revenue. Gatekeeper failure often results in missed calls, lost revenue, or both. Fields were introduced into H.323v2 to provide for Gatekeeper redundancy, but the usage of those fields was never fully explained. Version 4 introduces a new section that details the procedure that endpoints may follow in order to provide some robustness to the system.

In addition to procedural text, a new field was added to allow an endpoint to indicate whether it supports the Alternate Gatekeeper procedures. This allows the Gatekeeper to make intelligent decisions about redirecting an endpoint to provide for some level of load balancing across Gatekeepers.

Usage Information Reporting

To help provide accurate billing information, the Gatekeeper may request the endpoint to provide usage information reporting to the Gatekeeper at various times during the call, including at beginning of the call, during the call, and at the end of the call. This new capability works well with Annex G/H.225.0, where usage information reporting may be necessary and when call signaling is not routed through the Gatekeeper. This feature may also be used by alternate Gatekeepers, which handle the call termination for a call that did not originate with that Gatekeeper. Usage information reporting includes the start and end times, the call termination cause, and any non-standard data the endpoint wishes to provide.

Endpoint Capacity

One very frustrating aspect of many IP telephony services is that calls are often directed to Gateways or other devices that do not have available capacity to handle new calls. H.323 has had an indicator to indicate that a Gateway is "almost out of resources", but this cannot be used by other devices, such as high-capacity conference servers. In addition, indicating that capacity is low says nothing about the true state of the device. For example, are resources low because one of the two ports on a low capacity Gateway is in use or that only 20 ports on a 10,000 port Gateway are available?

With Version 4, the endpoints have the ability to provide precise information about resource availability to the Gatekeeper in a number of messages. The Gatekeeper can use this information to intelligently route traffic to a device it knows can handle the call. This increases the call success rate, and, in turn, increases revenue to the service provider.

Caller Identification Service

New fields were added to H.323 Version 3 to provide the means of providing caller identification, but no description existed for the proper usage of those fields. Version 4 now contains complete text to explain how to provide caller identification services with H.323.

Tones and Announcements

Version 4 details the procedure for indicating the presence of in-band tones and announcements. Such tones and announcements are often heard when the destination number is incorrect or unreachable.

In addition to in-band tones and announcements, the Gatekeeper may signal an endpoint to play specific announcements at various times: pre-call, mid-call, or end-call. This mechanism facilitates two-stage dialing, for example, where the Gatekeeper may request the Gateway to prompt the user for additional information. In that case, the Gateway will play an additional prompt to collect a PIN, for example, and then attempt once again to place the call.

Mapping Aliases

When routing calls, a telephone number in the IP-world may not be sufficient for proper routing into the SCN. In addition, it might be that a service provider would like to use the same Gateways to provide Virtual Voice Private Networks, but need some intelligence in a device to perform proper mapping. With Version 4, a Gateway, for example, can indicate that it can perform alias mapping at either the ingress or egress side of a call. This will reduce the number of malformed numbers, as well as provide a means for providing VVPN services.

Indicating Desired Protocols

When placing a call prior to Version 4, the Gatekeeper had no way of knowing whether or not the calling party needed special services, such as fax support in a Gateway. With Version 4, however, an endpoint may request in the ARQ that the Gatekeeper resolve the address so that the "desired" protocols are met by the destination endpoint. This will allow a caller, for example, to indicate that it wants to place a fax call and that only Gateways that support fax should be returned-- there is no point placing a fax call to a voice-only gateway, after all!

Bandwidth Management

Prior to H.323 Version 4, and endpoint could request much more bandwidth than it actually needed and, thus, cause network resources to go unutilized. With Version 4, it is now mandatory that an endpoint make bandwidth requests with a lower value if, indeed, the endpoint is using less bandwidth than it had initially indicated in the ARQ.

In addition, managing bandwidth for multicast sessions has been nearly impossible since, unless the Gatekeeper routed the H.245 signalling and carefully monitored the media channels that were opened, it could not determine whether two endpoints that request bandwidth are actually requesting bandwidth for a multicast session or unicast session. This becomes a much bigger issue when many people are participating in a multipoint multicast conference. With Version 4, specific details about the media channels are conveyed to the Gatekeeper in IRR messages (if the Gatekeeper requests them), so that the Gatekeeper can better control bandwidth utilization.

Reporting Call Status

Like the issue with large registrations, large endpoints, such as MCUs and Gateways, have trouble reporting call details to a Gatekeeper due to limitations in the size of a UDP packet. For this reason, Version 4 now provides a mechanism through which an IRR containing information for multiple calls may be broken into several distinct messages. This allows the endpoint to convey all of the call details to the Gatekeeper.

Enhancements to Annex D (Real-Time Fax)

A very useful feature of fax devices is the ability to initiate a voice call and then switch to fax at some point. Version 4 of H.323 extends Annex D to allow an endpoint to do just that. Along with the obvious benefit of allowing an IP-based fax device to operate in a similar manner as today's PSTN fax devices, the media switch is performed in such a way that DSP resources is conserved, which reduces the overall cost of equipment.

Annex D was also enhanced to utilize TCP for carrying fax data. Previously, UDP was the only real option for carrying fax data.

Call Linkage

H.323 Version 2 introduced the concept of the Call Identifier, which is a unique identifier that can be used to identify a call with multiple segments from end to end. However, there is also a need to associate that call to the original party when a call transfer or other service is invoked, in which the original participants are no longer present in the call. Version 4 introduces several new fields that allows equipment to "link" call legs together for this purpose. This provides for, among other things, more accurate billing for a call.


People understand that when signals are translated from one system to another and then back to the original signaling, certain information is lost. In H.323 systems used in both public and private networks, H.323 is often used to interwork between two circuit networks. To provide better interworking, Version 4 now provides a mechanism whereby QSIG and ISUP may be tunneled without translation—essentially, H.323 may act as a transparent tunnel for those non-H.323 signaling protocols.


Quality of Service is very important in any VoIP network. As a first step in improving QoS in H.323 systems, new procedures are defined in H.323 to allow for RSVP when not using Fast Connect. Obviously, work is continuing in this area in both the |LING||ITU| and the IETF.

H.245 in Parallel with Fast Connect

H.323 now allows H.245 to be started in parallel to Fast Connect by including H.245 messages in the Setup message. This allows an endpoint to exchange capabilities in order to determine whether certain features are supported, such as DTMF support in the UserInputIndication message. In addition, by starting H.245 early, two endpoints can more quickly establish an H.245 session in the event that Fast Connect cannot be accepted by the called endpoint.

Generic Extensibility Framework

One of the issues with H.323 as it matures is simply the number of parameters that exist in the base protocol specification. To prevent continued and unbounded growth of the ASN.1 that defines the H.225.0 protocol, a generic extensibility framework has been added to version 4. This framework actually serves two purposes. First, it allows one to send opaque data between H.323 entities without adding new fields to H.225.0, as just mentioned. Second, it introduces a new means of performing feature negotiation. The latter is definitely the most powerful use of this new framework.

An H.323 entity may use the generic extensibility framework in order to indicate its supported features, desired features, and needed features. Entities may exchange this feature information and may then take advantage of mutually supported features. When routing call signaling, entities in the middle of the call signaling path may add to or subtract from the specified feature set if those entities can perform the feature on behalf of one of the endpoints in the call. This means that more intelligence may be built into the network without having to add such intelligence to the endpoints in a call.

H.323 URL

The URL scheme "h323" is introduced in Version 4 of the protocol. The H.323 URL will allow entities to access users and services in a consistent manner, much like other defined URLs allow for other IP-based services. The form of the H.323 URL is "h323:user@host", where "user" is a user or service and "host" might be the Gatekeeper that can translate the URL into a call signaling address.

Call Credit-Related Capabilities

An extremely popular service which utilizes IP telephony today is to allow users to dial a Gateway to place a call (with the anticipation that the call will be much lower than a traditional PSTN call), which is then charged against a pre-paid calling card or to a user's account. Until now, there has been no standard means of communicating available funds or for the Gateway to control early call termination based on available funds. H.323v4 adds these features to the RAS protocol.

DTMF Relay via RTP

H.323 version 4 now allows an endpoint to utilize RFC 2833 to send and receive DTMF digits. This is important, for example, in order to convey precise timing of DTMF information. Also, it is a logical choice when the call is routed through the Gatekeeper and the Gatekeeper is not interested in that information.