Acme packet Interoperability with CUCM 7.1

[ggittins35]

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

CUCM---siptrunk----cube----acmepacket---verizon

is this a good design

[Ranjit Patel]

Why are you puting cube in between, you can directly configure SIP trunk between ACME

and CUCM......

[Jim Donovan]

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. 

Thanks,

Jim

[Ranjit Patel]

I m agree with Jim, CUCM---siptrunk-----acmepacket---verizon. I m saying no Cube .... establish a trunk between SBC and CUCM... that all

[Jim Donovan]

Just to be clear, what I am advocating this:

CUCM--E-SBC----SIP_trunk----SP-SBC---Service_Provider

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.

[Sarthak kumar Rohal]

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.

[Chandika Dias]

Hi Jim

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?

Thanks

Chandika

[Jim Donovan]

Hi Chandika - 

Your best approach would be to cross-post this request to the support forum here:

http://community.acmepacket.com/

Someone on this list should be able to help you with this request.

Thanks,

Jim

[David Hailey]

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.

[Jim Donovan]

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:

CUCM---SIP---E-SBC---SIP_trunk----SP-SBC---SP_SIP_core

<--enterprise_ntwk-->                 <--service_provider_ntwk-->

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)

http://www.ciscopress.com/bookstore/product.asp?isbn=1587059444

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.

Thanks,

Jim

[Felipe Garrido]

What are the exact issues being faced with the deployment? The more info the better.

-Felipe

[tjkoch1999]

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...