[cisco-voip] SBC/SIP Trunk Design queries
Terry Cheema
terry.cheema at gmail.com
Mon Mar 16 13:40:24 EDT 2015
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.wiklund at 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.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
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
More information about the cisco-voip
mailing list