06-09-2023 08:45 AM
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.
06-10-2023 06:01 AM
You might find this thread of interest.
https://community.cisco.com/t5/ip-telephony-and-phones/cisco-cusp-eol-solution-work-around/td-p/4763740
06-10-2023 07:59 PM
Oracle has been positioning themselves as a replacement for SIP Proxy using their SBC: https://www.oracle.com/communications/signaling-security/session-border-controller/
Just to note, CUSP still has a few years of support here... it'll go EoL in 2025. One thing to consider is if you actually need a SIP Proxy in your environment. We have a few customers that have been using Oracle SBC for years, so it plays well with Cisco.
11-15-2023 08:18 AM
Hello,
You may find this information useful:
"Cisco recommends Oracle® Communication Session Router, version SCZ9.1.0 GA (Build 46) or later. However, you can also choose to deploy any third-party SIP proxy that suits your requirement." in Contact Center Enterprise Solution Compatibility Matrix Release 12 5
Additionally you can learn more about the Deployment of Oracle Session Router with CCE in Cisco's Deployment guide:
Deployment Of Oracle® Enterprise Session Router SIP Proxy in Contact Center Enterprise Solution
Oracle Communications in collaboration with Cisco will be hosting a Live Webinar on Nov 30th on this topic, you can register here:
Seamlessly Transition from Cisco Unified SIP Proxy (CUSP) to Oracle Communications
Hope this helps.
Best regards,
Marco Mouta
Oracle Communications WW Alliances & Technology Partnerships Director
11-15-2023 08:46 AM
We have had some discussions with Oracle. The licensing is probably the hardest part to really nail down. On top of that it was nice to have a GUI interface for easy/quick interaction with vCUSP. Oracle is basically just selling a router with some additional command line level 'features' for the proxy. Its like returning back to the days when cusp was a module in a router and no GUI.
09-11-2024 10:11 AM
Does anyone know why Cisco would not be offering a vCUBE based solution for SIP proxy? From what I can tell, this would be converting the CUSP configuration to a combination of dial peers, sip server groups, and e164 pattern matches across a pair (or more) of vCUBEs.
09-11-2024 10:41 AM
You're opening a can of worms. So CUSP was announced to be end of life maybe this year or next year with absolutely no Cisco replacements... however there's a rumor that they might be changing your mind and CUSP might continue to live. As to your point about vCUBE to CUSP, yes that would make sense, but honestly I think it's much simpler to just let CUSP to continue to live than trying to replatform it.
david
09-11-2024 12:51 PM
My question was more about, is there a technical reason why Cisco would steer customers to Oracle vs vCUBEs to replace that functionality, assuming CPS is within performance requirements. Is there something I'm missing that will come to light during/after implementation?
09-11-2024 02:25 PM
I'm not a CUBE expert, they serve completely different functions. CUSP can't terminate SIP trunks, dial plan is super limited, server groups shouldn't be a thing in CUBE. Ultimately, they are two different devices that do tangentially related things, but not the same thing.
david
09-11-2024 02:43 PM - edited 09-11-2024 02:57 PM
CUBE/vCUBE is not a true SIP proxy. It's a B2BUA. Think of CUSP as a load balancer. You don't normally want a load balancer to handle the workload itself, only to distribute load across a pool of resources.
CUSP, especially with Record-Route set to Off, is capable of handling a significantly higher Calls Per Second volume than CUBE/vCUBE is. It's actually more powerful than most people realize IMO. The documentation was just horrible. It took me weeks to figure out the first time - and when I finally did I was even more annoyed because it's fairly straight forward.
For those wondering: the nearest analogy I can think of is imagine CUCM if you had to define each number string/pattern first and then associate it to a DN/TP/RP/etc. The string has no meaning until you attach it to something. A lot of CUSP's config works like that: define the thing, then use it somewhere.
Here's a real world example where CUBE wasn't sufficient - even on the largest chassis Cisco offers. This will make more sense if you are familiar with the CUBE sizing deck and the various caveats around the CPS figures listed on the CUBE data sheets. The customer was implementing SIP trunks with a PSTN provider that supported a single customer SIP address per-physical circuit to that provider. The provider used a larger provider-assigned IPv4 prefix (e.g., /28) but their SBC would only send/receive SIP traffic to a single IPv4 address in that prefix. The call volume/load, based on actual SIP messages vs. the assumed 14 per call cradle-to-grave, and CUBE feature requirements were such that it significantly exceeded the capacity of a single CUBE chassis. We needed to distribute that load across a pool of CUBEs - but didn't want to pay for additional Ethernet circuits per-chassis. CUSP, with Record Route on, was used in front of that CUBE pool. Each CUBE also had an address from that provider's IPv4 prefix for RTP traffic but all SIP traffic flowed through CUSP. A single CUSP was easily able to handle that load.
09-12-2024 02:22 PM
09-12-2024 03:10 PM
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.
10-02-2024 06:14 AM
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.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide