Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for
- Cisco Community
- Technology and Support
- DevNet Hub
- DevNet Collaboration
- Collaboration Knowledge Base
- CVP Comprehensive Flow
Options
- Subscribe to RSS Feed
- Mark as New
- Mark as Read
- Bookmark
- Subscribe
- Printer Friendly Page
- Report Inappropriate Content
903
Views
0
Helpful
0
Comments
Options
- Subscribe to RSS Feed
- Mark as New
- Mark as Read
- Bookmark
- Subscribe
- Printer Friendly Page
- Report Inappropriate Content
on 01-24-2014 12:04 PM
This document was generated from CDN thread
Created by: Ganesh Yegneshwaran on 26-05-2009 06:52:22 PM
Can someone help me understand how the comprehesive workflow works. Here is what I have currently:
1.Set up VoIP Phone to dial "12345" to call an IVR Application "ABC".
2.Set up a route pattern on Call Manager for 12345. This points to our SIP Proxy which is installed on the CUPS,
3. CUPS is set to send the call to VXML Gateway.
Its after this that I m having problems.
I understand the VXML Gateway needs a dial peer set with the incoming called number as 12345.
How do I point this to the CVP Call Server 's SIP service.
How would the ICM service pass this onto the ICM PG & invoke the appropriate ICM Script.
I know its required to set up a DNIS, Call Type & VRU Label on the ICM. I did refer to CVP Getting Started Guide.
My confusion is, should the DNIS & the VRU Label be the same as "12345" . My question is how do I map 12345 dialed from the phone to get to ABC via ICM.
Subject: RE: CVP Comprehensive Flow
Replied by: WILLIAM WEBB on 27-05-2009 05:49:43 PM
The CVP Comprehensive Model involves ICM, and the flow is much more involved than standalone. In a basic sense, here is the flow:
1. Call comes into IOS gateway on pots dial-peer.
2. Outgoing voip dial-peer targets "sip-server" to send call to CUPS (proxy).
3. CUPS returns IP address of CVP Server.
4. CVP Server sends "NEW_CALL" message to ICM through GED-125 interface on VRU PG.
5. ICM runs routing script and encounters "Send to VRU" node, which sends specialized Label back to CVP.
6. Ultimately this Label is intended to connect the call to a voip dial-peer on the IOS gateway that calls "bootstrap.tcl" application.
7. IOS gateway uses this to set up session with CVP Server, and CVP Server indicates session setup back to ICM.
8. ICM continues routing script, sets variables to build URL for VXML application, and sends request to call specific application using "Run External Script" node.
The Configuration and Administration Guide for CVP goes over the configuration of the entire system in pretty decent detail...
- Bill
Subject: RE: CVP Comprehensive Flow
Replied by: Ganesh Yegneshwaran on 29-05-2009 09:17:32 PM
Thanks Bill. Your reply helped me comprehend the Comprehensive flow.
I have gone far enough to be able to :
1. Set up a route pattern for the dialed number 12345 on my Call manager.
2. Associated the route pattern to my CUPS via SIP trunk.
3. Defined a static route on the CUPS to my CVP server.
Its after this, that I m finding lost. I have created the label(1234567890) , the routing script in ICM. Defined the dial peer on the VXML Gateway to match the label on ICM & pointed it to the bootstrap.
But I m not able to verify if my CVP Call server is indeed talking to ICM & sending the NEW CALL. When I dial 12345 I get a message "the call cannot be complete as dialed" . I know I m messing up somewhere.
Subject: RE: CVP Comprehensive Flow
Replied by: WILLIAM WEBB on 29-05-2009 10:11:02 PM
Ahh - ok - UCM-originated call flow. That's got a couple extra steps! ;-)
Here's what you need to set up:
1. Your "Dialed Number" should actually be a CTI Route Point associated with your "pguser" JTAPI User in UCM. This needs to be configured in ICM as a Dialed Number from the UCM Routing Client.
2. You also need to add a Label to your Network VRU for CVP (which should be a Type 10) for the UCM Routing Client.
3. Dialing the CTI Route Point will send a route request into ICM, which will run a script. The script will have a "Send to VRU" node as with a PSTN-originated call.
4. The Label for the UCM routing client as configured in the Network VRU (say it's the 1234567890 you mention) will be returned by ICM to the UCM. UCM now needs to have a Route Pattern for this number which ultimately routes the call to CUPS and on to CVP.
5. CVP will then send this number in a NEW_CALL message to ICM. ICM will then subsequently send the Label configured for the CVP Routing Client under the Network VRU configuration back to CVP. Whether via "Send to Originator" or via CUPS, this Label needs to get the call back to the VXML gateway on a voip dial-peer that calls the bootstrap.tcl application.
All of that happens just in the "Send to VRU" node when using the Type 10 Network VRU in ICM.
- Bill
Subject: RE: CVP Comprehensive Flow
Replied by: Ganesh Yegneshwaran on 03-06-2009 04:06:50 PM
Bill,
I m done with Items 1 & 2 on your list.
I m not sure about the "Send to VRU" usage you mentioned on item 3. One of the documentation mentioned that , this is used only for Type 3 & Type 7 VRU.
For Type 10 VRU to invoke my application on the VXML server this is what I do :
- Set the media server ULR with the port & IP address of CVP
- Set the application name through ToExtVXML[0]
- Set UseVXMLParams ECC to N
- Invoke the VRU Script GS,Server,V
So how will the SendToVRU return label to UCM ? I really wish things were simple with UCCE.May be its too early to call.
Subject: RE: CVP Comprehensive Flow
Replied by: Kamesh Chidambaram on 03-06-2009 04:41:48 PM
You do need a SendToVRU. It is possible that the document you referred to was out of date. Type 10 was introduced as a replacement to Type 5/Type7 configuration what we had to do in earlier versions. The Type 10 is really doing the role of a Type 7 when running VXML scripts. So SendToVRU is valid and will cause the ICM to return the transfer label.
You could skip the SendToVRU and get it working with a RunExternalScript node. But ICM would do an implicit 'SendToVRU' function if the current routing client is not a VRU. I prefer including a SendToVRU since it helps trouble shooting to identify where things went wrong.
Hope this helps,
regards,
Kamesh
Subject: RE: CVP Comprehensive Flow
Replied by: WILLIAM WEBB on 04-06-2009 12:54:34 PM
The Type 10 is actually more like the Type 7 ("VRU Leg") and Type 2 ("Switch Leg") combo... I wish I could tell you that CVP was "easy", but I'd be lying through my teeth!! ;-)
So as Kamesh said, you do actually need an explicit Send to VRU node in your ICM script. A couple other things to be sure of:
1. In ICM, in "System Information", make sure the Default Network VRU is your Type 10 CVP VRU.
2. In ICM, in "Instance Explorer", make sure the Customer Default Network VRU is also set to your CVP Type 10 VRU.
That said, don't confuse the "Send to VRU" with the "Run External Script". The Send to VRU only takes the "Switch Leg" of the call (in your case from the UCM Routing Client to the CVP Routing Client) and connects it to the "VRU Leg", which involves the Network VRU, which has Labels configured for each Routing Client.
Because you are configuring a UCM-originated call, you actually have 2 steps on the Switch Leg. Your first step is ICM sending the Label configured for the UCM Routing Client under the Type 10 CVP VRU to the UCM. The second is when UCM routes that Label to the CVP and ICM recieves a subsequent request from the CVP Routing Client. The second step is actually the VRU Leg transfer, where the Label configured for the CVP Routing Client under the Type 10 CVP VRU is sent back to CVP. It is up to CVP at this point to use this Label to route the call to the VXML gateway via a static route, CUPS, gatekeeper, etc. (depending on what protocol you are using).
Once the call arrives on the VXML gateway and invokes the "bootstrap.tcl" application, then the session is set up. This is all required in order for the "Send to VRU" node to exit out the "Success" output. At this point, you would then set the ECCs like you mentioned to configure what application you want to run. It is the "Run External Script" that invokes this.
- Bill
Created by: Ganesh Yegneshwaran on 26-05-2009 06:52:22 PM
Can someone help me understand how the comprehesive workflow works. Here is what I have currently:
1.Set up VoIP Phone to dial "12345" to call an IVR Application "ABC".
2.Set up a route pattern on Call Manager for 12345. This points to our SIP Proxy which is installed on the CUPS,
3. CUPS is set to send the call to VXML Gateway.
Its after this that I m having problems.
I understand the VXML Gateway needs a dial peer set with the incoming called number as 12345.
How do I point this to the CVP Call Server 's SIP service.
How would the ICM service pass this onto the ICM PG & invoke the appropriate ICM Script.
I know its required to set up a DNIS, Call Type & VRU Label on the ICM. I did refer to CVP Getting Started Guide.
My confusion is, should the DNIS & the VRU Label be the same as "12345" . My question is how do I map 12345 dialed from the phone to get to ABC via ICM.
Subject: RE: CVP Comprehensive Flow
Replied by: WILLIAM WEBB on 27-05-2009 05:49:43 PM
The CVP Comprehensive Model involves ICM, and the flow is much more involved than standalone. In a basic sense, here is the flow:
1. Call comes into IOS gateway on pots dial-peer.
2. Outgoing voip dial-peer targets "sip-server" to send call to CUPS (proxy).
3. CUPS returns IP address of CVP Server.
4. CVP Server sends "NEW_CALL" message to ICM through GED-125 interface on VRU PG.
5. ICM runs routing script and encounters "Send to VRU" node, which sends specialized Label back to CVP.
6. Ultimately this Label is intended to connect the call to a voip dial-peer on the IOS gateway that calls "bootstrap.tcl" application.
7. IOS gateway uses this to set up session with CVP Server, and CVP Server indicates session setup back to ICM.
8. ICM continues routing script, sets variables to build URL for VXML application, and sends request to call specific application using "Run External Script" node.
The Configuration and Administration Guide for CVP goes over the configuration of the entire system in pretty decent detail...
- Bill
Subject: RE: CVP Comprehensive Flow
Replied by: Ganesh Yegneshwaran on 29-05-2009 09:17:32 PM
Thanks Bill. Your reply helped me comprehend the Comprehensive flow.
I have gone far enough to be able to :
1. Set up a route pattern for the dialed number 12345 on my Call manager.
2. Associated the route pattern to my CUPS via SIP trunk.
3. Defined a static route on the CUPS to my CVP server.
Its after this, that I m finding lost. I have created the label(1234567890) , the routing script in ICM. Defined the dial peer on the VXML Gateway to match the label on ICM & pointed it to the bootstrap.
But I m not able to verify if my CVP Call server is indeed talking to ICM & sending the NEW CALL. When I dial 12345 I get a message "the call cannot be complete as dialed" . I know I m messing up somewhere.
Subject: RE: CVP Comprehensive Flow
Replied by: WILLIAM WEBB on 29-05-2009 10:11:02 PM
Ahh - ok - UCM-originated call flow. That's got a couple extra steps! ;-)
Here's what you need to set up:
1. Your "Dialed Number" should actually be a CTI Route Point associated with your "pguser" JTAPI User in UCM. This needs to be configured in ICM as a Dialed Number from the UCM Routing Client.
2. You also need to add a Label to your Network VRU for CVP (which should be a Type 10) for the UCM Routing Client.
3. Dialing the CTI Route Point will send a route request into ICM, which will run a script. The script will have a "Send to VRU" node as with a PSTN-originated call.
4. The Label for the UCM routing client as configured in the Network VRU (say it's the 1234567890 you mention) will be returned by ICM to the UCM. UCM now needs to have a Route Pattern for this number which ultimately routes the call to CUPS and on to CVP.
5. CVP will then send this number in a NEW_CALL message to ICM. ICM will then subsequently send the Label configured for the CVP Routing Client under the Network VRU configuration back to CVP. Whether via "Send to Originator" or via CUPS, this Label needs to get the call back to the VXML gateway on a voip dial-peer that calls the bootstrap.tcl application.
All of that happens just in the "Send to VRU" node when using the Type 10 Network VRU in ICM.
- Bill
Subject: RE: CVP Comprehensive Flow
Replied by: Ganesh Yegneshwaran on 03-06-2009 04:06:50 PM
Bill,
I m done with Items 1 & 2 on your list.
I m not sure about the "Send to VRU" usage you mentioned on item 3. One of the documentation mentioned that , this is used only for Type 3 & Type 7 VRU.
For Type 10 VRU to invoke my application on the VXML server this is what I do :
- Set the media server ULR with the port & IP address of CVP
- Set the application name through ToExtVXML[0]
- Set UseVXMLParams ECC to N
- Invoke the VRU Script GS,Server,V
So how will the SendToVRU return label to UCM ? I really wish things were simple with UCCE.May be its too early to call.
Subject: RE: CVP Comprehensive Flow
Replied by: Kamesh Chidambaram on 03-06-2009 04:41:48 PM
You do need a SendToVRU. It is possible that the document you referred to was out of date. Type 10 was introduced as a replacement to Type 5/Type7 configuration what we had to do in earlier versions. The Type 10 is really doing the role of a Type 7 when running VXML scripts. So SendToVRU is valid and will cause the ICM to return the transfer label.
You could skip the SendToVRU and get it working with a RunExternalScript node. But ICM would do an implicit 'SendToVRU' function if the current routing client is not a VRU. I prefer including a SendToVRU since it helps trouble shooting to identify where things went wrong.
Hope this helps,
regards,
Kamesh
Subject: RE: CVP Comprehensive Flow
Replied by: WILLIAM WEBB on 04-06-2009 12:54:34 PM
The Type 10 is actually more like the Type 7 ("VRU Leg") and Type 2 ("Switch Leg") combo... I wish I could tell you that CVP was "easy", but I'd be lying through my teeth!! ;-)
So as Kamesh said, you do actually need an explicit Send to VRU node in your ICM script. A couple other things to be sure of:
1. In ICM, in "System Information", make sure the Default Network VRU is your Type 10 CVP VRU.
2. In ICM, in "Instance Explorer", make sure the Customer Default Network VRU is also set to your CVP Type 10 VRU.
That said, don't confuse the "Send to VRU" with the "Run External Script". The Send to VRU only takes the "Switch Leg" of the call (in your case from the UCM Routing Client to the CVP Routing Client) and connects it to the "VRU Leg", which involves the Network VRU, which has Labels configured for each Routing Client.
Because you are configuring a UCM-originated call, you actually have 2 steps on the Switch Leg. Your first step is ICM sending the Label configured for the UCM Routing Client under the Type 10 CVP VRU to the UCM. The second is when UCM routes that Label to the CVP and ICM recieves a subsequent request from the CVP Routing Client. The second step is actually the VRU Leg transfer, where the Label configured for the CVP Routing Client under the Type 10 CVP VRU is sent back to CVP. It is up to CVP at this point to use this Label to route the call to the VXML gateway via a static route, CUPS, gatekeeper, etc. (depending on what protocol you are using).
Once the call arrives on the VXML gateway and invokes the "bootstrap.tcl" application, then the session is set up. This is all required in order for the "Send to VRU" node to exit out the "Success" output. At this point, you would then set the ECCs like you mentioned to configure what application you want to run. It is the "Run External Script" that invokes this.
- Bill
Labels:
Getting Started
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:
Customers Also Viewed These Support Documents