Showing results for 
Search instead for 
Did you mean: 

Detailed SIP Call Flow with CVP Comprehensive Model




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


The setup is very simple to demonstrate the SIP call flow.


  • 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


In the following section the details will be discussed step by step


(1) Call Comes in from the PSTN



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.


dial-peer voice 1 pots
service cvp-survivability
incominca-called-number 5417641400

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.

Call Matches following outbound sip voip dial-peer on the ingress-gw


dial-peer voice 1400 voip
translation-profile incoming block
preference 1
max-conn 2
destination-pattern 5417641400
session protocol sipv2
session target ipv4: ## CUPS SIP PROXY SERVER IP ADDRESS
dtmf-relay rtp-nte
codec g711ulaw
ip qos dscp cs3 signaling
no vad


CUPS load balance the call because there are static routes configured in it and sends call to CVP Call Server


Destination         VP Server IP Address         Priority           Weight  Protocol      
 5417641400 5060                1              1       UDP
 5417641400 5060                1              1       UDP 
 5417641400 5060                1              1       UDP 




(2) CUPS ----> CVP Server


Call lands to the CVP Call SERVER and in the CVP Call Server log you could see following


[CVP Server Logs]

3052: Mar 13 2008 14:34:39.703 -0700: %CVP_7_0_ICM-7-CALL: {Thrd=Pool:ICM[1450]} 
CALLGUID =  8B82AD85F07B11DC80250013192D1650, DLGID = 21 [SIP_LEG] - Publishing ,,    
[ICM_NEW_CALL],dialogueId=21,   sendSeqNo=1,trunkGroupId=100,trunkNumber=0,serviceId=1,
dialedNumber=5417641400,uui=,, LEGID = 8C1C7CEE-F07B11DC-8177F66C-9B680D18,DNIS = 5417641400,ANI = 4085274003


(3) CVP Server ---> CUICME via VRU-PG


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.


(4) CUICM [Runs Routing Script]--->Generates Label+Correlation-ID


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


[CUICME Router Logs]
14:51:07 Trace: CT_SL_Timer(56)(Init): CT(5000,PreSales_CT), Threshold(20 + 2).
14:51:07 Trace: Correlation id for dialog (23 x 0 : 0 0) is (44).
14:51:07 Trace: Dialog (23 x 44 : 0 0) transfer label = 5417641401

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.

[CVP Call Server Logs]
3053: Mar 13 2008 14:34:39.718 -0700: %CVP_7_0_ICM-7-CALL: {Thrd=Pool:ICM[1451]} 
CALLGUID = 8B82AD85F07B11DC80250013192D1650, DLGID = 21 [SIP_LEG] - Processing ,,  
[ICM_TEMPORARY_CONNECT],   dialogueId=21,sendSeqNo=1,   label=5417641401,   correlationId=44,, 
LEGID = 8C1C7CEE-F07B11DC-8177F66C-9B680D18, DNIS = 5417641400, ANI = 4085274003

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]


debug voip application vxml
calling Number=sip:4085274003@,(Calling Name=)(TON=National, NPI=ISDN, 
Screening=User, Passed, Presentation=Allowed),
Called Number=sip:541764140144@;transport=tcp(TON=Unknown, NPI=Unknown)



This label matches 1401 voip dial-peer in the VXML-GW and invokes bootstrap VXML application.


dial-peer voice 1401 voip

translation-profile incoming block
service bootstrap
session protocol sipv2
incoming called-number 5417641401T           ## T is used to match the correlation-id
dtmf-relay rtp-nte
codec g711ulaw
ip qos dscp cs3 signaling
no vad

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.

(5) CUICM---> RunExternalScript node


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.


063767: Mar 13 18:25:14.407 PST: //404/vxml_item_attrs_proc:
  host=987654 bridge=1 connecttimeout=0 maxtime=0 desttype=-1 destplan=-1 
  anitype=-1 aniplan=-1 anipi=-1, anisi=-1 rdntype=-1 rdnplan=-1 rdnpi=-1, rdnsi=-1, redirectreason=-1

