Unified SIP Proxy / vCUSP replacement

[bspalmer1]

It looks like Cisco is no longer going to be producing this product and has recommended an Oracle product or any other 3rd party sip proxy system in the compatibility matrix. 

Has anybody already replaced vCUSP with an alternative product?  If you have let me know what your thoughts and experiences are with that product.  Due to the nature/size of the enterprise I am handling the sort of product I would need has to have enterprise level support availability.  As much as I like open source options in some cases they don't offer support.

[Jason Durie]

Thanks for your response!! What I think I'm hearing is that it is a matter of CPS. Functionally, vCUBE can operate as a CUSP replacement if the CPS capacity is sufficient to handle the load of the CUSP deployment it is replacing, but it is far less efficient at the task, and therefore in many/most scenarios, it would be incapable of being a replacement for CUSP as traffic exceeds vCUBEs largest sizing . I think the reason I've been tasked with using CUBE is because the CPS is low enough to fit in the largest vCUBE sizing, and then the customer doesn't have to deal with licensing outside of their existing Cisco contract (I'm on the receiving end of this project...).

[Jonathan Schulenberg]

It sounds like it's a viable substitute for your deployment but I'd shy away from declaring that universally true since a proxy and B2BUA are fundamentally different tools. I can imagine use cases where CUBE would be undesirable even if it could handle the load since it terminates the SIP dialogs per-call leg. Different Call-IDs, SIP headers aren't maintained, SDP is processed/filtered, CUBE is stuck in the call signaling path (at least without a SIP REFER), CUBE is stuck in the media path (at least without flow around), etc. I suspect CUSP would have seen more traction if CUCM-SME and ILS didn't exist. And if you're really old, there are some Directory Gatekeeper comparisons to be made if Record Route is off.

[bspalmer1]

This is all good information.  My bet is that they had 1 or 2 developers working on vCUSP and simply didn't want to deal with moving it to a new OS from the current CentOS.  They likely had a bean counter that said the quantity of money it pulls  in is simply not enough to justify doing this.

I guess I liked it because it was stupid simple to operate with and while some engineers downplay a GUI it just makes things easier as commands don't have to be 'memorized'.  It just worked and did its job without having to specialize in it.  With computing continually getting more complex the ability to be a 'generalist' and at the same time a 'specialist' is continuing to burn out engineers that I know left and right.

We didn't want to deal with Oracle is our main problem.  We have an ASE that is working out the config with us to put it on a vCUBE like the other user here which is really not ideal at all.  One thing that was nice was the call counter and the ability to view stats for the server groups on the fly really quickly.

[bspalmer1]

An update to this is that CUSP is not a dead product and it looks like we will see a new version sometime in 26

[bill.king1]

@bspalmer1 , it looks like (unless they extend it) though that you'd still have a gap with no support since it looks like 9/30/25 is EOL? Or did you hear that may be extended too?
https://www.cisco.com/c/en/us/products/collateral/unified-communications/unified-sip-proxy-software/unified-sip-proxy-v10-eol.html 

[Jonathan Schulenberg]

@bspalmer1 Be careful not to violate your NDA here. Until something is published to Cisco.com, it's likely confidential - especially if it's a product roadmap item.