H.323 Version 5 - Overview

H.323 version 5 was officially approved at the end of July 2003. Unlike previous revisions of the Recommendation, H.323 version 5 aimed to maintain stability in the protocol by introducing only modest additions to the base protocol, rather than introducing sweeping changes as was the case in prior revisions. Look to version 5 as "maintenance" release of H.323 version 4, with just a few new fields added and only one new message type.

Of course, standardization activities surrounding H.323 are still quite active. Most of the new enhancements to H.323 have been introduced through the "Generic Extensibility Framework" (GEF) that was introduced in H.323 version 4. Since the approval of H.323 version 4 in 2000, we have added 9 new features to H.323 that utilize GEF. What's nice about GEF is that we are now able to add new features to H.323 without altering the base protocol. People have asked for stability and this is one step in that direction.

Some of the new additions to H.323 since version 4 include:

  • Annex M.3 - Tunneling of DSS1 signaling within H.323 systems
  • Annex O - Defines how to use the H.323 URL and other DNS services within the context of H.323 systems
  • Annex P - Describes how to do modem relay within H.323 systems
  • Annex Q - Far-end camera control for video conferences
  • Annex R - Provides for fault tolerance-- calls do not drop when a single intermediate signaling entity, such as a softswitch, fails while the calls are in progress. (GEF)
  • H.460.1 - Overview of the Generic Extensibility Framework and "author's guide"
  • H.460.2 - Number portability (GEF)
  • H.460.3 - Circuit Status Map (GEF)
  • H.460.4 - Call priority designation (GEF)
  • H.460.5 - Transport of duplicate Q.931 IEs (GEF)
  • H.460.6 - Extended Fast Connect (GEF)
  • H.460.7 - Digit maps (GEF)
  • H.460.8 - Querying for alternate routes (GEF)
  • H.460.9 - QoS monitoring and reporting (GEF)
  • A few additions to H.323v5 and H.225.0v5

As you can see, virtually all of the new enhancements utilize the GEF. In fact, the entire H.460.x series of documents are devoted to adding enhancements to H.323 via the GEF. Developers can pick and choose which of the GEF enhancements to support in their products.

In the remainder of this document, we will briefly discuss each of the aforementioned features added.

Annex M.3 - Tunneling DSS1

The Annex M.x series of documents describe how to carry various non-H.323 signaling protocols within the context of an established H.323 call. Annex M.3 specifically focuses on how to transport DSS1 signaling within an H.323 call. The H.323 entities involved do not have to be aware of what the DSS1 signaling looks like or what is being communicated. To H.323, it's just a stream of raw data.

Annex O - Use of URLs and DNS

This Annex describes how to utilize DNS for the purpose of resolving addresses in the form of H.323 URLs. Suppose that you wish to call somebody and are given the address "". You can give this alias address to your endpoint (which may then pass it along to its Gatekeeper, if there is one) to perform an address resolution operation. Depending on the composition of the URL, the H.323 may utilize ENUM, look for SRV records, or other kinds of DNS records in order to resolve the address.

URLs are not new to H.323. In fact, the URL alias types have been in H.323 since version 2. It has always been possible to give an H.323 endpoint a URL, including a web page, "tel" URL, or other such URL types. Of course, the problem has simply been that there have been no specific details about how to handle such URLs.

Annex O does not advise an endpoint in what to do in the case, for example, that a remote endpoint requests the call to be forwarded to a web page. That is certainly technically legal, but practically useless-- at least today. What does it mean to transfer a call to a web page? What if the phone doesn't have a display suitable to display said web page? Many things are possible with URLs, of course, but Annex O focuses on the practical cases that make sense from the perspective of routing audio, video, and data calls over IP networks.

Annex P - Modem Relay

Annex P defines how to use V.150.1, which describes how to carry modem signals over an IP network, within the context of an H.323 call. It leverages a new concept introduced in H.245 called "Multiple Payload Streams".

Multiple Payload Streams can be thought of as something quite similar to an "m=" line in SDP (RFC 3227). They were introduced into H.245v9 as a means of allowing an endpoint to open an RTP session that can carry voice and modem signals, DTMF (RFC 2833), or other signals (including text, fax, etc.).

