2.2. What is a Session Border Controller (SBC)?

Historically Session Border Controllers emerged after publication of the SIP standard as a panacea to early protocol design mistakes: ignorance of Network Address Translators (NATs), unclear data model, liberal syntax, reluctance to standardize legal interception and more.

Probably the single biggest mistake in the design of SIP was ignoring the existence of network address translators (NAT). This error came from a belief in the IETF leadership that IP address space would be exhausted more rapidly and would necessitate global upgrade to IPv6 which would eliminate the need for NATs. The SIP standard has assumed that NATs do not exist, an assumption, which turned out to be a failure. SIP simply didn’t work for the majority of Internet users who are behind NATs. At the same time it became apparent that the standardisation life-cycle is slower than how the market ticks: SBCs were born, and began to fix what the standards failed to do: NAT traversal.

Yet another source of mistakes has been the lack of a clear data model behind the protocol design. Numerous abstract notions, such as dialog or session, transaction or contact simply didn’t have unique unambiguous identifiers associated with them. They were calculated or almost guessed out of various combinations of header-fields, decreasing the interoperability. Some message elements, such as Call-ID, have been overloaded with multiple meanings.  While some of these were fixed in the later SIP revision and its extensions (rport RFC 3581, branch, gruu RFC 5628, session-id) the market forces jumped in quickly. SBCs began to implement “protocol repair”.

The other class of mistakes emerged from implementations. Many SIP components were built under a simplifying assumption that security comes for free. Numerous implementations were found to be vulnerable to malformed SIP messages or excessive load. The SBCs began to play a security role.

The reality in today’s real time communication networks is that, contrary to the end-to-end design of the Internet and its protocols, service operators can achieve the best user experience by exerting tight control - over the endpoints and over the interface to peering networks.

Over several years, Session Border Controllers became a de facto standard for which ironically no normative reference existed. A non-normative information reference on the subject, RFC 5853 was published as late as in 2013. Session Border Controllers nowadays handle NATs, fix oddities in SIP interoperability and filter out illegitimate traffic. They began to incorporate elements of the standardised SIP components. For example, routing functionality contemplated by the standards for proxy servers is nowadays part of SBC products. Similarly the SBCs often incorporate media recording and processing functions, whether that’s for quality assurance, archiving or legal-compliance purposes.

2.2.1. General Behaviour of SBCs

Purist SIP call flow depicts the message flow of an INVITE request between a caller and a callee. This is the simplest message sequence that one would encounter with only one proxy between the user agents. The proxy’s task is to identify the callee’s location and forward the request to it. It also adds a Via header with its own address to indicate the path that the response should traverse. The proxy does not change any dialog identification information present in the message such as the tag in the From header, the Call-Id or the Cseq. Proxies also do not alter any information in the SIP message bodies. Note that during the session initiation phase the user agents exchange SIP messages with the SDP bodies that include addresses at which the agents expect the media traffic. After successfully finishing the session initiation phase the user agents can exchange the media traffic directly between each other without the involvement of the proxy.

SBCs come in all kinds of shapes and forms and are used by operators and enterprises to achieve different goals. Actually even the same SBC implementation might act differently depending on its configuration and the use case. Hence, it is not easily possible to describe an exact SBC behaviour that would apply to all SBC implementations. However, in general one we can still identify certain features that are common for most of SBCs. For example, most SBCs are implemented as “Back-to-Back User Agent” (B2BUA).

A B2BUA is a proxy-like server that splits a SIP transaction in two pieces: on the side facing the User Agent Client, it acts as server; on the side facing the User Agent Server it acts as a client. While a proxy usually keeps only state information related to active transactions, B2BUAs keep state information about active dialogs, e.g., calls. That is, once a proxy receives a SIP request it will save some state information. Once the transaction is over, e.g., after receiving a response, the state information will soon after be deleted. A B2BUA will maintain state information for active calls and only delete this information once the call is terminated.

_images/10000201000005BD0000031B604143AA.png

Figure 1: Purist SIP call flow

SIP call flow with SBC depicts the same call flow as in Purist SIP call flow but with an SBC in between the caller and the proxy. The SBC acts as a B2BUA that behaves as a user agent server towards the caller and as user agent client towards the callee. In this sense, the SBC actually terminates that call that was generated by the caller and starts a new call towards the callee. The INVITE message sent by the SBC contains no longer a clear reference to the caller. The INVITE sent by the SBC to the proxy includes Via and Contact headers that point to the SBC itself and not the caller. SBCs often also manipulate the dialog identification information listed in the Call-Id and From tag. Further, in case the SBC is configured to also control the media traffic then the SBC also changes the media addressing information included in the c and m lines of the SDP body. Thereby, not only will all SIP messages traverse the SBC but also all audio and video packets. As the INVITE sent by the SBC establishes a new dialog, the SBC also manipulates the message sequence number (CSeq) as well the Max-Forwards value.

Note that the list of header manipulations listed in SIP call flow with SBC is only a subset of the possible changes that an SBC might introduce to a SIP message. Furthermore, some SBCs might not do all of the listed manipulations. If the SBC is not expected to control the media traffic then there might be no need to change anything in the SDP lines. Some SBCs do not change the dialog identification information and others might even not change the addressing information.

_images/10000201000005BB0000031B13202E8D.png

Figure 2: SIP call flow with SBC

2.2.2. General Deployment Scenarios of SBCs

Session border controllers are usually deployed in a similar manner to firewalls, namely with the goal of establishing a clear separation between two VoIP networks.

_images/100002010000086900000431995DD4E2.png

Figure 3: SBC deployment scenarios

In general one can distinguish three deployment scenarios, see SBC deployment scenarios:

  • User-Network-Interface (UNI): Operators use SBCs to establish a secure border between their core VoIP components and subscribers. The core components consists of PSTN gateways, media servers, SIP proxy and application servers. Subscribers use SIP hardphones and softphones, Internet Access Devices that connect analog and digital phones to the IP network, and newly web browsers deploying the WebRTC standard. Most important administrative tasks in this scenario include facilitation of NAT traversal (see NAT Traversal), achieving interoperability among multiple types of clients (see SIP Mediation), security against attacks coming from the public Internet (see Securing SIP Networks using ABC SBC and ABC Monitor (optional)) and off-loading registrar (see Section Registration Caching and Handling).
  • Network-Network-Interface (NNI): In the NNI interface, two operators connect to each other directly over SIP. Most important administrative concerns in this scenario include mediation of different network policies (see SIP Mediation), enforcement of service-level-agreements between providers by traffic shaping (see Traffic Limiting and Shaping) and multi-provider SIP routing (see SIP Routing).
  • Enterprise SBC (E-SBC): Enterprises are increasingly replacing their PBXs with VoIP PBX or are extending their PBX with a VoIP module to benefit from attractive VoIP minute prices. Enterprise SBCs are used to secure the access to the PBX. The enterprise SBC is also expected to secure the communication to the VoIP operator, which is offering the VoIP service to the enterprise. Typical administrative concerns include harmonization of dialing plans between an enterprise and its trunking partners using the mediation feature see SIP Mediation), and setting up secured VoIP connectivity for web-users (see Securing SIP Networks using ABC SBC and ABC Monitor (optional)).