Session Border Controllers - SBCs

If your business or organisation is seeking to reduce up to three quarters of its existing telephony costs, you could refresh your telephony by implementing SIP and VoIP trunk and endpoint registration services - but in order to do this, you’ll first need a session border controller (SBC).

Session Border Controllers enable businesses, organisations and enterprises to secure endpoint and SIP trunking services at their network border and enable a more seamless flow of SIP-based media for unified communication deployments.

In 2017, there are more than a dozen different session border contoller vendors, all of whom claim their portfolio provides the desired power, security and session control for enterprise SIP communications.

However, we should all realise that SBCs are not created equal. If you’re entertaining the idea of investing in a session border controller, you should carefully consider and compare factors such as session performance, feature set robustness, resilience, scalability and the ability to customise the border controller before choosing an SBC for your network.

A Session Border Contoller – What Should It Do?

Somewhat jack of many trades – there are lots of things that an SBC should do (and do so effectively) in order to help enterprises reduce communications costs and provide new, revenue-generating services.

These can be broken down into seven basic categories:

1. Security, or how well does it ensure privacy, negotiate firewalls and protect the network from internet-based attacks?

2. Session performance, or how many voice/video calls can it handle?

3. Policy and call routing, or how does it help control network users and network traffic?

4. SIP interoperability, or how well does it “play” with the rest of the hardware and software in the network?

5. Media transcoding, or how efficiently does it translate different types of media?

6. DTMF/fax interworking, or will the SBC support legacy call center solutions and technologies?

7. Scalability, or what happens when more horsepower is needed?

We’ll address each category in more detail below.

Border Security

The primary role of an SBC is to protect the organisation’s internal network from outside (usually internet) attacks and to ensure security and flow of SIP sessions, as they cross between secure and non-secure points.

Attacks from the internet occur for a variety of reasons, from a variety of different sources and can significantly impact a business. Some attacks are designed to bring a network down, such as a denial-of-service (DOS, or DDOS) attack that floods a network with fake requests, which can prevent call centres from receiving calls and result in lost sales.

Other attacks might be designed to steal confidential data, perhaps by accessing the network under a false identity or by eavesdropping on confidential communications.

Another common type of attack seeks to steal long distance service by illegally logging onto the network and using that organisation’s own service providers to make calls - an attack commonly known as toll fraud.

As well as protecting the network, SBCs can protect communications from intruders as they travel non-secure channels by encrypting the media and signalling.

Encryption is particularly important for businesses which are often trusted to handle confidential customer information - such as healthcare or financial organisations. In many cases, existing data, network and telephony security measures, such as Private or Network Address Translation (PAT or NAT) firewalls, require that SBCs provide secure workarounds to allow SIP sessions to pass through; this is known as NAT traversal and is an important requirement for SBCs, as many enterprises use NAT firewalls to protect both office-based and remote IP devices in their wider network.

Enterprises should therefore look for SBCs that are built around these best practices:

• Denial of Service or Distributed Denial of Service Prevention — Denial-of-service (DoS) and distributed denial-of-service (DDoS) attacks can kill an organisation’s network for seconds, minutes or hours. It does this by flooding the network with phony requests. (A Denial Of Service attack is usually only a single host generating all of these requests, while a Distributed Denial of Service attack involves many (often hundreds or thousands) of ‘zombies’ - devices generating a single request over and over). A Session Border Controller should be able to identify these attacks through a mix of end point recognition (e.g. is the request coming from a known attacker?) and pattern analysis (are thousands of devices sending an identical request?).

• Topology Hiding — An SBC should act as a wall that protects the identity of phones, computers and other IP devices behind it. Hiding topology prevents attackers from targeting and/or exploiting a specific device that has an IP address (e.g, an IP-enabled phone or PBX) in order to illegally access voicemail or other services.

• Rogue RTP Protection — RTP stands for Real-Time Transport Protocol, the procedure that is responsible for supplying real-time media like voice and video. In the case of toll fraud, unauthorized (or Rogue) RTP communications illegally penetrate the network. An SBC should include provisions to identify and block rogue RTP media streams.

• Media Encryption — cryptography is a system of using complex digital “keys” to lock and unlock information. Media encryption, therefore, refers to locking the media itself (namely voice, video or data), ensuring privacy of private communications. The standard form of media encryption in the world of SIP is called the Secure Real-Time Transport Protocol (or SRTP).