Annex Q - Far End Camera Control

Annex Q defines a means of performing far end camera control within the context of a video call. While H.323 systems already had standards for performing this capability (H.282 and H.283), the video equipment manufacturers felt that those standards were too complicated. While H.283 is flexible and can be used to control a wide range of devices, the video equipment manufacturers wanted to utilize H.281 for the narrow purpose of controlling a video camera, as it was considered much simpler. Every video equipment manufacturer endorsed Annex Q over H.282 and H.283, so do not even both with anything other than Annex Q for far end camera control.

Annex R - Robustness

Annex R focused on the problem of preventing an active call from being dropped in the face of any single device failure in the network. This Annex may be used be endpoints of intermediate signaling entities (e.g., Gatekeepers or Softswitches).

Prior to the introduction of Annex P, if a device failed in the call path, the call was simply dropped. The reason was that H.323 relied on the TCP connection for accurate, in-order delivery of call signaling messages. If a TCP connection was broken, devices didn't know how to react and just simply dropped the call. That was more of a design choice than a requirement in H.323.

Annex R introduces the needed language and specific procedures that endpoints and other devices must perform to prevent calls from being dropped in the event of a failure. Of course, TCP connections may be broken and Annex R fully explains how to recover those TCP connections and continue with the call.

H.460.1 - Generic Extensibility Framework

This is the first in a series of documents that describe new features for H.323 systems that utilize the Generic Extensibility Framework described in H.323v4. This document is primarily for the benefit of authors of H.460.x recommendations, but it may be of general interest to those reading and trying to understand GEF.

H.460.2 - Number Portability

As the name suggests, this document describes how to provide a number portability service within an H.323 network.

H.460.3 - Circuit Status Map

H.460.3 allows an gateway to report the detailed status information for circuits under its control to a gatekeeper. The gatekeeper may utilize this information, for example, when trying to route calls to the PSTN.

H.460.4 - Call Priority Designation

H.460.4 simply adds a mechanism to H.323 to allow a calling endpoint to signal the priority of a call. The priority may be emergency authorized, emergency, high, or normal.

H.460.5 - Transport of Duplicate IEs

H.225.0 forbids the existence of duplicate IEs of the same type. Generally, that is acceptable. However, there are some interworking cases wherein a PSTN gateway needs to deliver duplicate IEs to an egress PSTN gateway. This document makes those interworking scenarios possible.

H.450.6 - Extended Fast Connect

Extended Fast Connect, as the name implies, builds upon the very popular Fast Connect mechanism defined within H.323v2. With these new procedures, it is possible for an endpoint to modify, add, or remove media streams from a call by simply sending a new fastStart element to the other endpoint. There is no need to go through H.245 logical channel signaling, as was the case before.

Not only does Extended Fast Connect (EFC) decrease the complexity involved in changing media streams, it introduces some signaling scenarios that were not possible in the past. For example, suppose that an H.323 endpoint calls another H.323 endpoint. Further, suppose that some network element in the middle of the network wants to play media to the calling endpoint before connecting the call (e.g., to announce the amount of remaining credit, indicate that the call is progressing, etc.) What had to happen prior to the introduction of EFC was that the interior network elements had to accept the initial fastStart or perform H.245 logical channel signaling to transmit its message. It would then have to send an "Empty Capability Set" (or TCS=0) message to the calling endpoint, redirect the H.225.0 and H.245 signaling toward the called endpoint and exchange a number of H.245 to re-establish media. While this worked, it was more complicated. (Those latter procedures are defined in section 8.4.6 of H.323 under the heading "Third Party Pause and Re-Routing").

Given the same call scenario as above and the EFC feature, the intermediate signaling entities simply forward the original fastStart proposal on to the called endpoint. When it replies, media channels will automatically closed and re-opened as desired. It's significantly simpler.

H.460.7 -Digit Maps

One of the problems exhibited by most IP phones today is a delay in dialing the number once all of the digits are dialed. Either that, or the user is required to hit a special "send" key (sometimes the "#" key). The reason is simply that the IP phones did not know what the dialing patterns were supposed to look like. So, they had to introduce timers and wait for a certain amount of time since the last key press to initiate a call.

