Cisco Customer Voice Portal (CVP) Release 3.1 Solution Reference Network Design (SRND)
Using the GKTMP NIC
Downloads: This chapterpdf (PDF - 189.0KB) The complete bookPDF (PDF - 1.96MB) | Feedback

Using the GKTMP NIC

Table Of Contents

Using the GKTMP NIC

The Cisco Gatekeeper External Interface

The ICM GKTMP NIC

Typical Applications of GKTMP with CVP

Protocol Level Call Flow

Pre-Routing of incoming calls, call context passing not required

Pre-Routing of incoming calls, call context passing is required

Routing of post-ICM calls

Deployment Implications

Pre-Routing of incoming calls, call context passing not required

Pre-Routing of incoming calls, call context passing is required

Routing of post-ICM calls

Other implications


Using the GKTMP NIC


This chapter covers the following topics:

The Cisco Gatekeeper External Interface

The ICM GKTMP NIC

Typical Applications of GKTMP with CVP

The Cisco Gatekeeper External Interface

The Cisco H.323 Gatekeeper provides an external interface which uses Gatekeeper Transaction Message Protocol (GKTMP) to handoff the processing of RAS requests to external applications. This allows organizations to supplement the onboard capabilities of the gatekeeper and provide support for externally managed dial plans and intelligent call routing in an H.323 voice network.

GKTMP is based on RAS and provides a set of ASCII request/response messages that can be used to exchange information between the IOS Gatekeeper and the external application over a TCP connection.

For more information, consult the Cisco Gatekeeper External Interface Reference:

http://www.cisco.com/en/US/partner/products/sw/iosswrel/ps5207/products_programming_reference_guide_book09186a0080380f4b.html

The ICM GKTMP NIC

Using its GKTMP NIC the ICM can function as a GKTMP server for the gatekeeper, processing GKTMP request messages as route requests and running routing scripts in the normal way. The RAS sourceInfo Alias and destinationInfo Alias are made available to the ICM script as the Calling Line ID and Dialed Number respectively, the latter typically being used for script selection by the ICM Router. The ICM script might perform many different functions including database or back-end system access and finally sends a label back to the NIC for return to the gatekeeper and ultimately back to the requesting endpoint as the modified destinationInfo Alias. The ICM script can also modify the sourceInfo Alias. However, not all requesting endpoints utilize the translated sourceInfo Alias returned; IOS gateways make use of this whereas the CVP Call Server and Cisco CallManager both ignore it.

To force the gatekeeper to reject the Admission-Request (ARQ) and return an Admission-Reject (ARJ) to the requesting endpoint the ICM script can return a BUSY label, optionally with an additional reason code, for example DESTINATION_UNKNOWN.

For a complete description of the ICM GKTMP NIC and how it is configured, consult the GKTMP NIC System Management Guide Supplement, available from your Cisco Systems Engineer (SE).

Typical Applications of GKTMP with CVP

The GKTMP NIC can be used with CVP in both Pre-Routing and Post-Routing call scenarios. The former is used to process the Admission-Request from the ingress gateway before the call is routed to the CVP Call Server and answered, the latter for transfers being performed by the CVP Call Server.

Intelligent rejection before the call is answered by CVP

When an H.225 SETUP is received by the CVP Call Server it answers the call, returning a CONNECT message immediately. Sometimes it is required to make a routing decision before delivering the call to CVP and it being answered. One example is the use of look-ahead routing in which the ICM script determines the availability and leachability of other ICM peripherals that will be required for the overall call scenario once the call has been delivered to CVP. Using the GKTMP NIC it is possible to reject calls intelligently for alternate routing via the TDM network rather than answer them and not have the resources to handle them subsequently.

Selection of CVP Call Server based on H.323 call information

Occasionally the gatekeeper static configuration is not sufficient for selection of the most appropriate CVP Call Server to handle an incoming call. For example, the routing decision might need to be based on the calling line ID or source signalling address.

Manipulation of the calling line ID

Modification of the sourceInfo Alias is sometimes useful in order to overload the calling line ID with additional information required by the destination endpoint where translation routing is not possible.

ICM-based dial plan

ICM implements a centralized H.323 voice network dial plan, reducing the need for dial plan configuration on individual gatekeepers. This is appropriate only if the dial plan is large, complex, dynamic and difficult to maintain across multiple gatekeepers.

Time of day routing

Allows the gatekeeper routing to be supplemented with date and time based decisions, possibly to handle time dependent resource availability.

Back-end system and database queries