• Signaling Encryption — In addition to media encryption, signaling encryption is recommended to authenticate the end points in any SIP-based communication. There are two accepted signaling encryption standards in SIP: TLS (Transport Layer Security) and IPsec (IP Security). Due to the fact that some industry standards need differing signalling encryption methods (for example IPv6 recommends IPsec), we recommend an SBC that offers both encryption methods.

• NAT Traversal — A NAT firewall “conceals” the IP address of end points (phones, PCs, etc.) behind it, which is problematic during SIP sessions as it stops end points beyond the firewall establishing a direct connection with an end point inside the firewall. To get around this, SBCs can create a secure pinhole in the firewall by “re-pinging” the NAT-protected end point every few seconds; this allows the two end points to keep a stable connection for the duration of the SIP session.

Session Performance

In SIP language, an exchange of media (for example voice or video) between two end points is called a session. Session performance refers to the number of simultaneous sessions that an SBC can support at one time. As the ratio of users to sessions is usually higher than 1:1 (call centers being a particular exception), a business with 1,000 employees might only need an SBC that supports 350 concurrent sessions, which would allow for the possibility that one in every three employees would be engaged in a voice or video call at the same time.

Sadly, not all SBC vendors are willingly informative about how they determine the performance of their SBCs. Many use simple SIP sessions for their calculations so as to boost their numbers.

For example, an SBC that can support 20,000 concurrent SIP sessions may only support 10,000 simultaneous sessions when encryption is enabled on both sides of the communication, and 5,000 concurrent sessions when encryption and media transcoding are necessary. In order to select an SBC with adequate real-world performance, companies should look for an SBC that offers:

Call Routing/Policy Management

SBCs are not only responsible for intercepting SIP sessions at the network border, they also choose the best route to deliver that signaling and media to its end point. This call routing is one of many strategies that the SBC uses in order to ensure the smooth and efficient flow of traffic in your business network. This efficiency brings the benefit of significant financial savings, both by avoiding toll costs through intra-network routing and through a practice known as least cost routing (LCR).

An SBC uses Least Cost Routing calculations to select which path will save companies the largest amount of money. This can be done by, for example, choosing the lowest cost carrier for long-distance calls based on the time-of-day, call destination and other details. While the majority of SBCs will offer some level of call routing, many provide only basic routing choices. Needless to say, the more routing options an SBC exploits, the more opportunities your business has to both save money and provide higher quality of service by using the fastest paths with the lowest price and highest quality.

This is especially so in the case of a centralized dial plan, which stores call routing information for all enterprise PBXs in an SBC, and eliminates costly PBX provisioning services. Policy enforcement impacts many other aspects of SIP communications, including security, user preferences and network load balancing. For example, policy and routing decisions can help ensure the responsiveness and availability of contact center resources by balancing call loads during peak usage periods, such as between Noon and 1:00 PM. Most SBCs enforce these policies at the local level; in other words, each SBC maintains its own set of unique policies for the subscribers it serves.

While this local policy management model is fine for small networks, it presents a problem for networks with multiple SBCs: how to manage multiple policies on multiple SBCs. Provisioning policies for every SBC is a time-consuming process and one that historically creates problems as subscriber information changes, requiring updates to every SBC. For this reason, some SBC vendors have implemented a centralized policy management model that allows enterprises to maintain a centralized policy database that is provisioned once and automatically updated locally on every SBC in the network.

This method saves time, saves on device maintenance and reduces the provisioning errors created by multiple manual provisioning of network touchpoints.

• High session performance when features such as encryption and media transcoding are turned on

• Unimpacted performance during a DoS attack or overload conditions

• Rapid end point re-registration following a power outage

• 99.999% reliability or higher

• Hardware redundancy for seamless disaster recovery 3 SIP Interoperability

A key role of an SBC is to mediate SIP communications between different devices. While SIP is an industry-standard protocol, and industry standards are designed to ensure consistency across implementations, the reality is that SIP is not consistently implemented the same by hardware and software vendors.

The problem lies with the way the SIP guidelines were written, allowing individual vendors to decide how best to implement SIP through suggestions rather than hard rules. As a result, an SBC from Vendor A and an SBC from Vendor B may “speak” SIP differently, requiring some translation (known as SIP normalization) to ensure that signaling instructions are properly communicated. And it’s not just SBCs that have their own dialects of SIP; private branch exchanges (PBXs), automatic call distributors (ACDs) and interactive voice response (IVR) systems are other examples where SIP normalization may be required.

In order to simplify SIP communications (and ensure that enterprises can continue to use their existing PBXs, ACDs and other investments to keep costs down), an SBC should ensure interoperability between SIP and other signaling protocols. Enterprises should, therefore, look for the following interoperability features from an SBC:

• SIP normalization and SIP message manipulation (SMM) tools that allow enterprises to rapidly modify SIP headers for seamless communications between networks

• Adherence to industry SIP standards where possible, such as SIPconnect for SIP trunking implementations and SIP Forum for IP Multimedia Subsystem (IMS) implementations

• Extensive interoperability testing with third-party PBXs, IP phones and other devices

• IPv4-IPv6 interoperability

• Interworking between SIP, SIP-I/T and H.323 (legacy) protocols

Media Transcoding

Different kinds of telecommunications networks—for example, fixed-line and mobile networks—use different codecs (coder/decoders) to convert voice signals for digital transmission. (These different codecs are the reason why voices on your cell phone and your home phone sound different.)

Codecs may consume a lot of bandwidth to deliver a better quality sound, or use less bandwidth to provide faster transmission. Some, but not all, SBCs have the ability to translate between these different codecs, a process known as media transcoding. Transcoding has two advantages for enterprise networks: it can reduce the network bandwidth that a call consumes by temporarily translating a high-bandwidth codec into a lower bandwidth codec, and it can improve voice or video quality by translating communications into a codec that the end user device natively supports.

This latter advantage is especially important as more enterprises move to high definition (HD) voice, which often requires transcoding but in return delivers a measurably better experience for call center customers. So how much bandwidth can transcoding save you? As the chart below illustrates, transcoding from G.711 to G.729, for example, could reduce bandwidth consumption in your network by more than 60%.

There are three ways that SBCs can address transcoding:

1) Handing it off to an external transcoder;

2) Buying a third-party transcoding solution and packaging it into their SBC; and

3) Building a customized transcoding solution into the SBC. The third approach offers the most benefits to enterprises because it typically results in faster encoding/transcoding speeds, lower costs and more flexibility.

When looking at an SBC with media transcoding, enterprises should ask the following questions:

• How long has the vendor supported media transcoding in their SBCs?

• What media codecs are supported?

• Do they own their DSP intellectual property?

• Does the SBC draw CPU cycles from other processes when it performs transcoding?

• Is the media transcoding solution easily customizable or a generic OEM solution with very limited customization and flexibility?

DTMF/Fax Interworking

Dual-tone multi frequency (DTMF, also known as “touch-tone”) and fax services may be older technologies, but they show no sign of disappearing completely from enterprise communications systems. In fact, some enterprises have spent years (and millions of dollars) perfecting their Interactive Voice Response (IVR) and auto call attendant solutions—many of which rely on DTMF services—and aren’t about to replace those with newer SIP-based systems. That’s why it’s very important that an SBC support legacy technologies like DTMF and both PSTN- (T.30) and IP-based (T.38) fax transmission through robust protocol interworking and the accurate extraction of DTMF signals from both signaling and media packets.

If your enterprise relies on these legacy technologies to do business, ask your SBC vendor these questions:

• How accurately can they extract DTMF tones from in-band (i.e., signaling-based) communications?

• How accurately can they extract DTMF tones from out-of-band (i.e., media-based) communications?

• Do they support fax transmission/relay between IP-to-IP networks, IP-to-PSTN networks and PSTN-to-IP networks? • How long have they supported DTMF and fax relay interworking in their solutions?

Scalability

SIP communications traffic will continue to rise as more enterprises adopt a Bring Your Own Device (BYOD) strategy that introduces more SIP-based smartphones and tablets into the network ecosystem. What this means is that the SBC you buy today needs to be able to handle the growing traffic needs of tomorrow, and it must scale cost-effectively. Fortunately for enterprises, there are many SBCs that offer a wide range of session scalability, from several hundred sessions to several thousand. Pricing for those sessions, however, can vary greatly.

