The Evolution of Session Border Control - Sonus

The Evolution of Session Border Control

The Early Days of SBC Session Border Controllers (SBCs) originated as discrete devices in an IP network to provide two key functions: connectivity and security. Connectivity functions included Network Address Translation (NAT) and protocol repair, and security functions included topology hiding, encryption, and prevention of Denial of Service (DoS) and Distributed DoS (DDoS) attacks. Session Border Controllers were deployed as discrete network elements at the edge of an IP network, where they offered control of the signaling and media streams. In their original form, the “controller” part of SBC was potentially an overstatement, with the devices normally providing only basic routing functions and limited (or non-existent) media processing capabilities, relying instead on media servers. Furthermore, they de-emphasized call control features in favor of “passing through” those responsibilities to other nodes in the core of the network. This early role of session control expanded with the recognition of the unique logical and physical position an SBC enjoys in a network which, by its definition, establishes the “border” of the operator’s domain. SBC vendors and network operators alike continue to capitalize on the value that can be unlocked at this location. It simultaneously represents the first point in the network where the operator is free to exert influence on the incoming traffic, ensuring it adheres to their acceptable policies, and the last opportunity to achieve their bi-lateral agreements with the other party.

Enhanced Service Participation

FIGURE 1. Early SBC’ s role

Session Border Controllers have come a long way since they were first conceived in the early 2000s as a simple, security-focused element. As service providers and enterprises began deploying more advanced real-time applications over IP–including Unified Communications, video, instant messaging, and conferencing–the burden on SBCs grew in step. While their original purpose still rings true–providing secure, controlled IP connections across IP borders–much has changed in their scope and function, including the definitions of borders themselves. Today, SBCs are expected to provide a broad range of functions, including the following:

• Media processing • IP Multimedia Subsystem (IMS) signaling and media

Feature and service delivery are traditionally hosted on platforms at the core of the network, with the SBC as an adjunct device to aid them in that delivery. This paradigm makes sense when a service is used by a relatively small number of the subscribers on a network, as it allows pooling of resources that can be shared across anyone on the network who requires them. It makes less sense, however, for high-use services where the resource requirements are reaching parity with the number of subscribers registered to the network. In some of these cases, operators will be able to offload basic and frequently used call and communication services directly to the edge of the network, as SBCs become capable of taking on more of the functional demands normally associated with dedicated application platforms. Next-generation SBCs will provide native support of call services through user authentication, enrichment of the session control capabilities, routing intelligence, and flexibility of the signaling control. The intelligent routing and operator-defined policies will allow the SBC to selectively host features locally where appropriate, and to pass the session onto dedicated service platforms when necessary To achieve this, the SBC will need to support interfaces to centralized administration resources, such as for authentication credentials, policy control and, in some cases, routing databases. Through these interfaces and centrally administered resources, the operator contains operations costs while benefiting from the optimization of delivering services with fewer boxes, fewer hops, and less complexity.

• High message throughput • Signaling manipulation • Call Admission Control (CAC) • Security • Encryption • Call routing

FIGURE 3. SBCs and Enhanced Services

IMS Signaling and Media FIGURE 2. Factors Expanding the Breadth of SBC Requirements

Media Processing at the Border Wherever two networks connect, there is always a challenge of ensuring they talk the same dialect. SIP in particular has experienced explosive growth in capability, specification and utilization in recent years. Ultimately, this leads to fragmentation and often creates significant interoperability challenges. A critical, early function of SBCs was to normalize and police signaling (particularly SIP) to ensure traffic that could be processed was admitted and all other traffic was rejected. With the pace of SIP adoption and RFC creation accelerating, SBCs need to decouple operators from vendor software roadmaps as much as possible, making it easy for users to tailor and configure SIP signaling control. This is particularly true as increasing levels of non-VoIP traffic hit an SBC, including video, IM, SMS/MMS, file transfer, and other media types, many of which exercise SIP protocol elements that are still relatively uncommon. Critical as it is to control the signaling aspects of a session, remember that the bulk of the traffic crossing a border is the media. It’s equally critical for the operators to control the nature of the media traffic they admit into their network, and to control the nature of the media traffic they pass on to a peer. Media processing encompasses media handling functions such as transcoding, conversion of a media stream from one codec type to another, DTMF interworking functions where DTMF tones within the media flow are detected and converted into RFC2833/RFC4733 format, or fax interworking where G.711 fax is converted to T.38 fax. 2

