Gatekeeper Signaling

Cisco IOS gatekeepers use a variety of signaling methods to provide control capabilities, redundancy, and extensibility of the H.323 network. These include the H.323 Registration, Admission, and Status Protocol (RAS), the Gatekeeper Update Protocol (GUP), and the Gatekeeper Transaction Messaging Protocol (GKTMP).

RAS Signaling

Gatekeepers are H.323 devices that use the RAS protocol to communicate with Cisco voice gateways. RAS is a subset of the H.225 signaling protocol.

Call control and call setup are also done using H.225 signaling. If the call control/call setup H.225 messages go directly between gateways (not through the gatekeeper), it is known as direct endpoint signaling. Some gatekeeper implementations support gatekeeper-routed call signaling (GKRCS). With GKRCS, all H.225 signaling (RAS and call control/call setup) is passed from the gateway to the gatekeeper. No H.225 messages are sent directly between gateways.

Note

Cisco gatekeeper implementations do not support GKRCS. Only direct endpoint signaling is supported.

H.245 signaling is another subset of H.323 that is used for media control. H.245 flows directly between gateways to facilitate setup of the media stream.

Figure 16-2 shows the H.323 signaling and media flow for a typical voice call.

Figure 16-2. H.323 Signaling Flow

H.225 RAS uses defined message types to communicate between the gatekeeper and the gateway. Table 16-1 lists the specific RAS messages.

Table 16-1. H.225 RAS Messages

Message Type	Message Code	Message Code Expansion	Description
Gatekeeper discovery messages	GRQ	Gatekeeper Request	Message that a gateway sends during the gatekeeper discovery process.
	GCF	Gatekeeper Confirm	Reply from the gatekeeper to the gateway, which indicates the transport address (port) of the gatekeeper RAS channel.
	GRJ	Gatekeeper Reject	Reply from the gatekeeper to gateway that rejects the gateway request for registration. Usually due to gateway or gatekeeper configuration error.
Gatekeeper registration messages	RRQ	Registration Request	Message sent from a gateway to the gatekeeper.
	RCF	Registration Confirm	Message acknowledging that the gatekeeper has allowed gateway registration.
	RRJ	Registration Reject	Message acknowledging that the gatekeeper has not allowed the gateway to register.
	URQ	Unregister Request	Message sent from a gateway or gatekeeper requesting cancellation of the registration.
	UCF	Unregister Confirm	Message sent from a gateway or the gatekeeper to confirm unregistration.
	URJ	Unregister Reject	Response to a URQ when the gateway was not registered.
Admission control messages	ARQ	Admission Request	Message that a gateway sends to initiate a call.
	ACF	Admission Confirm	Reply from the gatekeeper to the gateway admitting the call. This message also contains the IP address of the destination gateway so that the originating gateway can begin call control signaling.
	ARJ	Admission Reject	Reply from the gatekeeper denying the call request. This can be for many reasons, including a number that could not be resolved to an IP address, insufficient available bandwidth, and so on.
Location request messages	LRQ	Location Request	Message sent between gatekeepers to find a gateway in a different zone.
	LCF	Location Confirm	Message sent between gatekeepers to provide the IP address of the requested gateway.
	LRJ	Location Reject	Message sent between gatekeepers in response to an LRQ when the requested gateway is unknown or not registered.
Status information messages	IRQ	Information Request	Message sent from the gatekeeper to a gateway.
	IRR	Information Response	Message sent from the gateway to tell the gatekeeper about active calls.
	IACK	Information Request Acknowledgement	Response from the gatekeeper to a successfully handled IRR.
	INACK	Information Request Negative Acknowledgement	Response from the gatekeeper for an unsuccessful IRR.
	RIP	Request in Progress	Message sent from a gatekeeper to a gateway when the gatekeeper must use an LRQ to resolve an ACF in a different zone.
Bandwidth control messages	BRQ	Bandwidth Request	A request for an increase/decrease in call bandwidth that the gateway sends to the gatekeeper.
	BCF	Bandwidth Confirm	Message that the gatekeeper sends to confirm the acceptance of the bandwidth change request.
	BRJ	Bandwidth Reject	Message that the gatekeeper sends to reject the bandwidth change request.
	RAI	Resource Availability Indication	Message that gateways use to inform the gatekeeper whether resources are available in the gateway to take on additional calls.
	RAC	Resource Availability Confirm	Response from the gatekeeper to the gateway that acknowledges the reception of the RAI message.

 

Gatekeeper Discovery Process

A gateway will send a GRQ RAS message when trying to identify the gatekeeper for its zone. An H.323 gateway can discover its zone gatekeeper in two ways:

• Unicast discovery This method requires that the IP address of the gatekeeper is configured in the gateway. The gateway immediately sends a GRQ using User Datagram Protocol (UDP) port 1718. The gatekeeper either responds with a GCF or a GRJ.
• Multicast discovery This method enables a gateway to automatically discover its gatekeeper through a multicast GRQ message sent on multicast address 224.0.1.41. Using this method has less administrative overhead because the gateways do not have to be statically configured with the gatekeeper address. A gatekeeper can be configured to respond only to certain subnets.

  If multiple gatekeepers are on the network, using multicast discovery might require you to implement an IP network design such that a gateway or other endpoint can reach only the correct gatekeeper using the multicast message, or use unicast gatekeeper discovery. If multiple gatekeepers are reachable, you will not know which gatekeeper is discovered by the multicast, and unpredictable behavior can result.

If a gatekeeper is not available, the gateway attempts to rediscover one. If a gateway discovers that its gatekeeper has gone off-line, it no longer accepts new calls; however, calls in progress are not affected.