ICM database lookup or application gateway capabilities data from external systems can be incorporated into routing decisions.

Filtering calls that might be sent immediately to an available destination and bypass CVP

While this approach might be seen as a way to avoid using CVP Call Server resources, it limits the functionality available, for example, there can be no intelligent requery for alternative destinations on ring-no-answer nor will it allow the call to be taken back to CVP for subsequent call treatment and transfers.

Pre-Routing with context passing to CVP

Used if call context collected during the Pre-Route phase of the call needs to be passed to CVP rather than simply performing a standalone routing request via the GKTMP NIC. In this example, the CVP Call Server must be configured as a Type 2 VRU in order that the call can be translation routed to it and still perform a subsequent transfer. (Note: this capability has limitations in ICM versions prior to 7.0(0) - see Deployment Implications.)

Protocol Level Call Flow

Fundamentally, GKTMP allows an ICM routing script to provide additional external business rules that are called by the gatekeeper to select an alternative destination label or target IP address for a call, given a dialed number or label. However, the protocol level call flow differs depending on the purpose for which the GKTMP request is being used. We consider the following uses of GKTMP separately:

Pre-Routing of incoming calls, call context passing not required

In this mode of operation, calls arriving at an ingress gateway make a request to ICM to select either a particular CVP Call Server target or a non-CVP target. When a CVP Call Server is selected, the call is delivered to CVP as a completely new call, with no link to the ICM script involved in the GKTMP-based routing step.

Pre-Routing of incoming calls, call context passing is required

Here, calls which arrive at an ingress gateway make a request to ICM via the GKTMP NIC before being delivered to a particular CVP Call Server target. Any information obtained by this initial ICM routing script is preserved and made available to the ICM script as processing resumes when the call is delivered to the CVP Call Server.

Routing of post-ICM calls

This is to modify the routing of calls that are being transferred to a destination label returned to CVP by an ICM routing script. No information obtained by the previous routing script is available to the new script invoked by the GKTMP request, which functions in a purely standalone manner.

Pre-Routing of incoming calls, call context passing not required

1. Call arrives at the ingress gateway

2. The ingress gateway requests the gatekeeper to identify a target CVP Call Server (or other IP destination)

3. The gatekeeper issues a GKTMP Request ARQ to ICM via the GKTMP NIC

4. ICM starts a routing script based on dialed number, ANI, time of day, etc.

5. The ICM routing script might return either a Response ARQ or a Response ACF to the gatekeeper. In the former case, the ICM returns modified information in the response and the gatekeeper resumes ARQ processing to select the IP endpoint. This approach is adopted if the ICM is returning a destination label only and not selecting the required destination IP endpoint address(es) explicitly. In the latter case, the ICM completes the processing of the request, returning modified information and selected target IP endpoints. In this case the gatekeeper regards the request as completed, does no further processing of the request and returns the ACF to the ARQing endpoint. The ICM routing script ends here.

6. The gatekeeper returns the selected IP address to the ingress gateway

7. If the target is a non-CVP device, the ingress gateway sets up a VoIP call to that target.

8. If the target is a CVP Call Server, the ingress gateway sets up a new call to it.

9. The CVP Call Server sends a New Call message to ICM

10. ICM starts an independent routing script to handle the incoming call

11. Normal call flow continues. Transfer to VRU leg, Transfer to agent, as well as subsequent blind Network VRU Transfers to secondary agents or return to queue are fully supported.

Pre-Routing of incoming calls, call context passing is required

1. Call arrives at the ingress gateway

2. The ingress gateway requests the gatekeeper to identify a target CVP Call Server (or other IP destination)

3. The gatekeeper issues a GKTMP Request ARQ to ICM via the GKTMP NIC

4. ICM starts a routing script based on dialed number, ANI, time of day, etc.

5. The ICM routing script executes a TranslationRouteToVRU to select a target CVP Call Server

6. ICM returns the selected translation route label (and optionally the destination endpoint IP address) in the GKTMP Response ARQ/ACF via the GKTMP NIC.

7. The gatekeeper returns the selected IP address to the ingress gateway

8. The ingress gateway sets up a new call to the selected CVP Call Server

9. The CVP Call Server sends a RequestInstruction message to ICM

10. The ICM routing script resumes after the TranslationRouteToVRU node

11. Normal call flow continues: Transfer to VRU leg, Transfer to agent, as well as subsequent blind Network VRU Transfers to secondary agents or return to queue are fully supported. (See Deployment Implications for pre-ICM 7.0(0) caveats.)