Historically, SBCs have not incorporated embedded media processing capabilities and, where they have done so, have supported very limited numbers of media services. The increasing connectivity between networks using IP and the disparate endpoints used within these networks create a strong need for a Session Border Controller that supports robust and scalable media processing capabilities. The reason why Session Border Controllers have traditionally not incorporated this functionality is that to perform these functions with any scale requires the use of Digital Signal Processors (DSPs). These devices were not present within many early generations of SBCs. Sonus Networks has integrated the ability to perform media processing functions directly into its SBC family of products. This allows any required media processing to be performed at the edge of the network rather than having to be transported to a central resource for processing.

Evolution of SBC Functionality

This white paper will explore the needs around each of these areas.

Being able to transcode a media stream directly at the border offers obvious simplifications to the operator. Operators only expose their core to the traffic profiles against which they have verified all of their network components. This consideration takes on added importance when operators consider mixed access environments, such as fixed/mobile convergence, where the range of media types offered may vary significantly from endpoint to endpoint.

IMS provides a framework for deploying both basic calling services and enhanced services through industry-standard components and protocols. The four key values that IMS provides are:

• Session control • Combining and integrating different applications/ services

• Enabling quality of service • Flexible and consistent charging for services Although not an IMS-defined element, the SBC has evolved to support a number of IMS-defined functions in part or in whole. These include the P-CSCF, IBCF, BGF/I-BGF, ALG, TrGW, IWF, SEG and some RACS functions.

FIGURE 4. SBCs Positioned in an IMS Environment

3

IMS – Access SBC On the access side of IMS is the Proxy-Call Session Control Function (P-CSCF), which is the entry point into the IMS network for user endpoints. It acts as the interface between the client and the Interrogating-Call Session Control Function (I-CSCF) and Serving-Call Session Control Function (S-CSCF). These components only handle the signaling element of the calls. An Access SBC integrates the P-CSCF with an Access Border Gateway Function (A-BGF) element so it can handle the signaling and media traffic within a single system appropriately. Functions performed by an Access SBC should include:

• Topology hiding

• Applied policy on a per-endpoint basis

• Monitoring and lawful intercept

• NAT/firewall traversal for signaling and

• User identity privacy

• Encryption

media

• Routing of signaling to the IMS core

IMS – Interconnect SBC On the interconnect side of IMS is the Interconnect Border Control Function (I-BCF), which provides the interface to external networks. These components only handle the signaling element of the calls. An Interconnect SBC integrates the I-BCF with an Interconnect Border Gateway Function (I-BGF) element to allow the appropriate handling of the signaling and media traffic within a single system. While the Access SBC interfaces to all the user endpoints, the Interconnect SBC interfaces to other networks over SIP trunks. Functions performed by an Interconnect SBC should include:

• Topology hiding

• Signaling interworking

• Routing of signaling to the IMS core

• Applies policy on a per-trunk basis

• User identity privacy

• Monitoring and lawful intercept

A basic SIP call procedure requires an average of seven SIP messages. Many SBCs measure their call handling performance in Call Attempts Per Second (CAPS). The SBC is generally limited by the number of SIP messages per second that it can handle. The average number of SIP messages generated by typical applications continues to increase.

FIGURE 5. Implications of NAT on Performance

SIP Message Manipulation A wide range of signaling manipulation can be required from a Session Border Controller, taking many forms. These can range from manipulation of individual SIP messages to protocol interworking.

SIP to SIP Interworking

FIGURE 7. SIP Message Manipulation Requirements

The Sonus SIP Message Manipulation (SMM) solution is easy to configure and provides a high degree of flexibility. It combines a set of decision-making criteria with a rule containing a set of actions to be performed when those criteria are met.

• The criteria to trigger a rule could be the presence/absence of a header/parameter/ token or a header/parameter/token having a specified value.

• The criterion for a rule may be based on a header/parameter/token, which is different than the header/parameter/token specified for action. For example, it is possible to delete Header-1 only if Header-2 is present.

• Add/delete/modify operations can be applied on specified header, header/ parameter, or header/parameter/token.

• Rules can be applied to a certain range of headers. For example, delete all Header-1 instances except the first one.

• Actions for a rule can be configured to take effect on all, first, last, or a range of instances of a header; e.g., a rule modifying only second-to-last instances of a header.

• Multiple actions can be taken in a single rule. For example, it is possible to delete Header-1 and add parameter-2 to Header-2 if Header-1 is present.

• Rules can be triggered depending on number of headers. For example, delete Header-1 only if there are more than three instances of Header-2.

