Session Manager versus Session Border Controller

by Andrew Prokop | Arrow Systems Integration

I am flying to Arizona this week to speak to an Avaya users group. This is the third year in a row that I’ve presented to this group and I am excited to be there again for a few reasons. First, Arizona is my place of birth and I lived there for the first 25 years of my life. I have friends and family scattered around the Valley of the Sun and I love it when my company is willing to fly me home for free. Second, the Phoenix chapter of the Avaya users group is well organized and their events always have a great turnout. They are engaged in the communications industry and won’t put up with people who just want to present a commercial for their company or product. They expect educational information that can be applied to their jobs.

Since I don’t want to waste their time with a repeat of something I told them last year or the year before, I thought for a while before deciding on my topic. My choice actually came from a customer a few weeks ago. I was asked, “Why do I need a Session Manager? Can’t I do the same thing with a session border controller?” It was a good question because if you read the literature for both products you will find a lot of overlap. In fact, so much overlap that if you didn’t dig below the marketing slicks you wouldn’t have a good answer. Well, I did the digging and have come up with the following answers. Yes and no. Please allow me to explain.

SIP is a protocol. It’s a series of request messages and responses. It’s a collection of headers and parameters. On its own, SIP is pretty useless. You need user agents to send and receive messages. You need proxies, registration servers, presence servers, and back-to-back user agents to get everything talking. On top of all those things you need session management to orchestrate all these different elements. Notice that I said session management and not Session Manager. The Avaya Session Manager implements many aspects of session management, but as you will see, it doesn’t do everything.

There are seven core aspects of session management:

Routing

Policy Management

Network Dial Plan

Call Admission Control

Protocol Normalization

Security

Proactive Media Quality Monitoring, reporting, and notification

To this list I would like to add one more that isn’t traditionally thought of as session management, but arguably should be.

SIP Registrar

Thinking about the Avaya Session Manager, I can easily see it doing quite a few of the above tasks. It’s a SIP routing engine whether it’s between applications, endpoints, or standalone systems. In conjunction with its management tool, System Manager, it does policy management. Session Manager has a number of components that allow you to implement a network dial plan. Call Admission Control (CAC) is accomplished by defining bandwidth values for network locations. Session Manager can perform CAC on both audio and video media types. Session Manager supports adaptation modules for Protocol Normalization, but only in a limited fashion. Adaptation modules must come from Avaya as either built into Session Manager or by engaging Avaya professional resources to create new ones. There is no customer accessible interface to write your own. Session Manager does provide for some SIP security by allowing an administrator to enforce TLS on SIP entity links. However, TLS is only a piece of full security. Session Manager only works with SIP signaling; it never sees the subsequent media. Therefore, it cannot provide Proactive Media Quality Monitoring, Reporting, and Notification. In the Avaya world, all SIP endpoints register directly to Session Manager thus making it a SIP Registrar.

In terms of the Session Border Controller (SBC), there is overlap, but the overlap must be understood. An SBC does Routing, but for the most part it routes SIP trunks. It isn’t really involved in routing between applications and it certainly doesn’t support the IMS model that allows Avaya to route to sequenced or call intercept applications. SBCs do not provide for Policy Management, a Network Dial Plan, or Call Admission Control. They do a much better job of Protocol Normalization by allowing users to create their own adaptation modules. An SBC is also the right place for edge Security. You never want to expose your Session Manager to the public Internet. If you are bringing in remote endpoints or SIP trunks, you want an SBC acting as a SIP firewall. Additionally, a SBC has a number of security components that a Session Manage does not support (e.g. deep packet inspection, denial of service prevention, break-in detection, etc.). Both SIP signaling and media run through an SBC making it the ideal place for Proactive Media Quality Monitoring, Reporting, and Notification. As I mentioned above, SIP endpoints register to a Session Manager so the SBC plays no role here.

So, back to the original question, “Do you need a Session Manager or can you do it all with a Session Border Controller?” In some cases, the answer is you can do it all with an SBC. However, you wouldn’t be using SIP endpoints, have the need to route to SIP applications, or do some of the other tasks that are only done by a Session Manager. However, if you were only bringing SIP trunks into a standalone system and had no need for anything else then you could easily get by with an SBC. That would be a pretty limited configuration, though, and with everything going towards SIP you would quickly outgrown it.

To wrap this up, I say that if you are going to stick with Avaya and plan on adding the value of SIP to your communications system then you need both a Session Manager and a session border controller. You cannot do it with just one box. You absolutely need the two to make your SIP orchestra sing.

Share this article

The thoughts and opinions in these blogs belong to the individual blogger and do not necessarily represent the views or opinions of Arrow Systems Integration.