Thanks Roger and everyone for the replies, its been very helpful. Terry
Sent from my iPhone > On 14 Mar 2015, at 11:27 pm, Roger Wiklund <roger.wikl...@gmail.com> wrote: > > We use Acme 3820 with our UCaas platform. Behind it we serve Cisco, > Mitel, Avaya and Lync PBX:es. > You can't go wrong with Acme, especially when it comes to SIP > manipulation, there's nothing you can't do. For me that's the number > one selling point. > HA is awesome with hitless failover. You can upgrade outside of > service windows if you have to. > Flow through/flow around is more flexible in Acme with media release > based on same-IP for example. > If you run Enterprise version or Service Provider version 7.2 you get > a web GUI which is very helpful when troubleshooting. > http://www.markholloway.com/blog/wp-content/uploads/2012/08/Screen-Shot-2012-08-08-at-3.00.55-PM.png > > The only downside with Acme for me is Oracle. I miss the days when it > was just Acme Packet, the support was awesome. Now, not so much. It > feels like all the talented engineers jumped ship. > > With that said we do use CUBE but for smaller on-prem solutions. It > does the job and it's easy to configure. > > Sonus is another player that i've heard some buzz about. > >> On Thu, Mar 12, 2015 at 1:34 AM, David Lin <david....@msn.com> wrote: >> 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: tim.sm...@enject.com.au >> To: terry.che...@gmail.com; cisco-voip@puck.nether.net >> 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:cisco-voip-boun...@puck.nether.net] 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 >> cisco-voip@puck.nether.net >> https://puck.nether.net/mailman/listinfo/cisco-voip >> >> _______________________________________________ >> cisco-voip mailing list >> cisco-voip@puck.nether.net >> https://puck.nether.net/mailman/listinfo/cisco-voip > _______________________________________________ > cisco-voip mailing list > cisco-voip@puck.nether.net > https://puck.nether.net/mailman/listinfo/cisco-voip _______________________________________________ cisco-voip mailing list cisco-voip@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-voip