GKTMP is used for communications between GKs and external applications where added functions or services are required beyond the capabilities of the GK. GKTMP passes information between Cisco IOS GKs and the external application using ASCII response/request messages based on RAS by way of an application programming interface (API) or over TCP connections. This works in a straightforward manner. Some of the incoming requests for the GK are sent to the external application to fulfill the request. The GK has triggers configured for each external application it will use. These triggers are based on RAS tags and values. Incoming RAS messages are checked against the triggers. If the messages match a trigger, the GK then repackages the message and forwards it to the correct external application. When the external application is finished processing, the results are sent to the GK for further processing, and messages are sent to the requesting endpoint. The main point to remember here is that GKTMP and API are both used to provide this functionality. Your triggers can be manually configured or dynamically configured through API. Static triggers are configured via the command line, whereas dynamic triggers are configured via an external application.
All GKTMP messages are either requests or responses. The GK creates the request, and the external application sends the response.
Example . Example: Registration Request
message line message header 1 message header 2 message header 3 message body line 1 message body line 2 message body line 3 message body line 4
The message line states what kind of request is being sent.
The message header is a few lines that contain the external application name, GK name, and version ID. Format is field:value.
Blank space is probably used to help with problem resolution.
The message body contains the triggers. The message body is optional. Format is tag=value.
ACF (Admission Confirm)
ARJ (Admission Reject)
ARQ (Admission Request)
BCF (Bandwidth Confirm)
BRJ (Bandwidth Reject)
BRQ (Bandwidth Request)
DRQ (Disengage Request)
IRR (Information Request)
LCF (Location Confirm)
LRJ (Location Reject)
LRQ (Location Request)
RIP (Request In Progress)
RAI (Resource Availability Indication)
RCF (Registration Confirm)
RRJ (Registration Reject)
RRQ (Registration Request)
URQ (Unregistration Request)
Some messages are only sent as a response from the external application; they are ACF, ARJ, BCF, BRJ, RCF, and RRJ. The GK sends the following messages as requests: DRQ, RAI, and UQ. Also, the application server can use a command URQ to send untriggered, unsolicited URQs to unregister an endpoint from a GK.
Now that we have covered the basic and advanced GK functions, let’s turn to ways to keep your network resources available for users. Most networks contain some kind of redundancy and availability to cope with network or device failures. Gatekeepers are not immune to hardware or software failures, so alternative methods must be engineered. Here are a few ways to help with this task.
Gatekeeper clustering provides redundancy for zones in the event of a GK failure. This addition to H.323 allows multiple GKs to control a single zone. When the GK starts, each cluster member receives a GRQ from all the other members. The GRQ contains the alternate GK information. The GK opens TCP connections to all cluster members. Clusters can have up to five GKs per clusters. The clusters communicate with Gatekeeper Update Protocol (GUP). When a device registers with its GK, it is provided with two alternate GKs that can take over when the primary GK fails.
GUP is used to pass information between GKs in a cluster. The information included is available and used bandwidth, CPU utilization, GK memory, and the number of endpoints registered. The GK’s CPU utilization and memory are used for resource management. If the GK is overloaded, it asks the endpoint to use another GK with the lowest resources used. One of the important things to remember about clustering is that all GKs share registered endpoint information. Therefore, all GKs within the zone know about all endpoints within the cluster, which helps with LRQs.
GUP uses messages to help exchange control and management information within the cluster. Here are the messages and when they are used:
AnnouncementIndication—. Sent every 30 seconds by default, by all cluster members. The GK updates information on call capacity, CPU load, endpoint load, memory usage, number of active calls, and number of registered endpoints received from the sending GK.
AnnouncementReject—. Sent if a configuration mismatch exists. The GK will terminate the GUP connection with the sender.
RegistrationIndication—. Sent when a connection is made with a new alternate GK, or when a new endpoint registers.
UnregistrationIndication—. Sent when a GK is down or an endpoint is aged out, or when an endpoint unregisters.
ResourceIndication—. Sent when the GW sends the GK an RAI message.
[