AVAYA CM 6.3 with Direct SIP trunking via SBC - Or - "Is there an easier way?" 1

[IPOthermia]

In early 2014 I investigated using an AVAYA provided SIP Trunking Solution. The SIP provider was to deliver SIP to two of our data center locations over their MPLS infrastructure. Good news is that this helps protect SIP from Internet threats.

More good news is that AVAYA 6.0 and higher does have the ability to do a direct SIP trunk. Most of the time these trunks are directed toward System Manager/Session Manager.

My problem is simple. My business leadership thinks installation of 10 physical servers and the spending of well over $100,000 is grossly unnecessary. As a result two SM/SM pairs were recommended by a vendor. Four Enterprise SBC's, and two controllers to monitor the SBC's. We want to start small with SIP trunking in two locations.

Does anyone know an a simple way to connect an AVAYA 6.3 CM to an SBC and ultimately a carrier without going bat crap crazy into capital expenditures and physical servers?

If SIP is such a great "standard" protocol why do I need a fleet of servers to interpret and NORMALIZE it for use by a PBX that in theory should already understand SIP?

Thanks.

 

[janni78]

Depends what capacity and redundancy you're looking for, but if you wanna start out small it sounds like a bit of an overkill.
Basically you'll need one System Manager, Session Manager and SBC to get SIP trunking (you could run them in VMWare).
You might be able to connect a SIP trunk directly to a CM with an SBC but haven't tried it myself.

It comes down to how mission critical the service is for you.

"Trying is the first step to failure..." - Homer

 

[mattKnight]

I tried to post a response from my phone but it wouldn't submit

However Janni78 has pretty much said everything I would. (star for that)

The key point is the system you have listed is highly resilient and it comes down to the risk to the service that the business will accept. It is possible that you could trim 2 of the session managers from the Bill of materials, but without knowing a lot more about your network I couldn't be sure.

I'd echo the idea of using virtual hosts - but unless you already have the infrastructure stood up and spare capacity, it won't save you much (if anything)

You can directly connect the SBC to ACM, but you woudl lose flexibility and resilience in doing that. I strongly suspect that would add Session Managers in the future if you did do it this way.

Which SBC are you using and why? I'd suspect that somewhere between 25% and 40% of the cost is there - can you reduce the cost with other devices (I personally like the Cisco UBE) and depending on the number of streams etc they may be more cost effective.

Whichever way you skin this, you will need to justify the project on something more than ROI (managers think SIP is cheap, to do it properly it isn't). Flexibility and resilience are good ones to suggest - but to quote Janni78 again, it comes down to how mission critical the service is and the cost of loss of service.

Take Care

Matt
I have always wished that my computer would be as easy to use as my telephone.
My wish has come true. I no longer know how to use my telephone.

Editted for spelling/typing

 

[IPOthermia]

So now that some time has passed we are looking at:

An Adtran 924e to take advantage of the H.323 Trunking from the PBX and connect us to our SIP trunk provider.
SIP will be arriving on the MPLS network of our carrier instead of the open internet. As I understand it today the Adtran has SBC functions, but I may be incorrect.

Regardless the goal is to start small and as was stated in two of the three posts above this one, SIP trunking done right isn't cheap. Additionally I'll have to involve another team member in day to day telecommunications support to free up my time to manage and implement this solution. My guess is there is a tipping point where SM/SM will become necessary but it seems like a huge waste o f money for "Middleware Servers" that do little more than normalize a protocol mangled by 20 years of incoherent adoption efforts.

My first exposure to SIP was - "It is SIMPLE and doesn't need a 'Server' in the middle to setup a telephone call. Oh, and it eliminates the need for a dialogic card" And in the next breath - "Here is the SIP server that you'll have to install to make it all work." To which I replied - "So instead of a dialogic card you sold the customer TWO servers, one of which will be acting like a voice server for SIP endpoints. Hey wait, that sounds like what the Communications Manager is already doing for H323 phones, how is this better??????"