When comparing the cost of an SBC now and later, be careful that you don’t get caught in an apples—and oranges—comparison. Weigh all your cost factors together including:

• Cost per session

• Cost per media transcoded session

• Cost per encrypted session

• Licensing cost for call routing/policy engines

• Installation and deployment costs

• Annual maintenance and support costs

Feature Comparisons:

A Look at the Top Three SBCs Now that we’ve identified what features are most important in an SBC, let’s see how the top three SBCs in the large enterprise class (16,000- 64,000 sessions) market stack up. The chart below gives a feature-by-feature comparison of the SBC 5200 and the other two leading enterprises SBCs on the market today.

What Can The Top 3 SBC Vendors Do For Your Enterprise?

How They Stack

As you can see, all of the top three SBCs on the market deliver robust features. There are, however, some distinguishing characteristics that separate the Sonus SBC 5200 from the competition. In the interest of fairness let’s just say the Sonus SBC 5200 is different than other SBCs. How? Let us count the ways:

1.Built-in, customized media transcoding firmware Sonus Networks has a rich history in media transcoding dating back to our industry-leading media gateways. We were the first company to introduce built-in media transcoding in our SBCs and, today, we’re the industry’s only SBC company that builds their own media transcoding firmware. Only recently have other SBC vendors followed our lead by addressing transcoding needs, and their lateness to the market shows in their complete reliance on generic, third-party transcoding firmware. Why is built-in, customizable transcoding important? Because it processes transcoding faster and allows enterprise to quickly address new codecs—key advantages when you consider that media transcoding needs are poised to grow exponentially with the explosion of tablets and multimedia mobile devices. Sonus’ media transcoding firmware also allows our SBCs to deliver more accurate dual-tone multi-frequency (DTMF) interworking for legacy enterprise systems such as Interactive Voice Response (IVR) systems, auto call attendants and fax machines.

2. Centralized policy management Here again, Sonus was the first to market with centralized policy management. Most SBC vendors feature local policy because they make boxes, not networks. At Sonus Networks, we see the big picture, and centralized policy management is simply a better approach for big networks. Why? Because it reduces provisioning time, reduces provisioning costs and reduces provisioning errors. It also plays a key role in centralized session management, something that Sonus offers with its Sonus Harmony session management solution.

3. Better performance in the real world Published performance numbers can be misleading, since many vendors inflate their SBC’s performance by basing it on simple, controlled SIP sessions. Which is fine if you’re planning on deploying the SBC in a test lab. But in the real world, SIP sessions are anything but simple, and often require encryption and transcoding: features that can drain an SBC’s performance. How much? Let’s see how the SBC 5200 stacks up against the leading SBC’s performance claims.

4. Better performance under pressure Any SBC will perform well under ideal conditions. But how does it perform during heavy workloads? Power outages? Overload conditions? DDoS attacks? The SBC 5200 performs extremely well under adverse conditions, as verified by Miercom, a third-party testing lab. In an independent study, Miercom tested the SBC 5200 under attack conditions and found that the SBC’s CPU and memory “were rarely stressed, indicating to us that this architecture has plenty of processing horsepower to spare.”

Things to Consider When Sourcing an SBC

If an enterprise chooses to purchase an SBC directly from a vendor and manage it themselves, they should look at additional criteria beyond the box itself, such as:

• Interoperability with third-party solutions. Make sure to check the vendor’s website for a list of technology/interoperability partners and ask for proof that the vendor has completed point-to-point interoperability testing between their products and third-party solutions. While SIP is an industry-standard protocol, various technology vendors interpret it differently.

• The vendor’s professional services capabilities to not only install and configure the solution, but also to integrate management of the SBC with the enterprise’s existing Unified Communications infrastructure.

• Ease of management. If sourcing SIP trunking through a reseller, the enterprise should check that the reseller is accredited to resell a vendor’s brand by going to the vendor’s website for a list of authorized/accredited channel partners. However, for the most part in the managed/hosted scenario, the enterprise does not know who the SBC vendor is; the enterprise trusts that the reseller has done the due diligence to bring the best SBC vendors into the reseller’s portfolio. As a safeguard, the enterprise could ask the reseller these questions:

• Has the reseller done a complete series of interoperability testing on the vendor’s SBC to ensure that the vendor’s SBC works with the other network elements within the SIP trunking service?

