I currently have a acme packet facing verizon SIP cloud , and we been having some issues with the appliance and CUCM, i went online to there website and cant seem to find a tested configuration as far as SIP profile.We are contemplaing the idea of trying out CUBE but on the back of the acme packet so the design would look like
is this a good design
Hi Jorge -
I have used Acme Packet SBCs before in the same application you are trying (I work for Acme Packet). Please drop me a private message with some more details on your problem to jdonovan at acmepacket.com and I will try to help you out.
To the other poster that asked why not connect CUCM directly to the VZB network, there are several reasons for this. The enterprise SBC provides security features that protect the enterprise as well as interworking capabilities that may be necessary in some service provider SIP trunking applications.
I m agree with Jim, CUCM---siptrunk-----acmepacket---verizon. I m saying no Cube .... establish a trunk between SBC and CUCM... that all
Just to be clear, what I am advocating this:
The SP-SBC is the service provider SBC (Acme Packet). The E-SBC is the enterprise SBC (Acme Packet or CUBE). Many service providers have fairly rigid settings on their SP-SBCs. That means if any adaptation or interworking of the SIP signaling or SIP-associated media flows is required, it has to be done on the enterprise side of the SIP trunk. This is one reason why you see E-SBCs depicted in Cisco reference architectures, such as those in the Cisco Press SIP Trunking book.
Hi, I am also having similar setup, can you pls share the parameters which we should keep in mind and sample configuration at CUCM.
In my setup we have Cisco CUBE running on ISR for E-SBC.
Thanks in adv.
I am trying to setup a Acme Packet Net-Net OS VM ECZ7.2.0 as E-SBC and Nortel as Service provider
CUCM <-sip trunk-> ACME VM E <-> Sip trunk <-> AAPT nortel box
Do you have a sample config for a VM EC code?
Hi Chandika -
Your best approach would be to cross-post this request to the support forum here:
Someone on this list should be able to help you with this request.
Jim - just an FYI. I've looked at Acme Packet for large SIP trunking deployments and I agree with you that the standard architecture would leave the Cube out and the SBC between the UC environment and VZW would be the Acme Packet.
Hi David (and others) -
I am afraid my past replies may be getting a bit misintepreted. What I was intending to recommend is an SBC on both sides of the Service Provider SIP trunk (the SP side and the enterprise side). The topology would look like this:
E-SBC = Enterprise SBC (CUBE, Acme Packet, etc. - there are several choices out there for this)
SP-SBC = Service Provider SBC (most likely an Acme Packet SBC based on market share)
This reference architecture is described further in the well-written Cisco Press book on SIP Trunking (URL below)
Below is a screen shot of a page from this book that shows the reference model I am talking about. If you look through the CUBE documentation, you will find similar reference topologies
I know many of you will ask "if the SP has an SBC on the SP side of the SIP trunk, why do I need another SBC on the enterprise side of the trunk?". This is a valid question and it comes up frequently. The Cisco SIP trunking book covers many of the reasons why you want an enterprise SBC but I'll try to summarize the below.
Security: The SP-SBC is used by the SP to protect their network. Many enterprise security engineers will insist on a similar degree of protection for the enterprise network. Yes, it's true that SIP trunks are often carried over private IP networks which does reduce the security threat to some degree. However, there are many other types of security threats that can affect SIP traffic.
Interoperability: The SP-SBCs are often provisioned in a way to only support certain types of SIP call flows. This is done so the SP can have a standardized interface facing enterprise customers that may have many different types of IP-PBXs and versions (i.e. CUCM v6.x, Avaya v5.2, etc.). Most SPs are reluctant to customize the enterprise-facing of their SP-SBC to match call flow needs of the enterprise IP telephony & UC systems. This means the enterprise SBC has to perform the function of conditioning SIP call flows from CUCM (for example) before interconnecting to the SP SIP trunk.
Can you connect CUCM directly to the SP SIP trunk without an enterprise SBC? Yes, technically that may work sometimes. However, sometimes it won't work (especially if the call flow changes when you upgrade to a new CUCM version) and you can either spend a great deal of time trying to tweak the CUCM config or negotiate with the SP (or you can just deploy an enterprise SBC).
I don't want to try to rewrite the Cisco SIP trunking book in this post so I'll stop here. Hopefully the summary points above give you some idea of the importance of enterprise SBCs.
From what I saw from the diagram, I would say the the Cisco CUBE would be a redundant componet...all you need to do is configure a SIP trunk from the Call Manager to the Acme packet SBC....the Acme Packet performs the same function as the CUBE...