This article has been published before on the now deprecated NextHop. I still get a lot of responses, so reposting to ensure that is stays available.
This article discusses the functionality of Session Border Controllers, including scenarios where they can be used and how they can be implemented.
A Session Border Controller (SBC) can be used to connect your Lync environment to one or more SIP Trunk providers or to other Voice over IP (VoIP) systems. SBCs are very common in Service Provider networks, but they can be useful on-premises as well.
The on-premises form of an SBC is also known as an Enterprise-SBC or E-SBC. In this article, we will use the term SBC. The original purpose of an SBC was to provide a secure entry point in a VoIP network. That is still a valid reason to deploy an SBC, but the modern SBC can do a lot more.
What functionality can an SBC provide?
There are several reasons that you might want to deploy an SBC. We will consider the following:
- Security
- Interoperability
- Migration
- Performance
- Application on the SBC
Security
Depending on how SIP Trunks or connections with other VoIP solutions enter the environment, it can make security sense to deploy an SBC in the traditional way. The risk is usually lower with a Multiprotocol Label Switching (MPLS) or Virtual Private Network (VPN) solution, but even then, it is still an external network connecting to yours.
Having connectivity with other networks always introduces security risks. Some risks are generic, such as Denial of Service (DoS) attacks, and some are voice specific, such as toll fraud or attempts to manipulate the media.
An SBC contains back-to-back user agent (b2bua) functionality. This provides the SBC the option to handle the media, as well as the signalling (SIP). This gives an SBC more control than an application layer firewall (ALG), which usually can handle SIP only.
Another security based reason is topology hiding.
From a security perspective an SBC is an addition to a firewall, not a replacement.
Interoperability
Not all VoIP solutions are created equal, and an SBC can be an excellent way of connecting those solutions.
An SBC can handle TCP/UDP conversion, codec conversion, and connectivity to H.323 systems (so you do not need to upgrade the legacy system), to name a few.
Although SBC’s can also handle normalization, that is usually not necessary with Lync, because Lync is good at handling that itself. Lync also has quite a few settings available through Set-CsTrunkConfiguration, if you need additional adjustments in the SIP traffic.
Some interoperability issues can also be resolved of by manipulating SIP with Microsoft SIP Programming Language (MSPL).
Migration
Another SBC usage scenario is where interoperability with a third-party IP-PBX solution is required for migration or co-existence scenarios.
Besides the interoperability functionality, there are some options that can simplify a migration. When migrating from another telephony solution, an AD lookup functionality can check to see if a user is enabled for Enterprise Voice and route accordingly to Lync or the legacy PBX. This could also include call forwarding and simultaneous ring provided by the gateway, which can be handled by Lync in most cases.
Performance
When using an SBC appliance, its Digital Signalling Processor (DSP) can help with encoding/decoding.
An SBC can provide media bypass functionality, which shifts load from the Mediation role, thus requiring fewer Lync servers.
Applications on the SBC
Some vendors provide additional functionality on their SBC, such as call recording or Sip Phone Support (SPS).
SPS is used to connect third-party IP phones or devices to Lync. This can result in limited functionality, but it can make sense for some migration or interoperability scenarios.
Types of SBC’s
Multiple vendors offer E-SBC solutions. This can be in the form of a physical or virtual appliance, a software product installed on a Windows server, or combined with a gateway product. When combined with a gateway product, an SBC can also provide PSTN failover functionality, for instance between SIP trunks and ISDN.
Some providers will deploy an on-premise SBC as part of their offering, in which case the providers can manage the SBC.
See Microsoft TechCenter: Infrastructure Qualified for Microsoft Lync (including SBC) for an overview of qualified SBC solutions.
Do you need an SBC?
Whether you need an SBC depends, amongst other things, on the connectivity situation and company security policy. Using a qualified SIP Trunk provider should prevent any interoperability issues between Lync and the SIP Trunk from occurring, but an SBC could still make sense for the additional functionality it provides.
The downside of using an SBC is that is needs to be maintained, which could lead to additional costs.
SBC’s can be very useful to deploy and their use is not only for provider networks or large enterprises.
Even with a qualified SIP Trunk, it still can be useful to deploy an SBC for media bypass or Sip Phone Support.
Additional Information
- Microsoft TechCenter: Infrastructure Qualified for Microsoft Lync (including SBC)
- The RFC Archive: RFC 5853, Requirements from Session Initiation Protocol (SIP) Session Border Control (SBC) Deployments
- NextHop: Deploying and Troubleshooting Lync Server 2010 MSPL Applications