Because of the criticality of the gatekeeper in the network, most users implement redundancy to minimize the possibility of a network outage because of a failure. Methods of implementing redundancy are discussed later in this chapter.

Figure 16-3 illustrates both methods of gatekeeper discovery.

Figure 16-3. Gatekeeper Discovery

 

H.323 Call Flows Using Gatekeepers

Figure 16-4 shows an example of a call flow between two gateways within the same zone when a gatekeeper is used for E.164 number resolution. Both sides must successfully request admission before the call can be completed. Both gateways send IRRs to the gatekeeper after the call setup is complete and again when the call is terminated. The IRR messages are especially important if you are using the gatekeeper to collect call detail records (CDR) or for call admission control (CAC). When the IRR is received at the end of a call, the CDR is logged and the bandwidth that is used by that call is freed.

Figure 16-4. H.323 Intrazone Call Setup

The process for setting up an intrazone H.323 call is as follows:

1. A New York phone dials 208-555-0100 to reach Boise.
2. A New York gateway sends an ARQ, asking permission to call Boise.
3. The gatekeeper does a lookup and finds that the Boise gateway is registered. The gatekeeper returns an ACF to the New York gateway with the IP address of Boise.
4. The New York gateway sends an H.225 (Q.931) call setup message to the Boise gateway, including the phone number.
5. The Boise gateway sends an ARQ to the gatekeeper requesting permission to answer the call.
6. The gatekeeper returns an ACF message, which includes the IP address of the New York gateway.
7. The Boise gateway sets up a plain old telephone service (POTS) call to the phone at 208-555-0100.
8. When the phone is answered, the Boise gateway sends an H.225 (Q.931) Connect message to the New York gateway.
9. Both gateways send an IRR to the gatekeeper after the call setup is complete.

Figure 16-5 shows an example of the signaling flow for the same call with each of the gateways belonging to a different gatekeeper zone.

Figure 16-5. H.323 Interzone Call Setup

The process for setting up an interzone H.323 call is as follows:

1. A New York phone calls the Boise phone at 208-555-0100.
2. A New York gateway sends Gatekeeper A (the gatekeeper where the New York gateway is registered) an ARQ, requesting permission to make the call.
3. Gatekeeper A does not find a match for the requested phone number; however, it does a prefix lookup and finds Gatekeeper B. Gatekeeper A sends an LRQ to Gatekeeper B. At the same time, Gatekeeper A sends an RIP message to the New York gateway.
4. Gatekeeper B finds a match on the number with the Boise gateway. Gatekeeper B returns an LCF to Gatekeeper A with the IP address of Boise.
5. Gatekeeper A sends an ACF to the New York gateway with the IP address of Boise.
6. The New York gateway sends an H.225 (Q.931) call setup request to the Boise gateway, including the 208-555-0100 called phone number.
7. The Boise gateway sends Gatekeeper B an ARQ requesting permission to complete the call.
8. Gatekeeper B returns an ACF that includes the IP address of the New York gateway.
9. The Boise gateway sets up a POTS call to the phone at 208-555-0100.
10. When the phone is answered, the Boise gateway sends an H.225 (Q.931) Connect message to the New York gateway.
11. Both gateways send an IRR to the gatekeeper after the call setup is complete.

Gatekeeper Update Protocol

Gatekeeper clustering or alternate gatekeepers are methods of providing gatekeeper redundancy that utilizes the GUP protocol. GUP messages are used both to establish the initial connections between members of the cluster and to exchange status information between cluster members.

GUP uses versions of RAS gatekeeper discovery messages that include nonstandard fields for communications.

When the cluster is first established, the gatekeeper opens and maintains a TCP connection to the other members of the cluster (the alternate gatekeepers). The gatekeeper announces its presence by sending a GRQ message containing nonstandard data; then it flags it as an announcement. The announcement also carries information about bandwidth utilization for a zone. This allows the alternate gatekeepers to manage the bandwidth for a zone even though they are separate devices.

GUP GRQ messages can be one of the following formats: announcementIndication, announcementReject, registrationIndication, unregistrationIndication, or resourceIndication.

GUP announcements are sent every 30 seconds by default. Cluster members assume that a gatekeeper has failed if nothing is heard from that gatekeeper for six consecutive announcement periods or if the TCP connection is lost.

When a gateway registers/unregisters with a gatekeeper in a cluster, that gatekeeper uses the registrationIndication/ unregistrationIndication message to update all other gatekeepers in that cluster.

If a gateway reports a resource change using an RAI message to a gatekeeper in a cluster, that gatekeeper reports the change to all alternate gatekeepers in the cluster using the GUP resourceIndication message.

GUP messages allow all the gatekeepers in a cluster to have knowledge about the registration status, bandwidth, active calls, and resource status for every gateway in the zone.

Gatekeeper Transaction Message Protocol

Although the Cisco gatekeeper provides a rich set of functions to assist in controlling an H.323 network, additional functionality might be needed sometimes. Examples might include requirements for additional authentication, the need to implement additional specific policy controls, the desire to use Internet call waiting, or any other customized application logic used to direct call setup and control.

GKTMP was developed along with the gatekeeper application programming interface (API) to facilitate communication between the gatekeeper and an external application.

GKTMP is based on RAS and provides a set of messages that can be used to exchange information between the Cisco gatekeeper and an external application over a TCP connection.

Through the use of GKTMP and the gatekeeper API, organizations can add new functionality to the gatekeeper by using external applications. This can be done transparently to the H.323 gateways.

You can find more information about GKTMP and the gatekeeper API in the Cisco Gatekeeper External Interface Reference available at Cisco.com.

E 164 Number Resolution