• Rules can be defined both in ingress and egress legs.

Some examples of the flexibility provided by the Sonus SMM are outlined below:

H.323 to SIP Interworking For many years, the industry predicted that the number of H.323 devices within networks would decline to zero. This has not occurred, so SBCs must continue to provide interworking functions from these H.323 devices to the SIP-based core networks that have become the norm.

The Performance Impact of Presence

4

As shown in Example 2 in Figure 6, the messages related to presence can quickly explode–with this example showing a nearly 400-fold increase. A Session Border Controller in the midst of this communication path faces scalability requirements to support presence, which will rapidly eclipse that of voice. It must therefore have sufficient performance to ensure that it can manage this load effectively.

The typical operations that are required to perform this manipulation are Add, Modify, and Delete. These can perform functions as simple as blocking a SIP header from entering a network, but can also perform much more powerful operations such as copying a parameter from one header, removing that header, and copying that parameter into a different header.

The Performance Impact of NAT

Another critical SBC scaling problem relates to the presence of IM services based on SIP/SIMPLE protocols. The message flow in a presence

Compare that to the impact of implementing a full Unified Communications environment. In this case, subscriber usage is likely ubiquitous with each user possessing a much larger list of contacts, and statuses that will update more frequently due to the inclusion of “in a meeting,” “on the phone,” etc.

The need to manipulate SIP messages has arisen from the range of interpretations of SIP made by different equipment vendors. This has led to situations where it is desirable, or even necessary, to change the headers or contents of SIP messages as they flow from endpoints into a carrier network or even when they pass between carrier networks.

Managing Exploding Session Counts

NAT traversal is a basic function of an SBC in an access deployment, where the SBC is used to solve the reachability issues caused by the endpoint sitting behind a NAT/firewall. NAT traversal in itself does not have a major impact on an SBC’s message-handling requirements, but the pinhole through the firewall must be kept open. The normal method for keeping the pinhole open is to set the expiry time for the registration of an endpoint to a value less than the timeout period expected for the pinhole on the firewall. As a result, the endpoint will send a SIP REGISTER message much more frequently than if it were not behind a NAT/firewall. Figure 5 illustrates the impact that supporting several users behind NATs/firewalls can have on an SBC’s message-handling capabilities. SBCs need to be able to handle these high levels of messages while still handling the calls generated by these users.

environment is impacted by three key factors: the number of subscribers, the number of contacts or “buddies” that each is connected with, and the timeframe between status changes. As each of these grows, the number of messages will expand multiplicatively. For example, in the first case below, only a small percentage of subscribers are using presence with relatively modest “buddy lists,” so the resulting number of SIP messages generated is fairly manageable.

SIP-I to SIP/SIP-I Interworking FIGURE 6. Performance Impact of SIP Presence

SIP-I is used to transport ISDN User Part (ISUP) messages around a network using SIP as the transport protocol. SBCs are required to provide interworking between the SIP-I and peer network devices that are using SIP and also to interoperate between SIP-I and SIP-I where different ISUP variants are being used in peer networks. 5

Call Admission Control One major function expected from Session Border Controllers is the ability to control the usage of resources within the network. Call (or Connection) Admission Control (CAC) allows the SBC to control the number of active calls on a per-trunk basis and can scale down to control an individual endpoint. The SBC can prevent trunks from completing more calls over them than they are capable of handling and control the number of calls that an endpoint can make based upon policy decisions. A very important function that must be combined with CAC is the ability to police the media traffic that is passing on calls that have been allowed to take place by CAC. This media is policed based on the type of media combined with the type of codec negotiated for the call.

Security As SIP networks have evolved, the need to provide security within the SIP networks has increased. The range of security threats has grown, ranging from attacks on the IP/UDP/TCP layer to attacks at the SIP layer; SBCs must be able to withstand these attacks while still maintaining service to the users. Attacks on IP/UDP/TCP at gigabit “wire speed” can only be handled via purpose-built network processors, which allow the main system CPU to deal with higher-layer processing. Another important security feature is enforcing whitelists and blacklists. Whitelists are lists of trusted endpoints, while blacklists are lists of endpoints that should be blocked from making or receiving calls. Sonus SBCs can create dynamic blacklists of misbehaving endpoints. This allows the SBC to respond to misbehaving endpoints without any intervention from the carrier. The events that can dynamically trigger the blacklisting of an endpoint include: multiple registration failures, receiving large quantities of bad SIP packets from an endpoint, or a configured parameter exceeding a call rate limit.

