The Basics of Session Border Controllers
What exactly is a session border controller? A session border controller (SBC) is a technology that is designed to help enable and secure important parts of any business’s telecommunications infrastructure. It controls a network by admitting (or no admitting) and the directing communications between two end devices on the network. These communications are called sessions.
The SBC does this session controlling at the point where traffic is handed off to from one network to another (called theborder). Because of where the SBC fits in the network, it can be usefully implemented by both businesses themselves and also by the service providers who serve them.
What Does a Session Border Controller Do?
Protect and Secure the Network
The SBC’s main role is protecting and securing the network. Built from the ground up to help eliminate spoofing attacks, denial-of-service attacks, and toll fraud. The SBC secures the network by hiding the architecture and making it difficult for bad guys to gain access to vulnerable parts of the network. It enables encryption that prevents communications from being illegally intercepted or tampered with.
Enable SIP Trunking
The SBC is a key element of any SIP trunking solution. The SBC looks at each session crossing between the internal enterprise network and external ITSP network and determines where the session should be routed and what priority the session is assigned when the network is busy. The SBC also determines how much bandwidth should be assigned to a session, based on network utilization and the policies established for the network. Most importantly, the SBC performs SIP interworking, which allows devices that sue subtly different variants of SIP to communicate with each other effectively and efficiently.
Interconnect with Topology Hiding and Protocol Translation
The SBC provides a smooth experience in terms of interconnecting and interworking between different networks and the protocols running over them. The SBC can translate between SIP variants between devices, so calls get through with all their features in tact. In addition, because different VoIP solutions may use different audio codecs that aren’t completely supported on both sides of the session, the SBC can translate protocols on the fly.
Session Traffic Cop
The SBC is the gatekeeper to the VoIP network in an enterprise or in a service provider network. In this role, it performs session admissions control. Session admissions control is the process of determining who has access to the network and who doesn’t. The SBC is the traffic cop of a VoIP network, keeping your VoIP highways safe and orderly and creating and accessing three lists – whitelists, blacklists, and greylists.
Key Features of SBCs
Identifying the Key Requirements of an SBC
There’s more than just security to the role of an SBC. Many in the industry say that it’s the security that causes customers to become interested in SBCs, but it’s the other functionality that really makes the sale.
SIP is the primary protocol that makes the connection between two endpoints and closes the connection when the call is finished. The use of SIP is critical to the ability of disparate network topologies from different vendors to be able to communicate with each other.
SIP is a communications standard authored by global community of engineers known as the Internet Engineering Task Force (IETF). The actual SIP implementations are left up to individual engineers and vendors, resulting in a multiplicity of SIP variations that are technically in compliance with published SIP standards but not necessarily compliant with one another. Enough variations exist in SIP that sometimes two systems connecting to each other using SIP find that they aren’t really speaking the same language. The basics are all there, but with different syntax and dialects in what otherwise appears to be a common language.
Any SBC must be able to speak all the different dialects of SIP and do on-the-fly translations in both directions. So, it a call is crossing a border between a system using Dialect X and another system using Dialect Y, the SC is required to find the parts of Dialect X and Y that don’t quite match up and convert them back and forth as the call moves across the SBC. It’s not rocket science in concept, but it’s hard to do, and the best SBCs make the whole process transparent and seamless.
The SBC’s job is to transcode, or change, codecs as sessions pass through the SBC. The SBC knows which codecs are supporter on each side of the network border, and is required, using a combination of software and special purpose digital signal processors (DSPs), to decode and then re-encode the voice or video signal as it crosses the network border.
Many codecs are in use in various VoIP and UC systems. Low and high quality bandwidth and video and voice codecs are designed to work differently on various devices including computers, tablets, dedicated VoIP phones, and mobile devices.
In a VoIP calls, there are always differing capabilities to support codecs. So, if an enterprise’s PBX supports one specific codec and the incoming call from an important customer is using a different codec, the SBC will understand both codecs and, in real time, and in both directions, modify the codec as the call passes through it.
Dealing with NAT Traversal
NAT is a technology service that translates between a single public IP address and the private IP addresses that your router assigns to all the attached devices on your network. NAT is a configuration that’s used because there aren’t enough IP addresses available in the world to assign each and every individual device its own unique address. NAT lets a small pool of IP addresses get used over and over in different private networks while letting the devices attached to that network communication with the broader Internet using a single, unique public IP address.
The problem with NAT is that creating an end-to-end session is difficult because the IP address of a device on a NAT isn’t a public IP address. This creates issues with end-to-end sessions like VoIP and requires some translation to happen between private and public addresses – translation beyond what the private network’s routers can do.
Many SBCs explicitly support what’s known as NAT Traversal, providing the ability to work with VoIP session packets and giving them the instructions they need to get through the NAT routed and to the actual device that’s on the end of the session. NAT Traversal requires a significant amount of computing capacity in the SBC because a large number of devices participating in VoIP and other sessions are being a NAT. An SBC requires a lot of processing power to do all the translating and routing required to traverse NATs.
Fax and Tone Detection
Often, legacy technologies linger on well past their “sell by” date, and the network needs to support them. A prominent example of this in the VOIP world is fax technology. An SBC can incorporate tone detection – the ability to recognize and act on standard analog telephone touch tones – to recognize and then properly route faxes.
Performance, Scalability, Resiliency, Survivability
SBCs need to be powerful and robust devices with the right degree of extra capacity and redundancy not only to handle the average number of calls coming through the system simultaneously, but also to sale up and handle peak calls. When evaluating an SBC’s performance, scalability, and resiliency, consider the following factors:
CPU Utilization – The SBC does a lot of computationally complex work. The CPU utilization during peak periods should allow plenty of overhead.
Concurrent Calls (or Sessions) Supported – How many concurrent calls is the device rated for? How does this match your network’s usage patterns? If your usage grows and begins to exceed the capacity of your SBC, how can you upgrade?
Redundancy – An SBC is performing a mission critical role for an enterprise or carrier. Are there any elements within the SBC that don’t have a redundant element that can take over a millisecond’s notice? If so, remember downtime means lost money.
Survivability – Survivability is similar to redundancy, but instead of failing over to another piece of hardware the SBC routes calls over another interface when its main interface is down.
Registration Rate – How many clients can the SBC register in a fixed period of time? This relates to registration storms. When a lot of users are connecting at once, make sure the device can handle it.
SBCs and Telecom Security
SBCs were initially deployed primarily within service provider networks. SBCs ensure that VoIP calls are properly routed between network providers, that differing protocols are understood so the call can be delivered across difference networks, and that calls are secured.
As VoIP has become more common – indeed, has become the dominant mechanism for transporting voice calls – the SBC has become useful in more places in the network, including at the border between an enterprise’s network and the carrier’s.
Securing the Network
The most talked about driver for the adoption of the SBC is security – and for good reason. VoIP (as well as other session-oriented applications) is an application that by its very nature is exposed to devices and networks that are out of the control of the enterprise or a network provider. VoIP isn’t like traditional telephony where a very highly circumscribed set of devices, protocols, and private networks is involved in the process of placing and carrying calls. In the old days when you placed a phone call (via landline or cellular), the call was placed on an approved device and carried across the private phone company network.
Like other IP applications, VoIP is often carried over public networks – oftentimes across several public networks – and calls can be initiated or completed on devices, such as person computers (PCs) or smartphones, by using VoIP apps that aren’t under the control and regulation of the phone company. This fact leaves the VoIP world considerably more vulnerable to the same kinds of malicious and fraudulent security threats that any internet service faces.
Facing the Issues
Among the threats that an SBC has been developed to help eliminate are the following:
Service Theft and Fraud – These attacks happen when a hacker (or organized group of hackers) accesses an inadequately secured VoIP system to route traffic across the network without paying for it. Not only do the hackers use up network resources without paying for them, but also the enterprise or service provider often ends up paying for the unauthorized toll charges.
Spoofing – Spoofing attacks come into play when people deliberately modify or disguise their identities on the network. This threat may occur to intercept calls intended for another (legitimate) party or simply in order to confuse or annoy.
Denial of Service (DoS) / Distributed Denial of Service (DDoS) – DoS attacks and their bigger, badder brother DDoS attacks seek to flood a server or SBC with requests in order to take it out of commission. DoS attacks can involve sometimes hundreds or even thousands of zombified computers (known collectively as botnet, for robot network).
Registration Storms – A registration storm is when thousands or millions of devices attempt to register with the SIP server all at once in a VoIP network. A registration storm can also occur for non-malicious reasons. For example, after a major network outage, there can be many thousands of VoIP devices all trying to reconnect and re-register with the network at the same time.
Stopping Attacks with an SBC
Networks are increasingly subjected to both malicious and fraudulent attacks. The common attacks of service theft and fraud, DoS, DDoS, spoofing, and registration storms can be dealt with through SBC tools.
Media and Signaling Encryption
This approach applies cryptographic scrambling, called encryption, to both the signaling session initiation, protocol (SIP) and media (voice, video, IM, and so on) portion of the call. Encryption provides more than just scrambled data. It also relies on an authentication mechanism, a way of identifying that a client has the proper half of the secret key, known only by that client. A properly implemented encryption system means that malicious parties can’t eavesdrop on VoIP calls, videoconferences, and other SIP-based communications.
Topology Hiding with B2BUA
A back to back user facing agent (B2BUA) is a system in which SIP calls are controlled by logical or virtual proxy configured for the call. This agent sets up the pathways across the network for both signaling and data. B2BUA causes all signal and media traffic to run through the SBC and hides the topology, or architecture, of the network so clients aren’t shown things like private IP addresses of servers and devices in the network. The net result is a network that’s easily accessible to clients for making and receiving calls, but the “innards” of the network are effectively invisible, which makes them less vulnerable to attack.
The SBC’s policy management system monitors incoming requests and calls, uses rules to identify people who are and aren’t abusing network resources and maintains certain lists:
Whitelists – People and devices that always have access to the network
Blacklists – People and devices that never have access to the network
Greylists – People and devices that sometimes have access to the network
How to get a Location Routing Number
Browse the following websites for an overview of the administrative authorities that control and assign telephone numbers:
www.nanpa.com – North American Numbering Plan Administration (NANPA)
www.nationalpooling.com – National Number Pooling Administration (PA)
www.npac.com – Number Portability Administration Center (NPAC)
Read the Frequently Asked Questions located on the North American Numbering Plan (NANPA) website at www.nanpa.com/faq/sitefaq.html for information on central office code related topics such as the NANP Administration System (NAS) and central office code related forms.
Read the Frequently Asked Questions located at www.nationalpooling.com under Tools, which provide answers to questions about the Pooling Administration System (PAS) and pooling related forms.
Read the frequently asked questions located at: http://www.npac.com/customer-center/faq for information about Local Number Portability, becoming an NPAC user and getting a Service Provider ID (SPID).
Review the Industry Numbering Committee (INC) guidelines: www.atis.org/inc/incguides.asp. ATIS defines the standards and solutions for North American telephone operations. The INC guidelines include Central Office Code (NXX); Assignment Guidelines (COCAG); Thousands-Block Number (NXX-X) Pooling Administration Guidelines (TBPAG)
Location Routing Number Assignment Practices
Step 1. Get an OCN from NECA
In order to request a Central Office (CO) code (NPA-NXX), your company must have an Operating Company Number (OCN). If your company does not have an OCN, contact the National Exchange Carrier Association (NECA) at www.neca.org to request a company code (OCN).
NECA defines a VoIP service provider as IPES (IP Enabled Services).
IPES – A Service Provider deploying IP-enabled services, including Voice over Internet Protocol (VoIP) services, on a commercial basis to residential and business customers. Company Codes in this category shall be used to identify IP-enabled Service Providers interconnecting to the PSTN and can be used to enable the deployment of any new IP-enabled service, technology, or advanced service. VoIP is transmission of voice (such as ordinary telephone calls) using Internet Protocol.
An IPES must submit the following information to request an OCN.
Legal documentation (e.g. Articles of Incorporation, State Registration, etc) as proof of existence and to reflect the telecommunications service provider’s legal name
Proof of service and customers, e.g., interconnection agreements (or evidence of an interconnection order pursuant to an approved tariff).
Contractual agreements with end-used customers or regulatory administration approval, if applicable.
An OCN is requested with the online form: www.neca.org/PublicInterior.aspx?id=1947 .
The fee to receive an OCN is $250.
Step 2. Become an NPAC User, obtain a SPID
To request a Central Office (CO) code (NPA-NXX), you also need a SPID (Service Provider ID) which is obtained from the Number Portability Administration Center (NPAC). Go to www.npac.com/the-npac/access/service-providers/new-user-registration for instructions on how to register with NPAC. Once you have registered with NPAC, your company will be given a SPID.
Step 3. Submit Number Utilization Forecast to NANPA
In order to request a central office code, you will need to have a current Numbering Resource Utilization/Forecast (NRUF) on file with NANPA. See the North American Numbering Plan Numbering Resource Utilization/Forecast Reporting (NRUF) Guidelines document on the ATIS website for more information. Go to www.nanpa.com/nruf/index.html for information on how to file an NRUF.
You must be a registered NAS (NANP Administration System) user before you may submit a number utilization forecast. Read the NAS User Registration Guide for instructions: www.nanpa.com/tools/trainGuides/NAS_User_Registration_Guide.pdf.
Step 4. Certification and Proof of Facilities Readiness
When requesting an initial central office code, you must provide evidence of certification and proof of facilities readiness as documented in sections 4.2.1 and 4.2.1 of the Central Office Code (NXX) Assignment Guidelines (COCAG) found at www.atis.org/inc/incguides.asp.
In addition, your code request may require state certification. A list showing certification requirements by state can be found at: www.nanpa.com/pdf/State_Certifications.pdf
Certification and Proof of Facilities Readiness is required for the next step.
Step 5. Enter Code Request with National Number Pool Administration
Read the Pooling Administration System (PAS) User Guide for Service Providers and Service Provider Consultants located on the Pooling website at www.nationalpooling.com under Documents.
Watch the “How to Request an Initial Central Office Code” training video at: www.nanpa.com/tools/request_initial_CO_code.html
To complete Part 1 of the PAS form, you will need a Common Language Location Identification (CLLI) code for your switch or Point of Interconnection (POI) to the Public Switched Telephone Network (PSTN). In addition, you will need to enter the CLLI of the homing tandem serving your POI. If your company is not a Competitive Local Exchange Carrier (CLEC), you can partner with a CLEC or alternative tandem provider to provide the PSTN POI facilities on your behalf. This is what Vonage did for the “Interconnected VoIP Number Trial” trial ordered by the FCC on June 17, 2013.
Enter your code request into the PAS.
Step 6. Enter your Code into the LERG
The LERG, or Local Exchange Routing Guide, is managed by iconectiv – a subsidiary of Ericsson. The iconectiv group that manages the LERG is still referred to as Telcordia, the company’s name before it was acquired by Ericsson.
Once your central office code has been assigned, the code, LRN, CLLI and other details must be entered into the TelcordiaTM Business Routing & Rating Database System (BIRRDS). Your company’s data can only be submitted to BIRRDS by an firm that has been issued an Administrative Operating Company Number (AOCN) by iconectiv. Your company can go through the process to get an AOCN or hire the services of a third party that has an AOCN. To find a list of AOCNs go to www.trainfo.com/products_services/tra/downloads/aocnlist.doc.
Step 7. Submit your code (LRN) to NPAC
As a registered NPAC user, enter your LRN into the NPAC Service Management System (SMS).
Step 8. Confirm Code is active in PAS
Within six months after receiving the code, confirm the code has been fully tested and is active by completing Part 4 of the Thousands Block Application Form in PAS. Only the active 1000 thousand blocks should be confirmed so the Pooling Administrator can reassign the unused 1000 blocks.