Packetizer Logo
 

H.323 Version 6 - Overview

H.323 version 6 was officially approved in June 2006, after ITU-T SG16 agreed to consent the text at the end of its meeting in April 2006. As promised, the H.323 experts group strived to keep the changes to the base specification to a minimum. There were a few minor additions, but most of the new functionality being added to H.323 these days are through extensions that utilize the "generic" fields and messages in H.225.0 and H.245.

The primary changes to the base H.323 specification is the introduction of the "Assigned Gatekeeper" concept, as described below. There were also a number of changes to try to improve the clarity of certain procedures, including the call clearing procedures, error handling, etc. Enhancements were made to the H.225.0 document to clarify usage of certain fields, provide a standard mapping of cause and reason codes for LRJ/ARJ and AccessReject/ARJ. (AccessReject is defined in H.501), add a new isupNumber alias type, and support the new QoS specification (H.361), and a language field for support of message broadcast (H.460.21). Finally, additions were made to H.323 Annex G to support the transport of real-time text (ToIP) interleaved with audio to support ITU-T Recommendation V.151.

A number of new documents and Annexes have been introduced for H.245 that enable H.323 system to utilize various codecs, including GSM, iLBC, and H.264. H.245 has been incrementally enhanced with various new features that H.323v6 systems can utilize.

Security-related documents have also been significantly enhanced and the H.235 document was entirely restructured. Now, rather than having a single H.235 document, they are numbered H.235.0, H.235.1, etc. Most importantly, support has been added for SRTP to secure RTP-based media streams.

Most of the new functionality was introduced incrementally over the past two years since the publication of H.323v5. Some of the newer documents that were approved include:

Assigned Gatekeepers

The concept of an "Assigned Gatekeeper" is an extension of the alternate Gatekeeper mechanism. An "Assigned" Gatekeeper is the Gatekeeper with which an endpoint should register out of a list of alternate Gatekeepers. In the event that the Assigned Gatekeeper fails, the endpoint would switch to an alternate (as per the alternate Gatekeeper procedures). However, either the endpoint or the "current" Gatekeeper will monitor the status of the Assigned Gatekeeper and, once the Assigned Gatekeeper is available, the endpoint will transition back to its Assigned Gatekeeper. This allows the network operator to maintain a preferred provisioned state. While alternate Gatekeepers may be geographically dispersed, there is generally a desire to have endpoints register with the alternate Gatekeeper that is physically closest. Whatever the registration preference of the network operator, the Assigned Gatekeeper concept gives more control to how resources are utilized.

H.235.1 - H.235.9 - Security for H.323 Systems

Most of these documents are enhancements to the former H.235 documents, but a lot of new material has been added, most notably support for SRTP.

H.239 - Role management

H.239 was first introduced with H.323v5, but not inadvertently omitted from Packetizer's "What's New in H.323v5". H.239 introduces the concept of "roles" in H.245, which allows, for example, for a device to indicate that one video stream is live video and one video stream is a presentation stream.

H.241 - Extended video procedures

This Recommendation introduces some extended video procedures for H.323 systems. Most notably, it adds support for H.264 to H.323 systems.

H.249 - Extended User Input Indication

This Recommendation adds the ability to signal new kinds of events like mouse clicks and cursor moves.

H.361 - End-to-End Quality of Service (QoS) and Service Priority Signalling

This document (formerly called H.323 Annex N) defines how to do end-to-end QoS within H.323 systems.

H.460.10 - Call Party Category

This document allows transport of the ISUP "call party category" field within H.323 systems.

H.460.11 - Delayed Call Establishment

The idea of "delayed call establishment" is to ensure that media streams or other conditions are met before alerting the user to an incoming call. This allows, for example, a device to ensure that QoS parameters are negotiated or that pinholes can be established through firewalls before ringing the remote party.

H.460.12 - Glare Control Indicator

This Recommendation specifies a mechanism that allows an egress H.323-PSTN Gateway to resolve a glare condition (also known as "dual seizure") that is detected on the Gateway when circuit selection is done on the Gatekeeper.

H.460.13 - Called User Release Control

When calling certain numbers (e.g., emergency access numbers), the called party should have some control over how and when the call is released. This recommendation provides that type of functionality.

H.460.14 - Multi-Level Precedence and Pre-emption

This Recommendation adds support for MLPP to H.323 systems.

H.460.15 - Call Signalling Transport Channel Suspension and Redirection

This Recommendation allows an intermediary device, for example, to suspend the H.225.0 call signal channel and have it re-routed to another device or, more commonly, point-to-point between the calling and called devices. This allows, for example, a call to be established through a Gatekeeper that routes call signaling and, once the call is stable, to have the signaling burden moved off of the Gatekeeper to the endpoints.

H.460.16 - Multiple-Message Release Sequence Capability

Generally, H.323 devices that wish to release the call do so by sending a Release Complete and closing the socket. Unfortunately, TCP implementations sometimes throw away messages immediately when a socket is closed, so the remote party does not receive the Release Complete message. This Recommendation defines a handshake to ensure that the Release Complete message (with the cause code) is properly delivered and received.

H.460.17 - Tunneling RAS through H.225.0

This Recommendation is used as part of a NAT/FW traversal solution, along with H.450.19, to allow devices to send and received H.323 calls through a NAT/FW device. The primary idea is to maintain a persistent TCP connection between the endpoint on the private network and the Gatekeeper on the public network.

H.460.18 - Traversal of H.323 signalling across Network Address Translators and Firewalls

This recommendation defines procedures for traversing a NAT/FW device. It defines new procedures that must be implemented by Gatekeepers and endpoints, but also allows for the use of a special "proxy" device to enable older devices to properly traverse a NAT/FW that do not understand the procedures required to do so autonomously. Like H.460.17, this Recommendation relies on H.460.19 for media traversal.

H.460.19 - Traversal of H.323 media across Network Address Translators and Firewalls

This Recommendation defines the procedures for passing media streams through a NAT/FW device and is used by both H.460.17 and H.460.18.

H.460.20 - Location Number for H.323

This Recommendation defines how to transport a "location number" (similar to that found in ISUP) within H.323.

H.460.21 - Message Broadcast for H.323 Systems

This Recommendation defines procedures for implementing a message broadcast service within H.323 networks. The service might be used only locally, such as an enterprise intercom system, or may be used globally in order to send announcements to a large number of people. There are no geographic limits and users may specify a language preference for announcements. Servers sending announcements may then provide announcements in accordance with the user's preferred language(s).