This document was generated from CDN thread
Created by: Luis Yrigoyen on 03-04-2012 02:21:52 PM
Hi,
We're running CVP comprehensive model 8.0 with ICM 8.5.
We currenlty have two sites (A and
, both sites have call centers and each site has:
1 PSTN gateway with a few PRIs
1 gateway running CVP (VXML broswer)
1 co-located CVP Call Server and CVP VXML Server (and media server)
and of course all the other telephony servers (CM, ROGGER,PG, CTIOS, etc)
All of our INBOUND calls get CVP treatment (contact center related calls and non-contact center related calls).
When callers call our non-contact center numbers (i.e. our main number) we play a CVP app (a menu with options).
We are now opening a new site (I'll call it Site C) which main number routes to a CVP app hosted at site A and I was wondering if we need a local CVP Call Server/VXML Server since I want to implement CVP survivability in case the WAN goes down.
any help is appreciated.
Subject: RE: CVP call server...do I need one for every vxml gateway?
Replied by: Luis Yrigoyen on 03-04-2012 03:02:05 PM
Mike,
thanks for the reply.
Yes, that clears things up.
I guess what we're really looking for is a way to route calls to any where else in case the wan goes down and that seems to be covered by CVP survivability...
but also we wanted to see if it was possible to prevent the call treatment from traversing the WAN without having all the cvp infrastructure at site C.
thanks
Subject: RE: CVP call server...do I need one for every vxml gateway?
Replied by: Michael Aossey on 03-04-2012 02:35:52 PM
Luis,
A CVP server at the remote site (site C) will do you no good if the WAN is down given that CVP is deployed in coprehensive mode and it would not be able to reach the Central Controller to make route requests. Survivability is a TCL based application that runs on the remote site gateway and hairpins the call back to another site (over the PSTN) when the CVP server and Central Controller are accessable. Alternativley you could place a CVP server at Site C in stand-alone mode to offer IVR functionallity but it would not be tied to ICM reporting in any way and would not have ACD functionality available.
I hope this helps!
Thanks, Mike.
Subject: RE: New Message from Luis Yrigoyen in Customer Voice Portal (CVP) - General
Replied by: GEOFFREY THOMPSON on 03-04-2012 02:51:16 PM
Survivability is a function of the gateway not CVP. So no, no need for Call Server at site C.
Regards,
Geoff
Subject: RE: CVP call server...do I need one for every vxml gateway?
Replied by: Michael Aossey on 03-04-2012 03:06:57 PM
If the call is ingressing from a gateway at site c and the gateway is setup to provide VXML treatment then only the signalling would traverse the way. All the audio treatment for any IVR scripts would be played at the gateway itself.
Subject: RE: New Message from Luis Yrigoyen in Customer Voice Portal (CVP) - General
Replied by: GEOFFREY THOMPSON on 03-04-2012 03:07:16 PM
>>>prevent the call treatment from traversing the WAN
CVP does that. Not sure what you are saying.
Regards,
Geoff
Subject: RE: New Message from Luis Yrigoyen in Customer Voice Portal (CVP) - General
Replied by: Bill Webb on 04-04-2012 11:30:08 AM
A Call Server can point to multiple gateways, but you need to use a SIP Server Group or some other method to create an SRV alias, or have unique DN patterns for each gateway.
Subject: RE: CVP call server...do I need one for every vxml gateway?
Replied by: Bill Webb on 04-04-2012 12:06:28 PM
I promise I'm not looking to be argumentative today - really! ;-)
Personally, I have yet to hear or see in practice a compelling reason to use CUPS or CUSP with CVP, especially with CVP 8.5 which allows for SIP Server Groups AND a consolidated Dial Plan that can be centrally maintained and deployed to multiple CVP Call Servers simultaneously!
But I digress - Luis, a CUPS or CUSP is not required, but if you want to target multiple gateways, for instance, for a particular DN pattern, then you need to create a SIP Server Group which works similar to a DNS alias in that it becomes a single alias targeting multiple other hosts/IP addresses.
The other part of the question is: What patterns/parts of the call flow would you be looking to target multiple gateways for? (It's not a loaded question - I'm just not sure of your architecture)...
- Bill
Subject: RE: CVP call server...do I need one for every vxml gateway?
Replied by: Luis Yrigoyen on 04-04-2012 10:36:47 AM
going back to the question about needing a call server for each vxml gateway or not?
If a gateway is setup for CVP (VXML/provide vxml treatment) then it needs a call server to route to it, no?
My site A has a VXML gateway (ip x.x.x.5) and it has a server running call server and vxml server (x.x.x.23) and my site B the same.
In the site A call server (SIP tab) we have a route pointing to the vxml gateway x.x.x.5 and site B the same with its own gateway and call server.
so if I want to "enable" CVP at site C (VXML gateway) I have to have a call server route to the site C vxml gateway; correct? since a call server can only point to a single VXML gateway.
Subject: RE: New Message from Luis Yrigoyen in Customer Voice Portal (CVP) - General
Replied by: GEOFFREY THOMPSON on 04-04-2012 10:51:16 AM
Where are your 2 SIP Proxies?
Regards,
Geoff
Subject: RE: CVP call server...do I need one for every vxml gateway?
Replied by: Luis Yrigoyen on 04-04-2012 11:33:16 AM
Im not really sure what you mean by proxys. I supposed one at each site.
We have one PSTN gateway at each site which directs calls to the site's CVP Call Server via dial-peers.
At each site we have a VXML gateway.
Subject: RE: New Message from Luis Yrigoyen in Customer Voice Portal (CVP) - General
Replied by: GEOFFREY THOMPSON on 04-04-2012 11:37:16 AM
>>> Im not really sure what you mean by proxys. I supposed one at each site.
Are you saying you have no SIP Proxy servers (either a CUPS or a CUSP)?
Regards,
Geoff
Subject: RE: CVP call server...do I need one for every vxml gateway?
Replied by: Luis Yrigoyen on 04-04-2012 11:46:53 AM
our dial-peers session target ipv4: line point to the server running CVP Call Server/VXML Server.
In the call server SIP config
outbound proxy and DNS SRV are disabled.
so I guess we don't have CUPS or CUSP.
Subject: RE: New Message from Luis Yrigoyen in Customer Voice Portal (CVP) - General
Replied by: GEOFFREY THOMPSON on 04-04-2012 12:04:16 PM
>>> so I guess we don't have CUPS or CUSP.
I guess you don’t. How did this design pass A2Q? Is this a very small site?
Regards,
Geoff
Subject: RE: New Message from Bill Webb in Customer Voice Portal (CVP) - General Dis
Replied by: GEOFFREY THOMPSON on 04-04-2012 12:17:16 PM
Bill,
Ooh, good – an argument. ;-)
We can see in the SRND that SIP Proxies are recommended.
“Unified CVP can also be deployed without a SIP Proxy Server depending on the design and complexity of the solution. In such cases, some of the same functions can be provided by the Unified CVP Server SIP Service. If a SIP Proxy Server is not used, then Ingress Gateways and Unified CMs must point directly to Unified CVP. In such a deployment, load balancing is done via DNS SRV lookups from the gateway to the DNS Server. Load balancing of calls outbound from Unified CVP (outbound call leg) can be done in a similar fashion.”
(Page 1-12)
I have hugely complicated CVP deployments that could not be done without gatekeepers or SIP Proxies. Some of these are 7 years old, so the new developments you mention with SIP were simply not there in earlier versions.
I very much favour a pair of CUSP in a CVP.
Regards,
Geoff
Subject: RE: CVP call server...do I need one for every vxml gateway?
Replied by: Gerard O'Rourke on 04-04-2012 12:27:14 PM
Geoff,
Do you know how quick CVP call flow is with and without a SIP proxy at failing over if one of the endpoints is out of service, e.g. CVP CallServers, VXML gateways, PSTN gateways or CUCM servers ?
All my existing customers are H323 with clustered GKs (which works very nicely for this - as the Gateways derigster from the GK - so a call is never routed to a failed endpoint.
Is it the same with CUSP (SIP Registration?) (and the GK are clustered - so if a GK fails no issue either).
I will be moving many of the customers to SIP when CVP upgrades occur and the larger customers will have CUSP, but I too was wondering if CUSP is really necssary?
It probably is really necssary when customer has a large number of Callservers / VXML gateways to allow easy and quick change for operationaly reasons?
Gerard
Subject: RE: New Message from Gerard O'Rourke in Customer Voice Portal (CVP) - Gener
Replied by: GEOFFREY THOMPSON on 04-04-2012 12:34:16 PM
With CUSP (the NME in a Router) you can make Server Groups which SIP sends the OPTION PING to every 10s or so, so the Proxy can know about failures and not have to rely on a retry strategy.
But with SIP, the time between 1st and 2nd INVITES is 0.5s, so if you have retries turned way down (I do) you will be sending the INVITE to the alternate very quickly.
I understand how good GKs are – I think SIP is now very, very close – and way easier!
Regards,
Geoff
Subject: RE: New Message from Gerard O'Rourke in Customer Voice Portal (CVP) - Gener
Replied by: Bill Webb on 04-04-2012 02:28:10 PM
So I'll qualify my statement with the ever-popular "it depends", with the rest being "on the architecture". You are absolutely correct, Geoff, that the recent additions to the product means they were not available until recently, so that is definitely a factor.
I have done a couple larger deployments, but these ended up being almost completely centralized, including things like VXML gateway farms. One was also H.323, so gatekeeper, unlike a SIP Proxy, was required no matter what and so was used for the dial plan.
I have done a couple smaller deployments with SIP (pre-8.5) without any proxy, with good results. Those customers, as described in the SRND, used DNS to manage SRV aliases and failover times were decent even before tweaking.
Fast forward to today for a new deployment or ten an upgrade with migration to SIP with CVP 8.5. First, I'd argue that the snippet you have from the SRND (which I'm all too familiar with!) doesn't really speak to me as a recommendation for the use of a proxy, which has been part of my argument for some time. Instead, it's really just a matter-of-fact statement that says you need to manage things differently.
So back to today, and an ideal environment where we have CVP 8.5 in a multi-site centralized deployment with distributed gateways (I would say the most common deployment, even if it is only 1 or 2 ingress gateway sites). Here's the setup:
1. Configure static SRV entries in the IOS gateways to reach the CVP Call Servers - this gives the same advantage as using DNS SRV, but doesn't rely on a DNS server and the possible delay it can introduce. You could argue that this creates additional overhead in terms of individual gateway configuration, but I would counter that with the robustness of not needing a DNS server, and the ability to tweak weights and priorities based on the gateway's proximity and link sizes to each Call Server location.
2. Use Send to Originator for the VRU leg, and make every gateway a "hybrid" ingress/VXML gateway.
3. In CVP Ops Console, create a SIP Server Group for the UCM Cluster nodes, and set up your "catch-all" static route entry to point to this alias: ">,ucm.customer.com". Advantage again to SIP Server Groups - no need for a DNS server anymore to manage the alias and its elements. You also still get the OPTIONS ping capability.
4. If needed, you could also have a gateway SIP Server Group, but it would seem like calls directed to a gateway are more site-specific (like for off-net routing or something) and might be better served by a Send to Originator pattern entry.
In that setup, I see no additional value for a proxy of any kind, because the dial plan is not very complex (and shouldn't need to be for the most part), and the centralized Dial Plan function in Ops Console with CVP 8.5 makes it easy to deploy initial config and changes very easily to almost any number of CVP Call Servers. The part I don't know for sure is the default behavior for static SRV entries at the IOS gateway level, but I'm guessing whatever limitation might exist there would not be enough to justify blowing the whole architecture out to include multiple proxy modules and the cost and effort involved in deploying and maintaining those.
I'll admit that I'm anal and probably even bull-headed at times in my conviction that "the simplest solution is usually the best", but considering how complex CVP can be anyway, this seems to be a good rule to live by.
I think I'm up to $0.04 for today now...! ;-)
- Bill
Subject: RE: New Message from Luis Yrigoyen in Customer Voice Portal (CVP) - General
Replied by: GEOFFREY THOMPSON on 05-04-2012 12:08:49 PM
You are confused by what “survivability” means, and perhaps I have confused you with my comment “CVP stand-alone application running on the gateway”. I don’t think I am confused because, in CVP, the gateway is the IVR. ;-) That’s where the Voice Browser lives and that’s where the VXML is interpreted – it comes from somewhere else normally (although bootstrap.vxml is in the flash of the router, so the VB can do that too).
Survivability is really for a branch office site, where there are IP phones connected to a remote CUCM Subscriber, and there is CVP Comprehensive. The WAN has failed and two things have happened:
(a) the phones have failed over to SRST on the gateway
(b) survivability, which is on the incoming pots dial peer, is taking alternative action because CVP cannot be contacted and is distributing calls across the ePhones in a hunt group. (CME can be more exotic with B-ACD).
If you don’t have IP phones, you don’t have survivability needs.
Now in your case (no agents at the branch) you MAY decide to take some alternative action if the WAN for CVP is down, but this requires a .tcl file and a .vxml file on the flash, and some serious coding. I don’t think that’s what you are going to do.
>>>>1. I'll set the site C GW for vxml and host this app on Site A's vxml server and use unique DNs for site C's vxml GW on the call sever at site A.
Yes. I would consider not using the Call Server at all. If this is a self-service IVR application, make it CVP VXML standalone. No DNs configured in ICM etc. No reporting of course, but through the Call logs on the VXML server. You can mix Comprehensive and Standalone.
>>>>2. configure survivability on site C's GW to forward calls to a CM DN at the site.
That’s possible, but is it necessary? The self-service app is down because the WAN is down. No agents at the site (you said) and all non-agent phones are running off SRST.
Are you saying you want to give these self-service calls to some of these non-agents? Can they handle it? What is the purpose?
(You would not be able to use CVP Standalone in this case)
Regards,
Geoff
Subject: RE: CVP call server...do I need one for every vxml gateway?
Replied by: Luis Yrigoyen on 05-04-2012 01:56:01 PM
Probably I am...
I can't use SRST at this particular branch since it has a local UCM.
All the calls to this branch office in Los Angeles (I'm calling it Site C) come in via the same main number, the router currently has a dial-peer which points to a CVP server in our Miami site.
The Miami site (Site A) is hosting the app (SiteC_Main) so what I want is two things:
1. I don't want the call treatment to ride the WAN
2. I don't want the calls to be dropped when the WAN is down.
So, I thought that to do #1 I needed to do #2 :-)
Subject: RE: CVP call server...do I need one for every vxml gateway?
Replied by: Luis Yrigoyen on 05-04-2012 10:02:48 AM
Sorry, I got busy and couldn't get back on; but I see the conversation got interesting...
"is this a small site?"
I don't know what would be consider small but yes, maybe; 15,000 calls/day, 300 agents, 1 vxml gw...
"The other part of the question is: What patterns/parts of the call flow would you be looking to target multiple gateways for?"
We now have a small remote site (no call center, minimum number of calls) but with an extensive IVR menu (CVP app). So I was looking into setting up the site's PSTN GW with vxml browsing to provide caching and survivability.
thanks
Subject: RE: New Message from Luis Yrigoyen in Customer Voice Portal (CVP) - General
Replied by: GEOFFREY THOMPSON on 05-04-2012 10:35:49 AM
>>>>We now have a small remote site (no call center, minimum number of calls) but with an extensive IVR menu (CVP app). So I was looking into setting up the site's PSTN GW with vxml browsing to provide caching and survivability.
So the gateway has PRIs to the carrier and calls ingress here?
If this site has no call center, are you saying that calls coming into this site, hitting the IVR menu, will be transferred (voip across the WAN) to another location? Or are you saying this menu is essentially a self-service app?
If the latter, you could make this a CVP stand-alone application, running on the gateway. The app would be installed on your primary and secondary VXML server, and the gateway would have fault-tolerance for the app with the standard config.
If the former, then you cannot have survivability – there are no local agents. VoIP across the WAN – ok on bandwidth, latency, QoS etc?
Regards,
Geoff
Subject: RE: New Message from Luis Yrigoyen in Customer Voice Portal (CVP) - General
Replied by: Luis Yrigoyen on 05-04-2012 10:46:36 AM
"So the gateway has PRIs to the carrier and calls ingress here?" correct.
"If this site has no call center, are you saying that calls coming into this site, hitting the IVR menu, will be transferred (voip across the WAN) to another location? Or are you saying this menu is essentially a self-service app?"
Yes, it is a self service app.
"If the latter, you could make this a CVP stand-alone application, running on the gateway. The app would be installed on your primary and secondary VXML server, and the gateway would have fault-tolerance for the app with the standard config."
So you're saying that by making it a CVP stand-alone application, the app will be active even if the WAN goes down?
thanks
Subject: RE: New Message from Luis Yrigoyen in Customer Voice Portal (CVP) - General
Replied by: GEOFFREY THOMPSON on 05-04-2012 10:59:49 AM
In CVP, if connection between the voice gateway and both VXML servers is lost, no design will allow the application to work. The VXML has to come from somewhere.
What were you thinking could happen?
Regards,
Geoff
Subject: RE: CVP call server...do I need one for every vxml gateway?
Replied by: Luis Yrigoyen on 05-04-2012 11:15:52 AM
I understand that if the wan goes down the app will no t be available and that survivability provides a "graceful" way to handle the call but I didn't expected to be available when the vxml servers are accessible via wan; but you wrote "If the latter, you could make this a CVP stand-alone application, running on the gateway."
that's why I was asking.
But I think I have an idea of what to do/test.
1. I'll set the site C GW for vxml and host this app on Site A's vxml server and use unique DNs for site C's vxml GW on the call sever at site A.
2. configure survivability on site C's GW to forward calls to a CM DN at the site.
thanks
Subject: RE: New Message from Luis Yrigoyen in Customer Voice Portal (CVP) - General
Replied by: Sidney Orret on 05-04-2012 11:53:49 AM
As long as you can reach one vxml server hosting the correct application from the vxml gw you should be fine. Only in the event that there is an unrecoverable failure should the survivability.tcl trigger. Assuming UCCE/CVP comprehensive this is what you can do.
on the UCCE script set user.microapp.media_server variable as http://vxmlserver:7000/CVP (Use the actual word vxmlserver, or any other name that you like but not the actual hostname of the vxmlserver. Most of the time I use the routing client name, that you can get from the ICM variable.)
Then on the vxml gw create the following ip host entries
ip host vxmlserver ip_of_primary_vxmlserver
ip host vxmlserver-backup ip_of_backup_vxmlserver
With that configuration if the primary vxmlserver is not available, the vxml gw will try the backup server, and survivability won’t trigger.
A more elegant solution if you have several vxml servers on your environment is to use CSS.
From: Cisco Developer Community Forums [mailto:cdicuser@developer.cisco.com]
Sent: Thursday, April 05, 2012 8:16 AM
To: cdicuser@developer.cisco.com
Subject: New Message from Luis Yrigoyen in Customer Voice Portal (CVP) - General Discussion - All Versions: RE: CVP call server...do I need one for every vxml gateway?
Luis Yrigoyen has created a new message in the forum "General Discussion - All Versions":
--------------------------------------------------------------
I understand that if the wan goes down the app will no t be available and that survivability provides a "graceful" way to handle the call but I didn't expected to be available when the vxml servers are accessible via wan; but you wrote "If the latter, you could make this a CVP stand-alone application, running on the gateway."
that's why I was asking.
But I think I have an idea of what to do/test.
1. I'll set the site C GW for vxml and host this app on Site A's vxml server and use unique DNs for site C's vxml GW on the call sever at site A.
2. configure survivability on site C's GW to forward calls to a CM DN at the site.
thanks
--
To respond to this post, please click the following link:
<http://developer.cisco.com/web/cvp/forums/-/message_boards/view_message/5412879>
or simply reply to this email.
Subject: RE: CVP call server...do I need one for every vxml gateway?
Replied by: Luis Yrigoyen on 30-04-2012 09:44:16 AM
It turns out that I need to setup SetSigDigits. I found the following post:
https://supportforums.cisco.com/docs/DOC-5832
thanks
Subject: RE: New Message from Luis Yrigoyen in Customer Voice Portal (CVP) - General
Replied by: GEOFFREY THOMPSON on 30-04-2012 09:50:51 AM
>>>It turns out that I need to setup SetSigDigits. I found the following post:
SIP SigDigits is a workable solution only when the Ingress Gateway and the VXML Gateway are separate – otherwise it may not be what you need. Is that your environment? Run the design by me again.
Regards,
Geoff
Created by: Luis Yrigoyen on 03-04-2012 02:21:52 PM
Hi,
We're running CVP comprehensive model 8.0 with ICM 8.5.
We currenlty have two sites (A and
, both sites have call centers and each site has:1 PSTN gateway with a few PRIs
1 gateway running CVP (VXML broswer)
1 co-located CVP Call Server and CVP VXML Server (and media server)
and of course all the other telephony servers (CM, ROGGER,PG, CTIOS, etc)
All of our INBOUND calls get CVP treatment (contact center related calls and non-contact center related calls).
When callers call our non-contact center numbers (i.e. our main number) we play a CVP app (a menu with options).
We are now opening a new site (I'll call it Site C) which main number routes to a CVP app hosted at site A and I was wondering if we need a local CVP Call Server/VXML Server since I want to implement CVP survivability in case the WAN goes down.
any help is appreciated.
Subject: RE: CVP call server...do I need one for every vxml gateway?
Replied by: Luis Yrigoyen on 03-04-2012 03:02:05 PM
Mike,
thanks for the reply.
Yes, that clears things up.
I guess what we're really looking for is a way to route calls to any where else in case the wan goes down and that seems to be covered by CVP survivability...
but also we wanted to see if it was possible to prevent the call treatment from traversing the WAN without having all the cvp infrastructure at site C.
thanks
Subject: RE: CVP call server...do I need one for every vxml gateway?
Replied by: Michael Aossey on 03-04-2012 02:35:52 PM
Luis,
A CVP server at the remote site (site C) will do you no good if the WAN is down given that CVP is deployed in coprehensive mode and it would not be able to reach the Central Controller to make route requests. Survivability is a TCL based application that runs on the remote site gateway and hairpins the call back to another site (over the PSTN) when the CVP server and Central Controller are accessable. Alternativley you could place a CVP server at Site C in stand-alone mode to offer IVR functionallity but it would not be tied to ICM reporting in any way and would not have ACD functionality available.
I hope this helps!
Thanks, Mike.
Subject: RE: New Message from Luis Yrigoyen in Customer Voice Portal (CVP) - General
Replied by: GEOFFREY THOMPSON on 03-04-2012 02:51:16 PM
Survivability is a function of the gateway not CVP. So no, no need for Call Server at site C.
Regards,
Geoff
Subject: RE: CVP call server...do I need one for every vxml gateway?
Replied by: Michael Aossey on 03-04-2012 03:06:57 PM
If the call is ingressing from a gateway at site c and the gateway is setup to provide VXML treatment then only the signalling would traverse the way. All the audio treatment for any IVR scripts would be played at the gateway itself.
Subject: RE: New Message from Luis Yrigoyen in Customer Voice Portal (CVP) - General
Replied by: GEOFFREY THOMPSON on 03-04-2012 03:07:16 PM
>>>prevent the call treatment from traversing the WAN
CVP does that. Not sure what you are saying.
Regards,
Geoff
Subject: RE: New Message from Luis Yrigoyen in Customer Voice Portal (CVP) - General
Replied by: Bill Webb on 04-04-2012 11:30:08 AM
A Call Server can point to multiple gateways, but you need to use a SIP Server Group or some other method to create an SRV alias, or have unique DN patterns for each gateway.
Subject: RE: CVP call server...do I need one for every vxml gateway?
Replied by: Bill Webb on 04-04-2012 12:06:28 PM
I promise I'm not looking to be argumentative today - really! ;-)
Personally, I have yet to hear or see in practice a compelling reason to use CUPS or CUSP with CVP, especially with CVP 8.5 which allows for SIP Server Groups AND a consolidated Dial Plan that can be centrally maintained and deployed to multiple CVP Call Servers simultaneously!
But I digress - Luis, a CUPS or CUSP is not required, but if you want to target multiple gateways, for instance, for a particular DN pattern, then you need to create a SIP Server Group which works similar to a DNS alias in that it becomes a single alias targeting multiple other hosts/IP addresses.
The other part of the question is: What patterns/parts of the call flow would you be looking to target multiple gateways for? (It's not a loaded question - I'm just not sure of your architecture)...
- Bill
Subject: RE: CVP call server...do I need one for every vxml gateway?
Replied by: Luis Yrigoyen on 04-04-2012 10:36:47 AM
going back to the question about needing a call server for each vxml gateway or not?
If a gateway is setup for CVP (VXML/provide vxml treatment) then it needs a call server to route to it, no?
My site A has a VXML gateway (ip x.x.x.5) and it has a server running call server and vxml server (x.x.x.23) and my site B the same.
In the site A call server (SIP tab) we have a route pointing to the vxml gateway x.x.x.5 and site B the same with its own gateway and call server.
so if I want to "enable" CVP at site C (VXML gateway) I have to have a call server route to the site C vxml gateway; correct? since a call server can only point to a single VXML gateway.
Subject: RE: New Message from Luis Yrigoyen in Customer Voice Portal (CVP) - General
Replied by: GEOFFREY THOMPSON on 04-04-2012 10:51:16 AM
Where are your 2 SIP Proxies?
Regards,
Geoff
Subject: RE: CVP call server...do I need one for every vxml gateway?
Replied by: Luis Yrigoyen on 04-04-2012 11:33:16 AM
Im not really sure what you mean by proxys. I supposed one at each site.
We have one PSTN gateway at each site which directs calls to the site's CVP Call Server via dial-peers.
At each site we have a VXML gateway.
Subject: RE: New Message from Luis Yrigoyen in Customer Voice Portal (CVP) - General
Replied by: GEOFFREY THOMPSON on 04-04-2012 11:37:16 AM
>>> Im not really sure what you mean by proxys. I supposed one at each site.
Are you saying you have no SIP Proxy servers (either a CUPS or a CUSP)?
Regards,
Geoff
Subject: RE: CVP call server...do I need one for every vxml gateway?
Replied by: Luis Yrigoyen on 04-04-2012 11:46:53 AM
our dial-peers session target ipv4: line point to the server running CVP Call Server/VXML Server.
In the call server SIP config
outbound proxy and DNS SRV are disabled.
so I guess we don't have CUPS or CUSP.
Subject: RE: New Message from Luis Yrigoyen in Customer Voice Portal (CVP) - General
Replied by: GEOFFREY THOMPSON on 04-04-2012 12:04:16 PM
>>> so I guess we don't have CUPS or CUSP.
I guess you don’t. How did this design pass A2Q? Is this a very small site?
Regards,
Geoff
Subject: RE: New Message from Bill Webb in Customer Voice Portal (CVP) - General Dis
Replied by: GEOFFREY THOMPSON on 04-04-2012 12:17:16 PM
Bill,
Ooh, good – an argument. ;-)
We can see in the SRND that SIP Proxies are recommended.
“Unified CVP can also be deployed without a SIP Proxy Server depending on the design and complexity of the solution. In such cases, some of the same functions can be provided by the Unified CVP Server SIP Service. If a SIP Proxy Server is not used, then Ingress Gateways and Unified CMs must point directly to Unified CVP. In such a deployment, load balancing is done via DNS SRV lookups from the gateway to the DNS Server. Load balancing of calls outbound from Unified CVP (outbound call leg) can be done in a similar fashion.”
(Page 1-12)
I have hugely complicated CVP deployments that could not be done without gatekeepers or SIP Proxies. Some of these are 7 years old, so the new developments you mention with SIP were simply not there in earlier versions.
I very much favour a pair of CUSP in a CVP.
Regards,
Geoff
Subject: RE: CVP call server...do I need one for every vxml gateway?
Replied by: Gerard O'Rourke on 04-04-2012 12:27:14 PM
Geoff,
Do you know how quick CVP call flow is with and without a SIP proxy at failing over if one of the endpoints is out of service, e.g. CVP CallServers, VXML gateways, PSTN gateways or CUCM servers ?
All my existing customers are H323 with clustered GKs (which works very nicely for this - as the Gateways derigster from the GK - so a call is never routed to a failed endpoint.
Is it the same with CUSP (SIP Registration?) (and the GK are clustered - so if a GK fails no issue either).
I will be moving many of the customers to SIP when CVP upgrades occur and the larger customers will have CUSP, but I too was wondering if CUSP is really necssary?
It probably is really necssary when customer has a large number of Callservers / VXML gateways to allow easy and quick change for operationaly reasons?
Gerard
Subject: RE: New Message from Gerard O'Rourke in Customer Voice Portal (CVP) - Gener
Replied by: GEOFFREY THOMPSON on 04-04-2012 12:34:16 PM
With CUSP (the NME in a Router) you can make Server Groups which SIP sends the OPTION PING to every 10s or so, so the Proxy can know about failures and not have to rely on a retry strategy.
But with SIP, the time between 1st and 2nd INVITES is 0.5s, so if you have retries turned way down (I do) you will be sending the INVITE to the alternate very quickly.
I understand how good GKs are – I think SIP is now very, very close – and way easier!
Regards,
Geoff
Subject: RE: New Message from Gerard O'Rourke in Customer Voice Portal (CVP) - Gener
Replied by: Bill Webb on 04-04-2012 02:28:10 PM
So I'll qualify my statement with the ever-popular "it depends", with the rest being "on the architecture". You are absolutely correct, Geoff, that the recent additions to the product means they were not available until recently, so that is definitely a factor.
I have done a couple larger deployments, but these ended up being almost completely centralized, including things like VXML gateway farms. One was also H.323, so gatekeeper, unlike a SIP Proxy, was required no matter what and so was used for the dial plan.
I have done a couple smaller deployments with SIP (pre-8.5) without any proxy, with good results. Those customers, as described in the SRND, used DNS to manage SRV aliases and failover times were decent even before tweaking.
Fast forward to today for a new deployment or ten an upgrade with migration to SIP with CVP 8.5. First, I'd argue that the snippet you have from the SRND (which I'm all too familiar with!) doesn't really speak to me as a recommendation for the use of a proxy, which has been part of my argument for some time. Instead, it's really just a matter-of-fact statement that says you need to manage things differently.
So back to today, and an ideal environment where we have CVP 8.5 in a multi-site centralized deployment with distributed gateways (I would say the most common deployment, even if it is only 1 or 2 ingress gateway sites). Here's the setup:
1. Configure static SRV entries in the IOS gateways to reach the CVP Call Servers - this gives the same advantage as using DNS SRV, but doesn't rely on a DNS server and the possible delay it can introduce. You could argue that this creates additional overhead in terms of individual gateway configuration, but I would counter that with the robustness of not needing a DNS server, and the ability to tweak weights and priorities based on the gateway's proximity and link sizes to each Call Server location.
2. Use Send to Originator for the VRU leg, and make every gateway a "hybrid" ingress/VXML gateway.
3. In CVP Ops Console, create a SIP Server Group for the UCM Cluster nodes, and set up your "catch-all" static route entry to point to this alias: ">,ucm.customer.com". Advantage again to SIP Server Groups - no need for a DNS server anymore to manage the alias and its elements. You also still get the OPTIONS ping capability.
4. If needed, you could also have a gateway SIP Server Group, but it would seem like calls directed to a gateway are more site-specific (like for off-net routing or something) and might be better served by a Send to Originator pattern entry.
In that setup, I see no additional value for a proxy of any kind, because the dial plan is not very complex (and shouldn't need to be for the most part), and the centralized Dial Plan function in Ops Console with CVP 8.5 makes it easy to deploy initial config and changes very easily to almost any number of CVP Call Servers. The part I don't know for sure is the default behavior for static SRV entries at the IOS gateway level, but I'm guessing whatever limitation might exist there would not be enough to justify blowing the whole architecture out to include multiple proxy modules and the cost and effort involved in deploying and maintaining those.
I'll admit that I'm anal and probably even bull-headed at times in my conviction that "the simplest solution is usually the best", but considering how complex CVP can be anyway, this seems to be a good rule to live by.
I think I'm up to $0.04 for today now...! ;-)
- Bill
Subject: RE: New Message from Luis Yrigoyen in Customer Voice Portal (CVP) - General
Replied by: GEOFFREY THOMPSON on 05-04-2012 12:08:49 PM
You are confused by what “survivability” means, and perhaps I have confused you with my comment “CVP stand-alone application running on the gateway”. I don’t think I am confused because, in CVP, the gateway is the IVR. ;-) That’s where the Voice Browser lives and that’s where the VXML is interpreted – it comes from somewhere else normally (although bootstrap.vxml is in the flash of the router, so the VB can do that too).
Survivability is really for a branch office site, where there are IP phones connected to a remote CUCM Subscriber, and there is CVP Comprehensive. The WAN has failed and two things have happened:
(a) the phones have failed over to SRST on the gateway
(b) survivability, which is on the incoming pots dial peer, is taking alternative action because CVP cannot be contacted and is distributing calls across the ePhones in a hunt group. (CME can be more exotic with B-ACD).
If you don’t have IP phones, you don’t have survivability needs.
Now in your case (no agents at the branch) you MAY decide to take some alternative action if the WAN for CVP is down, but this requires a .tcl file and a .vxml file on the flash, and some serious coding. I don’t think that’s what you are going to do.
>>>>1. I'll set the site C GW for vxml and host this app on Site A's vxml server and use unique DNs for site C's vxml GW on the call sever at site A.
Yes. I would consider not using the Call Server at all. If this is a self-service IVR application, make it CVP VXML standalone. No DNs configured in ICM etc. No reporting of course, but through the Call logs on the VXML server. You can mix Comprehensive and Standalone.
>>>>2. configure survivability on site C's GW to forward calls to a CM DN at the site.
That’s possible, but is it necessary? The self-service app is down because the WAN is down. No agents at the site (you said) and all non-agent phones are running off SRST.
Are you saying you want to give these self-service calls to some of these non-agents? Can they handle it? What is the purpose?
(You would not be able to use CVP Standalone in this case)
Regards,
Geoff
Subject: RE: CVP call server...do I need one for every vxml gateway?
Replied by: Luis Yrigoyen on 05-04-2012 01:56:01 PM
Probably I am...
I can't use SRST at this particular branch since it has a local UCM.
All the calls to this branch office in Los Angeles (I'm calling it Site C) come in via the same main number, the router currently has a dial-peer which points to a CVP server in our Miami site.
The Miami site (Site A) is hosting the app (SiteC_Main) so what I want is two things:
1. I don't want the call treatment to ride the WAN
2. I don't want the calls to be dropped when the WAN is down.
So, I thought that to do #1 I needed to do #2 :-)
Subject: RE: CVP call server...do I need one for every vxml gateway?
Replied by: Luis Yrigoyen on 05-04-2012 10:02:48 AM
Sorry, I got busy and couldn't get back on; but I see the conversation got interesting...
"is this a small site?"
I don't know what would be consider small but yes, maybe; 15,000 calls/day, 300 agents, 1 vxml gw...
"The other part of the question is: What patterns/parts of the call flow would you be looking to target multiple gateways for?"
We now have a small remote site (no call center, minimum number of calls) but with an extensive IVR menu (CVP app). So I was looking into setting up the site's PSTN GW with vxml browsing to provide caching and survivability.
thanks
Subject: RE: New Message from Luis Yrigoyen in Customer Voice Portal (CVP) - General
Replied by: GEOFFREY THOMPSON on 05-04-2012 10:35:49 AM
>>>>We now have a small remote site (no call center, minimum number of calls) but with an extensive IVR menu (CVP app). So I was looking into setting up the site's PSTN GW with vxml browsing to provide caching and survivability.
So the gateway has PRIs to the carrier and calls ingress here?
If this site has no call center, are you saying that calls coming into this site, hitting the IVR menu, will be transferred (voip across the WAN) to another location? Or are you saying this menu is essentially a self-service app?
If the latter, you could make this a CVP stand-alone application, running on the gateway. The app would be installed on your primary and secondary VXML server, and the gateway would have fault-tolerance for the app with the standard config.
If the former, then you cannot have survivability – there are no local agents. VoIP across the WAN – ok on bandwidth, latency, QoS etc?
Regards,
Geoff
Subject: RE: New Message from Luis Yrigoyen in Customer Voice Portal (CVP) - General
Replied by: Luis Yrigoyen on 05-04-2012 10:46:36 AM
"So the gateway has PRIs to the carrier and calls ingress here?" correct.
"If this site has no call center, are you saying that calls coming into this site, hitting the IVR menu, will be transferred (voip across the WAN) to another location? Or are you saying this menu is essentially a self-service app?"
Yes, it is a self service app.
"If the latter, you could make this a CVP stand-alone application, running on the gateway. The app would be installed on your primary and secondary VXML server, and the gateway would have fault-tolerance for the app with the standard config."
So you're saying that by making it a CVP stand-alone application, the app will be active even if the WAN goes down?
thanks
Subject: RE: New Message from Luis Yrigoyen in Customer Voice Portal (CVP) - General
Replied by: GEOFFREY THOMPSON on 05-04-2012 10:59:49 AM
In CVP, if connection between the voice gateway and both VXML servers is lost, no design will allow the application to work. The VXML has to come from somewhere.
What were you thinking could happen?
Regards,
Geoff
Subject: RE: CVP call server...do I need one for every vxml gateway?
Replied by: Luis Yrigoyen on 05-04-2012 11:15:52 AM
I understand that if the wan goes down the app will no t be available and that survivability provides a "graceful" way to handle the call but I didn't expected to be available when the vxml servers are accessible via wan; but you wrote "If the latter, you could make this a CVP stand-alone application, running on the gateway."
that's why I was asking.
But I think I have an idea of what to do/test.
1. I'll set the site C GW for vxml and host this app on Site A's vxml server and use unique DNs for site C's vxml GW on the call sever at site A.
2. configure survivability on site C's GW to forward calls to a CM DN at the site.
thanks
Subject: RE: New Message from Luis Yrigoyen in Customer Voice Portal (CVP) - General
Replied by: Sidney Orret on 05-04-2012 11:53:49 AM
As long as you can reach one vxml server hosting the correct application from the vxml gw you should be fine. Only in the event that there is an unrecoverable failure should the survivability.tcl trigger. Assuming UCCE/CVP comprehensive this is what you can do.
on the UCCE script set user.microapp.media_server variable as http://vxmlserver:7000/CVP (Use the actual word vxmlserver, or any other name that you like but not the actual hostname of the vxmlserver. Most of the time I use the routing client name, that you can get from the ICM variable.)
Then on the vxml gw create the following ip host entries
ip host vxmlserver ip_of_primary_vxmlserver
ip host vxmlserver-backup ip_of_backup_vxmlserver
With that configuration if the primary vxmlserver is not available, the vxml gw will try the backup server, and survivability won’t trigger.
A more elegant solution if you have several vxml servers on your environment is to use CSS.
From: Cisco Developer Community Forums [mailto:cdicuser@developer.cisco.com]
Sent: Thursday, April 05, 2012 8:16 AM
To: cdicuser@developer.cisco.com
Subject: New Message from Luis Yrigoyen in Customer Voice Portal (CVP) - General Discussion - All Versions: RE: CVP call server...do I need one for every vxml gateway?
Luis Yrigoyen has created a new message in the forum "General Discussion - All Versions":
--------------------------------------------------------------
I understand that if the wan goes down the app will no t be available and that survivability provides a "graceful" way to handle the call but I didn't expected to be available when the vxml servers are accessible via wan; but you wrote "If the latter, you could make this a CVP stand-alone application, running on the gateway."
that's why I was asking.
But I think I have an idea of what to do/test.
1. I'll set the site C GW for vxml and host this app on Site A's vxml server and use unique DNs for site C's vxml GW on the call sever at site A.
2. configure survivability on site C's GW to forward calls to a CM DN at the site.
thanks
--
To respond to this post, please click the following link:
<http://developer.cisco.com/web/cvp/forums/-/message_boards/view_message/5412879>
or simply reply to this email.
Subject: RE: CVP call server...do I need one for every vxml gateway?
Replied by: Luis Yrigoyen on 30-04-2012 09:44:16 AM
It turns out that I need to setup SetSigDigits. I found the following post:
https://supportforums.cisco.com/docs/DOC-5832
thanks
Subject: RE: New Message from Luis Yrigoyen in Customer Voice Portal (CVP) - General
Replied by: GEOFFREY THOMPSON on 30-04-2012 09:50:51 AM
>>>It turns out that I need to setup SetSigDigits. I found the following post:
SIP SigDigits is a workable solution only when the Ingress Gateway and the VXML Gateway are separate – otherwise it may not be what you need. Is that your environment? Run the design by me again.
Regards,
Geoff