cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
758
Views
0
Helpful
9
Replies

Ingress GW failover direct to CVP Server

micandre
Level 1
Level 1

Hello,

Having only previously installed CVP 3.X...

With CVP 4.X and SIP I want to have an ingress dial peer first pointing to my CUPS server. Then configure and second dial peer with a preference on 2 pointing directly to the CVP Server (In case CUPS fails).

Is this feasible, are there any issues with this?

Regards, Michael

1 Accepted Solution

Accepted Solutions

Hi Michael,

I understood where you were coming it is something we put in place for 2.0 and 3.0 in the early design guides but eventually dropped because of some potential issues and recommended to use HRSP on the GK instead(basically what happened as an issue was that callers were continually calling since they were dropped whenever bandwidth usage was above the set limit, since this RAS failure due to the bandwidth used, calls were routed via the dial peer preference to the CVP directly creating further bandwidth usage hence we ended up in a nightmare of high number of call setup and eventually dropped and the CVP servers completely brought out of service, basically defeating the original intent, better consider an additional GK and HRSP).

What you might consider for your failure scenario is routing directly from the GW to a Unified Call Manager SIP Trunk or for the previous releases directly to a UCM extension, not sure if the SIP SS will be in partial or out of service, but you need a CUPS to route those calls via SIP in the current CVP environment.

Regards,

Riccardo

View solution in original post

9 Replies 9

vmoopeung
Level 5
Level 5

There are many way to provide load balancing and redundancy for CVP.

using SIP proxy servers, gatekeeper, HSRP and other redundancy mechanisms.

The below url discuss this in detail.

http://www.cisco.com/en/US/docs/voice_ip_comm/cust_contact/contact_center/customer_voice_portal/srnd/4x/vp40high.html

Riccardo Bua
Level 5
Level 5

Hi Michael,

CUPS is only used as a mean to provision the SIP subsystems running on CVP of a SIP Proxy, if CUPS is down then most likely the subsystem will be down too, what are you planning to do on the CVP when you land there eventually in a similar scenario?

Regards,

Riccardo

Hi Riccardo,

Many thanks for your response. The reason I ask the question is that the design guide talks about the option of dial-peers pointing directly at SIP Proxy servers or directly to the CVP Server (SIP Service). It does not mention a combination of both where the preference would be to use the SIP Proxy Server and if this server fails then subsequent calls go directly to the CVP SIP Service.

I've had similar setup where the dial-peer points as a session target ras, with a second dial peer with a session target ipv4:.

At this stage it's for a design for a customer who wants to know what options they have. Using CVP 4.X Comprehensive model with ICM. My understanding from what you've put is that the SIP subsystem running on CVP is dependant on CUPS running, and if CUPS fails the SIP subsystem will stop as well?

Regards, Michael

Hi Michael,

I understood where you were coming it is something we put in place for 2.0 and 3.0 in the early design guides but eventually dropped because of some potential issues and recommended to use HRSP on the GK instead(basically what happened as an issue was that callers were continually calling since they were dropped whenever bandwidth usage was above the set limit, since this RAS failure due to the bandwidth used, calls were routed via the dial peer preference to the CVP directly creating further bandwidth usage hence we ended up in a nightmare of high number of call setup and eventually dropped and the CVP servers completely brought out of service, basically defeating the original intent, better consider an additional GK and HRSP).

What you might consider for your failure scenario is routing directly from the GW to a Unified Call Manager SIP Trunk or for the previous releases directly to a UCM extension, not sure if the SIP SS will be in partial or out of service, but you need a CUPS to route those calls via SIP in the current CVP environment.

Regards,

Riccardo

Many thanks for that Riccardo I will look into those options in the lab.

Regards, Michael

My understanding is, CVP SIP subsystem doesn't monitor CUPS status, it listens SIP port, and re-route calls to destinations by predefined status routes, so CUPS down won't cause CVP SIP service down.

I believe it is possible to have second dial peer pointing to CVP directly, just make sure on CVP SIP service, don't configure SIP proxy, so CVP can receive request from any SIP endpoints.

Wei

Thanks Wei,

I'll try that in the lab.

Regards, Michael

Hi Mike,

We had SIP with CUPS configured in a new install. We had major issues with CUPS around MTP's required on the trunks in and out. Went to Cisco Dev but was not resolved.

It was decided to change to H323.

We have 3 major upgrades this year, we where going to upgrade the customers to SIP but after the issues we seen with the CUPS server and SIP they are all staying with H323.

Also H323 Gatekeeper has better failover as it has a stateful connection. Plus H323 has better CAC functionality. CVP4 with SIP requires DNS SRV requests from CVP for load balancing and failover (7 you can use local statics)whch introduces delay.

Stay with H323 for comprehensive is my advice.

Regards

Anthony

Regarding the MTP usage with CUCM SIP Trunk in use on the CVP transfer call flows, it is only needed on consult transfers with queueing, when agent1 completes the transfer to caller while still in queue. The issue is with the VXML gateway not supporting the mid call media change and we are working on getting this issue supported. So the MTP usage is the workaround for this issue, and if the customer does have consults with queueing, and their agents may complete while in queue, then you will need the MTP until this is resolved. Also dual SIP Trunks can be configured so MTP is only allocated on the outbound trunk involved in the consults, ie not on 100% of the CVP SIP calls.

So CUPS proxy by itself is not causing the MTP requirement.

Regarding the CVP 4.0 DNS requirement for failover/load balancing, CVP 7.0 has added the local SRV configuration feature so there is no delay for lookups with each call.

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: