H.323: H.225, H.245, RAS

H.323 is a framework developed within the ITU that describes interactive multimedia communications. The framework itself encompasses a number of protocols, standards, and procedures, including the following:

• H.225 RAS (Registration, Admission, and Status): Facilitates communication between H.323 endpoints and gatekeepers. Gatekeepers provide a number of services, including call admission control (CAC), bandwidth management, address translation, dial plan resolution, and call routing. In H.323, the dial plan may be distributed, although gatekeepers can help to alleviate issues related to having a distributed dial plan.

• H.225 call control and signaling: Establishes connections between H.323 endpoints, such as phones.

• H.245: Endpoints use H.245 to communicate information relating to capabilities, establish logical channels for the transmission of media, and so on.

These protocols and standards are described more fully in the remainder of this section.

H.323 signaling is encoded using Abstract Syntax Notation One (ASN.1).

H.225 RAS is, as previously described, used for communication between H.323 endpoints and gatekeepers. UDP port 1719 is used for gatekeeper H.225 RAS communications, while UDP port 1718 is used for gatekeeper discovery via Gatekeeper Request (GRQ) messages. Multicast gatekeeper discovery uses IP destination address 224.0.1.41.

There are many types of H.225 RAS messages:

• Gatekeeper discovery: Used by endpoints to find a gatekeeper with which to register. Specific gatekeeper discovery messages include GRQ, Gatekeeper Confirm (GCF), and Gatekeeper Reject (GRJ).

• Registration and unregistration: This process is used by endpoints and other devices to register their addresses with gatekeepers and join a zone. Registration and unregistration messages include Registration Request (RRQ), Registration Confirm (RCF), Registration Reject (RRJ), Unregister Request (URQ), Unregister Confirm (UCF), and Unregister Reject (URJ).

• Admission control: These messages are used for CAC and bandwidth management. Specific message types include Admission Request (ARQ), Admission Confirm (ACF), and Admission Reject (ARJ).

• Bandwidth control: These messages can be used to change the amount of bandwidth during a call. Messages include Bandwidth Request (BRQ), Bandwidth Confirm (BCF), and Bandwidth Reject (BRJ).

• Endpoint location: Used to retrieve contact information. Messages include Location Request (LRQ), Location Confirm (LCF), and Location Reject (LRJ).

• Status information: Used to retrieve status information. Specific messages include Information Request (IRQ), and Information Request Response (IRR).

Figure 3-5 illustrates H.225 RAS in relation to H.225 call control signaling and H.245 (assuming direct endpoint call signaling).

Figure 3-5. H.225 RAS, H.225 Call Control, and H.245

H.225 call control signaling takes place on TCP port 1720 and uses Q.931 messages to establish, maintain, and tear down calls. Q.931 messages used for H.225 call control include Setup, Setup Acknowledge, Call Proceeding, Progress, Alerting, Connect, User Information, Release Complete, Status Inquiry, Status, Information, and Notify.

Although H.225 call control signaling can be used for call setup, H.245 must be used to determine a master/slave relationship, exchange terminal capabilities, logical channel signaling, and DTMF relay. Figure 3-6 depicts an example of H.225 call setup and H.245 signaling between endpoints.

Figure 3-6. H.225 Call Setup and H.245 Signaling Between Endpoints

In Figure 3-6, H.225 call control signaling is used to set up a call between Endpoint 2 and Endpoint 1 (messages 1[nd]4). The Connect message is used to communicate the IP address and TCP port that will be used to set up a connection for H.245.

The two endpoints now negotiate terminal capabilities, such as DTMF relay, hookflash relay, and supported codecs using Terminal Capability Set and Terminal Capability Set Ack messages.

At this point, the endpoints also determine the master/slave relationship using Master Slave Determination and Master Slave Determination Ack messages. The endpoint that becomes the master controls the session.

After capabilities exchange and master/slave determination takes place, the next step is for the endpoints to begin logical channel establishment.

Logical channel establishment comprises the initiation of unidirectional RTP/RTCP streams between the endpoints. Logical channel establishment is initiated using the Open Logical Channel and Open Logical Channel Ack message types.

