Cisco Unified Customer Voice Portal (CVP) 7.x Solution Reference Network Design (SRND)
Using the GKTMP NIC
Downloads: This chapterpdf (PDF - 370.0KB) The complete bookPDF (PDF - 3.14MB) | Feedback

Using the GKTMP NIC

Table Of Contents

Using the GKTMP NIC

The Cisco Gatekeeper External Interface

The Unified ICM GKTMP NIC

Typical Applications of GKTMP with Unified CVP

Protocol-Level Call Flow

Deployment Implications


Using the GKTMP NIC


Last revised on: August 8, 2008

 

This chapter covers the following topics:

The Cisco Gatekeeper External Interface

The Unified ICM GKTMP NIC

Typical Applications of GKTMP with Unified CVP

The Cisco Gatekeeper External Interface

The Cisco H.323 Gatekeeper provides an external interface that uses Gatekeeper Transaction Message Protocol (GKTMP) to hand off the processing of Registration Admission Status (RAS) requests to external applications. This feature allows organizations to supplement the on-board capabilities of the gatekeeper and to 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 and response messages that can be used to exchange information between the Cisco IOS Gatekeeper and the external application over a TCP connection.

For more information, consult the Cisco Gatekeeper External Interface Reference, available at

http://www.cisco.com/en/US/docs/ios/12_3/gktmpv4_3/guide/gktmp4_3.html

The Unified ICM GKTMP NIC

Using its GKTMP NIC, Unified 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 Unified ICM script as the Calling Line ID and Dialed Number respectively, the latter typically being used for script selection by the Unified ICM Router. The Unified 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 Unified ICM script can also modify the sourceInfo Alias. However, not all requesting endpoints use the translated sourceInfo Alias that is returned; Cisco IOS gateways make use of it, whereas the Unified CVP Call Server and Cisco Unified Communications Manager both ignore it.

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

For information on how to configure the GKTMP NIC, consult the ICM Setup and Installation Guide, available at

http://www.cisco.com/en/US/docs/voice_ip_comm/cust_contact/contact_center/icm_enterprise/icm_enterprise_7_5/installation/guide/icm75instl.pdf

Typical Applications of GKTMP with Unified CVP

The GKTMP NIC can be used with Unified 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 Unified CVP Call Server and answered, the latter for transfers being performed by the Unified CVP Call Server.

Intelligent rejection before the call is answered by Unified CVP

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

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

Occasionally the gatekeeper static configuration is not sufficient for selection of the most appropriate Unified 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.

Unified ICM-based dial plan

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

Time-of-day routing

This feature allows the gatekeeper routing to be supplemented with decisions based on date and time, possibly to handle time-dependent resource availability.

Back-end system and database queries

Unified 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 Unified CVP

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

Pre-routing with context passing to Unified CVP

This method is used if call context collected during the pre-routing phase of the call needs to be passed to Unified CVP rather than simply performing a standalone routing request via the GKTMP NIC. In this example, the Unified CVP Call Server must be configured as a Type 2 VRU so that the call can be translation-routed to it and still perform a subsequent transfer.

Protocol-Level Call Flow

Fundamentally, GKTMP allows a Unified 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, as described in the following scenarios:

Pre-routing of incoming calls, but call context passing is not required

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

Pre-routing of incoming calls, and call context passing is required

In this scenario, calls that arrive at an ingress gateway make a request to Unified ICM via the GKTMP NIC before being delivered to a particular Unified CVP Call Server target. Any information obtained by this initial Unified ICM routing script is preserved and made available to the Unified ICM script as processing resumes when the call is delivered to the Unified 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 Unified 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, but call context passing is not required

1. A call arrives at the ingress gateway.

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

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

4. Unified ICM starts a routing script based on dialed number, ANI, time of day, and so forth.

5. The Unified ICM routing script might return either a Response ARQ or a Response ACF to the gatekeeper. In the former case, Unified ICM returns modified information in the response, and the gatekeeper resumes ARQ processing to select the IP endpoint. This approach is adopted if Unified ICM is returning a destination label only and not selecting the required destination IP endpoint address(es) explicitly. In the latter case, Unified ICM completes the processing of the request, returning modified information and the 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 endpoint that issued the ARQ. The Unified ICM routing script ends at this point.

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

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

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

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

10. Unified 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, and call context passing is required

1. A call arrives at the ingress gateway.

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

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

4. Unified ICM starts a routing script based on dialed number, ANI, time of day, and so forth.

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

6. Unified ICM returns the selected translation route label (and optionally the destination endpoint IP address) in the GKTMP Response ARQ or 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 Unified CVP Call Server.

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

10. The Unified 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. (For limitations in Unified ICM versions prior to 7.0(0), see Deployment Implications.)

Routing of post-ICM calls

1. Unified ICM selects a target agent or other destination label. The Unified ICM routing script ends at this point.

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

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

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

5. Unified ICM starts a completely independent routing script based on the selected label, ANI, time of day, and so forth.

6. This new Unified ICM routing script selects an appropriate target for the call.

7. Unified ICM returns the selected label (and optionally the destination endpoint IP address) in the GKTMP Response ARQ or ACF response via the GKTMP NIC. The Unified ICM routing script ends at this point.

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

9. The Unified 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 the perspective of Unified ICM, 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 Unified CVP. The following discussion covers these call control implications for each of the three types of call flows described in the previous section:

Pre-routing of incoming calls, but call context passing is not required

Pre-routing of incoming calls, and call context passing is required

Routing of post-ICM calls

Other implications

Pre-routing of incoming calls, but call context passing is 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 Unified CVP, which is described elsewhere in this guide. The transfer from one script 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 that is associated with an endpoint other than a Unified CVP Call Server, no further call control is possible unless the endpoint is an ACD or VRU with its own post-routing interface into Unified ICM and its own ability to perform call control operations.

Pre-routing of incoming calls, and call context passing is required

With this option, the GKTMP-initiated and Unified CVP-initiated routing scripts are one and the same. A TranslationRouteToVRU node must be used to move the call to a Type 2 Unified 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 action might seem like an extraneous transfer, but it is necessary in order to force call control hand-off to Unified CVP.

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

Routing of post-ICM calls

Two completely independent Unified ICM routing scripts are used in this scenario. The only connection between the two is that the label returned by the first routing script becomes a Dialed Number that the gatekeeper uses to invoke the second routing script. This transfer is not via a translation route or VRU leg, 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 Unified ICM Router for each call processed in this way, and additional call detail records are written by the Unified ICM Logger. Where possible, configure the GKTMP server triggers on the gatekeeper so that only those calls specifically requiring the additional routing functionality afforded by the GKTMP NIC generate a Request ARQ to Unified ICM.