Table Of Contents

GKTMP Messages

GKTMP RAS Messages

Message Line

Message Header

Message Body

Registration Messages

Request RRQ

Response RRQ

Response RCF

Response RRJ

Unregistration Message

Request URQ

Command URQ

Result URQ

Admission Messages

Request ARQ

Response ARQ

Response ACF

Response ARJ

Location Messages

Request LRQ

Response LRQ

Request LCF

Response LCF

Request LRJ

Response LRJ

Disengage Messages

Request DRQ

Resource Messages

Request RAI

Bandwidth Messages

Request BRQ

Response BRQ

Response BCF

Response BRJ

Progress Messages

Response RIP

Request IRR

Request ALV

Response ALV

Trigger Registration Messages

Message Line

Message Header

Message Body

Register RRQ and RAI

Register URQ

Register ARQ, DRQ, IRR, and BRQ

Register LRQ

Register LCF

Register LRJ

Additional Messages

alternateEndpoint

FeatureSet

GTD

ReRouteCount

RobustnessData

AlternateGK

FromReplyAddress

ServiceControlSession

Usage Information

UsageReporting Capability

CallCapacity

CarrierInfo

TrunkGroupInfo

Alias-Address

PerCallInfo

ReleaseCompleteCauseIE

RemoteZone

Transport-Address

ClearToken

CryptoToken

CallMode

GKTMP Messages

---

This chapter describes GKTMP messages and contains the following sections:

•GKTMP RAS Messages

•Trigger Registration Messages

The GKTMP messages are used for communication between the Cisco IOS Gatekeeper and the external application. There are two types of GKTMP messages:

•GKTMP RAS Messages—Used to exchange the contents RAS messages between the Cisco IOS Gatekeeper and the external application.

•Trigger Registration Messages—Used by the external application to indicate to the Cisco IOS Gatekeeper which RAS message should be forwarded.

GKTMP RAS Messages

The general format of all GKTMP RAS messages is as follows:

•Single message line

•One or more message header lines

•Blank line, which separates the message header from the message body

•Zero or more message body lines

Message Line

Each GKTMP RAS message is either a request or a response. Requests are generated by the Cisco IOS Gatekeeper and responses are generated by the external application.

The first line of each GKTMP RAS message sent by the Cisco IOS Gatekeeper uses the format:

REQUEST RAS_message_type

The first line of each GKTMP RAS message sent by the external application uses the format:

RESPONSE RAS_message_type

Possible RAS message types are as follows:

•RRQ—Registration request

•RCF—Registration confirm

•RRJ—Registration reject

•URQ—Unregistration request

•ARQ—Admission request

•ACF—Admission confirm

•ARJ—Admission reject

•LRQ—Location request

•LCF—Location confirm

•LRJ—Location reject

•RIP—Request in progress

•DRQ—Disengage request

•RAI—Resource availability information

•BRQ—Bandwidth request

•BCF—Bandwidth confirm

•BRJ—Bandwidth reject

•IRR—Information request

---

Note The Cisco IOS Gatekeeper does not generate GKTMP Request RRQ messages for lightweight RRQ messages, which are used by H.323 endpoints as a keep-alive mechanism to refresh existing registrations.

---

Message Header

The message line is immediately followed by the message header. Each message header contains a field name and a value, separated by a colon (field:value). Table 4-1 shows the possible fields:

Table 4-1 Message Header Fields

Field Names	Field Values
Version-Id	Version of the protocol that the sender is running. The version ID consists of a major number (gk_major) and a minor number (gk_minor). For example, version 1 is represented as 100.
From	String that identifies the originator of the message. For requests from the Cisco IOS Gatekeeper, this field contains the gatekeeper ID. For responses from the external application, this field contains the server ID.
To	String that identifies the receiver of the message. For requests from the Cisco IOS Gatekeeper, this field contains the server ID. For responses from the external application, this field contains the ID of the gatekeeper that initiated the request.
Content-Length	Number of octets contained in the message body. If the message body is null, this field can be omitted.
Transaction-Id	String that identifies the transaction. If this field is present in the request from the Cisco IOS Gatekeeper, it must be echoed in the response from the external application.
Notification-Only	None. No value is included after the colon. If this field name is present, it indicates to the external application no response should be sent. Request URQ must contain this field. Also, Request RRQ contains this field when that message is used to populate the external application's registration database.

The message header is followed immediately by a blank line.

Message Body

The message body follows the blank line. Each line in the message body contains a tag and a value, separated by an equal sign (tag=value). The tags are case-sensitive and denote an RAS message field. The possible tags depend on the GKTMP RAS message.

---

Note If the message body is null, the message must terminate with a CRFL after the message header.

---

In some cases, depending on the field type, the value is preceded a value-type identifier followed by a colon (tag=type:value).

Possible field types are as follows:

•Alias-Address—This type of field can contain a series of addresses separated by spaces. Each is preceded by a value-type identifier that indicates the type of address. H indicates that the address is an H.323 ID; E indicates that the address is an E.164 address; M indicates that the address is an e-mail ID.

•Transport-Address—This type of field contains an address. Currently, only one value-type identifier is possible for this field type. That is I, which indicates that the address is an IP version 4 address. The address is specified in dotted-decimal notation and can be followed by a colon and a port number.

•Endpoint-Type—This type of field indicates the type of endpoint. Possible values are: gatekeeper, terminal, mcu, proxy, voice-gateway, h320-gateway, and other-gateway.

•Supported-Prefix—This type of field indicates a supported technology prefix. Possible values are the digits 0 through 9 and the pound sign (#).

•Globally-Unique-Identifier (GUID)—This type of field contains the 16-octet conference ID or call ID that uniquely identifies the call or conference. The IDs are specified in hexadecimal format.

•Bandwidth—This type of field contains an unsigned integer from 0 through 4294967295 that indicates the bandwidth in 100 bits per second.

•Boolean—This type of field contains a single character. T or t for true; F or f for false.

•IA5 String—This type of field contains characters from the International Alphabet 5 (IA5), which is a character set defined by the ITU X.400 Message Handling System specification.

•cryptoToken—This type of field contains one of the cryptoToken types defined for the CryptoH323Token field specified in H.225. Currently, the only type of cryptoToken supported is the cryptoEPPwdHash.

•HASHED-EncodedPwdCertToken—This type of field contains a 16 octet IA5String. It represents the RAS Message Digest 5 (MD5) hashed encoded PwdCertToken.

•TimeStamp—This type of field contains a 32-bit integer that represents Universal Time Coordinated (UTC) time.

•OBJECT-IDENTIFIER—This type of field contains a sequence of non-negative integer values separated by dots, which is used to uniquely identify an object.

•UseSpecifiedTransport—This type of field contains a string that indicates the transport layer that is used for the signaling: Annex E/UDP or TCP.

•AlternateGK—This type of field contains a set of fields enclosed in braces ({ }). Each field is identified by a tag and separated from the other fields by SP (ASCII space, 0x20) characters. This field can contain more than one set of fields, each enclosed by braces.

•AlternateEndpoint—This type of field contains a set of fields enclosed in braces. Each field is identified by a tag and separated from the other fields by SP (ASCII space, 0x20) characters. A message body line containing an AlternateEndpoint field must pertain to a single endpoint. Multiple call signal addresses and tokens that pertain to the same endpoint can be provided in a single message body line. If there are multiple AlternateEndpoints, each pertaining to a different H.323 endpoint, the information about the alternate endpoints must be provided in separate message body lines.

•AlternateTransportAddress—This type of field contains a single sub-field enclosed in braces. The fields within the braces pertain to a single instance of a RAS AlternateTransportAddress structure. They are defined as a Transport-Address and are encoded as defined for the Transport-Address field.

•clearToken—This type of field contains a set of fields enclosed in braces. Each field is identified by a tag and separated from the other fields by SP (ASCII space, 0x20) characters. The fields within the braces pertain to a single instance of a RAS ClearToken structure. However, the message line of a clearToken field can contain multiple instances, each enclosed in braces and separated by a space character. The clearToken field can be embedded within an AlternateEndpoint field.

•remoteZone—This type of field contains a set of fields enclosed in braces. Each field is identified by a tag and separated from the other fields by SP (ASCII space, 0x20) characters. The fields within the braces pertain to a single instance of a remoteZone structure. However, the message line of a remoteZone field can contain multiple instances, each enclosed in braces and separated by a space character.

This section describes the possible fields for each message. When the external application sends a response, it includes only the fields that it has altered. Unaltered fields must not be included.

Registration Messages

Registration messages are used to control which H.323 endpoints are in the gatekeeper's zone.

This section describes the following:

•Request RRQ

•Response RRQ

•Response RCF

•Response RRJ

Request RRQ

This message is sent from the Cisco IOS Gatekeeper to the external application when an H.323 endpoint wants to join the zone. This message can be used to populate the external application's registration database. In this case, the request is sent as a notification only and no response is expected from the external application.

Table 4-2 shows the possible Request RRQ tags:

Table 4-2 Request RRQ Tags

Tag	Field Type	Mandatory or Optional	Corresponding RAS Message Field
c	Transport-Address	Mandatory	RRQ:callSignalAddress. See Transport-Address.
r	Transport-Address	Mandatory	RRQ:rasAddress. See Transport-Address.
a	Alias-Address	Optional	RRQ:terminalAlias
t	Endpoint-Type	Mandatory	RRQ:terminalType
p	Supported-Prefix	Optional	RRQ:terminalType:gateway:protocol:*:supportedPrefixes
$	cryptoToken	Optional	RRQ:cryptoTokens. See CryptoToken.
T	clearToken	Optional	RRQ:tokens. See ClearToken.
C	Boolean	Optional	RRQ:callCapacityReportingCapability
K	CallCapacity	Optional	RRQ:capacity. See CallCapacity.
U	UsageReportingCapability	Optional	RRQ:UsageReportingCapability. See UsageReporting Capability.
Y	RobustnessData	Optional	RRQ:RobustnessData1 . See RobustnessData.

1 RobustnessData type is added to support Annex R implementation. The gatekeeper encodes the RobustnessData (Rrq_RDNXR *) into the REQ-RRQ message body. For example, to encode a RRQ message with Robustness Data, hasRepository bit mask set, featureSet is Needed, and a backup CSA (IP): Y=s:t f:1 b:I:172.18.192.10:1719

Response RRQ

This message is sent from the external application to the Cisco IOS Gatekeeper in response to a Request RRQ message. If the external application has no interest in the Request RRQ message, it returns a Response RRQ with a null body. Otherwise, the external application modifies the fields as appropriate and sends the response with the updated information to the Cisco IOS Gatekeeper for further processing.

For Response RRQ, the possible tags are shown in Table 4-3:

Table 4-3 Response RRQ Tags

Tag	Field Type	Mandatory or Optional	Corresponding RAS Message Field
a	Alias-Address	Optional	RRQ:terminalAlias
p	Supported-Prefix	Optional	RRQ:terminalType:gateway:protocol: *:supportedPrefixes
F	Boolean	Optional	Do not propagate this message onward.

Response RCF

This message is sent from the external application to the Cisco IOS Gatekeeper in response to a Request RRQ. This message indicates that the external application has completed the processing of the request.

For Response RCF, the possible tags are shown in Table 4-4:

Table 4-4 Response RCF Tags

Tag	Field Type	Mandatory or Optional	Corresponding RAS Message Field
a	Alias-Address	Optional	RRQ:terminalAlias
p	Supported-Prefix	Optional	RRQ:terminalType:gateway:protocol: *:supportedPrefixes
G	AlternateGK	Optional	RCF:alternateGatekeeper. See AlternateGK.

Response RRJ

This message is sent from the external application to the Cisco IOS Gatekeeper in response to a Request RRQ. It indicates that the Cisco IOS Gatekeeper should reject the request for the specified reason.

For Response RRJ, the possible tag is shown in Table 4-5:

Table 4-5 Response RRJ Tag

Tag	Field Type	Mandatory or Optional	Corresponding RAS Message Field
R	RRJ-Reason	Mandatory	RRJ:rejectReason

Possible values for the rejectReason are:

•undefinedReason

•securityDenial

•resourceUnavailable

•discoveryRequired

•invalidRevision

•invalidCallSignalAddress

•invalidRASAddress

•duplicateAlias

•invalidTerminalType

•transportNotSupported

•transportQOSNotSupported

•invalidAlias

•fullRegistrationRequired

•additiveRegistrationNotSupported

•invalidTerminalAlias

•genericDataReason

Unregistration Message

Unregistration messages are used to remove an H.323 endpoint from a gatekeeper zone.

This section describes the following:

•Request URQ

•Command URQ

•Result URQ

Request URQ

This message is sent from the Cisco IOS Gatekeeper to the external application when the H.323 endpoint wants to leave the zone or when its registration expires. This request is sent as a notification only. No response is generated by the external application.

For Request URQ, the possible tag is shown in Table 4-6:

Table 4-6 Request URQ

Tag	Field Type	Mandatory or Optional	Corresponding RAS Message Field
c	Transport-Address	Mandatory	URQ:callSignalAddress. See Transport-Address.

Command URQ

The Command URQ message is sent from the application server to the gatekeeper at any time to unregister an endpoint. The gatekeeper sends a URQ message to the endpoint and removes it from its registration database. The endpoint is identified by its call signaling address (IP address and port). The server can also specify an optional reason and alternate gatekeeper information.

Table 4-7 shows the new Command URQ tags:

Table 4-7 New Command URQ Tags

Tag	Field Type	Mandatory or Optional	Corresponding RAS Message Field
c	Transport-Address	Mandatory	URQ:callSignalAddress. See Transport-Address.
R	URQ-Reason	Optional	URQ:reason
G	AlternateGK	Optional	URQ:alternateGatekeeper. See AlternateGK.

Possible values for the reason are:

•reregistrationRequired

•ttlExpired

•securityDenial

•undefinedReason

Result URQ

The Result URQ message is sent from the gatekeeper to the application server to report the result of a Command URQ transaction as long as the command did not specify Notification-Only: in the message header. The endpoint is identified by its call signaling address (IP address and port).

If the endpoint was found and unregistered, the message header indicates Status: success. Otherwise it indicates Status: invalidGKID or Status: invalidEndpoint.

---

Note Success just means that a URQ message was sent to the endpoint and that it was removed from the gatekeeper registration database without error. It does not mean that a UCF message was received from the endpoint. The gatekeeper does not wait to receive a UCF message before sending the Result URQ message to the server.

---

Table 4-8 shows the new Result URQ tags:

Table 4-8 New Result URQ Tags

Tag	Field Type	Mandatory or Optional	Corresponding RAS Message Field
c	Transport-Address	Mandatory	URQ:callSignalAddress. See Transport-Address.

Admission Messages

Admission messages are used to control which H.323 endpoints can participate in calls.

This section describes the following:

•Request ARQ

•Response ARQ

•Response ACF

•Response ARJ

Request ARQ

This message is sent from the Cisco IOS Gatekeeper to the external application when an H.323 endpoint wants to initiate a call.

For Request ARQ, the possible tags are shown in Table 4-9:

Table 4-9 Request ARQ 

Tag	Field Type	Mandatory or Optional	Corresponding RAS Message Field
s	Alias-Address	Mandatory	ARQ:srcInfo
S	Transport-Address	Optional	ARQ:srcCallSignalAddress. See Transport-Address.
d	Alias-Address	Optional	ARQ:destinationInfo
D	Transport-Address	Optional	ARQ:destCallSignalAddress. See Transport-Address.
x	Alias-Address	Optional	ARQ:destExtraCallInfo
b	Bandwidth	Mandatory	ARQ:bandWidth
A	Boolean	Mandatory	ARQ:answerCall
c	GUID	Optional	ARQ:callIdentifier
C	GUID	Mandatory	ARQ:conferenceID
m	Boolean	Optional	ARQ:canMapAlias
e	IA5String	Optional	ARQ:nonStandardData:redirectNumber
E	integer	Optional	ARQ:nonStandardData:redirectReason1
p	integer	Optional	ARQ:nonStandardData:callingPartyNumOctet3a2
w	IA5string	Optional	ARQ:nonStandardData:displayIE
i	TransportAddress	Mandatory	arqing-endpoint identifier3
$	cryptoToken	Optional	ARQ:cryptoTokens. See CryptoToken.
T	clearToken	Optional	ARQ:tokens. See ClearToken.
B	IA5string	Optional	ARQ:nonStandardData:interfaceSpecific:BillingInfo
g	GTD	Optional	ARQ:nonStandardData:gtd. See GTD.
I	IA5String	Optional	ARQ:nonStandardData:interfaceDescriptor
J	IA5String	Optional	ARQ:circuitInfo:destinationCircuitID:group1
K	callCapacity	Optional	ARQ:capacity. See CallCapacity.
L	IA5String	Optional	ARQ:circuitInfo:sourceCircuitID:group1
P	IA5String	Optional	ARQ:circuitInfo:sourceCircuitID:group1
Q	IA5String	Optional	ARQ:circuitInfo:destinationCircuitID:group1
U	IA5String	Optional	ARQ:tokens:cisco_IZCT_OID:IZCToken:izctSrcZone2
W	IA5String	Optional	ARQ:tokens:cisco_IZCT_OID:IZCToken:izctDstZone
V	Integer	Optional	ARQ:nonStandardInfo:reRouteCount2. See ReRouteCount.
v	IA5 String	Optional	ARQ:nonStandardInfo:terminationCause: releaseCompleteCauseIE. See ReleaseCompleteCauseIE.
r	Integer	Optional	ARQ:nonStandardInfo:terminationCause:releaseCompleteReason
f	FeatureSet	Optional	ARQ:featureSet. See FeatureSet.

1 Tags `P' and `L' map to the same RAS message field (sourceCircuitID:group) while tags `J' and `Q' map to the same RAS message field (destinationCircuitID:group). This is because the ITU H.225.0v4 specification does not have separate trunk group and carrier ID RAS message fields defined. Tags `P' and `Q' in GKTMP represent the trunk group usage and tags `L' and `J' in GKTMP represent the carrier ID usage. This release of GKTMP treats carrier IDs and trunk-groups identically, leaving the proper reporting of incoming circuits and selection of outgoing circuits up to the endpoints. 2 Tags `U' and `V' are used to pass IZCT source and destination zone information to a GKTMP application server.

Possible values for the redirectReason are:

•0—Unknown

•1—Call forwarding busy or called DTE busy

•2—Call forwarded, no reply

•4—Call deflection

•9—Called DTE out of order

•10—Call forwarding by the called DTE

•15—Call forwarding unconditional or systematic call redirection

CallingPartyNumOctet3a is from the Q.931 Setup octet 3a of calling party number.

When an H.323 endpoint sends an ARQ to the Cisco IOS Gatekeeper, it includes its endpointIdentifier. Because this value is local and has meaning to the Cisco IOS Gatekeeper only and not to the external application, the Cisco IOS Gatekeeper substitutes a more meaningful value of CallSignalAddress in its Request ARQ messages.

Response ARQ

This message is sent from the external application to the Cisco IOS Gatekeeper in response to a Request ARQ message. If the external application has no interest in the Request ARQ message, it returns a Response ARQ with a null body. Otherwise, it modifies the fields as appropriate and sends the response with the updated information to the Cisco IOS Gatekeeper for further processing.

For Response ARQ, the possible tags are shown in Table 4-10:

Table 4-10 Response ARQ 

Tag	Field Type	Mandatory or Optional	Corresponding RAS Message Field
d	Alias-Address	Optional	ARQ:destinationInfo
D	Transport-Address	Optional	ARQ:destCallSignalAddress. See Transport-Address.
x	Alias-Address	Optional	ARQ:destExtraCallInfo
b	Bandwidth	Optional	ARQ:bandWidth
e	IA5String	Optional	ARQ:nonStandardData:redirectNumber
E	integer	Optional	ARQ:nonStandardData:redirectReason
w	IA5string	Optional	ARQ:nonStandardData:displayIE
z	remoteZone	Optional	None. See RemoteZone.
T	clearToken	Optional	ARQ:tokens. See ClearToken.
c	integer	Optional	None1
p	integer	Optional	None2
A	alternateEndpoint	Optional	ARQ:alternateEndpoints. See alternateEndpoint.
g	GTD	Optional	ARQ:nonStandardData:gtd. See GTD.
I	IA5String	Optional	ARQ:circuitInfo:sourceCircuitID:group
J	carrierInfo	Optional	See CarrierInfo.
F	Boolean	Optional	Do not propagate this message onward.
s	Alias-Address	Optional	ARQ:srcInfo. See Alias-Address.
P	IA5String	Optional	ARQ:circuitInfo:sourceCircuitID:group
Q	trunkGroupInfo	Optional	See TrunkGroupInfo.
y	ServiceControlSession	Optional	ACF:ServiceControlSession. See ServiceControlSession.
f	FeatureSet	Optional	ARQ:featureSet. See FeatureSet.

1 Reflects the cost value of the primary endpoint, if any, whose address is returned in the `D' field of this message. It should only be sent if the endpoint is filled in. 2 Reflects the priority value of the primary endpoint, if any whose address is returned in the `D' field of this message. It should only be sent if the endpoint is filled in.

The external application has the option of reducing the bandwidth.

If this field is included, the Cisco IOS Gatekeeper sends LRQs to all the listed zones. The zone with the least cost and highest priority that returns and LCF is chosen for inclusion in the ACF that is sent to the endpoint.

Response ACF

This message is sent from the external application to the Cisco IOS Gatekeeper in response to a Request ARQ. The message indicates that the external application has completed the processing of the request.

For Response ACF, the possible tags are shown in Table 4-11:

Table 4-11 Response ACF 

Tag	Field Type	Mandatory or Optional	Corresponding RAS Message Field
d	Alias-Address	Optional	ACF:destinationInfo
D	Transport-Address	Mandatory	ACF:destCallSignalAddress. See Transport-Address.
x	Alias-Address	Optional	ACF:destExtraCallInfo
X	Alias-Address	Optional	ACF:remoteExtensionAddress
b	Bandwidth	Optional	ARQ:bandWidth
t	Endpoint-type	Optional	ACF:destinationType
T	ClearToken	Optional	ACF:tokens. See ClearToken.
A	AlternateEndpoint	Optional	ACF:alternateEndpoints. See alternateEndpoint.
N	AlternateTransportAddr	Optional	ACF:alternateTransportAddress
u	useSpecifiedTransport	Optional	ACF:useSpecifiedAddress. SeeMessage Body.
g	GTD	Optional	ACF:nonStandardData:gtd:gtdData. See GTD.
s	Service-Descriptor	Optional	ACF:nonStandardData:serviceDescriptor
y	ServiceControlSession	Optional	ACF:ServiceControlSession. See ServiceControlSession.
J	carrierInfo	Optional	See CarrierInfo.
Q	trunkGroupInfo	Optional	See TrunkGroupInfo.
f	FeatureSet	Optional	ARQ:featureSet. See FeatureSet.

If the message contains an AlternateTransportAddr field, the additional field shown in Table 4-12 is included:

Table 4-12 Additional Field

Tag	Field Type	Mandatory or Optional	Corresponding RAS Message Field
I	Transport-Address	Mandatory	IP address and port for Annex E. See Transport-Address.

Response ARJ

This message is sent from the external application to the Cisco IOS Gatekeeper in response to a Request ARQ. The message indicates that the Cisco IOS Gatekeeper should reject the request for the specified reason.

For Response ARJ, the possible tag is shown in Table 4-13:

Table 4-13 Response ARJ

Tag	Field Type	Mandatory or Optional	Corresponding RAS Message Field
R	ARJ-Reason	Mandatory	ARJ:rejectReason
y	ServiceControlSession	Optional	ACF:ServiceControlSession. See ServiceControlSession.
v	IA5String	Optional	ARJ:terminationCause:releaseCompleteCauseIE.1 See ReleaseCompleteCauseIE.

1 This field is included if the GKTMP server wishes to provide a Q.850 cause code that it wants to be used to release the call.

Possible values for rejectReason are:

•calledPartyNotRegistered

•invalidPermission

•requestDenied

•undefinedReason

•resourceUnavailable

•securityDenial

•carrierIdUnspecified (maps to undefinedReason)

•carrierIdUnknown (maps to undefinedReason)

•ingressCarrierInactive (maps to undefinedReason)

•carrierOrigPcntExceeded (maps to undefinedReason)

•carrierMaxUnitsExceeded (maps to undefinedReason)

•destinationUnknown (maps to undefinedReason)

•noRouteAvailable (maps to undefinedReason)

•callerNotRegistered

•routeCallToGatekeeper

•invalidEndpointID

•qosControlNotSupported

•incompleteAddress

•aliasesInconsistent

•routeCallToSCN

•exceedsCallCapacity

•collectDestination

•collectPin

•genericDataReason

•neededFeatureNotSupported

Location Messages

Location messages are used by gatekeepers to communicate with each other to process interzone calls.

This section describes the following:

•Request LRQ

•Response LRQ

•Response LCF

•Request LRJ

•Response LRJ

Request LRQ

This message is sent from the Cisco IOS Gatekeeper to the external application when the Cisco IOS Gatekeeper has received an interzone location request.

For Request LRQ, the possible tags are shown in Table 4-14:

Table 4-14 Request LRQ 

Tag	Field Type	Mandatory or Optional	Corresponding RAS Message Field
s	Alias-Address	Optional	LRQ:srcInfo
d	Alias-Address	Mandatory	LRQ:destinationInfo
e	IA5String	Optional	LRQ:nonStandardData:redirectNumber
E	integer	Optional	LRQ:nonStandardData:redirectReason1
p	integer	Optional	LRQ:nonStandardData:callingPartyNumOctet3a2
w	IA5String	Optional	LRQ:nonStandardData:displayIE
c	IA5String	Optional	LRQ:nonStandardData:callingPartyNum
T	clearToken	Optional	LRQ:tokens. See ClearToken.
g	GTD	Optional	LRQ:nonStandardData:gtd. See GTD.
I	IA5String	Optional	LRQ:nonStandardData:interfaceDescriptor
J	IA5String	Optional	LRQ:circuitInfo:destinationCircuitID:group
L	IA5String	Optional	LRQ:circuitInfo:sourceCarrierID:group
b	Integer	Optional	LRQ:nonStandardData:bandwidth
C	IA5String	Optional	LRQ:nonStandardData:callIdentifier
P	IA5String	Optional	LRQ:circuitInfo:sourceCircuitID:group
Q	IA5String	Optional	LRQ:circuitInfo:destinationCircuitID:group
S	IA5String	Optional	LRQ:tokens:cisco_IZCT_OID:IZCTToken:izctSrctZone
D	IA5String	Optional	LRQ:tokens:cisco_IZCT_OID:IZCTToken:izctDstZone
i	FromReplyAddress	Optional	See FromReplyAddress.
V	Integer	Optional	ARQ:nonStandardInfo:reRouteCount. See ReRouteCount.
v	IA5 String	Optional	ARQ:nonStandardInfo:terminationCause: releaseCompleteCauseIE
r	Integer	Optional	ARQ:nonStandardInfo:terminationCause: releaseCompleteReason
f	FeatureSet	Optional	LRQ:featureSet. See FeatureSet.

Possible values for the redirectReason are:

•0—Unknown

•1—Call forwarding busy or called DTE busy

•2—Call forwarded, no reply

•4—Call deflection

•9—Called DTE out of order

•10—Call forwarding by the called DTE

•15—Call forwarding unconditional or systematic call redirection

CallingPartyNumOctet3a is from the Q.931 Setup octet 3a of calling party number.

Response LRQ

This message is sent from the external application to the Cisco IOS Gatekeeper in response to a Request LRQ message. If the external application has no interest in the Request LRQ message, it returns a Response LRQ with a null body. Otherwise, it modifies the fields as appropriate and sends the response with the updated information to the Cisco IOS Gatekeeper for further processing.

Provisional LCF in Response LRQ

The Provisional LCF in Response LRQ feature is invoked when the `D' and `r' tags are present in the Response LRQ message. These tags carry the call signaling and RAS addresses of the provisional (primary) endpoint in the Provisional LCF. The provisional endpoint is defined as the endpoint whose transport address is carried in the `D' tag, and is sent in a LCF message if no other endpoint is found locally, or at any of the remote Cisco IOS gatekeepers.

The `D' and `r' tags are used only if a primary endpoint is not found locally or at any of the remote Cisco IOS gatekeepers. If a primary endpoint is not found, the provisional endpoint becomes the primary endpoint. However, if a primary endpoint is found, the provisional endpoint is designated as an alternate endpoint that is ranked above an alternate endpoint in an `A' tag.

The provisional endpoint is sent in a LCF message if the Provisional LCF in a Response LRQ feature is invoked, and all remote Cisco IOS gatekeepers with LRQs forwarded to them, either fail to respond or respond with LRJs.

The provisional endpoint is also sent in a LCF message if a remote Cisco IOS gatekeeper is unavailable, or has not been configured, and a search of the local database by the gatekeeper does not result in any endpoints satisfying the LRQ.

The DNIS information for the provisional endpoint can be replaced with the `d' tag. The destination carrier name of the provisional endpoint can be replaced with the first `J' tag that is not attached to a remote gatekeeper.

The `c' and `p' tags specify, respectively, the cost and priority values of the provisional endpoint. The default value for both tags is 50. The designated values for these must not rank the provisional endpoint lower than any alternate endpoint in the `A' tag in the Response LRQ. A violation of this condition results in the Cisco IOS gatekeeper overriding the designated values and replacing them with values of the highest ranked alternate endpoint in the `A' tag.

If an endpoint other than the provisional endpoint satisfies a LRQ, the message is processed with a list of alternate endpoints, arranged by their costs and priorites provided by the GKTMP server. The provisional endpoint is at the top of the list.

For Response LRQ, the possible tags are shown in Table 4-15:

Table 4-15 Response LRQ 

Tag	Field Type	Mandatory or Optional	Corresponding RAS Message Field
d	Alias-Address	Optional	LRQ:destinationInfo
z	remoteZone	Optional	None. See RemoteZone.
T	clearToken	Optional	ARQ:tokens. See ClearToken.
c	integer	Optional	None1
p	integer	Optional	None2
A	alternateEndpoint	Optional	ARQ:alternateEndpoints. See alternateEndpoint.
g	GTD	Optional	LRQ:nonStandardData:gtd. See GTD.
I	IA5String	Optional	LRQ:circuitInfo:sourceCircuitID:group3
J	carrierInfo	Optional	See CarrierInfo.3
F	Boolean	Optional	Do not propagate this message onward.
s	Alias-Address	Optional	LRQ:srcInfo. See Alias-Address.
Q	trunkGroupInfo	Optional	See TrunkGroupInfo.3
P	IA5String	Optional	LRQ:circuitInfo:sourceCircuitID:group3
f	FeatureSet	Optional	LRQ:featureSet. See FeatureSet.
D	Transport-Address	Optional	LCF:callSignalAddress4
r	Transport-Address	Optional	LCF:rasAddress4

1 Reflects the cost value of the primary endpoint, if any, whose address is returned in the `D' field of this message. It should only be sent if the endpoint is filled in. 2 Reflects the priority value of the primary endpoint, if any whose address is returned in the `D' field of this message. It should only be sent if the endpoint is filled in. 3 Tags `P' and `I' map to the same RAS message field (sourceCircuitID:group). This is because the ITU H.225.0v4 specification does not have separate trunk group and carrier ID RAS message fields defined. Tags `P' and `Q' in GKTMP represent the trunk group usage and tags `I' and `J' in GKTMP represent the carrier ID usage. 4 The `r' tag is mandatory if the `D' tag is present.

If an endpoint is identified with a LCF received by the Cisco IOS gatekeeper, that gatekeeper consolidates and arranges all the alternate endpoints in an outgoing LCF, and may also replace the primary endpoint of its received LCF with the highest ranked alternate endpoint.

Request LCF

This message is sent from the Cisco IOS Gatekeeper to the external application when the Cisco IOS Gatekeeper has received an LCF from the remote Cisco IOS Gatekeeper. This gives the external application an opportunity to accept (Response LCF), modify (Response LCF), or reject (Response LRJ) the information contained in the LCF.

For Request LCF, the possible tags are shown in Table 4-16:

Table 4-16 Request LCF

Tag	Field Type	Mandatory or Optional	Corresponding RAS Message Field
s	Alias-Address	Optional	LRQ:srcInfo
e	IA5String	Optional	LRQ:nonStandardData:redirectNumber
E	integer	Optional	LRQ:nonStandardData:redirectReason
p	integer	Optional	LRQ:nonStandardData:callingPartyNumOctet3a
w	IA5String	Optional	LRQ:nonStandardData:displayIE
c	IA5String	Optional	LRQ:nonStandardData:callingPartyNum
d	Alias-Address	Mandatory	LRQ/LCF:destinationInfo
D	Transport-Address	Mandatory	LCF:callSignalAddress. See Transport-Address.
r	Transport-Address	Mandatory	LCF:rasAddress. See Transport-Address.
x	Alias-Address	Optional	LCF:destExtraCallInfo
X	Alias-Address	Optional	LCF:remoteExtensionAddress
t	Endpoint-Type	Optional	LCF:destinationType
N	AlternateTransportAddr	Optional	LCF:AlternateTransportAddress
u	useSpecifiedTransport	Optional	ACF:useSpecifiedAddress
T	clearToken	Optional	LCF:tokens. See ClearToken.
g	GTD	Optional	LCF:nonStandardData:gtd:gtdData. See GTD.
y	ServiceControlSession	Optional	LCF:ServiceControlSession. See ServiceControlSession.
C	IA5String	Optional	ARQ:callIdentifier
f	FeatureSet	Optional	LCF:featureSet. See FeatureSet.

The destinationInfo from the LCF is used if one is available. Otherwise, the destinationInfo from the LRQ is used.

If the message contains an AlternateTransportAddr field, the following additional field shown in Table 4-17 is included:

Table 4-17 Additional Field

Tag	Field Type	Mandatory or Optional	Corresponding RAS Message Field
I	Transport-Address	Mandatory	IP address and port for Annex E. See Transport-Address.

Response LCF

This message is sent from the external application to the Cisco IOS Gatekeeper in response to a Request LRQ. The message indicates that the external application has completed the processing of the request.

This message can also be sent to the Cisco IOS Gatekeeper from the external application in response to a Request LCF or a Request LRJ. In the case of a Request LCF, the response can contain:

•A null message body, which indicates that the external application accepts the information in the Request LCF.

•Modified fields, which indicates that the external application wants to use different values than those included in the Request LCF.

In the case of a Request LRJ, the response contains an alternate destination.

For Response LCF, the possible tags are shown in Table 4-18:

Table 4-18 Response LCF

Tag	Field Type	Mandatory or Optional	Corresponding RAS Message Field
d	Alias-Address	Optional	LCF:destinationInfo
D	Transport-Address	Mandatory	LCF:destCallSignalAddress. See Transport-Address.
r	Transport-Address	Mandatory	LCF:rasAddress. See Transport-Address.
x	Alias-Address	Optional	LCF:destExtraCallInfo
X	Alias-Address	Optional	LCF:remoteExtensionAddress
t	Endpoint-Type	Optional	LCF:destinationType
A	AlternateEndpoint	Optional	ACF:alternateEndpoints. See alternateEndpoint.
N	AlternateTransportAddr	Optional	LCF:AlternateTransportAddress
u	useSpecifiedTransport	Optional	ACF:useSpecifiedAddress
T	clearToken	Optional	LCF:tokens. See ClearToken.
g	GTD	Optional	LCF:nonStandardData:gtd:gtdData. See GTD.
s	Service-Descriptor	Optional	LCF:nonStandardData:serviceDescriptor
y	ServiceControlSession	Optional	ACF:ServiceControlSession. See ServiceControlSession.
J	carrierInfo	Optional	See CarrierInfo.
Q	trunkGroupInfo	Optional	See TrunkGroupInfo.
f	FeatureSet	Optional	LCF:featureSet. See FeatureSet.
S	Suppress Alternate Endpoints	Optional	ACF:alternateEndpoints

The route server (RS) can send a suppress (S) tag to suppress the alternate endpoints that are sent in the outgoing ACF to the originating gateway (OGW). An example follows:

RESPONSE LCF

Version-id: 403

From: ani

To: zone1

Transaction-Id: 629EEDCC0000000A

Content-Length: 9

S=A:{ }

S -> Suppress Flag.

A -> Suppress sending of alternate endpoints in the outgoing ACF.

The suppress flag should be sent only in Response LCF if the RS receives a Request LC. The suppress flag should not be sent if the RS receives a Request LRQ.

The D and r are not required if the Response LCF is being sent in reply to a Request LCF. If the message contains an AlternateTransportAddr field, the additional field shown in Table 4-19 included:

Table 4-19 Additional Field

Tag	Field Type	Mandatory or Optional	Corresponding RAS Message Field
I	Transport-Address	Mandatory	IP address and port for Annex E. See Transport-Address.

Request LRJ

This message is sent from the Cisco IOS Gatekeeper to the external application when the Cisco IOS Gatekeeper has received an LRJ from a remote Cisco IOS Gatekeeper. This gives the Cisco IOS Gatekeeper the opportunity to accept the rejection (Response LRJ) or propose an alternative destination (Response LCF).

For Request LRJ, the possible tags are shown in Table 4-20:

Table 4-20 Request LRJ

Tag	Field Type	Mandatory or Optional	Corresponding RAS Message Field
s	Alias-Address	Optional	LRQ:srcInfo
d	Alias-Address	Mandatory	LRQ:destinationInfo
e	IA5String	Optional	LRQ:nonStandardData:redirectNumber
E	integer	Optional	LRQ:nonStandardData:redirectReason
p	integer	Optional	LRQ:nonStandardData:callingPartyNumOctet3a
w	IA5String	Optional	LRQ:nonStandardData:displayIE
c	IA5String	Optional	LRQ:nonStandardData:callingPartyNum
R	LRJ-reason	Mandatory	LRJ:rejectReason
y	ServiceControl Session	Optional
C	IA5String	Optional	ARQ:callIdentifier
v	IA5String	Optional	LRJ:terminationCause:releaseCompleteCauseIE1 . See ReleaseCompleteCauseIE.

1 This field is included if the GKTMP server wishes to provide a Q.850 cause code that it wants to be used to release the call.

Response LRJ

This message is sent from the external application to the Cisco IOS Gatekeeper in response to a Request LRQ. The message indicates that the Cisco IOS Gatekeeper should reject the request for the specified reason.

This message can also be sent to the Cisco IOS Gatekeeper from the external application in response to a Request LCF or a Request LRJ. In the case of a Request LCF, this response rejects the information provided in the LCF for the specified reason. In the case of a Request LRJ, this response acknowledges the rejection. The reason is optional when the Response LRJ is sent due to a Request LRJ.

For Response LRJ, the possible tag is shown in Table 4-21:

Table 4-21 Response LRJ

Tag	Field Type	Mandatory or Optional	Corresponding RAS Message Field
n	Boolean	Optional	LRJ:nomoreRetry
R	LRJ-Reason	Mandatory (LRQ, LCF) Optional (LRJ)	LRJ:rejectReason
y	ServiceControlSession	Optional	ACF:ServiceControlSession
v	IA5String	Optional	LRJ:terminationCause:releaseCompleteCauseIE1 . See ReleaseCompleteCauseIE.

1 This field is included if the GKTMP server wishes to provide a Q.850 cause code that it wants to be used to release the call.

Possible values for rejectReason are:

•notRegistered

•invalidPermission

•requestDenied

•undefinedReason

•securityDenial

•carrierIdUnspecified (maps to undefinedReason)

•carrierIdUnknown (maps to undefinedReason)

•ingressCarrierInactive (maps to undefinedReason)

•carrierOrigPcntExceeded (maps to undefinedReason)

•carrierMaxUnitsExceeded (maps to undefinedReason)

•destinationUnknown (maps to undefinedReason)

•noRouteAvailable (maps to undefinedReason)

•aliasesInconsistent

•routeCallToSCN

•resourcesUnavailable

•genericDataReason

•neededFeatureNotSupported

•hopcountExceeded

•incompleteAddress

The n tag is an optional boolean field. It is sent in the Response LRJ message that is generated in response to a Request LRQ message. It has a default value of false if it is not present in the Response LRJ message.

Disengage Messages

Disengage messages are used to indicate that a party wants to end the call.

Request DRQ

This message is sent from the Cisco IOS Gatekeeper to the external application to indicate that an endpoint wants to end the call.

For Request DRQ, the possible tags are shown in Table 4-22:

Table 4-22 Request DRQ

Tag	Field Type	Mandatory or Optional	Corresponding RAS Message Field
c	GUID	Optional	DRQ:callIdentifier
C	GUID	Mandatory	DRQ:conferenceID
R	DRQ-reason	Mandatory	DRQ:disengageReason
A	Boolean	Mandatory	DRQ:answeredCall
S	Transport-Address	Mandatory	ARQ:srcCallSignalAddress. See Transport-Address.
T	clearToken	Optional	DRQ:tokens. See ClearToken.
g	GTD	Optional	DRQ:gtd. See GTD.
K	callCapacity	Optional	DRQ:capacity. See CallCapacity.
v	IA5String	Optional	DRQ:terminationCause:releaseCompleteCauseIE. See ReleaseCompleteCauseIE.
r	IA5String	Optional	DRQ:terminationCause:releaseCompleteReason
I	UsageInformation	Optional	DRQ:usageInformation. See Usage Information.

Possible values for the DRQ-reason are:

•forcedDrop

•normalDrop

•undefinedReason

---

Note All Request DRQ messages must contain Notification-only in the header. No response to this message is sent.

---

Resource Messages

Resource messages are used to indicate the current call capacity of the gateway.

Request RAI

This message is sent from the Cisco IOS Gatekeeper to the external application to indicate the call capacity and data rate of the gateway for H.323 calls.

For Request RAI, the possible tags are shown in Table 4-23:

Table 4-23 Request RAI

Tag	Field Type	Mandatory or Optional	Corresponding RAS Message Field
c	Transport-Address	Mandatory	RRQ:callSignalAddress. See Transport-Address.
r	Boolean	Mandatory	RAI:almostOutOfResources
K	callCapacity	Optional	RAI:capacity. See CallCapacity.

---

Note All Request RAI messages must contain Notification-only in the header. No response to this message is sent.

---

Bandwidth Messages

Bandwidth messages are used to request a change in bandwidth.

This section describes the following:

•Request BRQ

•Response BCF

•Response BRJ

Request BRQ

This message is sent from the Cisco IOS Gatekeeper to the external application to request that an endpoint be allowed to change (increase or decrease) its bandwidth.

For Request BRQ, the possible tags are shown in Table 4-24:

Table 4-24 Request BRQ 

Tag	Field Type	Mandatory or Optional	Corresponding RAS Message Field
i	Transport-Address	Mandatory	See Note. See Transport-Address.
b	Bandwidth	Mandatory	BRQ:bandWidth
C	GUID	Mandatory	BRQ:conferenceID
c	GUID	Mandatory	BRQ:callIdentifier
A	Boolean	Mandatory	BRQ:answeredCall

---

Note When sending a BRQ message, an endpoint identifies itself to the gatekeeper using the endpointIdentifier that it received from the gatekeeper in the RCF. Because this endpointIdentifier has only local significance to the gatekeeper and no significance to the server, the endpoint's CallSignalAddress is used here as an identifier.

---

Response BRQ

The server may modify the fields shown in Table 4-25 in the BRQ.

Table 4-25 Response BRQ

Tag	Field Type	Mandatory or Optional	Corresponding RAS Message Field
b	Bandwidth	Optional	BRQ:bandWidth
F	Boolean	Optional	None

Response BCF

This message is sent from the external application to the Cisco IOS Gatekeeper to confirm the request to allow an endpoint to change (increase or decrease) its bandwidth. This response gives the external application the opportunity to modify the Bandwidth field of a received LCF, but because the Cisco IOS Gatekeeper is not prepared to make changes in its bandwidth, any change in the BCF will automatically generate a BRJ back to the endpoint.

For Response BCF, the possible tag is shown in Table 4-26:

Table 4-26 Response BCF

Tag	Field Type	Mandatory or Optional	Corresponding RAS Message Field
b	Bandwidth	Mandatory	BCF:bandWidth

Response BRJ

This message is sent from the external application the Cisco IOS Gatekeeper to deny the request to allow an endpoint to change (increase or decrease) its bandwidth.

For Response BRJ, the possible tag is shown in Table 4-27:

Table 4-27 Response BRJ

Tag	Field Type	Mandatory or Optional	Corresponding RAS Message Field
R	BRJ-Reason	Mandatory	BRJ:rejectReason

Possible values for rejectReason are:

•notBound

•invalidConferenceID

•invalidPermission

•insufficientResource

•invalidRevision

•undefinedReason

•securityDenial

Progress Messages

Progress messages provide information about the progress of a request. Progress messages include:

•Response RIP

•Request IRR

•Request ALV

•Response ALV

Response RIP

This message is sent from the external application to the Cisco IOS Gatekeeper when the external application cannot immediately process the request. This message indicates that the request is in progress (RIP) and that additional time is needed. When the Cisco IOS Gatekeeper receives this message, it forwards a request to the H.323 endpoint indicating that an extension of the timeout is required. The external application can send more that one Response RIP as is needed to process the request.

For Response RIP, the possible tag is shown in Table 4-28:

Table 4-28 Response RIP

Tag	Field Type	Mandatory or Optional	Corresponding RAS Message Field
d	Integer	Mandatory	RIP:delay

Possible values of the delay are 1 through 65535 milliseconds.

Request IRR

This message is sent to the GK and contains details for the call after a successful connect. A Request IRR message is sent at both the originating and terminating side of the call. If both legs reference the same GK, only one Request IRR is sent. The GK sends information for only one call in each Request IRR message.

Table 4-29 shows the new Request IRR tags:

Table 4-29 New Request IRR Tags

Tag	Field Type	Mandatory or Optional	Corresponding RAS Message Field
S	Transport-Address	Mandatory	IRR:srcCallSignalAddress. See Transport-Address.
P	PerCallInfo	Optional	IRR:perCallInfo. See PerCallInfo.
K	callCapacity	Optional	IRR:capacity. See CallCapacity.

Request ALV

The REQUEST ALV is sent from the Gatekeeper to a GKTMP server on the detection of slower response or server failure.

This message does not contain any parameters in its body.

Response ALV

This message is returned in response to a REQUEST ALV message and does not contain any parameters in its body.

Trigger Registration Messages

Trigger registration messages are used by external applications to inform the Cisco IOS Gatekeeper which RAS messages are interesting to the external application. Interesting RAS messages trip a trigger in the Cisco IOS Gatekeeper and cause the Cisco IOS Gatekeeper to send a GKTMP RAS message to the external application.

As with the GKTMP RAS messages, trigger registration messages have the following format:

•Single message line

•One or more message header lines

•Blank line, which separates the message header from the message body

•Zero or more message body lines

Message Line

There are two types of trigger registration messages: register and unregister.

The first line of each trigger registration request/response message uses the format:

REGISTER RAS_message_type

The first line of each trigger unregistration request/response message uses the format:

UNREGISTER RAS_message_type

Possible RAS message types are as follows:

•RRQ—Registration request

•URQ—Unregistration request

•ARQ—Admission request

•LRQ—Location request

•LCF—Location confirm

•LRJ—Location reject

•DRQ—Disengage request

•RAI—Resource availability information

•BRQ—Bandwidth request

Message Header

The message line is immediately followed by the message header. Each message header contains a field name and a value, separated by a colon (field:value). Possible fields are shown in Table 4-30:

Table 4-30 Message Header Fields 

Field Names	Field Values
Version-ID	Version of the GKTMP. The version ID consists of a major number (gk_major) and a minor number (gk_minor). For example, Version 1 is represented as 100.
From	String that identifies the originator of the message. For trigger registration requests from the external application, this field contains the server ID. For trigger registration responses from the Cisco IOS Gatekeeper, this field contains the gatekeeper ID. This field is required for trigger registration and unregistration requests and responses.
To	String that identifies the receiver of the message. For trigger registration requests from the external application, this field contains the gatekeeper ID. For trigger registration responses from the Cisco IOS Gatekeeper, this field contains the ID of the external application that initiated the request. This field is required for trigger registration and unregistration requests and responses.
Priority	A number indicating the priority of this trigger in relation to other triggers for the same RAS message type. Possible values are 1 through 20. 1 is the highest priority. If the Cisco IOS Gatekeeper has a registration for a RAS message type and receives another registration for the same RAS message from the same external application with the same priority, the Cisco IOS Gatekeeper uses the new registration and discards the previous one. If the Cisco IOS Gatekeeper has a registration for a RAS message type and receives another registration with the same priority from a different external application, the Cisco IOS Gatekeeper discards the new registration. This field is required for trigger registration and unregistration requests and is echoed in trigger registration and unregistration responses.
Content-length	The number of octets contained in the message body. If the message body is null, this field is omitted. This field is used only in trigger registration requests.
Notification-only	None. No value is included after the colon. If this field name is present, it indicates to the Cisco IOS Gatekeeper that it should forward requests for the specified RAS messages as a notification only. This field is used only in trigger registration requests.
Status	String that indicates the response code from the Cisco IOS Gatekeeper. This field is used only in trigger registration and unregistration responses. Possible response codes for unregistration requests are: •success—The registration has been accepted. •invalidPriority—The registration has been rejected because the Gatekeeper already has a registration for this RAS message type with the same priority from another application. •invalidFilters—Parsing of the message body failed. •invalidGKID—The gatekeeper ID specified in the "To" field of the request does not match the ID of any gatekeepers on this Cisco router. Possible response codes for unregistration responses are: •success—The unregistration has been accepted. •invalidPriority—The unregistration has been rejected because the Gatekeeper does not have a registration for this RAS message type with the same priority from this application. •invalidGKID—The gatekeeper ID specified in the "To" field of the request does not match the ID of any gatekeepers on this Cisco router.

The message header is followed immediately by a blank line.

Message Body

The message body follows the blank line. Only trigger registration requests contain a message body. Trigger registration responses, unregistration requests, and unregistration responses end after the blank line.

The message body in a trigger registration request can be used to narrow the circumstances under which the Cisco IOS Gatekeeper sends a REQUEST xxx to the external application. In this case, the external application includes tags and values in the message body that if matched will trigger the Cisco IOS Gatekeeper to generate a REQUEST xxx.

The tags that can be included vary depending on the RAS message type, and are a subset of the types that can be included in GKTMP RAS messages.

For the field type of Alias-Address, trailing wildcards can be used with E.164 addresses. An asterisk can be used to indicate a string of characters (for example, 1800*). A period can be used to indicate a single character (for example, 1800.......).

---

Note Wildcards cannot be used at the beginning or in the midst of a value, only at the end. If you include a wildcard at the beginning or in the midst of a value, it will be interpreted as a literal character.

---

Register RRQ and RAI

For Register RRQ and RAI, the tags shown in Table 4-31 can be used to filter messages:

Table 4-31 Register RRQ and RAI

Tag	Field Type	Mandatory or Optional	Corresponding RAS Message Field
t	Endpoint-Type	Optional	RRQ:terminalType
p	Supported-Prefix	Optional	RRQ:terminalType:gateway:protocol:*:supportedPrefixes
S	Boolean	Optional

Register URQ

For Register URQ, the tags shown in Table 4-32 can be used to filter messages:

Table 4-32 Register URQ

Tag	Field Type	Mandatory or Optional	Corresponding RAS Message Field
t	Endpoint-Type	Optional	RRQ:terminalType
p	Supported-Prefix	Optional	RRQ:terminalType:gateway:protocol:*:supportedPrefixes

Register ARQ, DRQ, IRR, and BRQ

For Register ARQ, DRQ, IRR, and BRQ the tags shown in Table 4-33 can be used to filter messages:

Table 4-33 Register ARQ, DRQ, IRR, and BRQ

Tag	Field Type	Mandatory or Optional	Corresponding RAS Message Field
d	Alias-Address	Optional	ARQ:destinationInfo
E	integer	Optional	ARQ:nonStandardData:redirectReason

Register LRQ

For Register LRQ, the tags shown in Table 4-34 can be used to filter messages:

Table 4-34 Register LRQ

Tag	Field Type	Mandatory or Optional	Corresponding RAS Message Field
d	Alias-Address	Optional	LRQ:destinationInfo
E	integer	Optional	LRQ:nonStandardData:redirectReason

---

Note A gatekeeper might not be the final destination of the LRQ messages that it receives. If the queried address in an LRQ is in another Gatekeeper's zone, the LRQ is forwarded to that gatekeeper and is not resolved locally. This means that there might not be a local zone that can be associated with the LRQ. To address this situation, the gatekeeper arbitrarily uses the server registrations for the first configured local zone. Because the order in which configured zones appear can change with deletions and additions, servers should send identical LRQ registrations to all zones (all logical gatekeepers) on the same router.

---

Register LCF

For Register LCF, the tags shown in Table 4-35 can be used to filter messages:

Table 4-35 Register LCF

Tag	Field Type	Mandatory or Optional	Corresponding RAS Message Field
d	Alias-Address	Optional	LRQ/LCF:destinationInfo
X	Alias-Address	Optional	LCF:remoteExtensionAddress

Register LRJ

For Register LRJ, the tag shown in Table 4-36 can be used to filter messages:

Table 4-36 Register LRJ

Tag	Field Type	Mandatory or Optional	Corresponding RAS Message Field
d	Alias-Address	Optional	LRQ:destinationInfo

Additional Messages

alternateEndpoint

The alternateEndpoint field contains the tags shown in Table 4-37.

Table 4-37 alternateEndpoint Tags 

Tag	Field Type	Mandatory or Optional	Description
C	Integer	Optional	Cost value associated with the zone
p	Integer	Optional	Priority value associated with the zone
c	Transport-Address	Mandatory	alternateEndpoints:callSignalAddress. See Transport-Address.
J	IA5string	Optional	CarrierId
Q	IA5string	Optional	TrunkGroupLabel
T	clear-Token	Optional	alternateEndpoints:tokens
d	Alias-Address	Optional	alternateEndpoints:destination
s	Alias-Address	Optional	alternateEndpoints:sourceAlias

Usage Notes

•The `C' and `p' parameters define the associated cost and priority of using this endpoint. The Gatekeeper merges the endpoints in the order of cost/ priority and presents an ordered list. If there are any remote endpoints, obtained by sending LRQs, they are assigned the cost value of the zone and merged accordingly.

For instance, in an ACF, the application may indicate two alternate endpoints with the following information:

A=c:{I:172.18.29.10:1780 I:172.18.29.15:1780} T:{O:1.2.3.4 p:567432 t:2345632 
o:1.2.6.7 d:3452323} {O:1.2.12.23 p:129087 t:8976657 o:1.2.6.7 d:12345989} C:10 
J:CARRIER_X Q:TGL_Y

A=c:{I:172.18.29.4:1780} d:{E:552601} T:{O:1.2.3.4 p:987668 t:1219889 o:1.2.6.7 
d:98766343} C:5 C:10 J:CARRIER_X Q:TGL_Y

•The first alternateEndpoint line contains multiple call signal addresses and information for multiple RAS ClearToken structures.

In this case, the multiple call signal addresses are associated with a single endpoint. Based on their cost values, the second endpoint is placed before the first in the list to be transmitted to the originating endpoint.

•The s tag allows ANI manipulation of alternate endpoints. The route server (RS) provides the originating gatekeeper (OGK) with multiple alternate endpoints. If the OGK cannot set up a call with the primary endpoint, it tries to set up a call with the ANI and DNIS of one of the alternate endpoints provided by the RS.

If the call is not successful, the OGK tries another alternate endpoint. This process continues until the OGK is successful in setting up a call with one of the multiple alternate endpoints. If it cannot set up the call with the alternate endpoints, the call fails.

---

Note The route server can send modified ANI through the GTD and the "s" tag of the alternate endpoint. When the route server is used with a call application, it should be programmed to send modified ANI in either the GTD or the "s" tag and not in both of them.

---

FeatureSet

Table 4-38 shows the new featureSet tags:

Table 4-38 featureSet Tags

Tag	Field Type	Mandatory or Optional	Corresponding RAS Message Field
n	Integer	Optional	For needed features.
d	Integer	Optional	For desired features.
s	Integer	Optional	For supported features.

Example

f=n:1, f=d:3, f=s:1

Where 1 or 3 is the feature identifier for a particular feature.

GTD

The Generic Transparency Descriptor (GTD) field type is a structure comprising of two sub-fields: length and data. This field type is required for values that contain <cr><lf> pairs in its body. The length (B) sub-field indicates the size of the data sub-field and indicates to the parser that any occurrence of <cr><lf> within the data sub-field is not a <tag>=<value> delimiter.

Table 4-39 shows the new GTD tags:

Table 4-39 GTD Tags

Tag	Field Type	Mandatory or Optional	Corresponding RAS Message Field
B	IA5String	Mandatory	Length of the data sub-field. Contains 5-digit ASCII characters.
Data	subfield	Mandatory	Opaque data transported by GKTMP.

Usage Notes

The GTD field type is different from other GKTMP fields in that <cr><lf> does not indicate the end of the GTD line. The following rules must be followed in processing the GTD field type:

•Use `g' as a GTD tag across all REQUEST and RESPONSE messages.

•The length of the GTD data sub-field is specified by `B' and is represented by five ASCII digits.

•A `B' sub-field is delimited by `:'.

•<cr><lf> or <lf> within the GTD body should not be interpreted as a tag or value delimiter. The <cr><lf> after the GTD sub-field—specified by length sub-field—is the delimiter.

•The GTD field should not be included in any tag other than `g'.

•Gatekeeper to Server:

–`g=B:<Five ASCII digits>:<data>' should be used to send the GTD.

–`g=' is illegal.

–The absence of a `g' tag indicates there is no GTD data.

–All other `g' tag formats are illegal

•Server to Gatekeeper:

–The `g' tag can only be sent in a RESPONSE message corresponding to a REQUEST message from the gatekeeper in which a GTD is present. The server cannot generate and send a GTD if it has not received a GTD from the gatekeeper.

–`g=B:<Five ASCII digits>:<data>' indicates the server is returning the GTD it received in a request from the gatekeeper. (This GTD could be a modified version of gatekeeper GTD.) The gatekeeper should replace its cached copy of the GTD with the received copy of the GTD.

–`g=' indicates that server wants the gatekeeper to retain its copy of the GTD.

–The absence of a `g' tag indicates that the gatekeeper should delete its copy of GTD.

•The gatekeeper should not send a `g' tag or value if the server GKTMP version is less than version 4.1. Versions below version 4.1 cannot interpret the GTD and <cr><lf> may not delimit the GTD tagor value, so these lower versions cannot to skip the `g' tag line.

Format

g=B:<Length in 5 ASCII digits>:<Data>

Example

g=B:00003:1AB

ReRouteCount

The reRouteCount can be used by the originating gateway to send additional ARQs to the gatekeeper and then to a route server after all the alternative endpoints returned in the first ARQ have failed. The subsequent ARQs use the same global call ID and will also have a reroute count that is set to one for the first reroute request (second ARQ) and is incremented for each subsequent reroute request.

Table 4-40 shows the tags for the reRouteCount field:

Table 4-40 ReRouteCount Tags

Tag	Field Type	Required or Optional	Description
V	Integer	Optional	Number of reroute requests.

RobustnessData

The RobustnessData can be sent from gateway to gatekeeper to indicate that the endpoint (GW) is supporting Annex R. The GKTMP messages, REQ-RRQ/RSP-RRQ/RSP-RCF, REQ-ARQ/RSP-ARQ/RSP-ACF, REQ-LRQ/REQ-LCF/RSP-LRQ/RSP-LCF can contain RobustnessData. The GKTMP can change the values of the RobustnessData in the response messages.

Table 4-41 shows the tag being added to the RobustnessData field:

Table 4-41 RobustnessData Tags

Tag	Field Type	Required or Optional	Description
s	Boolean	Optional	hasSharedRepository1
b	Transport-Address	Optional	List of backup endpoint CSAs2

1 Information hasSharedRepository indicates the Method B Robustness. 2 Backup CallSignalAddress can have a list of backup endpoint addresses. b:{I:172.18.192.10:1780 I:172.18.196.1:1719} Braces should always be put around the contents, even if it is only a single CSA. For example: Y=b:{I:1.1.1.1:2} Y=s:t b:{I:1.2.3.4:5 I:6.7.8.9:10}

AlternateGK

A message body line containing a field of type AlternateGK contains a set of fields enclosed within curly braces "{ }". Each of the fields within the curly braces are identified by a tag, with each field separated by SP (ascii space, 0x20) characters.

Table 4-42 shows the AlternateGK tags:

Table 4-42 AlternateGK Tags 

Tag	Field Type	Mandatory or Optional	Corresponding RAS Message Field
r	Transport-Address	Mandatory	AlternateGK:rasAddress. See Transport-Address.
g	Alias-Address	Optional	AlternateGK:gatekeeperIdentifier. See Alias-Address.
n	Boolean	Mandatory	AlternateGK:needToRegister
p	integer	Mandatory	AlternateGK:priority

FromReplyAddress

The from IP address is the address from which an LRQ message was received. The reply-to address is the mandatory IP address specified in the RAS LRQ message replyAddress field. A GKTMP application can use these fields to authenticate the source of LRQ message.

Table 4-43 shows the FromReplyAddress tags:

Table 4-43 FromReplyAddress Tags

Tag	Field Type	Mandatory or Optional	Corresponding RAS Message Field
f	IP address	Mandatory	Address of the gatekeeper from which this LRQ message was received.
r	IP address	Mandatory	LRQ::replyAddress:ipAddress:ip

ServiceControlSession

Table 4-44 shows the new Service Control Session tags:

Table 4-44 New ServiceControl Sessions Tags

Tag	Field Type	Mandatory or Optional	Corresponding RAS Message Field
d	IA5String	Optional	serviceControl:contents
r	IA5String	Mandatory	serviceControl:reason
s	Integer	Mandatory	serviceControl:sessionId

A message body line carries one or more remote zone definitions. The following example depicts a message body line comprising two zone definitions. Allowable values for cost and priority are between 1 and 100.

	z={r:I:172.18.29.10:1719 d:E:552601 c:10 p:10} {r:I:172.18.29.15:1719 c:15 p:10}

Usage Notes

Any clear tokens returned with the remote zone definition are sent in the LRQ to that zone.

Usage Information

The Usage Information field can be sent from the gateway to gatekeeper to report the billing information about the call. It can be included within DRQ at the end of the call. It can contain the alert time, connect time, end time, and release source for the call. Table 4-45 shows the Usage Information tags:

Table 4-45 Usage Information Tags

Tag	Field Type	Mandatory or Optional	Corresponding RAS Message Field
a	System Time	Optional	Alert time of the call.
c	System Time	Optional	Connect time of the call.
e	System Time	Optional	End time of the call.
f	Integer	Optional	Release source of the call.
C	Call Mode	Optional	DRQRasnonStdUsageInfo

UsageReporting Capability

The UsageReporting Capability is sent by the gateway to the gatekeeper to report its ability to collect and report usage information. It specifies if the endpoint has the capability to report the start, endtime, and termination cause of the call to the gatekeeper. It is sent within RRQ upon registration. Table 4-44 shows the UsageReporting Capability tags:

Table 46 UsageReporting Capability Tags

Tag	Field Type	Mandatory or Optional	Corresponding RAS Message Field
s	Null	Optional	Start time of the call can be reported.
e	Null	Optional	End time of the call can be reported.
c	Null	Optional	Termination cause of the call can be reported.

CallCapacity

The CallCapacity message indicates the ability of the gateway to accept each type of call the gateway supports, such as voice calls.

Table 4-47 shows the CallCapacity tags:

Table 4-47 CallCapacity Tags 

Tag	Field Type	Mandatory or Optional	Corresponding RAS Message Field
T	CallCapacityType	Mandatory	xRQ::callCapacity:maximum/currentCallCapacity:xxxxGwCallsAvailable
G	IA5String	Mandatory	xRQ::callCapacity:maximum/currentCallCapacity:xxxxGwCallsAvailable:group
C	Integer	Mandatory	xRQ::callCapacity:maximumCallCapacity:xxxxGwCallsAvailable:calls
c	Integer	Mandatory	xRQ::callCapacity:currentCallCapacity:xxxxGwCallsAvailable:calls

CarrierInfo

The gatekeeper sends incoming carrier information received in a RAS ARQ message from the gateway to an external GKTMP application. This information allows the application to select an outbound carrier and remote zones that the carrier may exist in. The gatekeeper uses this outbound carrier and zone information to query for the egress gateway.

Table 4-48 shows the new Carrier Information tags:

Table 4-48 CarrierInfo Tags

Tag	Field Type	Mandatory or Optional	Corresponding RAS Message Field
i	IA5String	Mandatory	destination carrierID
p	Integer	Optional	Priority of this carrier
z	remoteZone	Optional	Remote zone information. See RemoteZone.

TrunkGroupInfo

Table 4-49 shows the new Trunk Group Information tags:

Table 4-49 TrunkGroupInfo Tags

Tag	Field Type	Mandatory or Optional	Corresponding RAS Message Field
i	IA5String	Mandatory	Destination trunk group
p	Integer	Optional	Priority of this trunk group
z	remoteZone	Optional	Remote zone information. See RemoteZone.

Alias-Address

A field of type Alias-Address contains a sequence of aliases separated by SP (ascii space, 0x20) characters. Each alias is prefixed by one of the following type characters, followed by a colon:

•H: an H.323-ID

• E: an E.164 address

• M: an email ID

For example, in an RRQ message, a terminal alias containing the sequence of an H.323-ID of "John Smith", an E164 address of 4085551212, and an email-id of "jsmith@somewhere.com" is indicated by the line: a=H:"John Smith" E:4085551212 M:jsmith@somewhere.com

PerCallInfo

If the message contains a PerCallInfo field, the following fields shown in Table 4-50 are included:

Table 4-50 PerCallInfo Fields

Tag	Field Type	Mandatory or Optional	Corresponding RAS Message Field
c	GUID	Optional	IRR:perCallInfo:callIdentifier
C	GUID	Mandatory	IRR:perCallInfo:conferenceID
A	Boolean	Optional	IRR:perCallInfo:originator
b	Bandwidth	Mandatory	IRR:perCallInfo:bandwidth
t	System Time	Optional	IRR:perCallInfo:NonStandard:start_time
s	IA5String	Optional	IRR:perCallInfo:tokens:IZCT:srcZone
d	IA5String	Optional	IRR:perCallInfo:tokens:IZCT:dstZone
S	IA5String	Optional	IRR:perCallInfo:srcCarrierId
D	IA5String	Optional	IRR:perCallInfo:dstCarrierId

ReleaseCompleteCauseIE

ReleaseCompleteCauseIE, also known as terminationCause, is sent to the GKTMP application to inform the GKTMP server that a release complete cause IE was sent to the Gatekeeper.

Table 4-51 shows the ReleaseCompleteCauseIE tags:

Table 4-51 ReleaseCompleteCauseIE Tags

Tag	Field Type	Mandatory or Optional	Corresponding RAS Message Field
v	IA5String	Optional	terminationCause:releaseCompleteCauseIE
r	IA5String	Optional	terminationCause:releaseCompleteReason

RemoteZone

A remoteZone is a structure type comprised of multiple sub-fields. Each sub-field type within the remoteZone is identified with a tag and the associated data is enclosed with curly braces "{ }". The fields within the curly braces pertain to a single instance of a remoteZone structure. The message line with a remoteZone field can contain multiple instances, each enclosed within curly braces and separated by a space character. Each of the sub-fields themselves are separated by a space character.

Table 4-52 shows the remoteZone field tags:

Table 4-52 RemoteZone Tags

Tag	Field Type	Mandatory or Optional	Description
r	Transport-Address	Mandatory	RAS address of the zone. See Transport-Address.
c	Integer	Optional	Cost value associated with the zone
p	Integer	Optional	Priority value associated with the zone
T	clearToken	Optional	ARQ:tokens. See ClearToken.
s	Alias-Address	Optional	ANI manipulation of alternate endpoints.

The "s" tag allows ANI manipulation for a remote zone. The route server (RS) provides the directory or originating gatekeeper with multiple remote zones to contact for resolving the E.164 number. With the s tag, it provides a unique ANI for each of the remote zones, where the ANI for a remote zone is sent in the non-standard field of the LRQ that is forwarded to that remote zone.

Example

This is an example of modified ANI with a z tag:

z={r:I:172.18.29.10:1719 d:E:552601 c:10 p:10} {r:I:172.18.29.15:1719 c:15 p:10}

Usage Notes

Any Cleartokens returned with the remote zone definition are sent in the LRQ message to that zone.

Transport-Address

The only type of transport address currently supported by the gatekeeper is IP version 4. However, a type prefix is defined for future extensibility. For example, I: IP version 4 address.

The address is specified in the usual dotted string form, followed by a colon and port number. For example, the callSignalAddress in an RRQ message may be specified as: c=I:172.21.137.4:1720.

ClearToken

If the message contains a clearToken field, the fields shown in Table 4-53 are included:

Table 4-53 ClearToken Fields 

Tag	Field Type	Mandatory or Optional	Corresponding RAS Message Field
O	OBJECT-IDENTIFIER	Mandatory	tokens:objectIdentifier
p	IA5string	Optional	tokens:password
t	integer	Optional	tokens:timestamp
s	IA5string	Optional	tokens:challengeString
r	integer	Optional	tokens:random
G	IA5string	Optional	tokens:generalID
o	OBJECT-IDENTIFIER	Optional	tokens:nonStandard:objectIdentifier
d	IA5string	Optional	tokens:nonStandard:data

CryptoToken

If the message contains a cryptoToken field, the additional fields shown in Table 4-54 are included:

Table 4-54 CryptoToken Fields

Tag	Field Type	Mandatory or Optional	Corresponding RAS Message Field
H	IA5string	Optional	CryptoToken:alias
t	IA5string	Optional	CryptoToken:timestamp
h	IA5string	Optional	CryptoToken:token

CallMode

The CallMode field type contains multiple info-type fields. The info-type field denotes the type of media that is present in a call and is represented by an integer, such as 1 for voice, 2 for fax, or 3 for modem. There can be one or more info-type fields in a CallMode entry. Table 4-55 shows the CallMode field type.

Table 4-55 CallMode Field

Tag	Field Type	Mandatory or Optional	Corresponding RAS Message Field
i	Integer	Mandatory	CallMode:infotype