|
This chapter describes the API functions and structures that an external application must use to exchange messages with the Cisco IOS Gatekeeper, and contains the following sections:
The external application links with the object code, which contains the API functions. The header file contains API prototypes and type definitions.
This section describes the functions provided with the API. These functions should be used by the external application to gather information from and provide information to the Cisco IOS Gatekeeper. The functions described in this section are:
This function sets up the socket for the application to communicate as a client with the Cisco IOS Gatekeeper. In this situation, the application is the client and the Gatekeeper is the server, which means the application must initiate the communication with the Cisco IOS Gatekeeper.
The input to this function is:
The return for this function is an integer. If the client socket connection has been set up successfully or is in progress, a connection handle is returned. This connection handle is the socket descriptor that the application uses to wait on a connection completion or read socket event. If an error occurs while setting up the client connection, the value -1 is returned. In this case, the error information is provided in the STATUS_TYPE.
This function sets up the socket for the application to communicate as a server with the Cisco IOS Gatekeeper. In this situation, the application is the server and the Gatekeeper is the client, which means that the application will accept incoming connections from Cisco IOS Gatekeeper clients.
The return for this function is an integer. If the client socket connection has been set up successfully or is in progress, a connection handle is returned. This connection handle is the socket descriptor that the application uses to wait on a connection completion or read socket event. If an error occurs while setting up the client connection, the value -1 is returned. In this case, the error information is provided in the STATUS_TYPE.
This function must be called by the application to indicate that a select event for a connect complete has occurred.
The input to this function is:
The return for this function is an integer. If the socket connection has been set up successfully or is in progress, a connection handle is returned. This connection handle is the socket descriptor that the application uses to wait on a connection completion or read socket event. If an error occurs while setting up the client connection, the value -1 is returned. In this case, the error information is provided in the STATUS_TYPE.
This function must be called by the application (when it is running in the server mode) to indicate that a select event for an incoming connection has occurred.
The return for this function is an integer. If the socket connection has been set up successfully or is in progress, a connection handle is returned. This connection handle is the socket descriptor that the application uses to wait on a connection completion or read socket event. If an error occurs while setting up the client connection, the value -1 is returned. In this case, the error information is provided in the STATUS_TYPE.
Applications can use this function to obtain the GKTMP version used by the API and the gatekeeper. The version number consists of a major number (gk_major) and a minor number (gk_minor). For example, Version 1 is represented as 100.
The return for this function is an integer. The integer indicates one of the following status codes:
This function closes the TCP connection between the external application and the Cisco IOS Gatekeeper. This function is called under error circumstances and when the external application no longer wants to maintain a relationship with the Cisco IOS Gatekeeper.
The input for this function is a pointer to the GKAPI_SOCK_INFO structure.
There is no return for this function.
This function allocates memory for the size of GK_READ_MSG structure. This structure is used to store messages received from the Cisco IOS Gatekeeper. This function contains an enumeration of the messages that can be received (REQUEST messages from the Cisco IOS Gatekeeper for RRQ, ARQ, LRQ, LCF, LRJ, as well as registration and unregistration responses from the Cisco IOS Gatekeeper for ARQ, RRQ, URQ, LRQ, LCF, LRJ messages) and a union of structures for the different messages.
Note When the external application no longer needs the message buffer, the application must call FreeReadMsgBuffer to release the memory back to the system. |
There is no input to this function.
The return for this function is a pointer to the GK_READ_MSG structure. If the memory allocation fails, this pointer will be NULL.
This function reads a message from the TCP socket and should be called when the external application has detected a read event on the socket. This function stores the message type into the structure. The parameters received in the message are stored in the structure that corresponds with the message type.
Note GetReadMsgBuffer must be called to allocate an empty buffer before this function can be used. FreeReadMsgBuffer must be called after this function has completed, except when the STATUS_TYPE returns INCOMPLETE_MSG_READ. |
After reading a message, this function sets the message type and populates the appropriate structure. For example, if an ARQ message has been received from the Cisco IOS Gatekeeper, the msgType parameter is set to ARQ_REQUEST_MSG and the ARQ_REQUEST_MSG structure is populated.
Because some parameters are optional, these parameters might not be received for a particular message. Structure members that are character pointers are initialized to NULL. Integers and enumerations are set to their initialization values. Therefore, the API can assume that if a structure member has a pointer set to NULL or to its initialization value, that particular parameter has not been received.
The following initialization values indicate that the parameter was not received from the Cisco IOS Gatekeeper:
The input for this function is:
The return for this function is the STATUS_TYPE. Possible values for STATUS_TYPE are:
This function frees memory that was allocated by the call to GetReadMsgBuffer and ReadMsgBuffer. This function must be called after processing the information returned by ReadMsgBuffer.
The input for this function is a pointer to the GK_READ_MSG structure.
There is no return for this function.
This function writes a response message to the Cisco IOS Gatekeeper. This structure contains RESPONSE_MSG_TYPE, which is an enumeration of the response messages that can be sent to the Cisco IOS Gatekeeper.
The calling function must set the message type and populate the appropriate structure within the union. For example, if a response RCF needs to be sent to the Cisco IOS Gatekeeper, the application should set the msgType to RCF_RESPONSE_MSG and populate the RCF_RESPONSE_MSG structure.
The following rules apply to responses sent by the external application to the Cisco IOS Gatekeeper:
Only changed or new fields should be populated and sent to the Cisco IOS Gatekeeper. Parameters that are not to be sent to the Cisco IOS Gatekeeper must either be set to their initialization value or to NULL (for pointers). The API assumes that if a structure member is set to its initialization value or has a pointer set to NULL, that parameter should not be sent to the Cisco IOS Gatekeeper.
The following initialization values indicate that the parameter should not be sent to the Cisco IOS Gatekeeper:
Note If the application requires additional time before responding to a message from the Cisco IOS Gatekeeper, the application can send a "delay" message by setting msgType to RIP_RESPONSE_MSG. The delay value (1 through 65536) must be specified and the transactionID must be the same as the one received from the Cisco IOS Gatekeeper. |
The input for this function is:
The return for this function is the STATUS_TYPE. Possible values for STATUS_TYPE are:
This function sends a registration message to the Cisco IOS Gatekeeper and allows triggers to be dynamically registered with the Cisco IOS Gatekeeper. This structure, REGISTER_MSG_TYPE, contains an enumeration of messages that can be registered with the Cisco IOS Gatekeeper.
The REGISTER_REQUEST_HEADER structure must include the "from," "to," "priority," and "notification-only" fields.
The input for this function is:
The return for this function is the STATUS_TYPE. Possible values for STATUS_TYPE are:
The following initialization values indicate that the parameter should not be sent to the Cisco IOS Gatekeeper for Registration, and the external application is not interested in these parameters:
This function sends an unregister message to the Cisco IOS Gatekeeper when the application no longer wants to receive a particular message. This structure contains REGISTER_MSG_TYPE, which is an enumeration of messages that can be unregistered with the Cisco IOS Gatekeeper.
The input for this function is:
The return for this function is the STATUS_TYPE. Possible values for STATUS_TYPE are:
This function allows the application to control the type of debug messages that the Gatekeeper API provides and the location of the debug output.
The input for this function is:
There is no return for this function.
This function returns the current debug setting for the Gatekeeper API.
There is no input for this function.
The return for this function is an integer that indicates the type of debugging being performed by the Gatekeeper API.
The Gatekeeper API stores all data received from the Cisco IOS Gatekeeper in structures. The structures point to character strings, integers, and often enumerations (which are lists of possible values for a specific field). The structures used by the Gatekeeper API are:
The GKAPI_SOCK_INFO structure is used by several API functions to identify the connection to the Cisco IOS Gatekeeper. This structure contains the fields shown in Table 5-1:
TCPPort and IPAddress are provided by the calling function. The API writes the handle into gkHandle and serverHandle when the connection is established. If an error is encountered in the handle creation or in the connection, the gkHandle will be set to -1. The external application is responsible for storing the handle and using it to read, write, and close the connection.
The GKAPI_TCP_ADDR_INFO structure is used to store the TCP Port and IP address. This structure contains the fields shown in Table 5-2:
The GKAPI_VERSION_INFO structure is used to store the major and minor version numbers of the gatekeeper TMP and API. This structure contains the fields shown in Table 5-3:
Field | Field Type | Description |
---|---|---|
The GK_REGISTER_MSG structure is used to send registration messages to the Cisco IOS Gatekeeper. This structure contains the fields shown in Table 5-4:
Field | Field Type | Description |
---|---|---|
See REGISTER_MSG_TYPE. |
||
See RRQ_REGISTER_MSG. |
||
See URQ_REGISTER_MSG. |
||
See ARQ_REGISTER_MSG. |
||
See LRQ_REGISTER_MSG. |
||
See LCF_REGISTER_MSG. |
||
See LRJ_REGISTER_MSG. |
The GK_UNREGISTER_MSG structure is used to send unregistration messages to the Cisco IOS Gatekeeper. This structure contains the fields shown in Table 5-5:
Field | Field Type | Description |
---|---|---|
See REGISTER_MSG_TYPE. |
||
Identifier of the version of GKTMP being used. For the initial release, the only possible value is 1. |
||
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. The limit of this field is MAX_ENDPOINT_LENGTH + 1. |
||
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. The limit of this field is MAX_ENDPOINT_LENGTH + 1. |
||
Priority of the filter. Possible values are 1 through 20. 1 is the highest priority. |
The REG_UNREG_RESP_MSG structure is used to process registration and unregistration responses from the Cisco IOS Gatekeeper. This structure contains the field shown in Table 5-6:
Field | Field Type | Description |
---|---|---|
The REGISTER_REQUEST_HEADER structure is used when a registration request is to be sent to Cisco IOS Gatekeeper. This structure contains the fields shown in Table 5-7:
The REGISTER_RESPONSE_HEADER structure is used when a registration or unregistration response is received from the Cisco IOS Gatekeeper. The registration or unregistration response is received after the application sends a registration or unregistration request to the Cisco IOS Gatekeeper. This structure contains the fields shown in Table 5-8:
Field | Field Type | Description |
---|---|---|
Identifier of the version of GKTMP being used. For the initial release, the only possible value is 1. |
||
Originator of the message, which for registration responses is the gatekeeper ID. The limit of this field is MAX_ENDPOINT_LENGTH+1. |
||
Receiver of the message, which for registration responses is the server ID. The limit of this field is MAX_ENDPOINT_LENGTH+1. |
||
Priority of the filter. Possible values are 1 through 20. 1 is the highest priority. |
||
See REG_STATUS_TYPE. |
The ARQ_REGISTER_MSG structure is used to send registrations for ARQ requests to the Cisco IOS Gatekeeper.
This structure contains the fields shown in Table 5-9:
Field | Field Type | Description |
---|---|---|
Sequence of alias addresses for the destination endpoint. The limit of this field is MAX_NUM_ARQ_DEST_INFO. |
||
Taken from the Q.931 Setup Redirecting Number IE. See REDIRECT_REASON_TYPE. The limit of this field is MAX_NUM_ARQ_REDIRECT_REASON. |
The RRQ_REGISTER_MSG structure is used to send registrations for RRQ requests to the Cisco IOS Gatekeeper. This structure contains the fields shown in Table 5-10:
Field | Field Type | Description |
---|---|---|
Type of endpoint being registered. See ENDPOINT_TYPE. The limit of this field is MAX_NUM_ENDPOINT_TYPES. |
||
Prefix associated with the supported protocol. The limit of this field is MAX_NUM_SUPPORTED_PREFIX. |
The URQ_REGISTER_MSG structure is used to send registrations for URQ requests to the Cisco IOS Gatekeeper. This structure contains the fields shown in Table 5-11:
Field | Field Type | Description |
---|---|---|
Type of endpoint being unregistered. See ENDPOINT_TYPE. The limit of this field is MAX_NUM_ENDPOINT_TYPES. |
||
Prefix associated with the supported protocol. The limit of this field is MAX_NUM_SUPPORTED_PREFIX. |
The LRQ_REGISTER_MSG structure is used to send registrations for LRQ requests to the Cisco IOS Gatekeeper.
This structure contains the fields shown in Table 5-12:
Field | Field Type | Description |
---|---|---|
Sequence of alias addresses for the destination endpoint. The limit of this field is MAX_NUM_LRQ_DEST_INFO. |
||
Taken from the Q.931 Setup Redirecting Number IE. See REDIRECT_REASON_TYPE. The limit of this field is MAX_NUM_LRQ_REDIRECT_REASON. |
The LCF_REGISTER_MSG structure is used to send registrations for LCF requests to the Cisco IOS Gatekeeper. This structure contains the fields shown in Table 5-13:
The LRJ_REGISTER_MSG structure is used to send registrations for LRJ requests to the Cisco IOS Gatekeeper. This structure contains the fields shown in Table 5-14:
Field | Field Type | Description |
---|---|---|
Sequence of alias addresses for the destination endpoint. The limit of this field is MAX_NUM_LRJ_DEST_INFO. |
The RAI_REGISTER_MSG structure is used to send registrations for RAI requests to the Cisco IOS Gatekeeper.
This structure contains the fields shown in Table 5-15:
Field | Field Type | Description |
---|---|---|
Type of endpoint. See ENDPOINT_TYPE. The limit of this field is MAX_NUM_ENDPOINT_TYPES. |
||
Prefix associated with the supported protocol. The limit of this field is MAX_NUM_SUPPORTED_PREFIX. |
The DRQ_REGISTER_MSG structure is used to send registrations for DRQ requests to the Cisco IOS Gatekeeper. This structure contains the fields shown in Table 5-16:
Field | Field Type | Description |
---|---|---|
Sequence of alias addresses for the destination endpoint. The limit of this field is MAX_NUM_ARQ_DEST_INFO. |
||
Taken from the Q.931 Setup Redirecting Number IE. See REDIRECT_REASON_TYPE. The limit of this field is MAX_NUM_LRQ_REDIRECT_REASON. |
The BRQ_REGISTER_MSG structure is used to send registrations for BRQ requests to the Cisco IOS Gatekeeper. This structure contains the fields shown in Table 5-17:
Field | Field Type | Description |
---|---|---|
Sequence of alias addresses for the destination endpoint. The limit of this field is MAX_NUM_ARQ_DEST_INFO. |
||
Taken from the Q.931 Setup Redirecting Number IE. See REDIRECT_REASON_TYPE. The limit of this field is MAX_NUM_ARQ_REDIRECT_REASON. |
The GK_READ_MSG structure is used process REQUEST messages from the Cisco IOS Gatekeeper for the supported RAS messages, as well as registration and unregistration responses from the Cisco IOS Gatekeeper for the supported RAS messages. This structure contains the fields shown in Table 5-18:
Field | Field Type | Description |
---|---|---|
See REQUEST_MSG_TYPE. |
||
See RRQ_REQUEST_MSG. |
||
See URQ_REQUEST_MSG. |
||
See ARQ_REQUEST_MSG. |
||
See LRQ_REQUEST_MSG. |
||
See LCF_REQUEST_MSG. |
||
See LRJ_REQUEST_MSG. |
||
See RAI_REQUEST_MSG. |
||
See DRQ_REQUEST_MSG. |
||
See BRQ_REQUEST_MSG. |
||
See UNSUPPORTED_MSG. |
||
See REG_UNREG_RESP_MSG. |
If the message received from the Cisco IOS Gatekeeper is a RAS message that is not supported by the API function, the msgType is set to MSG_NOT_SUPPORTED. If a response is required, an appropriate response is constructed by the API function and sent to the Cisco IOS Gatekeeper. The header information in the UNSUPPORTED_MSG structure is filled in by the API function. This situation could occur if the Cisco IOS Gatekeeper has been upgraded to support new messages but the API function has not been correspondingly upgraded.
If the message received from the Cisco IOS Gatekeeper, is not recognized by the API function, the msgType is set to UNKNOWN_MSG and the STATUS_TYPE is set to MSG_READ_ERROR. In this case, the external application should close the connection to the Cisco IOS Gatekeeper by calling the CloseGateKeeperConnection function.
The HEADER_INFO structure is used to process header information sent from the Cisco IOS Gatekeeper or information that is sent by the application to the Cisco IOS Gatekeeper.
This structure contains the fields shown in Table 5-19:
The ARQ_REQUEST_MSG structure is used to process ARQ requests from the Cisco IOS Gatekeeper. This structure contains the fields shown in Table 5-20:
Field | Field Type | Description |
---|---|---|
See HEADER_INFO. |
||
Transport address used at the destination for call signaling. |
||
Bandwidth (in 100 kbps) requested for the bi-directional call. |
||
Indicates to the Cisco IOS Gatekeeper that the call is incoming. |
||
A unique call identifier (set by the originating endpoint), which can be used to associate RAS signaling with the modified Q.931 signaling used in H.225.0. |
||
Whether the endpoint can copy information from the resulting ACF into the destinationAddress, destExtraCallInfo, and remoteExtensionAddress fields of the SETUP message. |
||
Taken from the Number Digits field of Q.931 Setup Redirecting Number IE. |
||
Taken from the Q.931 Setup Redirecting Number IE. See REDIRECT_REASON_TYPE. |
||
Call signaling transport address of the endpoint sending the ARQ. |
||
See ALV_RESPONSE_MSG. |
||
See CLEAR_TOKEN. |
The RRQ_REQUEST_MSG structure is used to process RRQ requests from the Cisco IOS Gatekeeper. This structure contains the fields shown in Table 5-21:
Field | Field Type | Description |
---|---|---|
See HEADER_INFO. |
||
Registration and status transport address for this endpoint. |
||
List of alias addresses by which other terminals can identify this terminal. |
||
Type of endpoint being registered. See ENDPOINT_TYPE. |
||
See ALV_RESPONSE_MSG. |
||
See CLEAR_TOKEN. |
||
The URQ_REQUEST_MSG structure is used to process URQ requests from the Cisco IOS Gatekeeper. This structure contains the fields shown in Table 5-22:
Field | Field Type | Description |
---|---|---|
See HEADER_INFO. |
||
The LRQ_REQUEST_MSG structure is used to process LRQ requests from the Cisco IOS Gatekeeper. This structure contains the fields shown in Table 5-23:
Field | Field Type | Description |
---|---|---|
See HEADER_INFO. |
||
Taken from the Number Digits field of Q.931 Setup Redirecting Number IE. |
||
Taken from the Q.931 Setup Redirecting Number IE. See REDIRECT_REASON_TYPE. |
||
The LCF_REQUEST_MSG structure is used to process LCF requests from the Cisco IOS Gatekeeper. This structure contains the fields shown in Table 5-24:
Field | Field Type | Description |
---|---|---|
See HEADER_INFO. |
||
Taken from the Number Digits field of Q.931 Setup Redirecting Number IE. |
||
Taken from the Q.931 Setup Redirecting Number IE. See REDIRECT_REASON_TYPE. |
||
Registration and status transport address for this endpoint. |
||
Alias address of a called endpoint, present in cases where this information is required to traverse multiple gateways. |
||
Type of destination endpoint. See ENDPOINT_TYPE. |
||
The LRJ_REQUEST_MSG structure is used to process LRJ requests from the Cisco IOS Gatekeeper. This structure contains the fields shown in Table 5-25:
Field | Field Type | Description |
---|---|---|
See HEADER_INFO. |
||
Taken from the Number Digits field of Q.931 Setup Redirecting Number IE. |
||
Taken from the Q.931 Setup Redirecting Number IE. See REDIRECT_REASON_TYPE. |
||
Reason for the rejection of the request. See LRJ_REJECT_REASON_TYPE. |
The RAI_REQUEST_MSG structure is used to process RAI requests from the Cisco IOS Gatekeeper. This structure contains the fields shown in Table 5-26:
Field | Field Type | Description |
---|---|---|
The DRQ_REQUEST_MSG structure is used to process DRQ requests from the Cisco IOS Gatekeeper. This structure contains the fields shown in Table 5-27:
Field | Field Type | Description |
---|---|---|
Reason received for a DRQ sent by an endpoint. See DRQ_REASON_TYPE. |
||
Indicates that this party was the original destination. The value is TRUE or FALSE. |
||
A unique call identifier (set by the originating endpoint) which can be used to associate RAS signaling with the modified Q.931 signaling used in H225.0. |
||
See CLEAR_TOKEN. |
The BRQ_REQUEST_MSG structure is used to process BRQ requests from the Cisco IOS Gatekeeper. This structure contains the fields shown in Table 5-28:
Field | Field Type | Description |
---|---|---|
See HEADER_INFO. |
||
Indicates to the Cisco IOS Gatekeeper that the call is incoming. |
||
Bandwidth (in 100 kbps) requested for the bi-directional call. |
||
A unique call identifier (set by the originating endpoint), which can be used to associate RAS signaling with the modified Q.931 signaling used in H.225.0. |
||
See ALV_RESPONSE_MSG. |
||
See CLEAR_TOKEN. |
The IRR_REQUEST_MSG structure is used to process IRR requests from the Cisco IOS Gatekeeper. This structure contains the fields shown in Table 5-29.
Field | Field Type | Description |
---|---|---|
Contains information about the call, including the call identifier, conference ID, originator, bandwidth, and call start time. |
The ALV_REQUEST_MSG structure is used to process ALV requests from the Cisco IOS Gatekeeper. This structure contains the fields shown in Table 5-30:
Field | Field Type | Description |
---|---|---|
See HEADER_INFO. |
The GK_WRITE_MSG structure is used to process responses from the external application to the Cisco IOS Gatekeeper.
This structure contains the fields shown in Table 5-31:
Field | Field Type | Description |
---|---|---|
See RESPONSE_MSG_TYPE. |
||
See ARQ_RESPONSE_MSG. |
||
See ACF_RESPONSE_MSG. |
||
See ARJ_RESPONSE_MSG. |
||
See RRQ_RESPONSE_MSG. |
||
See RRJ_RESPONSE_MSG. |
||
See RCF_RESPONSE_MSG. |
||
See LRQ_RESPONSE_MSG. |
||
See LCF_RESPONSE_MSG. |
||
See LRJ_RESPONSE_MSG. |
||
See RIP_RESPONSE_MSG. |
The ARQ_RESPONSE_MSG structure is used to process ARQ responses from the external application. This structure contains the fields shown in Table 5-32:
Field | Field Type | Description |
---|---|---|
See HEADER_INFO. |
||
Transport address used at the destination for call signaling. |
||
Bandwidth (in 100 kbps) requested for the bidirectional call. |
||
Taken from the Number Digits field of Q.931 Setup Redirecting Number IE. |
||
Taken from the Q.931 Setup Redirecting Number IE. See REDIRECT_REASON_TYPE. |
||
The ACF_RESPONSE_MSG structure is used to process ACF responses from the external application. This structure contains the fields shown in Table 5-33:
Field | Field Type | Description |
---|---|---|
See HEADER_INFO. |
||
Transport address used at the destination for call signaling. |
||
Alias address of a called endpoint, present in cases where this information is required to traverse multiple gateways. |
||
Bandwidth (in 100 kbps) requested for the bidirectional call. |
||
Type of destination endpoint. See ENDPOINT_TYPE. |
||
See ALTERNATE_ENDPOINT. |
||
See CLEAR_TOKEN. |
||
The ARJ_RESPONSE_MSG structure is used to process ARJ responses from the external application. This structure contains the fields shown in Table 5-34:
Field | Field Type | Description |
---|---|---|
See HEADER_INFO. |
||
Reason the request was rejected. See ARJ_REJECT_REASON_TYPE. |
The RRQ_RESPONSE_MSG structure is used to process RRQ responses from the external application. This structure contains the fields shown in Table 5-35:
Field | Field Type | Description |
---|---|---|
See HEADER_INFO. |
||
List of alias addresses by which other terminals can identify this terminal. |
||
The RCF_RESPONSE_MSG structure is used to process RCF responses from the external application. This structure contains the fields shown in Table 5-36:
Field | Field Type | Description |
---|---|---|
See HEADER_INFO. |
||
List of alias addresses by which other terminals can identify this terminal. |
||
See ALTERNATE_GK. |
The RRJ_RESPONSE_MSG structure is used to process RRJ responses from the external application. This structure contains the fields shown in Table 5-37:
Field | Field Type | Description |
---|---|---|
See HEADER_INFO. |
||
Reason the request was rejected. See RRJ_REJECT_REASON_TYPE. |
The LRQ_RESPONSE_MSG structure is used to process LRQ responses from the external application. This structure contains the fields shown in Table 5-38:
Field | Field Type | Description |
---|---|---|
See HEADER_INFO. |
||
The LCF_RESPONSE_MSG structure is used to process LCF responses from the external application. This structure contains the fields shown in Table 5-39:
Field | Field Type | Description |
---|---|---|
See HEADER_INFO. |
||
Registration and status transport address for this endpoint. |
||
Alias address of a called endpoint, present in cases where this information is required to traverse multiple gateways. |
||
Type of destination endpoint. See ENDPOINT_TYPE. |
||
The LRJ_RESPONSE_MSG structure is used to process LRJ responses from the external application. This structure contains the fields shown in Table 5-40:
Field | Field Type | Description |
---|---|---|
See HEADER_INFO. |
||
Reason the request was rejected. See LRJ_REJECT_REASON_TYPE. |
The BRQ_RESPONSE_MSG structure is used to process BRQ responses from the external application. This structure contains the fields shown in Table 5-41:
Field | Field Type | Description |
---|---|---|
See HEADER_INFO. |
||
Bandwidth (in 100 kbps) requested for the bidirectional call. |
The BCF_RESPONSE_MSG structure is used to process BCF responses from the external application. This structure contains the fields shown in Table 5-42:
Field | Field Type | Description |
---|---|---|
See HEADER_INFO. |
||
Bandwidth (in 100 kbps) requested for the bidirectional call. |
The BRJ_RESPONSE_MSG structure is used to process BRJ responses from the external application. This structure contains the fields shown in Table 5-43:
Field | Field Type | Description |
---|---|---|
See HEADER_INFO. |
||
The ALV_RESPONSE_MSG structure is used to process ALV responses from the external application. This structure contains the fields shown in Table 5-44:
Field | Field Type | Description |
---|---|---|
See HEADER_INFO. |
The CRYPTO_H323_TOKEN structure is used to process cryptoTokens. This structure contains the fields shown in Table 5-45:
Field | Field Type | Description |
---|---|---|
See CRYPTO_EP_PWD_HASH. |
||
See CRYPTO_EP_PWD_ENCR. |
||
See CRYPTO_EP_CERT. |
The CRYPTO_EP_PWD_HASH structure is used to process cryptoTokens. This structure contains the sections shown in Table 5-46:
Field | Field Type | Description |
---|---|---|
Registration and status transport address for this endpoint. |
||
16 octet IA5String that represents the MD5 hashed encoded PwdCertToken. |
The CRYPTO_EP_PWD_ENCR structure is used to process the encrypted data of a cryptoToken. This structure contains the fields shown in Table 5-47:
Field | Field Type | Description |
---|---|---|
The CRYPTO_EP_CERT structure is used to process the authentication certificate of a cryptoToken. This structure contains the fields shown in Table 5-48:
The CLEAR_TOKEN structure is used to process the clear tokens field. This structure contains the fields shown in Table 5-49:
The ALTERNATE_GK structure is used to process information about an alternate gatekeeper. This structure contains the fields shown in Table 5-50:
Field | Field Type | Description |
---|---|---|
Registration and status transport address for this endpoint. |
||
Priority of this gatekeeper. Possible values are 1 through 127. |
The ALTERNATE_ENDPOINT structure is used to process information about an alternate H.323 endpoint.
This structure contains the fields shown in Table 5-51:
Field | Field Type | Description |
---|---|---|
Registration and status transport address for this endpoint. |
||
See CLEAR_TOKEN. |
The ALTERNATE_TRANSPORT_ADDR_TYPE structure is used to convey information about an Annex E transport address of the destination H.323 endpoint. This structure contains the fields shown in Table 5-52:
The RIP_RESPONSE_MSG structure is used to process requests from the external application for additional time. This structure contains the fields shown in Table 5-53:
Field | Field Type | Description |
---|---|---|
See HEADER_INFO. |
||
Amount of time, in milliseconds (1 through 65,536), that the endpoint should wait before retrying the request. |
The UNSUPPORTED_MSG structure is used to process requests from the Cisco IOS Gatekeeper that contain a RAS message type that is not supported by the API. This structure contains the field shown in Table 5-54:
Field | Field Type | Description |
---|---|---|
See HEADER_INFO. |
Some of the API structures contain enumerations. An enumeration is simply a list of possible values. This section lists the enumerations used by the structures and includes the following sections:
The STATUS_TYPE enumeration lists the possible return values from calls to read, write, register and unregister functions. The possible values are:
The REG_STATUS_TYPE enumeration lists the possible status values for registration and unregistration responses received from the Cisco IOS Gatekeeper. The possible values are:
The ENDPOINT_TYPE enumeration lists the possible types of endpoints. The possible values are:
The REDIRECT_REASON_TYPE enumeration lists the possible reasons that a call might be redirected. The possible values are:
The DRQ_REASON_TYPE enumeration lists the reasons received for a DRQ sent by an endpoint. The possible values are:
The LRJ_REJECT_REASON_TYPE enumeration lists the possible reasons that an LRQ request might be rejected. The possible values are:
The REQUEST_MSG_TYPE enumeration lists the possible messages that can be received from the Cisco IOS Gatekeeper. The possible values are:
The RRJ_REJECT_REASON_TYPE enumeration lists the possible reasons that an RRQ request might be rejected. The possible values are:
The ARJ_REJECT_REASON_TYPE enumeration lists the possible reasons that an ARQ request might be rejected. The possible values are:
The BRJ_REJECT_REASON_TYPE enumeration lists the possible reasons that a BRQ request might be rejected. The possible values are:
The RESPONSE_MSG_TYPE enumeration lists the possible messages that the external application can send to the Cisco IOS Gatekeeper. The possible values are:
The REGISTER_MSG_TYPE enumeration lists the possible registration messages that the external application can send to the Cisco IOS Gatekeeper. The possible values are:
The REPORT_DEST_T enumeration lists the possible destinations for the Gatekeeper API debug output. The possible values are:
The CRYPTO_H323_TOKEN_TYPE_S enumeration lists the possible types of cryptoTokens. The possible values are:
The USE_SPECIFIED_TRANSPORT_TYPE_T enumeration lists the possible transport types that an endpoint can select for H.225 signalling. The possible values are:
Some of the fields are limited in size. The limits are set using variables in the header file. The limits as set in the default header file are shown in Table 5-55:
Variable | Initial Value |
---|---|
Posted: Wed Jan 15 01:49:19 PST 2003
All contents are Copyright © 1992--2002 Cisco Systems, Inc. All rights reserved.
Important Notices and Privacy Statement.