Starting with version 8.x of CVP, H.323 is no longer a supported protocol for greenfield deployments. The caveat is that a common ground upgrade does support H.323. I have not heard that a gateway physically does not support H.323 but mostly advisement that all new deployments of CVP 8.x and beyond should be placed on a SIP infrastructure. Furthermore, virtualization of CVP using UCS B or C series servers also do not support the virtualization of H.323. Therefore, if a customer is performing a technology refresh and is looking to virtualized Unified CVP and currently using H.323, you must plan to perform a protocol migration to SIP prior to the virtualization event or plan to virtualize and migrate to SIP simultaneously.
I found a document that states if CVP server is virtualized, it must be SIP and not h323. So this means we have to use a sip proxy to register everything. CUPS, or CUPS is what I see so far.
We are being told that CUPS is EOS for CVP SIP Proxy as of March, and that honestly we can't really buy it without alot of hoops (no support etc). Also they are making no new features sets on CVP for SIP. So it sounds to me the only choice is SIP with CUSP, or without a SIP Proxy, which is fine for say 2 CVP server but no more.. and only 1 CUCM cluster... anything above thise you need a SIP Proxy to not make the install look like garbage.
So if I only have (1) CVP server and (1) gateway, I do not need CUSP. But if I have multiple gateways, multiple CVP servers, I need CUSP to load balance and route the SIP traffic to/from the gateway and CVP servers.
Bingo, you could do some minor load balancing with dial'eers but ultimatly CVP towards anything else is fully unredundant in its routes, and needs a SIP Proxy to do any good.
Depending on the environment with CVP 8.5 and new "Dialed Number Pattern System Configuration" configuration you may be able to get away from needing proxy server, the feature makes it alot easier to simply configure all routing within CVP OAMP and push out to all Call Servers, the admin guide disusses it in more detail:
Does this have the ability to allow you to somehow load balance or preferentialy route calls out of the CVP server towards VXML gateways and CUCM clusers? Or is this only inbound into ICM as it suggests, not solving the real problem a SIP Proxy is necessary for?
Hi, Chris or others with CVP SIP experience:
I'm new to contact center, and am feeling that there is no definitive guidance as to whether you need to use a SIP proxy or if you can manage routing in the Operations Console/DNS SRV records. At what point does the SIP Proxy actually become necessary? Is this documented? We have 2 pairs of redundant CVP servers, each pair hosted on a separate CallManager cluster, I'll call each set a region. Each region has only 2-4 VXML gateways and <30 total agents. Do you have any advise? I've scanned the SRND and CVP Admin Guide, but can't seem to find the right guidance I'm looking for.
With what you described above, you could get away without a SIP Proxy. However, anything larger than this deployment best practice states that you should deploy a SIP Proxy to centralize your dial plan and stream line your Call Server deployments. It is not impossible to deploy larger CVP farms and never use a SIP Proxy but other than cost, why would you ever want to generate that much pain from an operational perspective?
Take a look at my new book on Unified CVP, there is a great chapter on CVP redundancy which includes non-native component redundancy using a SIP Proxy server. The book can be purchased from different outlets but here is the Cisco Press link: