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
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 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
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:
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
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
|
Required or Optional
|
Corresponding RAS Message Field
|
c
|
Transport-Address
|
Required
|
RRQ:callSignalAddress
|
r
|
Transport-Address
|
Required
|
RRQ:rasAddress
|
a
|
Alias-Address
|
Optional
|
RRQ:terminalAlias
|
t
|
Endpoint-Type
|
Required
|
RRQ:terminalType
|
P
|
Supported-Prefix
|
Optional
|
RRQ:terminalType:gateway:protocol:*:supportedPrefixes
|
$
|
cryptoToken
|
Optional
|
RRQ:cyptoTokens
|
T
|
clearToken
|
Optional
|
RRQ:tokens
|
N
|
AlternateTransportAddr
|
Optional
|
RRQ:AlternateTransportAddress
|
If the message contains a cryptoToken field with a value of cryptoEPPwdHash, the additional fields shown in Table 4-3 are included:
Table 4-3 Additional Fields
Tag
|
Field Type
|
Required or Optional
|
Corresponding RAS Message Field
|
a
|
Alias-Address
|
Required
|
CryptoH323Token:cryptoEPPwdHash:alias
|
t
|
TimeStamp
|
Required
|
CryptoH323Token:cryptoEPPwdHash:timestamp
|
h
|
HashedToken
|
Required
|
CryptoH323Token:cryptoEPPwdHash:token
|
If the message contains a clearToken field, the additional fields shown in Table 4-4 are included:
Table 4-4 Additional Fields
Tag
|
Field Type
|
Required or Optional
|
Corresponding RAS Message Field
|
O
|
OBJECT-IDENTIFIER
|
Required
|
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
|
If the message contains an AlternateTransportAddr field, the additional field shown in Table 4-5 is included:
Table 4-5 Additional Field
Tag
|
Field Type
|
Required or Optional
|
Corresponding RAS Message Field
|
I
|
Transport-Address
|
Required
|
IP address and port for Annex E
|
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-6:
Table 4-6 Response RRQ Tags
Tag
|
Field Type
|
Required or Optional
|
Corresponding RAS Message Field
|
a
|
Alias-Address
|
Optional
|
RRQ:terminalAlias
|
p
|
Supported-Prefix
|
Optional
|
RRQ:terminalType:gateway:protocol: *:supportedPrefixes
|
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-7:
Table 4-7 Response RCF Tags
Tag
|
Field Type
|
Required 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
|
If the message contains an AlternateGK field, the additional fields shown in Table 4-8 are included:
Table 4-8 Additional Fields
Tag
|
Field Type
|
Required or Optional
|
Corresponding RAS Message Field
|
r
|
Transport-Address
|
Required
|
AlternateGK:rasAddress
|
g
|
Alias-Address
|
Optional
|
AlternateGK:gatekeeperIdentifier
|
n
|
Boolean
|
Required
|
AlternateGK:needToRegister
|
p
|
integer
|
Required
|
AlternateGK:priority
|
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-9:
Table 4-9 Response RRJ Tag
Tag
|
Field Type
|
Required or Optional
|
Corresponding RAS Message Field
|
R
|
RRJ-Reason
|
Required
|
RRJ:rejectReason
|
Possible values for the rejectReason are:
•
undefinedReason
•
securityDenial
•
resourceUnavailable
Unregistration Message
Unregistration messages are used to remove an H.323 endpoint from a gatekeeper zone.
This section describes the following:
•
Request 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-10:
Table 4-10 Request URQ
Tag
|
Field Type
|
Required or Optional
|
Corresponding RAS Message Field
|
c
|
Transport-Address
|
Required
|
URQ:callSignalAddress
|
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-11:
Table 4-11 Request ARQ
Tag
|
Field Type
|
Required or Optional
|
Corresponding RAS Message Field
|
s
|
Alias-Address
|
Required
|
ARQ:srcInfo
|
S
|
Transport-Address
|
Optional
|
ARQ:srcCallSignalAddress
|
d
|
Alias-Address
|
Optional
|
ARQ:destinationInfo
|
D
|
Transport-Address
|
Optional
|
ARQ:destCallSignalAddress
|
x
|
Alias-Address
|
Optional
|
ARQ:destExtraCallInfo
|
b
|
Bandwidth
|
Required
|
ARQ:bandWidth
|
A
|
Boolean
|
Required
|
ARQ:answerCall
|
c
|
GUID
|
Optional
|
ARQ:callIdentifier
|
C
|
GUID
|
Required
|
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
|
Required
|
arqing-endpoint identifier3
|
$
|
cryptoToken
|
Optional
|
ARQ:cyptoTokens
|
T
|
clearToken
|
Optional
|
ARQ:tokens
|
B
|
IA5string
|
Optional
|
ARQ:nonStandardData:interfaceSpecific:BillingInfo
|
I
|
IA5string
|
Optional
|
ARQ:nonStandardData:interfaceDescriptor
|
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.
If the message contains a cryptoToken field with a value of cryptoEPPwdHash, the additional fields shown in Table 4-12 are included:
Table 4-12 Additional Fields
Tag
|
Field Type
|
Required or Optional
|
Corresponding RAS Message Field
|
a
|
Alias-Address
|
Required
|
CryptoH323Token:cryptoEPPwdHash:alias
|
t
|
TimeStamp
|
Required
|
CryptoH323Token:cryptoEPPwdHash:timestamp
|
h
|
HashedToken
|
Required
|
CryptoH323Token:cryptoEPPwdHash:token
|
If the message contains a clearToken field, the additional fields shown in Table 4-13 are included:
Table 4-13 Additional Fields
Tag
|
Field Type
|
Required or Optional
|
Corresponding RAS Message Field
|
O
|
OBJECT-IDENTIFIER
|
Required
|
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
|
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-14:
Table 4-14 Response ARQ
Tag
|
Field Type
|
Required or Optional
|
Corresponding RAS Message Field
|
d
|
Alias-Address
|
Optional
|
ARQ:destinationInfo
|
D
|
Transport-Address
|
Optional
|
ARQ:destCallSignalAddress
|
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
|
T
|
clearToken
|
Optional
|
ARQ:tokens
|
c
|
integer
|
Optional
|
None1
|
p
|
integer
|
Optional
|
None2
|
A
|
alternateEndpoint
|
Optional
|
ARQ:alternateEndpoints
|
The external application has the option of reducing the bandwidth.
If the message contains a remoteZone field, the additional fields shown in Table 4-15 are included:
Table 4-15 Additional Fields
Tag
|
Field Type
|
Required or Optional
|
Description
|
r
|
Transport-Address
|
Required
|
RAS address of the zone
|
c
|
Integer
|
Optional
|
Cost value associated with the zone
|
p
|
Integer
|
Optional
|
Priority value associated with the zone
|
T
|
clearToken
|
Optional
|
ARQ:tokens
|
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.
If the message contains an alternateEndpoint field, the additional fields shown in Table 4-16 are included:
Table 4-16 Additional Fields
Tag
|
Field Type
|
Required or Optional
|
Description
|
C
|
Integer
|
Optional
|
Cost value associated with the zone
|
p
|
Integer
|
Optional
|
Priority value associated with the zone
|
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-17:
Table 4-17 Response ACF
Tag
|
Field Type
|
Required or Optional
|
Corresponding RAS Message Field
|
d
|
Alias-Address
|
Optional
|
ACF:destinationInfo
|
D
|
Transport-Address
|
Required
|
ACF:destCallSignalAddress
|
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
|
A
|
AlternateEndpoint
|
Optional
|
ACF:alternateEndpoints
|
N
|
AlternateTransportAddr
|
Optional
|
ACF:alternateTransportAddress
|
u
|
useSpecifiedTransport
|
Optional
|
ACF:useSpecifiedAddress
|
If the message contains an AlternateEndpoint field, the additional fields shown in Table 4-18 are included:
Table 4-18 Additional Fields
Tag
|
Field Type
|
Required or Optional
|
Corresponding RAS Message Field
|
c
|
Transport-Address
|
Required
|
alternateEndpoints:callSignalAddress
|
T
|
clearToken
|
Optional
|
alternateEndpoints:tokens
|
If the AlternateEndpoint field contains a clearToken field, the additional fields shown in Table 4-19 are included:
Table 4-19 Additional Fields
Tag
|
Field Type
|
Required or Optional
|
Corresponding RAS Message Field
|
O
|
OBJECT-IDENTIFIER
|
Required
|
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
|
If the message contains an AlternateTransportAddr field, the additional field shown in Table 4-20 is included:
Table 4-20 Additional Field
Tag
|
Field Type
|
Required or Optional
|
Corresponding RAS Message Field
|
I
|
Transport-Address
|
Required
|
IP address and port for Annex E
|
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-21:
Table 4-21 Response ARJ
Tag
|
Field Type
|
Required or Optional
|
Corresponding RAS Message Field
|
R
|
ARJ-Reason
|
Required
|
ARJ:rejectReason
|
Possible values for rejectReason are:
•
calledPartyNotRegistered
•
invalidPermission
•
requestDenied
•
undefinedReason
•
resourceUnavailable
•
securityDenial
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
•
Request LCF
•
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-22:
Table 4-22 Request LRQ
Tag
|
Field Type
|
Required or Optional
|
Corresponding RAS Message Field
|
s
|
Alias-Address
|
Optional
|
LRQ:srcInfo
|
d
|
Alias-Address
|
Required
|
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
|
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.
For Response LRQ, the possible tags are shown in Table 4-23:
Table 4-23 Response LRQ
Tag
|
Field Type
|
Required or Optional
|
Corresponding RAS Message Field
|
d
|
Alias-Address
|
Optional
|
LRQ:destinationInfo
|
z
|
remoteZone
|
Optional
|
None
|
T
|
clearToken
|
Optional
|
ARQ:tokens
|
c
|
integer
|
Optional
|
None1
|
p
|
integer
|
Optional
|
None2
|
A
|
alternateEndpoint
|
Optional
|
ARQ:alternateEndpoints
|
If the message contains a remoteZone field, the additional fields shown in Table 4-24 are included:
Table 4-24 Additional Fields
Tag
|
Field Type
|
Required or Optional
|
Description
|
r
|
Transport-Address
|
Required
|
RAS address of the zone
|
c
|
Integer
|
Optional
|
Cost value associated with the zone
|
p
|
Integer
|
Optional
|
Priority value associated with the zone
|
T
|
clearToken
|
Optional
|
LRQ:tokens
|
If this field is included, the Cisco IOS Gatekeeper will send the original LRQs to all the listed zones.
If the message contains an alternateEndpoint field, the additional fields shown in Table 4-25 are included:
Table 4-25 Additional Fields
Tag
|
Field Type
|
Required or Optional
|
Description
|
C
|
Integer
|
Optional
|
Cost value associated with the zone
|
p
|
Integer
|
Optional
|
Priority value associated with the zone
|
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-26:
Table 4-26 Request LCF
Tag
|
Field Type
|
Required 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
|
Required
|
LRQ/LCF:destinationInfo
|
D
|
Transport-Address
|
Required
|
LCF:callSignalAddress
|
r
|
Transport-Address
|
Required
|
LCF:rasAddress
|
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
|
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-27 is included:
Table 4-27 Additional Field
Tag
|
Field Type
|
Required or Optional
|
Corresponding RAS Message Field
|
I
|
Transport-Address
|
Required
|
IP address and port for Annex E
|
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-28:
Table 4-28 Response LCF
Tag
|
Field Type
|
Required or Optional
|
Corresponding RAS Message Field
|
d
|
Alias-Address
|
Optional
|
LCF:destinationInfo
|
D
|
Transport-Address
|
Required
|
LCF:destCallSignalAddress
|
r
|
Transport-Address
|
Required
|
LCF:rasAddress
|
x
|
Alias-Address
|
Optional
|
LCF:destExtraCallInfo
|
X
|
Alias-Address
|
Optional
|
LCF:remoteExtensionAddress
|
t
|
Endpoint-Type
|
Optional
|
LCF:destinationType
|
A
|
AlternateEndpoint
|
Optional
|
ACF:alternateEndpoints
|
N
|
AlternateTransportAddr
|
Optional
|
LCF:AlternateTransportAddress
|
u
|
useSpecifiedTransport
|
Optional
|
ACF:useSpecifiedAddress
|
T
|
clearToken
|
Optional
|
LCF:tokens
|
Note
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-29 included:
Table 4-29 Additional Field
Tag
|
Field Type
|
Required or Optional
|
Corresponding RAS Message Field
|
I
|
Transport-Address
|
Required
|
IP address and port for Annex E
|
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-30:
Table 4-30 Request LRJ
Tag
|
Field Type
|
Required or Optional
|
Corresponding RAS Message Field
|
s
|
Alias-Address
|
Optional
|
LRQ:srcInfo
|
d
|
Alias-Address
|
Required
|
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
|
Required
|
LRJ:rejectReason
|
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-31:
Table 4-31 Response LRJ
Tag
|
Field Type
|
Required or Optional
|
Corresponding RAS Message Field
|
R
|
LRJ-Reason
|
Required (LRQ, LCF)
Optional (LRJ)
|
LRJ:rejectReason
|
Possible values for rejectReason are:
•
notRegistered
•
invalidPermission
•
requestDenied
•
undefinedReason
•
securityDenial
Disengage Messages
Disengage messages are used to indicate that a party wants to end the call.
This section describes the following:
•
Request DRQ
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-32:
Table 4-32 Request DRQ
Tag
|
Field Type
|
Required or Optional
|
Corresponding RAS Message Field
|
c
|
GUID
|
Optional
|
DRQ:callIdentifier
|
C
|
GUID
|
Required
|
DRQ:conferenceID
|
R
|
DRQ-reason
|
Required
|
DRQ:disengageReason
|
A
|
Boolean
|
Required
|
DRQ:answeredCall
|
S
|
Transport-Address
|
Required
|
ARQ:srcCallSignalAddress
|
T
|
clearToken
|
Optional
|
DRQ:tokens
|
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.
This section describes the following:
•
Request RAI
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-33:
Table 4-33 Request RAI
Tag
|
Field Type
|
Required or Optional
|
Corresponding RAS Message Field
|
c
|
Transport-Address
|
Required
|
RRQ:callSignalAddress
|
r
|
Boolean
|
Required
|
RAI:almostOutOfResources
|
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 inTable 4-34:
Table 4-34 Request BRQ
Tag
|
Field Type
|
Required or Optional
|
Corresponding RAS Message Field
|
i
|
Transport-Address
|
Required
|
See Note
|
b
|
Bandwidth
|
Required
|
BRQ:bandWidth
|
C
|
GUID
|
Required
|
BRQ:conferenceID
|
c
|
GUID
|
Required
|
BRQ:callIdentifier
|
A
|
Boolean
|
Required
|
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 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-35:
Table 4-35 Response BCF
Tag
|
Field Type
|
Required or Optional
|
Corresponding RAS Message Field
|
b
|
Bandwidth
|
Required
|
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-36:
Table 4-36 Response BRJ
Tag
|
Field Type
|
Required or Optional
|
Corresponding RAS Message Field
|
R
|
BRJ-Reason
|
Required
|
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-37:
Table 4-37 Response RIP
Tag
|
Field Type
|
Required or Optional
|
Corresponding RAS Message Field
|
d
|
Integer
|
Required
|
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-38 shows the new Request IRR tags:
Table 4-38 New Request IRR Tags
Tag
|
Field Type
|
Required or Optional
|
Corresponding RAS Message Field
|
S
|
Transport-Address
|
Mandatory
|
IRR:srcCallSignalAddress
|
P
|
PerCallInfo
|
Optional
|
IRR:perCallInfo
|
If the message contains a PerCallInfo field, the following additional fields shown in Table 4-39 are included:
Table 4-39 New Additional Fields
Tag
|
Field Type
|
Required 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
|
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-40:
Table 4-40 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-41 can be used to filter messages:
Table 4-41 Register RRQ and RAI
Tag
|
Field Type
|
Required or Optional
|
Corresponding RAS Message Field
|
t
|
Endpoint-Type
|
Optional
|
RRQ:terminalType
|
p
|
Supported-Prefix
|
Optional
|
RRQ:terminalType:gateway:protocol:*:supportedPrefixes
|
Register URQ
For Register URQ, the tags shown in Table 4-42 can be used to filter messages:
Table 4-42 Register URQ
Tag
|
Field Type
|
Required 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-43 can be used to filter messages:
Table 4-43 Register ARQ, DRQ, IRR, and BRQ
Tag
|
Field Type
|
Required 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-44 can be used to filter messages:
Table 4-44 Register LRQ
Tag
|
Field Type
|
Required 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-45 can be used to filter messages:
Table 4-45 Register LCF
Tag
|
Field Type
|
Required 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-46 can be used to filter messages:
Table 4-46 Register LRJ
Tag
|
Field Type
|
Required or Optional
|
Corresponding RAS Message Field
|
d
|
Alias-Address
|
Optional
|
LRQ:destinationInfo
|