• Does the reseller have a no-fee evaluation program so the enterprise can test the solution in their company lab, including assistance from the reseller to set up their test plan?

• What are the support terms/SLAs offered by the reseller?

• Does the reseller frequently attend manufacturer training sessions?

• Does the reseller have an SBC customer reference list?

• Does the reseller have Sales Engineers and other 24/7 support staff?

• Does the reseller offer financing options?

• What type of end-user training does the reseller offer? Does it include not only training on the product itself, but also training on the processes for post-sales support: How to access the reseller’s technical assistance center, How to log a ticket, and How to submit a product change request?

The Buyer’s Conclusion

Choosing a session border controller is more than an IT decision, it’s a business decision. Today’s enterprise SBC has evolved beyond the role of a security appliance to become a vital communications solution that enables higher quality voice and video, more flexibility to deliver multimedia applications to customers and employees, and cost efficiencies by dramatically reducing telecommunications fees and network management complexity. SBCs are fast becoming a requirement for enterprise communications, not only for what they can enable today (SIP trunking, SIP-based applications like Skype and videoconferencing, etc.) but for the cloud-based services they’ll enable tomorrow. Thus, the SBC selection process is a critical one for enterprises, as it will impact their communications capabilities for years to come.

Although this Buyer’s Guide has focused on large enterprise SBCs, many of the same criteria hold for mid-sized enterprise SBCs as well. In any case, enterprises should perform their own due diligence in selecting an SBC and weigh all of their options carefully. No one SBC is right for every enterprise, and some enterprises may find a mix of different SBC vendors, or different SBC models from the same vendor, provides the best solution.

Appendix A: Benefits of SIP Trunking In the past, enterprises had one way to get high-quality voice services at a lower cost: by leasing PRI (Primary Rate Interface) lines from their service provider. With the advent of Voice over IP (VoIP), however, service providers began to offer SIP trunking services to their enterprise customers.

SIP trunks have many advantages over PRI trunks:

• They deliver both voice (SIP) and data (IP) over a single trunk connection, which better utilizes the trunking bandwidth

• They enable enterprises to take advantage of new SIP-based applications like Skype

• Unlike PRI trunks, they don’t require a dedicated trunk for every location

• They cost up to 25% less than PRI trunks per session

Case Study: A National Retail Chain

Company A is a national retail chain with more than 1,000 stores nationwide. The company decided to consolidate their voice and data network across two national data centers, using SIP as the foundation for their VoIP network. While the initial driver for the consolidation was to reduce operating expenses—in part by replacing expensive PRI trunks with less expensive SIP trunks—the company also viewed the network consolidation as an opportunity to improve their call center operations. In evaluating an SBC, the retailer looked for several key features:

• Security and encryption standards that would meet the regulatory requirements for financial and personal confidentiality

• Simplified SBC provisioning that could be easily replicated as SIP services are rolled out to new stores

• A centralized dial plan and routing system that connects callers to their local store

• Specialized tones and announcements that reassure callers as their call is being transferred to a local store or department

By moving to more cost-effective SIP trunking services, the company will save millions of dollars per year in leasing costs compared to more expensive PRI trunks. In addition, by directly routing calls to their local stores over their WAN rather than the public switched network, the company will substantially reduce their long-distance fees.

Case Study: A National Bank, Post-Merger

In the case of business mergers and acquisitions, it’s important to consider how companies will merge their communications networks. For a national bank, the blending of two separate data networks and two separate voice networks created a sizable logistics challenge. So the merged bank decided to consolidate its data and voice network into a single SIP network that would support the bank’s future plans for a Unified Communications system. By implementing SBCs at the borders of both networks, the bank was able to solve the interoperability issues between different SIP and H.323 legacy devices so that both voice networks could work together seamlessly.

The new SBCs enabled the merged bank to extend SIP trunking services to both sets of regional branches and route calls seamlessly to local branches. In addition, the SIP-based infrastructure allowed the bank to implement its own audio-conferencing and videoconferencing solutions so employees from both banks could collaborate from their offices and their homes.

The bank will save millions of dollars by reducing their PRI trunking costs and the OPEX associated with maintaining two sets of networks. As an added benefit, the company is able to save substantial amounts of money each year on long-distance and audio-conferencing costs by moving to their own hosted, WAN-based solution.