Encryption Originally SBCs didn’t provide much in the way of encryption, with few endpoints supporting it. As the services have grown and the capabilities of the endpoints have increased, the demand for encryption has grown. Encryption within SBCs is required for both the signaling and media. The signaling traffic is encrypted via either IPsec or TLS while RTP traffic can be encrypted via Secure RTP (SRTP). To handle encryption with any scale without having a large impact on the overall performance of an SBC, it is necessary to provide encryption via specialized hardware within the SBC - something most first-generation SBCs do not have. This hardware relieves the core CPU from the high processing load imposed by encryption, thereby allowing it to handle the general functions of the SBC.

Call Routing At their inception, SBCs performed very limited functions with regard to routing calls within a network, relying on other elements within the network to perform routing and policy decisions. Historically SBCs have looked at the To: address and made a forwarding decision based upon the address type. SIP has two general address types: SIP addresses, known as a “SIP URI,” and telephony addresses, known as a “tel URI.” SIP URIs take a form very similar to an email address, consisting of a username and a hostname; e.g., sip:[email protected], where “abcd.com” is the domain name of Bill’s service provider and “bill” is Bill’s unique user address within that service provider. The hostname does not have to take the form of an FQDN but could be an IP address, such as sip:[email protected], where 10.3.4.5 is generally the IP address of the call server within the service provider. Tel URIs take the form of telephone numbers either in global (E.164) format or in local notation (e.g., +1 555 555 5555 or 911), with numbers from private numbering plans, emergency codes, etc. also being supported with additional context information. The way in which SBCs used these addresses to forward the SIP messages varied from address type to address type. The expected behavior was configured for each address type and was typically as outlined below. For SIP URIs, if the hostname is in FQDN format then the choices are:

• Use DNS SRV lookups to determine next hop

• Use the IP address as the next hop

• Use a local lookup table in the SBC first to see if any local

• Use a list of IP addresses provisioned on the SBC to forward to

behavior is provisioned for the FQDN (e.g., local DNS cache)

• Use a list of IP addresses provisioned on the SBC to forward to regardless of the FQDN For tel URIs the choices are:

• Using the list of IP addresses/FQDNs provisioned on the SBC

6

For SIP URIs, if the hostname is in IP Address format then the choices are:

regardless of the IP Address

• Use a local lookup table in the SBC first to see if any local behavior is provisioned for the IP Address (e.g., FQDN to use instead)

With all these options, the SBC isn’t performing any real routing decisions for the addresses but is simply finding out where to forward the SIP message so that any routing decisions can take place there. The routing decisions are actually being made at either a SIP Call Agent (CA) or a softswitch with the SBC protecting the edge of the network but deferring any other decisions to the CA/softswitch. The decision to use a CA or a softswitch would be based upon the size of the network, the diversity of the networking devices in the network and the overall budget. More recently, SBCs have started to adopt other routing techniques such as ENUM. ENUM is used to take an E.164 address, such as would FIGURE 10. Support for Local or Centralized Routing and Policies be used in the tel URI above, and convert it into a NAPTR/DNS address which can then be routed as a SIP URI. Some SBCs have started to add more call routing capabilities into their product suites. These are varied in their nature and include either the addition of a routing database into the SBC or the addition of an adjunct platform to perform the routing function in the form of a stateful or stateless proxy. Where a routing database has been added to the SBC, it is generally limited in the scale of the routing database and the performance due to the additional memory and processing requirements it places on the SBC. As the complexity of the routing grows, the need to manage and configure the routing databases centrally arises. Some SBC vendors have implemented such configuration tools, which then push the routing database out to the devices within the network. Sonus has a strong heritage in the call routing area with the Sonus PSX™ Centralized Policy and Routing Server. The Sonus PSX server is a proven, highly scalable routing and policy engine that can be configured centrally and can be scaled within the network by replicating the FIGURE 11. Sonus PSX Server – Fully Redundant, database between master and distributed devices. Within the Sonus Distributed Policy and Routing Engine solution, whether the device is a TDM gateway or a Border Controller, the PSX server leverages the same PSTN-style traffic control (Telcordia’s GR-477-CORE standard) for both TDM and IP trunk groups. The Sonus PSX server can act as a routing SIP proxy within the network or the Sonus device can launch a Diameter Policy Request to the PSX server asking for instructions on how to route the call. This allows the routing policies to remain on the PSX server and to be acted upon by the Sonus SBC. There is continued demand for call routing capabilities in SBCs, and SBC vendors are reacting by building modest routing capabilities into their SBCs. In contrast, Sonus has a strong heritage in call routing and policy and is leveraging the superior functionality and proven scale of the PSX server within the border control solutions that it offers to the market.