063779: Mar 13 18:25:14.407 PST: //404/vapp_media_play: prompt=
063780: Mar 13 18:25:14.407 PST: //404/vapp_media_play: prompt=
063781: Mar 13 18:25:14.407 PST: //404/vapp_media_play: prompt=
063782: Mar 13 18:25:14.407 PST: //404/vapp_media_play: prompt=


(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:


    • ingress gateway to CVP;
    • CVP to VXML GW (IVR);
    • CVP to VXML GW (ringtone);
    • 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.
  • Thus, CVP acts as a pivot point for the call.
  • 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


dial-peer voice 9191 voip
service ringtone
incoming called-number 91919191
dtmf-relay rtp-nte h245-signal h245-alphanumeric
codec g711ulaw
session protocol sipv2
no vad
dial-peer voice 9292 voip
service cvperror
incoming called-number 92929292
dtmf-relay rtp-nte h245-signal h245-alphanumeric
codec g711ulaw 
session protocol sipv2
no vad

  • You can see the VXML-GW playing the file by noticing the following debugs


[Debugs VXM GW]
062151: Mar 13 18:14:12.483 PST: //383/tcl_MediaObjCmd:  media play leg_incoming flash:ringback.wav
062152: Mar 13 18:14:12.483 PST: //383/tcl_MediaPlayObjCmd:  play leg_incoming flash:ringback.wav



NOTE: Ignore the timestamp in the debug messages. These debugs were captured by making multiple calls over a period of time



Different Gateway Applications


The script extracts required parameters and then hands off the call to the boot strap VXML service named "new-call" which loads the bootstrap.vxml file. This VXML page then submits a new call HTTP 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". For SIP calls, this script extracts Call GUID, Call Server URL, and DNIS. Call Server host is extracted from the App-Info header. For H.323 calls, Call GUID and DNIS are extracted. Call Server is also extracted from the call data. For both SIP and H.323 calls, the Call GUID is normalized in base16, 35 char length hex format as follows(not base10, 43 char length):


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 has the sole job of disconnecting a call with a code an ISDN Q.850 code of 38.


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.

Community Member

Greetings! This is a great document, it breaks up the call flow and explains well...

I found a typo in the first step, "Call Comes in from the PSTN".


I think it should be


Kindly look into it. Thanks, G'day!

Ahmad Abuhannoud



Fantastic explanation of the black magic performed by ICM.  I have asked numerous ICM engineers to explain the call flow involved with an inbound ICM call and have yet to receive such a good explanation.  Thank you very much for the time you have invested in this document as it is a great knowledge transfer tool.

On this Section "Call Comes in from the PSTN " you mentioned.

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.

My concern is as follows,

  1. First thing the call will not fail if we dont have CVP Survivability TCL on the Ingress gateway.
  2. CVP Survivability TCL will take over the call only if there is any WAN outage, CVP call server outage and so on.
  3. survivability.tcl this will takeover the call only when any of the outage occured allowing the call to survive with several options simply say smooth ending the call.

The rest of the call flow was awesome...

Keep posting more documents like this....

Jerry Cody
Cisco Employee

Outstanding document!

  • You can see the VXML-GW playing the file by noticing the following debugs


Could you let me know what is that debug commands to check?






We are doing a PCCE impl. Should we add a dial peer from voice gateway[ingress+vxml] towards cucm. I did not understand if this was needed




Should we add a dial peer matching all agent extensions towards cucm from ingress gateway


Try, debug vxml application and debug vxml trace.



Anil Kumar
Community Member


How ICM will know to run specific routing scripts? If there are many routing scripts on ICM.


Through DNIS, in above case its 5417641400. In ICM DNIS will be mapped to a call type and script will be scheduled for the call type.

DNIS-->Call Type--> Script.



Mohammed Iqbal

He given great document and single typo is nothing found typo and again you also wrote the wrong command

It should be incoming called-number .

Manish Jain
Cisco Employee



Is this CVP survivability script supports G711alaw codec or does it support G711ulaw codec only?  What will be the solution if service provider supports G711alaw codec only on SIP Trunk?






Outstanding document!

Nice Docs

Its Great Notes and call flow is very easy understand and

can please send some troubleshooting documents for

so that i can read further

Recognize Your Peers
Content for Community-Ad