I am flying to Arizona next 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:
Network Dial Plan
Call Admission Control
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.
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.
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.
Thanks for the clarification presented in this blog…this is helpful.
Thank you for reading and commenting!
[…] I’ve written extensively about session management (please see my articles, Session Management and Avaya Session Manager vs. Session Border Controller), but the main thing to understand here is that it loosely connects disparate SIP services, […]
Great Description & Differentiation about both SIP components
Thank you for reading and taking the time to comment.
Hello Please i am currently deploying Avaya Aura® System Manager 6.3 , i have done all my best to get the SIP trunk work, but not still coming, when you dial, it give a tone and drop. so i want to know if there is anything am not doing right and also want to know if i must deploy an SBC to make it work or can the SIP trunk work without SBCE?
Hope to get a swift response.
Although an SBC is highly desired, unless you have a protocol adaptation need, it’s not technically necessary. Have you read my article on SIP trunks on Avaya Aura? It might help: https://andrewjprokop.wordpress.com/2013/07/30/a-guide-to-implementing-sip-trunks/
SBC is s back-to-back user agent, SM – is not. Back-to-back means that for ouside user SBC looks like the endpoint actually making the calls, rather then relaying it. All headers in the inital SIP message are modified to substitute initial ip addresses, names, etc with the ones configured on SBC. SBC is masking internal sensentive information for outside world providing security.
You are correct. I address quite a bit of that in other articles here on SIP Adventures. For instance: https://andrewjprokop.wordpress.com/2015/04/06/the-fine-art-of-choosing-the-right-sbc/
What could be the reason for sbc not routing incoming calls to session manager. Please comment.
Mismatched protocol (UDP/TCP/TLS)? Bad routing tables? Call admission control?
Sorry to bother you Andrew, but I have replaced an AVAYA System Manager for a ProSBC, and now I have a problem I cannot put my finger on it. When I call POTS everything is fine, when i call cellphones I dont hear ringback. AVAYACM–>ProSBC–>Telephone company.
When I call POTs I receive 180 ringing, when I canll cellphones I receive 183 progress, I dont know what Im sending now that I wasnt sending when we used the AVAYA System Manager. Any clue you could give me?