H.460.7 resolves this problem by allowing the Gatekeeper to provide the endpoint with a digit map. Essentially, this tells the endpoint precisely what the acceptable phone numbers look like. This allows the endpoint to know, without question, that the last digit has been dialed or that additional digits are needed, thus allowing the IP phone to initiate calls in the most efficient manner.

Of course, it is not practical to provide an IP phone with the dialing information for the entire world. Even so, it is possible to use H.460.6 to provide part of the dialing information and then allow the endpoint to used overlapped sending or use an internal timer (as it originally did) to collect digits for calls that did not match a recognized dialing pattern.

When using overlapped sending (through RAS), the endpoint may transmit an ARQ message to the gatekeeper to see if the digits form a complete address. If not, the gatekeeper may then inform the endpoint that the address is incomplete and, based on the digits that were dialed up to that point, provide the endpoint with a new, refined, more granular dialing pattern that aligns with the digits dialed.

The choice to install a complete dial plan into the IP phone, use overlapped sending through RAS, or force the phone to use a timer to timeout digit entry is entirely up to the network operator.

H.460.8 - Querying for Alternate Routes

Sometimes, when an endpoint queries the gatekeeper for an address (ARQ), the call attempt will fail. H.323v2 attempted to resolve this problem by introducing "alternate endpoints". However, the use of alternate endpoints does not allow one to offer different information about the destination endpoint, such as "modifiedSourceInfo", "multipleCalls", and other elements found within the ACF message. Also, since most calls are expected to succeed, it is costly to have to generate unique security information for several alternate endpoints just in case the primary attempt (route) fails.

H.460.8 allows the endpoint to re-query the gatekeeper in the case that the initial call attempt failed. This allows the gatekeeper to provide alternative routing information to the endpoint. It also gives the endpoint an opportunity to report error codes to the gatekeeper about call attempts that failed, which may prove important in running an efficient network.

H.460.9 - QoS Monitoring and Reporting

H.460.9 provides the wherewithal for an endpoint to provide RTCP statistics to the gatekeeper. There is on-going work within the IETF to enhance the RTCP statistics reporting capabilities, which is expected to be integrated as Annex B of this document.

Miscellaneous H.323v5 and H.225.0v5 Additions

Of course, there were new things added directly to H.323v5. I briefly mention those that may be of more significance

Hop Count

While H.323 devices have had the wherewithal to detect routing loops within H.323 networks, routing loops could still exist when going onto the PSTN and back on again. The same is true for going between H.323 and SIP networks. The reason is that the information that is vital to loop detection (the Call Identifier) is lost in such protocol interworking points. To address this, H.323 introduced a Hop Count field (values ranging from 1 to 31), to align with the same parameter in ISUP.

SIP as a Supported Protocol

Gateways now have the wherewithal to advertise themselves as both an H.323 gateway and a SIP gateway to a Gatekeeper. This allows SIP devices to utilize the H.323 addressing resolution fabric that is already widely deployed around the world for PSTN egress.

Enterprise Numbers

Traditionally, H.323 systems have identified the vendor information using a T.35 country code, extension, and manufacturer code assigned nationally. However, when interworking with some SIP systems, it is also necessary to advertise an IANA assigned Enterprise Number. This capability was added to H.225.0v5

SCTP as a Transport

SCTP (RFC 3309) was given official support by including fields and a description of how to use that transport within H.323 systems.

Admission Confirm Sequence

As explained above for H.460.8, the alternate endpoint information is not always sufficient for properly re-routing calls in the event of a failure. At the same time, if a network generally does have a relatively high call failure rate, using H.460.8 may prove expensive. As an alternative, ACF Sequences was added to H.225.0v5. Essentially, this allows a gatekeeper to provide a list of ACF messages in a single reply. This allows the endpoint to try any number of alternate routes before giving up. It is still possible to use H.460.8 in conjunction with ACF Sequences. This might be desirable, for example, when there are two gateways that could serve as alternates and have the same security attributes, but then a third gateway requires different security and the gatekeeper prefers to not provide that information until the two primary destinations are attempted.