The Sonus SBC Family As a leader in secure VoIP networks, Sonus Networks has offered carriers a high-performance border solution with the hybrid TDM/IP SBC 9000™ since 2003. Our security portfolio expanded with the addition of a pure IP appliance that leverages many of the same features: the Sonus SBC 5200™ Session Border Controller. Together, they provide robust session control, media transcoding, and security for both legacy networks in transition and the next generation of pure IP communications. Based on a unique Sonus architecture that combines multiple, embedded hardware elements to address media transcoding, security, and encryption functions, the Sonus SBC portfolio offers a proven and scalable, high-performance session border solution that meets the challenges of today’s IP communications networks. The SBC 5200 is the first of a new class of Sonus VoIP solutions that provides, providing superior price-performance in a small form-factor. Both share the same engineering cornerstones:

• High performance under load

• Embedded media transcoding

• Robust call control

• Robust security 7

The SBC 9000 and SBC 5200 share many of the same industry-leading features on different strategic platforms. The SBC 9000 is based on Sonus’ unique GSX™ Open Services Platform and provides the only high-density media gateway that evolves gracefully from TDM to hybrid TDM/ IP to all-IP secure interconnect in a single chassis.

Conclusion

SBC 9000

SBC 5200

Built on GSX9000 platform

Built on pure IP platform

Embedded or centralized Centralized routing via PSX As IP networks evolve, demands on the SBC PSX routing engine continue to increase, both in supported TDM migrating to IP-PI functionality and in performance requirements. IP-IP with media transcoding with media transcoding We have identified a few key areas where the next Compelling migration path generation of SBCs will differentiate themselves Industry Leading Performance Densily of gateway investment from their predecessors. As their capabilities increase, they will allow more complex tasks to FIGURE 12. The Next Generation of Border Control be accomplished immediately at the edge of the network, reducing the need to hairpin sessions through the core network for treatment. We believe this will significantly simplify operations and improve scalability of the network by eliminating unnecessary call legs and hot spots. To achieve these benefits, the SBC must be designed with carrier-grade performance, competitive call and message throughput deployed concurrently with other advanced features such as wire rate security protection, encryption, CDRs, lawful intercept, RTCP and of course over both IPv4 and IPv6. A wide range of transmission protocols and signaling interworking considerations must also be addressed. To meet these demands, SBCs will need to be flexible and scale independently across three dimensions:

• Providing advanced call routing and policy enablement capabilities; • Transcoding media from one format to another; • Performing wire-speed packet inspection and signaling message manipulation. SBCs that rely on general-purpose computing to perform all three functions will find it difficult to meet these requirements. Sonus SBCs use purpose-built hardware and optimized software to support a rich set of features and achieve the high-performance requirements needed in these evolving IP networks.

Sonus Networks North American Headquarters

Sonus Networks APAC Headquarters

Sonus Networks EMEA Headquarters

Sonus Networks CALA Headquarters

4 Technology Park Drive Westford, MA 01886 U.S.A. Tel: +1-855-GO-SONUS

1 Fullerton Road #02-01 One Fullerton Singapore 049213 Singapore Tel: +65 6832 5589

56 Kingston Road Staines, Middlesex TW18 4NL United Kingdom Tel: +44-0-17-8422-5750

Mexico City, Campos Eliseos Polanco Andrés Bello 10, Pisos 6 y 7, Torre Forum Col. Chapultepec Morales, Ciudad de México Mexico City, 11560 Mexico Tel: +52 55 36010600

To learn more, call your Sonus sales representative or visit us online at www.sonus.net The content in this document is for informational purposes only and is subject to change by Sonus Networks without notice. While reasonable efforts have been made in the preparation of this publication to assure its accuracy, Sonus Networks assumes no liability resulting from technical or editorial errors or omissions, or for any damages resulting from the use of this information. Unless specifically included in a written agreement with Sonus Networks, Sonus Networks has no obligation to develop or deliver any future release or upgrade or any feature, enhancement or function. Copyright © 2012 Sonus Networks, Inc. All rights reserved. Sonus is a registered trademark of Sonus Networks, Inc. All other trademarks, service marks, registered trademarks or registered service marks may be the property of their respective owners.

DS-1201 01/13 8