Routing of post-ICM calls

1. ICM selects a target agent or other destination label. The ICM routing script ends here.

2. ICM returns the selected label to the CVP Call Server

3. The CVP Call Server requests the gatekeeper for the endpoint IP address associated with that label

4. The gatekeeper issues a GKTMP Request ARQ to ICM via the GKTMP NIC

5. ICM starts a completely independent routing script based on the selected label, ANI, time of day, etc.

6. The ICM routing script selects an appropriate target for the call

7. ICM returns the selected label (and optionally the destination endpoint IP address) in the GKTMP Response ARQ/ACF response via the GKTMP NIC. The ICM routing script ends here.

8. The gatekeeper returns the selected endpoint IP address to the CVP Call Server

9. The CVP Call Server performs and Empty Capability Set transfer, communicating with the ingress gateway and the transfer destination endpoint to establish a VoIP call between them.

Deployment Implications

GKTMP is a simple request/response protocol. From an ICM perspective, this means that the GKTMP NIC cannot perform any call control other than returning a single label and/or endpoint IP address. Third party call control through the GKTMP NIC is not possible once that single destination has been returned. However, it is possible when call control responsibilities are handed off to CVP. The discussion below covers the implications of this for each of the three types of call flow described above:

Pre-Routing of incoming calls, call context passing not required

Pre-Routing of incoming calls, call context passing is required

Routing of post-ICM calls

Other implications

Pre-Routing of incoming calls, call context passing not required

Two ICM routing scripts are required for this option. The first script identifies the initial target for the incoming call; the second script is the normal routing script for call handling at CVP which is assumed elsewhere in this guide. The transfer from one to the other is via a plain label; it is not a translation route or a VRU leg transfer. The GKTMP-initiated script cannot perform any queuing or other VRU activity; it can only modify the Admission-Request content and optionally return an endpoint IP address.

In the case where the Pre-Routing script returns a label which is associated with an endpoint other than a CVP Call Server, no further call control is possible (unless the end point is an ACD or VRU with its own post-routing interface into ICM and its own ability to perform call control operations).

Pre-Routing of incoming calls, call context passing is required

With this option, the GKTMP-initiated and CVP-initiated routing scripts are one and the same. A TranslationRouteToVRU node must be used to move the call to a Type 2 CVP NetworkVRU. This node must precede any Queue node if the customer needs the ability to perform any subsequent agent-to-agent transfers, even if an appropriate agent is already available. This might seem like an extraneous transfer, but it is necessary in order to force call control handoff to CVP.

Following the TranslationRouteToVRU and prior to executing any RunExternalScript nodes, a second VRU transfer is required using a SendToVRU node to establish the VRU call leg to the VXML gateway.

With ICM implementations prior to 7.0(0), this capability is severely limited, and usually not recommended. Specifically, there are two restrictions:

Once ICM delivers the call to an agent, subsequent agent to agent transfers are not supported via blind Network VRU Transfers with queuing. Agent to agent transfers can still be performed using the ACD's or IPCC's own call switching capabilities, but the Type 2 CVP Network VRU can play no further part in the call.

The second transfer to CVP's VRU leg cannot be done with a SendToVRU node. However, two workarounds are possible, each with its own limitations:

Use a second TranslationRouteToVRU node instead of the SendToVRU step. This however requires that the destination be configured as a Type 8 NetworkVRU, which means it must be a different physical CVP Call Server to the Type 2 CVP platform. This leads to a requirement for extra hardware which might not otherwise be needed based on capacity expectations alone.

Do not do the transfer to CVP's VRU leg at all. This leaves the media terminated at the CVP Call Server and does not use a VXML gateway at all. It allows no support for ASR/TTS or VoiceXML Server applications, and it requires G.711 RTP between the ingress gateway and the CVP Call Server. This is a deprecated call flow and might soon be declared end-of-life.

Routing of post-ICM calls

Two completely independent ICM routing scripts are used in this scenario. The only connection between the two is that the label returned by the first routing script is used as a Dialed Number which the gatekeeper uses to invoke the second routing script. This is not a translation route or VRU leg transfer, and call context is not available to the second script other than what is included in the gatekeeper request itself.

Other implications

Note that inserting the GKTMP NIC into the call flow does result in additional route requests being processed by the ICM Router for each call processed in this way and additional call detail records will be written by the ICM Logger. Where possible, configure the GKTMP server triggers on the gatekeeper such that only the calls specifically requiring the additional routing functionality afforded by the GKTMP NIC generate a Request ARQ to the ICM.