Cisco CVP routing for Large Enterprise – Part 1

This will be a multi part blog about my favorite product of all of Cisco’s Products, CVP (Customer Voice Portal). Customer Voice Portal is the enterprise IVR solution Cisco has on the market, and is now the preferred choice for IVR with any Cisco UCCE implementation. The problem with CVP is it is a bear to get your hands around for the first time. CVP has a ton of components, which no one refers to by the right names, and it has 2 different call flows. I also see a ton of really poorly done CVP installs. I am going to give an overview of all the components we will use in our CVP design before I start going into it. This is a design in use at 5-10 large Fortune 500 size customers, right from my design documents. Part 1 will focus on an overview of CVP and Ingress Gateway configuration.

Call Flow Models for CVP

There are 2 ways to use CVP. The first an easiest is in ‘self-service mode’. This generally means it’s not connected to any other products and is used for what it says, self service operations for your customers without agent involvement. I have never run into a true self-service in the wild outside of the lab, but they exist.

The other model is called ‘comprehensive’. This uses UCCE and generally a SIP Proxy or H.323 GK for centralized dial-plan management. This model includes most customers that use CVP, so we are going to focus on comprehensive in this post.

CVP Call Server

CVP itself has two major components that work together to make an IVR call happen. The first is the CVP Call Server. This is a VERY important component. One way CVP differs from most IVRs, or even specifically IP IVR is that CVP Front ends the call. This means that if you present an IVR to the caller BEFORE it goes to an agent, CUCM or a PBX is skipped and the call is sent directly to CVP. The CVP Call Server is the component that speaks SIP or H323 (We are going to focus on SIP, since it’s the future at Cisco). It handles all of the actual call handling, and has nothing to do with the IVR being played to the caller.

So far we have something like this…

CALL WITH CVP

PSTN (PRI) -> Cisco ISR (29xx or 39xx) -> CVP Call Server

CALL WITHOUT CVP

PSTN (PRI) -> Cisco ISR (29xx or 39xx) -> CUCM

What this means is in our design below you will see us break off calls destined for the call center and send them to CVP with dial-peers, we will send the rest of the traffic to CUCM. This is also too simple because we are going to toss a CUSP SIP Proxy in the middle of all these transactions to help maintain a centralized dial-plan.

REAL CALL WITH CVP

TELCO (PRI) -> Cisco ISR (29xx or 39xx) -> CUSP -> CVP Call Server

CVP VXML Server

The other major component of CVP is the VXML Server. VXML is a format that describes an IVR interaction and it stands for Voice XML. The VXML Server is the component that actually hosts the VXML Files (Like an HTTP Server would). This is the component that actually uses the scripts your write in CVP Studio or the micro apps coded in UCCE.

VXML Gateway

A VXML gateway is required for CVP to work. Cisco routers support VXML and when used in conjunction with CVP VXML Server, it is called a VXML Gateway. This renders the VXML document hosted by the VXML Server into actual voice and actions heard on the phone to the person calling in.

CUSP (Unified SIP Proxy)

CUSP is a module that can go in any router with an NM slot. It is a sip proxy with a web application like CUE meant specifically for centralized dial-plans. It is way more flexible then CUPS, and not as heavy as a Cisco SME cluster. It can also be configured via CLI…. but I have never tried that all the way through even though it would certainly be easier for bulking in a new install.

Design

So we have explained all our components in the CVP install, let’s gather our thoughts and figure out what our goals are for this tutorial

• Route a call with the proper call flow all the way from the TELCO to an agent.
• Have this call use the Comprehensive model for CVP.
• Have 2 sets of ingress points so we can show how to keep it on the proper side of the WAN.
• This tutorial is only about CVP related dialing, all UCCE specifics I assume you know them.

OK, those all seem like pretty realistic goals. Our fake setup will use 2 main datacenters, one in Charlotte, NC and another in Nashville, TN. Our components for the design are below.

1. 2 Ingress Gateways (29xx) – one in each datacenter
2. 2 VXML Gateways (39xx) – one in each datacenter
3. 2 CUSP modules (29xx chasis) – one in each datacenter
4. 2 CVP Combo boxes (Call + VXML Server on one box) – one in each datacenter
5. UCCE Cluster
6. CUCM Cluster

Significant Digits

CVP provides a mechanism named significant digits to help us keep calls optimized in our call flow. How this works is when DNIS numbers come in your ingress gateways you prepend “significant digits” to the DNIS before sending them to CVP. In CVP you configure the length of significant digits to be stripped off before sending to UCCE. UCCE then looks at the original DNIS (the DNIS before having prepended the sig digits in the gateway) in the Dialed Number list, finds it and launches the relevant script. Anytime UCCE sends a label, it goes back to CVP and takes the routing defined in the OAMP (CVP Operation Console). Lastly when the CVP Call server gets that request it adds the significant digits back to the call before sending the sip proxy. This gives us a method for always determining where in the network the call originated, and therefore what VXML gateway we should optimally render it on. It also gives us complete control of the CVP call routing.

We will use Charlotte gateway sig digits as 11 and Nashville sig digits as 22

Step 1: Ingress Gateways

The first step is to point the calls coming in the ingress gateways (PSTN Terminators) to their relevant locations. Contact center (CVP) Calls will go point at the SIP Proxies and normal DID’s for users will go to CUCM.

