I think one of important things is the capacity you are looking for.ACME does give you better scalability and better troubleshooting capability, but if you are only looking for couple hundreds of concurrent calls, you probably can live with CUBE to keep your cost lower.
D. From: [email protected] To: [email protected]; [email protected] Date: Wed, 11 Mar 2015 04:19:22 +0000 Subject: Re: [cisco-voip] SBC/SIP Trunk Design queries Hi Terry, I do quite a bit of CUBE, and have done a bit of Acme as well. There were some recent partner sessions that talk about some interesting things coming for CUBE, so it’s worth making sure you are getting latest roadmap info. My main comparison points.. # HA In enterprise there was HA on CUBE, and it was improving in each release (but there are caveats with it) Have found Acme HA to be seamless and rock solid. # Deployment Cisco has some great interop guides – if you go with a carrier that has spent the money, a lot of the hard work has been done for you in terms of testing (as you know SIP can be implemented and configured in many different ways – if someone hasn’t done a lot of testing up front, you do sometimes end up adding SIP profiles and tweaks as you discover issues) Acme has some very thorough guides – I’m not sure if they have interop testing with carriers – given they are in SP’s a lot, there is a good chance they do. I’d look into it that with the Acme SE. Talk to prospective ITSP’s about their testing, and supported SBC’s. # Ops CUBE enterprise is great, IOS, most people are familiar. You will most likely need to train people on Acme I find troubleshooting a bit of a let down with CUBE. Basically log to buffer, copy to file, or packet captures. Wireshark with ladders or TranslatorX are great, but it’s getting the files there that bugs me. Alternatively, there did seem to be a few 3rd party tools out there, but you are probably looking at $$$ Acme has web interface, list of calls and then ability to drill down with ladder diagrams, messaging capture etc. You should see this before making decision. Some good knowledge on Acme forums Acme has very flexible manipulation – CUBE is quite good too (and they have great profile testing tool) – plus you can also use CUCM LUA on the SIP trunk # On your other notes Centralised – this is great for flexibility DR etc, standard stuff be aware of the call volumes over the WAN, caller ID considerations for emergency and local pizza shop type services WAN – we terminate on existing equipment, and Acme is in a VLAN, I think this is most flexible.. you have a very flexible set up in Acme in regard to networking, lots of zones, interface options etc. Transcoding – I think you could still utilise CUCM registered transcoders for the ASR scenario.. Virtual - We use virtual Acme, it had some teething problems in very first versions (and a clunky license on USB stick thing going on) but it seems to be good now We don’t have transcoding / media resources in the virtual edition Flow through / around – a lot of designs the carrier doesn’t have connectivity into the rest of the network, so flow through is quite typical. However, we do have carriers here that have SBC’s on your WAN, so flow through can be nice here – it also then makes CUBE HA less important, i.e. if call is set up, media is from end point to carrier SBC already (if no xcoding involved) So I won’t say one way or the other, just my thoughts on things you can consider. I like both, and will continue to work on both! Cheers, Tim From: cisco-voip [mailto:[email protected]] On Behalf Of Terry Cheema Sent: Wednesday, 11 March 2015 1:10 PM To: cisco-voip voyp list Subject: [cisco-voip] SBC/SIP Trunk Design queries Hi List, I am working on to finalize the SBC vendor for one of our environments. I have a couple of queries related to the SIP Trunk design and SBC vendor choices(basically CUBE vs Acme Packet). I would really appreciate if anyone with SIP Trunking/SBC expertise (Cisco/Acme Packet) can provide some input on the below queries: 1) CUBE vs Acme Packet: First of all Cisco has marked the CUBE SP Edition product line for EoL, exiting the SBC Service Provider segment, so leaving only SBC Enterprise as the option. Although at this stage we are looking for an enterprise grade SBC but it will be a plus if it has the potential to step up into a SP SBC in a multi-tenanted environment. I was comparing AP 3820 with the CUBE Ent ASR1k-x: CUBE provides no HA (though in some documents it says, came out from a meeting with the Cisco SME informing HA is not available), No transcoding (due to lack of DSP on ASR1K), No Multi-tenancy support with all of these features supported in a 3820 SBC Any feature better in CUBE that I may have overlooked? I am aware that CUBE configuration etc. can be easy compared to Acme Packet but apart from that any solid reason to choose CUBE over AP? 2) HA vs Non-HA: HA is obviously the preferred approach and looks like only possible with AP. Can anyone confirm the HA works as claimed by AP? Due to the costs involved in double the equipment – whats the common approach followed here HA or non-HA? 3) Centralised Design: We are planning on a centralised SIP solution (with SBCs at both the DCs), anything to be careful of? 4) Transcoding: CUBE ASR1K does not support transcoding (due to to lack of DSPs on this platform). Normally we would have an agreement with the provider on codecs, but still any scenarios when a SBC would need transcoding or on-board DSPs ? 5) WAN link termination – If we are to provision new WAN links for the this SIP service, what’s the preferred approach – terminating WAN links directly on the SBC or on the existing routers, does Acme Packet supports WAN link termination? 6) Media flow around vs flow thru – Any comments on which approach is better? I am preferring flow through at this stage. Any suggestions? 7) Acme Packet Virtual SBC: I was looking into AP virtual SBC although it has a limited scalability at this stage, but would like to hear any input if anyone is using this. Thanks in advance. Terry _______________________________________________ cisco-voip mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-voip
_______________________________________________ cisco-voip mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-voip
