Cisco Cisco Customer Voice Portal 8.0(1) Guía De Diseño
5-15
Cisco Unified Customer Voice Portal (CVP) 8.x Solution Reference Network Design (SRND)
OL-15989-06
Chapter 5 Interactions with Cisco Unified ICM
Using Third-Party VRUs
the Unified ICM script returns a label, that label will be returned to the Network routing client (Unified
CVP), and the caller is sent directly to the new destination. This configuration avoids a timing problem
that can occur if an agent uses Unified CM CTI Route Points to initiate a network transfer.
CVP), and the caller is sent directly to the new destination. This configuration avoids a timing problem
that can occur if an agent uses Unified CM CTI Route Points to initiate a network transfer.
Using Third-Party VRUs
A third-party TDM VRU can be used in any of the following ways:
•
As the initial routing client (using the GED-125 Call Routing Interface)
•
As a traditional VRU (using the GED-125 Call Routing Interface)
•
As a Service Control VRU (using the GED-125 Service Control Interface)
In the first and second cases, the VRU acts exactly like an ACD, as described in the section on
. Like an ACD, the VRU can be a destination for calls that arrive from
another source. Calls can even be translation-routed to such devices in order to carry call context
information. (This operation is known as a traditional translation route, not a TranslationRouteToVRU.)
Also like an ACD, the VRU can issue its own Route Requests and invoke routing scripts to transfer the
call to subsequent destinations or even to Unified CVP for self-service operations. Such transfers almost
always use the Translation Route transfer mechanism.
information. (This operation is known as a traditional translation route, not a TranslationRouteToVRU.)
Also like an ACD, the VRU can issue its own Route Requests and invoke routing scripts to transfer the
call to subsequent destinations or even to Unified CVP for self-service operations. Such transfers almost
always use the Translation Route transfer mechanism.
In the third case, the VRU takes the place of either Unified CVP's Switch leg or Unified CVP's VRU leg,
or it can even take the place of Unified CVP entirely. Such deployments are beyond the scope of this
document.
or it can even take the place of Unified CVP entirely. Such deployments are beyond the scope of this
document.
DS0 Trunk Information
Release 8.0(1) of Unified CVP adds the capability of passing the PSTN gateway trunk and DS0
information to Unified ICM from the arriving SIP call.
information to Unified ICM from the arriving SIP call.
PSTN gateway trunk and DS0 information received at ICM can be used for two purposes
•
Reporting
•
Routing in the Unified CCE Script Editor where TrunkGroupID and TrunkGroupChannelNum
information is available for routing decisions.
information is available for routing decisions.
The following message is used in the logic examples that follow:
The PSTN trunk group data comes from the PSTN Gateway in the SIP INVITE message as given below:
Via: SIP/2.0/UDP 192.168.1.79:5060;x-route-tag="tgrp:2811-b-000";x-ds0num="ISDN 0/0/0:15
0/0/0:DS1 1:DS0";branch
0/0/0:DS1 1:DS0";branch
Examples
The following logic is used in Unified CVP to parse and pass the PSTN trunk group info to Unified ICM:
•
For TrunkGroupID, look for tgrp: in the x-route-tag field
If tgrp: found TrunkGroupID = <value after tgrp:> + <data between ISDN and :DS1 tags>
Using the above example: TrunkGroupID = 2811-b-000<space>0/0/0:15 0/0/0
else TrunkGroupID = <IP addr of originating device in Via header> + <data between ISDN and
:DS1 tags>
:DS1 tags>
Using the above example: TrunkGroupID = 192.168.1.79<space>0/0/0:15 0/0/0