I will provide an entire (relevant) ingress template for Charlotte below and after wards I will explain some key parts. Relevant means to show how CVP works, all your other configuration like controllers, circuits, dial-peers, media resources, SRST, etc. are not considered below.

 
ip host clt-cusp.cloverhound.com 10.20.134.1
ip host nvl-cusp.cloverhound.com 10.10.134.1
ip host _sip._udp.cusp.cloverhound.com srv 1 50 5060 clt-cusp.cloverhound.com
ip host _sip._udp.cusp.cloverhound.com srv 2 50 5060 nvl-cusp.cloverhound.com

voice service voip
no ip address trusted authenticate
allow-connections sip to sip
redirect ip2ip
fax protocol t38 version 0 ls-redundancy 0 hs-redundancy 0 fallback none
sip
  bind control source-interface GigabitEthernet0/0
  bind media source-interface GigabitEthernet0/0
  rel1xx disable
  header-passing
!
voice class codec 1
codec preference 1 g711ulaw
codec preference 2 g729r8
!
voice translation-rule 1299
rule 12 /^21/ /1121/
!
voice translation-profile INCOMING
translate called 1299
!
application
service cvp-survivability flash:survivability.tcl
  paramspace english index 0
  paramspace english language en
  paramspace english location flash
  paramspace english prefix en
!
!
dial-peer voice 1299 pots
translation-profile incoming INCOMING
service cvp-survivability
incoming called-number 21...
!
dial-peer voice 298 voip
description Dial-Peer to SIP Proxy
destination-pattern 1121...
session protocol sipv2
session target sip-server
voice-class codec 1
dtmf-relay rtp-nte 
no vad
!
dial-peer voice 198 voip
description Dial-Peer to CUCM
destination-pattern 4....
session protocol sipv2
session target ipv4:10.10.10.10
voice-class codec 1
dtmf-relay rtp-nte 
no vad
!
!
sip-ua
retry invite 1
timers expires 60000
sip-server dns:cusp.cloverhound.com
reason-header override
!

• The IP Host commands at the top are all for configuring DNS SRV for targeting 2 sip proxies. IOS can only have a single Sip User Agent (last part of the config) configured. Because of this the mechanism for targeting multiple SIP Proxies is by using DNS SRV records. These could also be configured on a DNS Server however they are not as flexible. By configuring them in IOS you can give the SRV difference preferences and weights per ingress gateway meaning you can even keep the sip signaling local to the datacenter. Also hosting it externally on Microsoft DNS gives us another point of failure. IOS is always preferred.
• Voice Services VoIP is all the CUBE configuration necessary to allow this to work… a few key notes about this.
1. no ip address trusted authenticate – this turns off toll fraud functionality. This is a quick fix but optimally this should be an list of all allowed IP’s for routing SIP traffic.
2. allow-connections sip to sip – this enable CUBE functionality for sip to sip calls. This isn’t really necessary unless you have a sip trunk, or are sharing your ingress and VXML gateways (common for remote sites).
3. The bind commands are important for guaranteeing the source of your traffic in both the SIP Proxy and CUCM SIP trunks.
• The application command is necessary for the CVP survivability TCL script. This offers basic hunt-group functionality if CVP is unreachable. It also turns out its REQUIRED to enable the CVP error message to play correctly (odd).
• The incoming dial-peer is how we syphon off traffic destined for the call center, launch the survivability TCL script, and prepend the sig digits to the call.
• Dial-Peer 298 is how we send the call to the SIP Proxy User Agent (First Charlotte, then if fails tries Nashville). G711ulaw preference.
• Dial-Peer 198 is how we send the rest of the calls to CUCM. We will not cover CUCM any further then this. You would need a SIP trunk configured on CUCM with the ingress gateway’s IP which you binded too.

An important question to ask is assuming that Charlotte and Nashville are in a trunk group from the Telco side, what should be different on the Nashville router?

The only differences will be the significant digits in the translation pattern. Since Nashville is 22 it would just be this small change.

voice translation-rule 1299
rule 12 /^21/ /2221/
!

Generally it would also be preferred to change the order of our SRV records in Nashville to preference the CUSP module in Nashville. Nashville would look like below, notice the only difference is the weights on the SRV records

ip host clt-cusp.cloverhound.com 10.20.134.1
ip host nvl-cusp.cloverhound.com 10.10.134.1
ip host _sip._udp.cusp.cloverhound.com srv 2 50 5060 clt-cusp.cloverhound.com
ip host _sip._udp.cusp.cloverhound.com srv 1 50 5060 nvl-cusp.cloverhound.com

Let’s say the trunk group is split 50/50 between Charlotte and Nashville. When a DNIS comes in as 21000 on Charlotte 1121000 will be sent to the Sip Proxy in Charlotte. When 21000 comes in on Nashville 2221000 will be sent to the SIP Proxy in Nashville.

Conclusion – Part 1

So far we have outlined what all the CVP components do, what a proper CVP Call flow should look like, and a basic overall list of goals. We also took a deep dive into the ingress gateway of a Comprehensive CVP Call.

There will be 2 more parts of this blog that follow the call after it leaves the ingress gateways through the rest of the UCCE call flow. As you can see learning CVP is quite the task, but it really can teach a person a lot about routing calls in a VoIP environment.

Chad