Yes - definitely will like to have views from the community where things are heading these days.
I have updated the title slightly, lets see if it gets further response. -Terry Sent from my iPhone > On 11 Mar 2015, at 5:17 pm, Tim Smith <[email protected]> wrote: > > No problems, I'm also keen to hear other peoples experience too. > > It's an interesting topic! > > > > Cheers, > > > > Tim. > > > > > From: Terry Cheema <[email protected]> > Sent: Wednesday, 11 March 2015 5:09 PM > To: Tim Smith > Cc: cisco-voip voyp list > Subject: Re: [cisco-voip] SBC/SIP Trunk Design queries > > 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
