Documenti di Didattica
Documenti di Professioni
Documenti di Cultura
Network Setup
ICM Script Flow
(1) Call Comes in from the PSTN
(2) CUPS ----> CVP Server
(3) CVP Server ---> CUICME via VRU-PG
(4) CUICM [Runs Routing Script]--->Generates Label+Correlation-ID
(6) CUICM---->Agent
Different Gateway Applications
Introduction
This documents aims to provide detailed SIP CVP comprehensive Call Flow with the
debugs captured from the CVP logs and IOS/VXML Gateways
Network Setup
A call comes in from PSTN Phone and goes to the ingress gateway
Ingress gateway is also acting as VXML Gateway for this setup
Ingress gateway sends the call to CUP SIP Proxy
CUP SIP Proxy sends the call to the CVP Call Server
CVP Call Server will send the call to ICM
Agents are connected to the CUCM
Following script is being used (Notice that Microapps are being used and no Call Studio
script is being used in this setup)
ICM Script Flow
Call comes in and hit Start
Some variables are being set (HTTP Media Server IP Address, Directory Name for the
stored media files, en-us locale, input type being set it digits etc.)
Then call is being sent to VRU which VXML-GW
VXML instructions are being sent to the VXML-GW
Save the digits into a variable
Play those digits back to the caller
Set LAA (Longest Available Agent) agent selection algorithm
Wait in the queue for agent to become available
During this time play a hold music to the caller in the loop
PSTNph---PSTN----Ingress-gw----->CUPS
Call matches an incoming pots dial-peer for the destination number. It is important to
configure cvp-survivability service under the POTS dial-peer. If this service is not
configured on the incoming pots dial-peer, the ingress gateway will not be able to
communicate with the CVP Call Server and might receive “SIP/2.0 503 Service
Unavailable” message from the CVP Call Server.
In the event of some critical CVP application failure, survivability.tcl script will attempt to
recover and smoothly disconnect the caller after playing critical_error.wav file from
Ingress-GW’s flash. It is very important to have this script because this script also plays
pleasewait.wav and holdmusic.wav files from flash depending on situation.
CUPS load balance the call because there are static routes configured in it
and sends call to CVP Call Server
CVP Server sends the call to CUICM via VRU PG. Notice that we didn't configure the IP
address of the CUICM or the VRU-PG in the CVP Call Server. CVP Call Server
automatically sends the information to the CUICM's VRU-PG, because during the
CUICM configuration, we had already specified the IP addresses of our CVP Call
Servers. The VRU PG will connect to the ICM Service on the CVP Call Server. Once
that TCP socket is established, the CVP acting as the routing client functionality
becomes active in ICM and CVP will communicate with ICM/PG over that socket.
When call arrives at CUICM, it causes Unified ICM to run a routing script. In the routing
script there is a node called SendToVRU node (Remember: VRU in our case is VXML-
GW and SendToVRU node is added right after setting the basic variables). The
SendToVRU is what triggers ICM to transfer the call to the VXML GW (which is the
VRU). The routing script will typically initiate a transfer of the call to a VoiceXML
Gateway port (due to SendToVRU node) via the SIP Service. You could see following in
the router process windows on the CUICM Server
As you can see from above that ICM returns a VRU label 5417641401+correlation-id
(44) back to CVP Call Server (Remember CVP Server was the routing-client).You can
see the same information on the CVP Call Server logs that a call goes to ICM and ICM
returns a label back to the CVP Call Server (Which is the routing-client for ICM). This
correlation-id (which is 44 in our case ) will be appended at the end of the label.
Now CVP Call Server will send this VRU label (5417641401+44) to the VXML GW (It is
more accurate to say that CVP transfers the call TO the VXML GW, with the
label+correlation ID as the destination phone number). In our case, it is only
coincidence that the VXML GW is the same as the ingress GW. The “transfer” that CVP
does is not a typical one either, because CVP stays in the call path (whereas usually the
transferor drops out of the call path).
In reality CVP is setting up a NEW call to the VXML GW and is shuffling the SDP from
the ingress GW to the VXML GW in order to connect the media directly (similar to
CUCM or CUBE in flow-around mode). CVP stays in the signaling path so that it can
retain call control.
[VXML-GW Debugs]
This label matches 1401 voip dial-peer in the VXML-GW and invokes bootstrap VXML
application.
The bootstrap VXML application tells the CVP that it is a new call and CVP then sends
the same label (5417641401+44) back to ICM. Once ICM sees its own generated label,
this actually completes the loop and ICM at this point knows that there is a VXML
Gateway ready to accept the instructions.
The steps below are the RunExternalScript nodes that tell CVP what VXML pages to
send to the VXML gateway (play prompt, get digits, etc). CUICM execute the script
instruction called “RunExternalScript”. This basically tells CVP that IVR related
instructions are coming. CUICM then sends instructions like for example “Get4Digits”.
CVP sends this instruction to VXML-GW to play the prompt to the caller. When caller
enters the digit, ICM stores it in its variable [for example Call.CallerEnteredDigits
variable].
[VXML-GW Debugs]
063686: Mar 13 18:25:14.383 PST: //404/vapp_digit_collection_done: digits
[5432], status [0], pattern [v0]
063687: Mar 13 18:25:14.383 PST: //404/vxml_digit_collection_done:
vxmlp 6A6D1EA4 status 0 async_status 200000000
063688: Mar 13 18:25:14.383 PST: //404/vxml_digit_collection_done: digits
(5432)
ICM Script then instructs CVP to play the prompts back to the user on the PSTN
side. For simplicity we can say that in order to do that CVP makes an inbound call to the
VXML gateway by dialing 987654 and plays the prompt. But in reality we wouldn’t say
that CVP makes an inbound call to the VXML gateway (since that already happened
above). The 987654 is actually a transfer instruction that was received via VXML from
CVP, the only reason it exists is because it is a workaround for some problem with
playing media files and retaining the vxml session.
[VXML-GW DEBUGS]
(6) CUICM---->Agent
When an agent becomes available, ICM instructs CVP to transfer the call to the agent.
CVP will disconnect the call to the VXML GW (SIP BYE), will send a re-INVITE back to
the ingress gateway to stop media, and will send a new INVITE to the agent phone and
to the ringtone service below.
When the ringtone service answers, a re-INVITE is sent to the ingress gateway with the
VXML GW’s SDP in order to establish the media stream for the ringback.
Once the Agent answers the phone, CVP disconnects the call to the VXML GW (with
BYE & re-INVITE same as before), and then connects the media stream from the
ingress gateway to the agent phone.
In this entire call flow, there have been 4 distinct SIP phone calls that are separate from
each other:
o CVP to Agent.
Each phone call, from a SIP perspective, is completely separate from the others,
because CVP is a B2BUA and not a proxy.
Whenever CVP does a transfer, it disconnects the previous destination that the caller
was connected to and connects them to the new destination.
Since CVP is under control of ICM, that is what makes CVP so powerful – the ability to
control the call from very first component that received the call. This is in contrast to a
typical PBX/ACD (including CUCM) where the transfers are tromboned through every
component that was involved in the call, tying up additional DS0’s or memory.
In a SIP call flow, during the time when CUICM is transferring call over to the agent,
there is a need to play ringtone back to the caller. And also if in case there is an error
during transfer, CVP should be able to play error tone back to the caller. These tones
will be generated by playing a .wav file off of the VXML gateway flash.
In the CVP, there are two parameters under SIP section. These are the DNs that CVP
sends to VXML GW when there is a need to generate the ringtone or error tone.
When these numbers reach the VXML GW, it matches with an incoming voip dial-peer
and VXML GW starts the respective service/app
You can see the VXML-GW playing the file by noticing the following debugs
NOTE: Ignore the timestamp in the debug messages. These debugs were captur
ed by making multiple calls over a period of time
bootstrap.vxml
The VXML-GW sends a new call request to the Customer Voice Portal (CVP) IVR
Service which kicks off a sequence of VXML communications between the VXML
Gateway and the CVP IVR Service, commonly called “MicroApps”. Any HTTP errors, or
fetch errors (7 second timeout), will handoff to recovery.vxml in flash and handoff.tcl in
flash.
Handoff.tcl
Handoff.tcl has the sole job of disconnecting a call with a code an ISDN Q.850 code of
38.
survivablity.tcl
This service should be placed on the ingress-gw on the incoming pots dial-peer that is
destined for CVP. In the event of critical CVP application errors or a WAN failure that
would normally disconnect the caller, this script allows the gateway to attempt a transfer
to some alternate location after the failure occurs instead of disconnecting the caller. In
the event that the call cannot be transfered to an alternate agent, the script will play a
"call-back-later" message and disconnect.