![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() |
This chapter describes GKTMP messages and contains the following sections:
The GKTMP messages are used for communication between the Cisco IOS Gatekeeper and the external application. There are two types of GKTMP messages:
The general format of all GKTMP RAS messages is as follows:
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:
Possible RAS message types are as follows:
![]() |
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. |
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:
The message header is followed immediately by a blank line.
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:
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 are used to control which H.323 endpoints are in the gatekeeper's zone.
This section describes the following:
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:
Tag | Field Type | Mandatory or Optional | Corresponding RAS Message Field |
---|---|---|---|
RRQ:callSignalAddress. See Transport-Address. |
|||
RRQ:rasAddress. See Transport-Address. |
|||
RRQ:cryptoTokens. See CryptoToken. |
|||
RRQ:tokens. See ClearToken. |
|||
RRQ:capacity. See CallCapacity. |
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:
Tag | Field Type | Mandatory or Optional | Corresponding RAS Message Field |
---|---|---|---|
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:
Tag | Field Type | Mandatory or Optional | Corresponding RAS Message Field |
---|---|---|---|
RCF:alternateGatekeeper. See AlternateGK. |
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:
Tag | Field Type | Mandatory or Optional | Corresponding RAS Message Field |
---|---|---|---|
Possible values for the rejectReason are:
Unregistration messages are used to remove an H.323 endpoint from a gatekeeper zone.
This section describes the following:
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:
Tag | Field Type | Mandatory or Optional | Corresponding RAS Message Field |
---|---|---|---|
URQ:callSignalAddress. See Transport-Address. |
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:
Tag | Field Type | Mandatory or Optional | Corresponding RAS Message Field |
---|---|---|---|
URQ:callSignalAddress. See Transport-Address. |
|||
URQ:alternateGatekeeper. See AlternateGK. |
Possible values for the reason are:
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:
Tag | Field Type | Mandatory or Optional | Corresponding RAS Message Field |
---|---|---|---|
URQ:callSignalAddress. See Transport-Address. |
Admission messages are used to control which H.323 endpoints can participate in calls.
This section describes the following:
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:
Tag | Field Type | Mandatory or Optional | Corresponding RAS Message Field |
---|---|---|---|
ARQ:srcCallSignalAddress. See Transport-Address. |
|||
ARQ:destCallSignalAddress. See Transport-Address. |
|||
ARQ:cryptoTokens. See CryptoToken. |
|||
ARQ:tokens. See ClearToken. |
|||
ARQ:nonStandardData:gtd. See GTD. |
|||
ARQ:capacity. See CallCapacity. |
|||
Possible values for the redirectReason are:
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.
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:
Tag | Field Type | Mandatory or Optional | Corresponding RAS Message Field |
---|---|---|---|
ARQ:destCallSignalAddress. See Transport-Address. |
|||
None. See RemoteZone. |
|||
ARQ:tokens. See ClearToken. |
|||
ARQ:nonStandardData:gtd. See GTD. |
|||
See CarrierInfo. |
|||
ARQ:srcInfo. See Alias-Address. |
|||
See TrunkGroupInfo. |
1Reflects 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.
2Reflects 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.
If the message contains an alternateEndpoint field, the additional fields shown in Table 4-11 are included:
Tag | Field Type | Mandatory or Optional | Description |
---|---|---|---|
alternateEndpoints:callSignalAddress. See Transport-Address. |
|||
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-12:
Tag | Field Type | Mandatory or Optional | Corresponding RAS Message Field |
---|---|---|---|
ACF:destCallSignalAddress. See Transport-Address. |
|||
ACF:tokens. See ClearToken. |
|||
ACF:useSpecifiedAddress. SeeMessage Body. |
|||
ACF:nonStandardData:gtd:gtdData. See GTD. |
|||
ACF:ServiceControlSession. See ServiceControlSession. |
|||
See CarrierInfo. |
|||
See TrunkGroupInfo. |
If the message contains an AlternateEndpoint field, the additional fields shown in Table 4-13 are included:
Tag | Field Type | Mandatory or Optional | Corresponding RAS Message Field |
---|---|---|---|
alternateEndpoints:callSignalAddress. See Transport-Address. |
|||
alternateEndpoints:tokens. See ClearToken. |
|||
None1 |
|||
1The `C' and `p' parameters define the associated cost and priority of using this endpoint. The Gatekeeper merges the endpoints in order of their cost/priority and present an ordered list. Remote endpoints, if any (obtained by sending LRQs), are assigned the cost value of the zone and merged accordingly. |
If the message contains an AlternateTransportAddr field, the additional field shown in Table 4-14 is included:
Tag | Field Type | Mandatory or Optional | Corresponding RAS Message Field |
---|---|---|---|
IP address and port for Annex E. See Transport-Address. |
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-15:
Tag | Field Type | Mandatory or Optional | Corresponding RAS Message Field |
---|---|---|---|
1This 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:
Location messages are used by gatekeepers to communicate with each other to process interzone calls.
This section describes the following:
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-16:
Tag | Field Type | Mandatory or Optional | Corresponding RAS Message Field |
---|---|---|---|
LRQ:tokens. See ClearToken. |
|||
LRQ:nonStandardData:gtd. See GTD. |
|||
See FromReplyAddress. |
Possible values for the redirectReason are:
CallingPartyNumOctet3a is from the Q.931 Setup octet 3a of calling party number.
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-17:
Tag | Field Type | Mandatory or Optional | Corresponding RAS Message Field |
---|---|---|---|
None. See RemoteZone. |
|||
ARQ:tokens. See ClearToken. |
|||
LRQ:nonStandardData:gtd. See GTD. |
|||
See CarrierInfo. |
|||
LRQ:srcInfo. See Alias-Address. |
|||
See TrunkGroupInfo. |
|||
1Reflects 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.
2Reflects 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. |
If the message contains an alternateEndpoint field, the additional fields shown in Table 4-18 are included:
Tag | Field Type | Mandatory or Optional | Description |
---|---|---|---|
alternateEndpoints:callSignalAddress. See Transport-Address. |
|||
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-19:
Tag | Field Type | Mandatory or Optional | Corresponding RAS Message Field |
---|---|---|---|
LCF:callSignalAddress. See Transport-Address. |
|||
LCF:rasAddress. See Transport-Address. |
|||
LCF:tokens. See ClearToken. |
|||
LCF:nonStandardData:gtd:gtdData. See GTD. |
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-20 is included:
Tag | Field Type | Mandatory or Optional | Corresponding RAS Message Field |
---|---|---|---|
IP address and port for Annex E. See Transport-Address. |
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:
In the case of a Request LRJ, the response contains an alternate destination.
For Response LCF, the possible tags are shown in Table 4-21:
Tag | Field Type | Mandatory or Optional | Corresponding RAS Message Field |
---|---|---|---|
LCF:destCallSignalAddress. See Transport-Address. |
|||
LCF:rasAddress. See Transport-Address. |
|||
LCF:tokens. See ClearToken. |
|||
LCF:nonStandardData:gtd:gtdData. See GTD. |
|||
ACF:ServiceControlSession. See ServiceControlSession. |
|||
See CarrierInfo. |
|||
See TrunkGroupInfo. |
![]() |
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-22 included:
Tag | Field Type | Mandatory or Optional | Corresponding RAS Message Field |
---|---|---|---|
IP address and port for Annex E. See Transport-Address. |
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-23:
Tag | Field Type | Mandatory or Optional | Corresponding RAS Message Field |
---|---|---|---|
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-24:
Tag | Field Type | Mandatory or Optional | Corresponding RAS Message Field |
---|---|---|---|
1This 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:
Disengage messages are used to indicate that a party wants to end the call.
This section describes the following:
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-25:
Tag | Field Type | Mandatory or Optional | Corresponding RAS Message Field |
---|---|---|---|
ARQ:srcCallSignalAddress. See Transport-Address. |
|||
DRQ:tokens. See ClearToken. |
|||
DRQ:gtd. See GTD. |
|||
DRQ:capacity. See CallCapacity. |
|||
Possible values for the DRQ-reason are:
Resource messages are used to indicate the current call capacity of the gateway.
This section describes the following:
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-26:
Tag | Field Type | Mandatory or Optional | Corresponding RAS Message Field |
---|---|---|---|
RRQ:callSignalAddress. See Transport-Address. |
|||
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 are used to request a change in bandwidth.
This section describes the following:
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-27:
Tag | Field Type | Mandatory or Optional | Corresponding RAS Message Field |
---|---|---|---|
See Note. See Transport-Address. |
|||
![]() |
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. |
The server may modify the fields shown in Table 4-28 in the BRQ.
Tag | Field Type | Mandatory or Optional | Corresponding RAS Message Field |
---|---|---|---|
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-29:
Tag | Field Type | Mandatory or Optional | Corresponding RAS Message Field |
---|---|---|---|
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-30:
Tag | Field Type | Mandatory or Optional | Corresponding RAS Message Field |
---|---|---|---|
Possible values for rejectReason are:
Progress messages provide information about the progress of a request. Progress messages include:
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-31:
Tag | Field Type | Mandatory or Optional | Corresponding RAS Message Field |
---|---|---|---|
Possible values of the delay are 1 through 65535 milliseconds.
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-32 shows the new Request IRR tags:
Tag | Field Type | Mandatory or Optional | Corresponding RAS Message Field |
---|---|---|---|
IRR:srcCallSignalAddress. See Transport-Address. |
|||
IRR:perCallInfo. See PerCallInfo. |
|||
IRR:capacity. See CallCapacity. |
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.
This message is returned in response to a REQUEST ALV message and does not contain any parameters in its body.
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:
There are two types of trigger registration messages: register and unregister.
The first line of each trigger registration request/response message uses the format:
The first line of each trigger unregistration request/response message uses the format:
Possible RAS message types are as follows:
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-33:
The message header is followed immediately by a blank line.
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. |
For Register RRQ and RAI, the tags shown in Table 4-34 can be used to filter messages:
Tag | Field Type | Mandatory or Optional | Corresponding RAS Message Field |
---|---|---|---|
Synchronize current registrations (send notification-only Request RRQs) |
For Register URQ, the tags shown in Table 4-35 can be used to filter messages:
Tag | Field Type | Mandatory or Optional | Corresponding RAS Message Field |
---|---|---|---|
For Register ARQ, DRQ, IRR, and BRQ the tags shown in Table 4-36 can be used to filter messages:
Tag | Field Type | Mandatory or Optional | Corresponding RAS Message Field |
---|---|---|---|
For Register LRQ, the tags shown in Table 4-37 can be used to filter messages:
Tag | Field Type | Mandatory or Optional | Corresponding RAS Message Field |
---|---|---|---|
![]() |
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. |
For Register LCF, the tags shown in Table 4-38 can be used to filter messages:
Tag | Field Type | Mandatory or Optional | Corresponding RAS Message Field |
---|---|---|---|
For Register LRJ, the tag shown in Table 4-39 can be used to filter messages:
Tag | Field Type | Mandatory or Optional | Corresponding RAS Message Field |
---|---|---|---|
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-40 shows the new GTD tags:
Tag | Field Type | Mandatory or Optional | Corresponding RAS Message Field |
---|---|---|---|
Length of the data sub-field. Contains 5-digit ASCII characters. |
|||
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:
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-41 shows the AlternateGK tags:
Tag | Field Type | Mandatory or Optional | Corresponding RAS Message Field |
---|---|---|---|
AlternateGK:rasAddress. See Transport-Address. |
|||
AlternateGK:gatekeeperIdentifier. See Alias-Address. |
|||
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-42 shows the FromReplyAddress tags:
Tag | Field Type | Mandatory or Optional | Corresponding RAS Message Field |
---|---|---|---|
Address of the gatekeeper from which this LRQ message was received. |
|||
Table 4-43 shows the new Service Control Session tags:
Tag | Field Type | Mandatory or Optional | Corresponding RAS Message Field |
---|---|---|---|
The CallCapacity message indicates the ability of the gateway to accept each type of call the gateway supports, such as voice calls.
Table 4-44 shows the CallCapacity tags:
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-45 shows the new Carrier Information tags:
Tag | Field Type | Mandatory or Optional | Corresponding RAS Message Field |
---|---|---|---|
Remote zone information. See RemoteZone. |
Table 4-46 shows the new Trunk Group Information tags:
Tag | Field Type | Mandatory or Optional | Corresponding RAS Message Field |
---|---|---|---|
Remote zone information. See RemoteZone. |
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:
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
If the message contains a PerCallInfo field, the following fields shown in Table 4-47 are included:
Tag | Field Type | Mandatory or Optional | Corresponding RAS Message Field |
---|---|---|---|
Table 4-48 shows the remoteZone field tags:
Tag | Field Type | Mandatory or Optional | Description |
---|---|---|---|
RAS address of the zone. See Transport-Address. |
|||
ARQ:tokens. See ClearToken. |
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.
If the message contains a clearToken field, the fields shown in Table 4-49 are included:
Tag | Field Type | Mandatory or Optional | Corresponding RAS Message Field |
---|---|---|---|
If the message contains a cryptoToken field, the additional fields shown in Table 4-50 are included:
Tag | Field Type | Mandatory or Optional | Corresponding RAS Message Field |
---|---|---|---|
Posted: Wed Jan 15 01:59:17 PST 2003
All contents are Copyright © 1992--2002 Cisco Systems, Inc. All rights reserved.
Important Notices and Privacy Statement.