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:

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

Категории