[cisco-voip] SBC/SIP Trunk Design queries

[Roger Wiklund]

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.lin at 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.smith at enject.com.au
> To: terry.cheema at gmail.com; cisco-voip at 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-bounces at 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 at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>