Tim, Thanks for your detailed and a quick response, much appreciated.
Thanks, Terry On Wed, Mar 11, 2015 at 3:19 PM, Tim Smith <[email protected]> wrote: > 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
