10027.Diving into the H.323 Version 4 Spec

Diving into the H.323 Version 4 Spec

The latest rev on the popular H.323 call signaling spec provides enhanced security, better PSTN integration, and support for HTTP service control. Here's a look at these looks at these enhanced features and their impact on VoIP designs.

By Eli Orr, Radvision
CommsDesign.com 11, 2003	<script language=javascript> function launcher() { var url = "/emailBox.jhtml?articleID=16,500,698"; window.open(url, "", "toolbar=no, scrollbars=auto, location=no, status=no, width=500, height=400, resizable=1") } </script>

For years, carriers and equipment manufacturers loved to quibble over the best signaling scheme for their voice-over-IP (VoIP) gateway architectures. During the debate, industry members pitted the H.323 spec, which was backed by the ILECs, against the session initiation protocol (SIP), which was backed by the growing IP equipment/service provider sector.

Fast forward to 2003. With the market sagging and the CLECs long gone, the debates between SIP and H.323 are starting to fade. But, while the debates lessen, interest in H.323 is on the rise. In fact, Cisco recently reported that China Unicom, iBasis, ITXC, Genuity, PhoneOpia and Ntera have carried at least one billion H.323-based VoIP minutes. China Unicom, Cisco's largest VoIP carrier, has transported more than three billion H.323 VoIP minutes as of July 2002.

However, most products are based on, and most service providers are using, version two or three of H.323 protocol. While effective, these revs of the H.323 spec still face challenges on the security, PSTN harmonization, service management, and scalability fronts. To solve these problems, a new rev of the H.323 spec has been unveiled, delivering better security, better PSTN harmonization, HTTP serrvices control, and more. Let's take a look at the key enhancements.

H.323: The Basics
The ITU-T Recommendation H.323 specification defines four different H.323 entities as the functional units of a complete H.323 network that can be packaged together into a co-located product. These include gatekeepers, multipoint control units (MCUs), gateways, and terminals.

• Gatekeepers: In service provider and enterprise networks, Gatekeepers play a key role in performing address resolution functions in order to get calls routed across the enterprise or around the world as their basic feature. H.323 gatekeepers are network and service management entities that control the end points access to services, network resources, and optionally can provide add-on centralized services. Gatekeepers also monitor service usage, locating gateways, network bandwidth management and other network administration tasks and usage policies. They perform the critical control, administration, and management functions needed to maintain the integrity of enterprise LANs and WANs.

• MCUs: The multipoint control units are designed to support multi-party conferences between three or more locations. In H.323, the multipoint-session dynamics are very flexible. The standard allows for a variety of ad hoc conferencing scenarios, centralized or decentralized.

• Gateways: Connect IP and circuit-switched networks. Gateways are essential network components for routing voice/video/data between H.323-based systems on IP networks and PSTN networks.

• Terminals: Terminals are the end-user devices that provide real-time, two-way communication. Terminals can provide voice-only and/or multimedia such as video and real-time application collaboration.

  Features in H.323 can be categorized into three classes: local features, network-based features, and supplementary services. Local features can be implemented in the endpoints without requiring specific signaling to other network entities. Examples for local features are: repeat a call, call history and call lists, local address book, speed dialing, privacy functions like do not disturb and mute, etc.

  Network-based features are implemented in a centralized fashion in the gatekeeper (GK) or as a backend service behind the GK. Examples are authorization, address resolution, call admission, call detail recording (CDR), and name/number suppression.

  Supplementary services are features that require special signaling between the corresponding entities. Examples for supplementary services are: call forwarding, call transfer, call completion, call hold, etc.

  The key characteristic of the H.323 service architecture is its explicit definition of separate state machines for each feature independent from the basic call state machine. From the signaling point of view the function split of feature control into framework and extensions is a consequence of this separation. The ITU-T has already standardized the feature state machines of the most important telephony features, with further features being added every few months. The syntax is specified with ASN.1 and the semantics are described using SDL (State Definition Language) diagrams.

  Like any specification in the sector, the H.323 specification is continually being tweaked by industry sector. In the case of H.323, the International Telecommunication Union's (ITU's) Signaling Group is handling the tweaks, releasing version 4 of the spec in November of 2000.

  Revision 4 of the H.323 specification provides some big steps forward for engineers working with H.323 In this article, we'll focus on only a few key enhancements: security, PSTN harmonization, HTTP services control, and supplementary services management. More detailed information on revision 4 of the spec can be found at http://www.h323forum.org/standards/. Let's start our discussion by looking at security.

  Security Enhancements
  The need for enhanced security services in today's IP and PSTN infrastructure are growing. Some of the main drivers include: accurate user authentication, billing verification, and large-scale key management.

  Earlier version of the H.323 specification defined a sub protocol, H.235 version 1, for supporting security services. This protocol defined very basic security guidelines and thus lacked well-defined security procedures, which lead to interoperability headaches between vendors.

  H.323v4 attacked the security problems encountered in previous architectures by reworking the H.235 sub-protocol. From that work, version 2.0 of the H.235 spec emerged, bringing with it two new security procedures between end points and the gatekeeper, named annex D and annex E.

  Improving security with H.235
  Before diving into the specifics on annexes A and D, let's look at the scope of H.235 and the security services this spec enables. Figure 1 the H.323 sub protocols that H.235 version 2 secures.

  
  Figure 1: Diagram of the key elements housed in the H.235 version 2.0 sub-protocol.

  As Figure 1 points out, the H.235 spec includes: Q.931 call signaling, H.245 call control, H.225.0 RAS (registration, admission, and status) protocol between end point and gatekeeper and RTP (for media confidentiality). Let's review each of these sub-layers.

  1. Securing H.225.0— Q.931 can be secured via transport-layer security (TLS) or IPSec prior to any H.225.0 message exchange. During the RAS phase of registering, the end point and the gatekeeper can exchange security policies and capabilities to define the security methods to be used in the initiated call session.

  2. Securing H.245—In order to perform secured H.245, the H.225.0 channel should exchange the h235SecurityCapability field as part of H.225.0 setup user-user information element (UUIE). Another option is to open an H.235 security channel as logical channel opened by H.245 using IPSec or TLS to secure that channel.

  3. Securing RTP— In order to secure RTP channels carrying voice, video and application data for confidentiality (media privacy), H.323 defines a method of opening a secured RTP channel using H.245 signaling messages. The method uses H.245 capability exchange for opening secured logical channels as part of the H.245 capability exchange phase. The object h235SecurityCapability choice should be used for negotiating channel security mechanism to be used such as DES, 3DES or AES. The security capability is exchanged per media stream (RTP channel) opened so that if applied the channel it is enabled with confidentiality (privacy). The encryption key to be used is exchange via Diffie-Hellman (DH) to generate the shared secret key to be used.

  For media streams encryption, the master determinate in the master/slave determination is responsible for generating the key. The key length is dependant on the encryption algorithms such as DES and 3DES. For example, in DES a 56-bit key is generated.

  The Annex D Spec
  OK, now that we've reviewed the basics of H.235 version 2, let's review each of the new security procedures defined in H.235 version 2. We'll start with the annex D procedures.

  Annex D provides a base line security profile that provides authentication and integrity for RAS, H.225.0, and H.245. Optionally it provides confidentiality for RTP/RTCP media streams during RAS. The baseline security profile uses Diffie-Hellman (DH) key exchange to generate the shared secret key.

  The four main features provided under the annex D spec include:
  

  • User authentication: Irrespective of the number of application level hops.
  • Message authentication and integrity: Authentication and integrity of all or critical portions (fields) of messages for any number of hops number, for RAS, H225.0 and tunneled H.245.0
  • Hop-by-hop security: The spec provides hop-by-hop message authentication, which delivers integrity for the entire message.
  • Confidentiality for the media stream: Provided by symmetric encryption.

  The main benefits of these technologies for the design community include the use password-based cryptographic techniques, the delivery of a security profile for voice encryption, support for the GK routed model, and exchange of symmetric key/passwords among H.323 entities. The spec also provides integrated key management capabilities and the use of symmetric key techniques for authentication and integrity applications.

  Annex D will prove to be an easy protocol for designers to implement. However, it does have some drawbacks. First, it's not scaleable for "global" IP telephony because of the symmetric key concept. Second, it lacks proper key management solution. Finally, it provides limited security by allowing the terminal and GK to know the shared key. Thus, a third-part can take and use the key.

  The Annex E Spec
  Annex E is an enhancement on the annex D security protocol that enables certificate procedure for usable key management to enable key modifications to be handled by the end user with RAS and H.225.0. Certificates are objects that allow you to prove your identity in electronic transaction and can be grated to in a secured way from external system. The basic difference between this security procedure and the H.235/annex D is that digital signatures (certificates) are used instead of the shared secret that annex D defines allowing much advanced scalable and enhanced security solution.

  The algorithms used to create digital signatures can be either RSA-SHA1 or RSA-MD5. The secret key exchanged can be used for advanced scalable user authentication by a gatekeeper and for media stream confidentiality for the users participating in the session.

  The annex E security protocol calls out four profile features (Figure 2). These include:

  • User authentication—An unlimited number of application level hops using digital signatures and certificates.
  • Message Integrity—Provides integrity of all or critical portions (fields) of messages.
  • Hop-by-hop security—Hop-by-hop message authentication, integrity and non-repudiation for the entire message.
  • Non-repudiation of messages exchanged—Irrespective of the number of application level hops the message traverses.
  
  Figure 2: Call functions versus security services in the annex E protocol. Like the annex D spec, the annex E spec has its pluses and minuses. On the positive front, the spec enables scalability, does not depend on the mutual shared secrets of hops in different domains, and offers more security than annex D. On the negative side, this protocol consumes high bandwidth in the signaling stage and requires high processing (More powerful CPU power for Scalable solution)

  Working Better with the PSTN
  Now that we've wrapped our discussion on security, let's turn to the second major area of improvement in version 4 of the H.323 standard— PSTN harmonization.

  The evolving reality of VoIP (based on H.323) is that the voice network is now becoming a hybrid of voice and data networks. As such, the two worlds—IP and TDM—must operate together seamlessly.

  PSTN harmonization in H.323 signaling started since version one for call set-up based PSTN Q.931 and later with QSIG (Q signaling) logical layer for supplementary services H.450. While these provided a first step in the process, designers have realized that there is an additional need for transmitting PSTN signaling over H.323 networks to a remote end in order to utilize a hybrid of H.323 and PSTN networks.

  To solve this request, the H.323v4 enables PSTN signaling used in one PSTN network to be transmitted through H.323 and then passed on to another PSTN network as if the two PSTN networks were one. In many deployment scenarios of hybrid PSTN and H.323 networks the PSTN signaling tunneling capability enables cost effective calls using IP for long distance routes and better service coverage for PSTN subscribers.

  H.323v4 defines the following PSTN protocols to be carried via H.323: ISDN user part (ISUP) and QSIG. These protocols can be tunneled without translation.

  QSIG and ISUP Tunneling
  In a hybrid PSTN/H.323 network, one of the main challenges left open before H.323 version four was the ability to connect remote PBXs for QSIG messages exchange with H.323. H.323v4 annex M.1 addresses this need by describing the tunneling of QSIG signaling in H.323 networks.

  Endpoints that support QSIG information tunneling are required to use the private ISDN signaling-domain object identifier for carrying QSIG message. The H.225.0 message tunnels the entire QSIG message, unchanged, starting with the protocol discriminator field, and ending with the other information elements. The binary content of the QSIG messages is encoded as binary in the message H323-UU-PDU.tunnelledSignallingMessage.messageContent.

  Since the binary encoding of QSIG messages is what is tunneled, the integrity of the QSIG messages is fully preserved, including any basic encoding rule defined ASN.1 in Facility or Notification indicator information elements.

  ISUP is used for signaling between end-user terminal and a PBX for services such as initiating a call to a remote terminal (phone), getting call signal (ringing), and terminating a call session. The ability to transmit this PSTN signaling with QSIG through H.323 networks enables better utilization of hybrid PSTN and H.323 networks for better coverage and reduced operational costs.

  H.323 annex M.2 describes the tunneling of SS7- ISUP signaling in H.323 networks. This annex describes a mechanism for transmitting ISUP messages, unmodified, within H.225.0 call signaling messages. Calls are marked in the switched circuit networks in the initial address message (IAM) of the ISUP signaling. In the case where these messages terminate at an entity (such as a gatekeeper which is providing ISUP services) on the H.323 network, as described in H.323 annex M.2, the entity must assure that the marking is preserved when the ISUP tunnel is forwarded to the destination endpoint.

  HTTP Service Control
  Now that we've finished our discussion on better PSTN/H.323 integration, let's turn our focus to providing better integration of HTTP and H.323.

  With HTTP becoming a de-facto standard in the sector, the ITU decided to add a guideline in H.323v4 for integrating HTTP with H.323. Under the H.323v4 spec, HTTP service control can be used for the transport of service control with call or non-call related H.323 signaling. This enables full-featured advanced videoconference services to be accessed from a friendly web browser interface.

  With these new features an application can locate a pre-defined (personalized) URL and enable the provision of a personalized service through the web. Examples of web-based services that can be incorporated in applications are:
  

  • Address book navigation
  • Click to dial
  • Point and click for multi-party conference setup
  • Interactive web/voice response
  • Web multimedia instant messaging and presence
  • Follow-me services

  Annex K in the H.323v4 spec defines the integration between H.323 and HTTP. During initial RAS signaling, annex K allows a central device, such as a gatekeeper (or softswitch with gatekeeper call control), to initiate a parallel HTTP session to a predefined URL. In the registration confirm (RCF) (Registration Confirm) message, the gatekeeper may return a URL. Note that if you combine the services of accurate user authentication, this HTTP service control capability enables valuable service personalization, sending a personalized URL for the specific user as a personalized web page defined user services and preferences.

  The parallel HTTP session allows call control and non-call control services to be incorporated into H.323 real-time voice and video over IP applications and devices. The HTTP server maps HTTP events and call control actions in a manner transparent to the endpoints. Furthermore, H.323v4 allows various types of text formats, images, and sounds to be added and utilized dynamically. The flow diagram demonstrates address book navigation service using combined H.323 and HTTP protocol services. When address is selected the user can initiate a point and click rich media session with the user resides in the address destination.

  Figure 3 shows an example of HTTP service control. In this example, the terminal sends a registration request (RRQ) to the gatekeeper. The gatekeeper returns an RCF message that includes a specific URL for the user such as his private address book saved in the service provider (web server). The web browser application at the terminal side opens the personalized URL from the gatekeeper for the specific user. The user than updates the address book stored at the web server. Later the user initiates a call to a user defined in the address book, so that the address is taken to the H.323 application at the terminal and the application sends an admission request (ARQ) to the gatekeeper to initiate the call.

  
  Figure 3:Diagram illustrating a typical HTTP service control implementation.

  Additional Supplementary services
  Previous H.323 versions defined a set of additional services that can enhance the user basic call services, such as call transfer or call diversion to enable a pre-defined policy. H.323v4 expands this suite with the addition of the H.450 services set.

  The previous H.323 versions defined the following supplementary services:
  

  • H.450.1—General concept for using QSIG logical layer
  • H.450.2—Call transfer
  • H.450.3—Call diversion (unconditional, on busy and when no answer)
  • H.450.4—Call hold
  • H.450.5—Call park and pick-up commonly used by call centers
  • H.450.6—Call waiting indication
  • H.450.7—Message waiting indication and naming indication (H.450.8), which enables the exchange of readable descriptive text about the endpoint user, such as the useful information that normally appears on a business card.

  The H.323 supplementary services suite H.450 are based on QSIG logical procedures. That is, H.323 supplementary services use exactly the same logic as QSIG. So when a supplementary service needs to be provided between a PSTN network and an IP network (via a gateway) the inter-network mapping is straightforward and simple.

  In H.323v4, the ITU added some addition services to the initial H.450 set. These include:
  

  • Call Completion on Busy (H.450.9) signals the caller and the callee when both parties are free to receive a call. Applies to "call completion for busy" or "no answer" scenarios.
  • Call Offer (H.450.10) enhances the call waiting service by notifying the called user who can then accept the offered call or reject it. The called user can also accept the offered call after putting the existing call on hold or terminating it.
  • Call Intrusion (H.450.11) enables the ranking of endpoints. A higher-ranking endpoint can intrude in the call of a lower-ranking endpoint. Intrusion can be the breaking into an existing call or silently monitoring the called user (auditing).
  • Common Information Additional Network (H.450.12) enables endpoints to exchange information relating to the endpoint category and the supplementary services supported by each. This information can be used by the endpoint or gatekeeper applications to determine what supplementary services to use and how they can best interoperate.

  Having the additional suite of services H.323v4 defined, the user can have very rich suite of powerful add-on services during call session and ability to define automatic call handling services policies. Implementing this suite of services the service provider can provide a very rich set of additional valuable services as add-on to differentiate and have an up-sale of services to each of its subscribers.

  About the Author
  Eli Orr is a product manager in Radvision's Technology Business Unit. He has more than 18 years in computing systems, the last 10 years focused in the development of IP-based communications systems and technologies. Eli can be reached at eliorr@radvision.com.