The Open Logical Channel messages specify media channel parameters, such as UDP ports for RTP/RTCP, codec, DTMF support, and so on. Open Logical Channel Ack is used to indicate that the endpoint will accept the media, as well as to confirm IP addresses and ports to use for RTP.

As you can see from Figure 3-6, regular call setup can be involved. Call setup can be expedited by using a method called H323 Fast Start (or Fast Connect), which involves carrying H.245 information in H.225 messages.

The following example shows the configuration of an IOS H.323 gateway that’s integrated with CUCM:

voice service voip
 h323
  ccm-compatible
!
interface GigabitEthernet1/0
 ip address 10.2.2.1 255.255.255.0
 h323-gateway voip bind srcaddr 10.2.2.1
!voice class h323 1
 h225 timeout tcp establish 3
!
dial-peer voice 20 voip
 preference 1
 destination-pattern 5...
 voice-class h323 1
 session target ipv4:10.2.2.1
 codec g711alaw
!
dial-peer voice 30 voip
 preference 2
 destination-pattern 5...
 voice-class h323 1
 session target ipv4:10.2.2.2
 codec g711alaw

As previously discussed, the voice service voip command is used to enter voice service configuration mode.

Next, the h323 command enters the H.323 submode, and the ccm-compatible command configures the gateway for connectivity with a CUCM.

The h323-gateway voip bind srcaddr ip-address command is now used to configure the IP address used as a source IP address for messages sent to a CUCM.

The voice class h323 tag command is then used to configure an H.323 voice class. With the H.323 voice class, the h225 timeout tcp seconds command configures the H.225 TCP establish timeout.

VoIP dial peers are then configured pointing to redundant CUCMs, and the previously defined voice class is referenced within each VoIP dial peer.

H.323 gateways can be configured in CUCM by navigating to Device, Gateway.

Although most problems with H.323 gateways are caused by simple misconfiguration, before finishing this section, it is worth looking at some particular issues that can occur when deploying H.323 gateways in conjunction with CUCM. These issues result in no ringback tone being played when it should be. The following three conditions can occur:

• No ringback tone on an IP phone when calling a destination in the PSTN: This issue occurs because of the way in which CUCM handles ringback when it is calling out via an H.323 gateway. It can be resolved by configuring the progress_ind alert enable 8 command under the appropriate POTS dial peer.

This command ensures that the gateway treats the incoming (ISDN) Alerting message as if it contains a progress indicator of 8, which indicates that in-band information is available. (The PSTN does not actually include this progress indicator in the Alerting message in this situation [PI=0].)

• No ringback tone on a phone in the PSTN when calling an IP phone: This occurs because the IOS gateway does not play a ringback tone to the phone on the PSTN because the Setup message received from the PSTN did not include a progress indicator (PI=0).

The gateway assumes the network is ISDN end to end and that playback tones will be handled by the PSTN, but in fact, that network is not ISDN end to end, and tones are therefore not handled by the PSTN. (The PSTN should have sent the Setup message with a progress indicator of 3.)

This issue can be resolved by configuring the progress_ind setup enable 3 command under VoIP dial peers that are used for the incoming call. This command forces the gateway to play an in-band ringback tone irrespective of the progress indicator in the Setup message.

• No ringback tone is played to the phone on the PSTN when a call is transferred by an IP phone: This issue is caused because an IOS gateway tears down logical channels when transferring a call, so audio is not sent.

This issue can be solved by running IOS 12.2(3) and later, together with CUCM 3.0(8) and later, and setting the CUCM ToSendH225UserInfoMsg service parameter to True.

IOS H.323 gateways can send DTMF digits in a number of ways, including the following:

• H.245 alphanumeric: In this case, digit tones are sent out-of-band via H.245 signaling, but this does not include tone duration. (Each digit is assumed to be 500 ms long.)

• H.245 signal: This is similar to H.245 alphanumeric, but tone duration is sent.

• RTP-NTE: Tones are sent in the RTP stream using NTE packets, with the payload type value being negotiated.

• Cisco proprietary: Tones are sent in the RTP stream using payload type 121.