these materials are © 2017 john wiley & sons, inc. any ... · 26 session order controllers or...


Session Border Controllers

by Lawrence C. Miller

4th Sonus Special Edition


Session Border Controllers For Dummies®, 4th Sonus Special EditionPublished by John Wiley & Sons, Inc. 111 River Street Hoboken, NJ 07030‐5774 www.wiley.com

Copyright © 2017 by John Wiley & Sons, Inc.

No part of this publication may be reproduced, stored in a retrieval system or transmitted in any form or by any means, electronic, mechanical, photocopying, recording, scanning or otherwise, except as permitted under Sections 107 or 108 of the 1976 United States Copyright Act, without the prior written permission of the Publisher. Requests to the Publisher for permission should be addressed to the Permissions Department, John Wiley & Sons, Inc., 111 River Street, Hoboken, NJ 07030, (201) 748‐6011, fax (201) 748‐6008, or online at http://www.wiley.com/go/permissions.

Trademarks: Wiley, the Wiley logo, For Dummies, the Dummies Man logo, A Reference for the Rest of Us!, The Dummies Way, Dummies.com, Making Everything Easier, and related trade dress are trade-marks or registered trademarks of John Wiley & Sons, Inc. and/or its affiliates in the United States and other countries, and may not be used without written permission. Sonus and the Sonus logo are registered trademarks of Sonus. All other trademarks are the property of their respective owners. John Wiley & Sons, Inc., is not associated with any product or vendor mentioned in this book.

LIMIT OF LIABILITY/DISCLAIMER OF WARRANTY: THE PUBLISHER AND THE AUTHOR MAKE NO REPRESENTATIONS OR WARRANTIES WITH RESPECT TO THE ACCURACY OR COMPLETENESS OF THE CONTENTS OF THIS WORK AND SPECIFICALLY DISCLAIM ALL WARRANTIES, INCLUDING WITHOUT LIMITATION WARRANTIES OF FITNESS FOR A PARTICULAR PURPOSE. NO WARRANTY MAY BE CREATED OR EXTENDED BY SALES OR PROMOTIONAL MATERIALS. THE ADVICE AND STRATEGIES CONTAINED HEREIN MAY NOT BE SUITABLE FOR EVERY SITUATION. THIS WORK IS SOLD WITH THE UNDERSTANDING THAT THE PUBLISHER IS NOT ENGAGED IN RENDERING LEGAL, ACCOUNTING, OR OTHER PROFESSIONAL SERVICES. IF PROFESSIONAL ASSISTANCE IS REQUIRED, THE SERVICES OF A COMPETENT PROFESSIONAL PERSON SHOULD BE SOUGHT. NEITHER THE PUBLISHER NOR THE AUTHOR SHALL BE LIABLE FOR DAMAGES ARISING HEREFROM. THE FACT THAT AN ORGANIZATION OR WEBSITE IS REFERRED TO IN THIS WORK AS A CITATION AND/OR A POTENTIAL SOURCE OF FURTHER INFORMATION DOES NOT MEAN THAT THE AUTHOR OR THE PUBLISHER ENDORSES THE INFORMATION THE ORGANIZATION OR WEBSITE MAY PROVIDE OR RECOMMENDATIONS IT MAY MAKE. FURTHER, READERS SHOULD BE AWARE THAT INTERNET WEBSITES LISTED IN THIS WORK MAY HAVE CHANGED OR DISAPPEARED BETWEEN WHEN THIS WORK WAS WRITTEN AND WHEN IT IS READ.

For general information on our other products and services, or how to create a custom For Dummies book for your business or organization, please contact our Business Development Department in the U.S. at 877‐409‐4177, contact [email protected], or visit www.wiley.com/go/custompub. For information about licensing the For Dummies brand for products or services, contact BrandedRights&[email protected].

ISBN: 978‐1‐119‐39974‐2 (pbk); ISBN: 978‐1‐119‐39975‐9 (ebk)

Manufactured in the United States of America

10 9 8 7 6 5 4 3 2 1

Publisher’s AcknowledgmentsWe’re proud of this book and of the people who worked on it. Some of the people who helped bring this book to market include the following:

Project Editor: Carrie A. Burchfield

Acquisitions Editor: Katie Mohr

Editorial Manager: Rev Mengle

Business Development Representative: Sue Blessing

Key Sonus Contributor: Daniel Teichman

http://www.wiley.com

http://www.wiley.com/go/permissions

mailto:[email protected]

www.wiley.com/go/custompub

mailto:BrandedRights&[email protected]


Table of ContentsIntroduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1

About This Book ........................................................................ 1Foolish Assumptions ................................................................. 2Icons Used in This Book ............................................................ 2Beyond the Book ........................................................................ 2

Chapter 1: Protecting Real‐Time Communications with SBCs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3

Looking at the SBC’s Role ......................................................... 3Understanding the Need for SBCs ........................................... 5

Chapter 2: Identifying the Key Requirements of an SBC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9

Normalizing SIP .......................................................................... 9Transcoding Calls .................................................................... 10

HD voice .......................................................................... 11Bandwidth restrictions ................................................. 12

Dealing with NAT Traversal .................................................... 12Fax and Tone Detection .......................................................... 13Video Support........................................................................... 13Performance, Scalability, Resiliency ..................................... 14

Chapter 3: Virtualization and Cloud Optimization of the SBC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15

What’s a Virtual SBC? .............................................................. 15Knowing What to Look for in a Cloud‐Optimized SBC ........ 17

Chapter 4: Deploying SBCs for Different Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .23

Unified Communications ......................................................... 23Contact Center ......................................................................... 24Enterprise Connectivity .......................................................... 26Mobile ........................................................................................ 27IMS Networks ............................................................................ 28WebRTC..................................................................................... 28

Session Border Controllers For Dummies, 4th Sonus Special Edition iv


Chapter 5: Multimedia Matters . . . . . . . . . . . . . . . . . . . . .31Video Should “Just Work” ....................................................... 31Adding Value to Video with SBCs .......................................... 33

Session management ..................................................... 33Endpoint interoperability ............................................. 33

Chapter 6: Determining ROI and Value in an SBC . . . . .35Reducing Costs with Intelligent Policies ............................... 36Increasing Efficiency through a Single Point

of Management ..................................................................... 36Minimizing Costly Downtime with High Availability ........... 38Consolidating Multiple Functions in a Single Solution ........ 38Getting Real about Cost Savings with a Virtual SBC ............ 39

Chapter 7: Ten Reasons to Choose a Sonus SBC . . . . . .41Local Policy Configuration ...................................................... 41Networked Policy Management ............................................. 41Peak Performance .................................................................... 42High‐Scale Transcoding Support............................................ 42Robust Security ........................................................................ 42Advanced Media Support........................................................ 43Proven Track Record ............................................................... 43Interoperability ........................................................................ 43Seamless Scalability ................................................................. 44Virtual and Cloud Optimized .................................................. 44


Introduction

T oday’s real‐time communications (RTC) no longer just consists of voice calls, but now includes video conferenc-

ing, instant messaging, desktop sharing, team collaboration, and presence management. Making these different applica-tions work together seamlessly requires a signaling protocol, known as the Session Initiation Protocol (SIP), which is used to establish RTC sessions between parties.

As powerful as SIP is, it isn’t without challenges that include differences in implementation between vendors and the security issues involved when transporting data across the Internet. Session border controllers (SBCs) are designed to control RTC traversing an enterprise or service provider IP network. SBCs also handle all the signaling and media func-tions, such as interworking and translation required to make SIP work seamlessly.

About This BookSession Border Controllers For Dummies, 4th Sonus Special Edition, consists of seven short chapters that explore

✓ What SBCs are and why they’re needed to protect RTC (Chapter 1)

✓ What else an SBC does in an RTC network (Chapter 2)

✓ How a virtual, cloud‐optimized SBC can benefit enter-prises and service providers (Chapter 3)

✓ SBC use cases and real‐world deployment scenarios (Chapter 4)

✓ How video benefits from an SBC (Chapter 5)

✓ How to derive value from an SBC (Chapter 6)

✓ Why your organization needs a Sonus SBC (Chapter 7)

Session Border Controllers For Dummies, 4th Sonus Special Edition 2


Foolish AssumptionsIt’s been said that most assumptions have outlived their uselessness, but I assume a few things nonetheless! Mainly, I assume that you know a few things about RTC and network security. As such, this book is written primarily for technical readers — but I explain any technical concepts and spell out all those wonderful IT acronyms, just in case you’re a non‐technical reader looking to broaden your mind or become the center of the social universe to your coworkers.

Icons Used in This BookThroughout this book, I occasionally use special icons to call attention to important information. Here’s what to expect:

This icon points out information that you should commit to your non‐volatile memory — along with important dates.

This icon explains the jargon beneath the jargon and is the stuff legends — well, nerds — are made of.

The Tip icon points out a bit of information that aids in your understanding of a topic or provides a little extra information that may save you time, money, and a headache.

This information tells you to steer clear of things that may cost you big bucks, are time suckers, or are just bad SBC practices.

Beyond the BookI’m sure this book will give you a better understanding of SBCs, but if you’re left wanting more, visit the Sonus website at www.sonus.net where you can learn more about how Sonus’s expertise helps customers deploy, manage, and opti-mize their SBCs. If you want to talk to someone, instead of just looking at the website, please call 1‐855‐GO‐SONUS.

http://www.sonus.net


Protecting Real‐Time Communications with SBCsIn This Chapter

▶▶ Understanding the role of the SBC in real‐time communications

▶▶ Recognizing why enterprises and service providers need SBCs

R eal‐time communications (RTC) in modern businesses includes phone calls, video conferencing, chat, text mes-

saging, desktop sharing, and team collaboration. In this chapter, you learn how a session border controller (SBC) enables and secures enterprise and service provider RTC infrastructure.

Looking at the SBC’s RoleAn SBC secures and controls a Session Initiation Protocol (SIP) network by admitting (or not admitting) and then direct-ing communications between two end devices on the network, such as a Voice over Internet Protocol (VoIP) call between two phones or a video conference between multiple devices. SBCs are deployed at the network perimeter (or border), so they can control and secure real‐time communication ses-sions for both enterprises and service providers. An SBC per-forms the following functions:

✓ Securing the RTC network: An SBC protects and secures RTC from various threats such as spoofing, denial‐of‐ service (DoS) attacks, and toll fraud. The SBC secures RTC by

• Acting as a Back‐to‐Back User Agent (B2BUA), which allows the SBC to hide the topology of the internal IP network, making it difficult or impossible

Chapter 1



for bad actors to gain access to potentially vulner-able parts of the network

• Encryption of both the signaling and media to prevent communications from being illegally inter-cepted or tampered with as well as maintaining privacy

• Detecting and preventing DoS attacks before they impair network performance

• Enabling call admission control and dynamic black-listing of rogue endpoints to avoid threats such as telephony DoS (T‐DoS) and toll fraud

✓ Enabling SIP trunking: An SBC provides you with a demarcation or termination point of the SIP trunk con-nection into your communications network. An SBC provides the security, interoperability, and some of the intelligence (for example, where to route SIP calls) needed to safely connect SIP trunks with your network. The SIP service provider also needs an SBC on its side of the SIP trunk to protect its network. You can think of an SBC as a SIP firewall that includes a host of value‐added services like intelligent routing controls, signaling and media interworking, resiliency, and high quality of ser-vice between different network devices.

Typical savings from SIP trunking, trunking consolida-tion, and the move to VoIP and unified communications (UC) can reduce traditional enterprise telecom bills by up to 75 percent. Additionally, the SBC can provide secured access to SIP trunking services, so an enterprise can maintain security while saving money.

✓ Interconnecting and interworking networks and pro-tocols: An SBC provides a smooth experience in terms of interconnecting and interworking between different net-works and the protocols running over them. Specifically, the SBC performs tasks such as

• Dealing with SIP variants: SIP has a lot of variants based on different vendor implementations. An SBC can translate these variants between devices (a process known as SIP normalization, covered in more detail in Chapter 2) so calls get through with all their features intact.

Chapter 1: Protecting Real‐Time Communications with SBCs 5


• Translating protocols: Different UC solutions may utilize different audio codecs and other protocols that aren’t completely supported on both sides of the session. The SBC knows all these protocols and can translate between them on‐the‐fly.

✓ Acting as session traffic cop: The SBC is the gatekeeper to SIP‐based services in an enterprise or service provider network. In this role, SBCs perform session admission control, which is the process of determining who has access to the network. This makes the SBC the traffic cop of a SIP network, keeping your SIP highways safe and orderly and creating and accessing three lists: whitelists, blacklists, and greylists (discussed in the later section, “Understanding the Need for SBCs” in this chapter).

✓ Intelligent Routing and Policy Controls: In larger deployments, where multiple SBCs are installed at mul-tiple network borders, the task of individually configur-ing routing and policies on all SBCs can be tedious and expensive. An alternative to localized policy control is further centralization using a master policy server to automatically propagate a single set of routing and policy rules dynamically to each SBC on the network.

Understanding the Need for SBCs

SBCs were initially deployed within service provider net-works. SBCs ensure that

✓ RTC traffic is properly routed between network providers

✓ Differing protocols are understood so the call can be delivered across different networks

✓ Calls are secured

As VoIP adoption became more common in the enterprise, SBCs were increasingly deployed at the border between an enterprise’s network and the carrier’s network. The most talked about driver for deploying an SBC is security. 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 an enterprise or a network pro-vider. VoIP isn’t like traditional telephony in which a very highly circumscribed set of devices, protocols, and private networks are involved in the process of placing and carrying calls. In the old days when you placed a phone call, the call was placed on an approved device and carried across the pri-vate phone company network.

Like other IP applications, VoIP can be carried over public networks — often across several public networks — and calls can be initiated or completed on devices, such as personal computers (PCs) or smartphones, using VoIP applications that aren’t under the control and regulation of the phone company. This makes the VoIP world considerably more vul-nerable and broadens the attack surface to the same kinds of security threats as any other Internet service.

Some common VoIP attacks include

✓ Service theft and fraud: Attackers accessing a VoIP system to route traffic and use network resources with-out paying for them

✓ Spoofing: Deliberately modifying or disguising an iden-tity (for example, caller ID) on the network

✓ DoS/Distributed Denial‐of‐Service (DDoS) attacks: Flooding a server or SBC with requests to overwhelm its available resources

✓ Registration storms: Like a DDoS attack, in which many devices (typically hundreds of thousands to millions) simultaneously attempt to register with a SIP server in a UC network

An SBC employs various techniques to protect enterprises and service providers from cyberattacks against RTC net-works, including the following:

✓ Media and signaling encryption: Encryption prevents unauthorized parties from eavesdropping on real‐time communication sessions or tampering with a session. Encryption also provides an authentication mechanism to verify that a client is who it says it is. The signaling component of RTC is typically secured by Transport Layer Security (TLS) or Internet Protocol Security (IPsec), while the media layer is secured by Secure Real‐time Transport Protocol (SRTP).

Chapter 1: Protecting Real‐Time Communications with SBCs 7


✓ Dynamic pinholing: A pinhole is a port opened in a firewall to allow an application to access the IP network. Leaving a port open for an extended period can poten-tially enable a security breach. SBCs can create pinholes programmatically and leave them open for only the short period that a session is active to minimize security expo-sure. SBCs can then re‐open ports as needed for trusted applications to send and receive data.

✓ Topology hiding with B2BUA: A B2BUA system controls SIP calls by a 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 private IP addresses of servers and devices in the network. The net result is a network that’s easily acces-sible to clients for making and receiving calls, but the “innards” of the network are effectively invisible, which makes them less vulnerable to attack.

✓ List monitoring: The SBC’s policy management func-tion monitors incoming requests and calls, uses rules to identify people who are and aren’t abusing network resources, and maintains certain lists including

• 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

Alternatives to SBCs include virtual private network (VPN) tunnels and firewalls, but each of these alternatives have some disadvantages:

✓ VPN tunnels: A VPN can cause trouble when there’s a need to look inside the packets encapsulated in the VPN to route calls and provide services. VoIP packets must be decrypted and acted on — removing the end‐to‐end encryption element that keeps a VPN secure.

✓ Firewalls: A firewall can be configured to allow VoIP sessions to pass through the network to client devices within the network. The problem is that VoIP (and UC)



sessions are exceedingly dynamic. Sessions are set up and torn down frequently and in large numbers. Additional services are often added during the middle of a call (for example, when someone begins to instant message another user during a conference call, or when someone shares a picture or video during a voice call). Typically, a firewall just isn’t set up to handle this kind of dynamic service provisioning.

IPv6 is (finally) hereThe IP variant (IPv4) that has powered the Internet for as long as most of us can remember has an issue. IPv4 uses a 32‐bit address space, which means it’s limited to only about 4.3 billion addresses — and it just ran out of available addresses (not literally just now; it happened in 2015).

IPv6 increases the address space to 128 bits, which means that there are now 340,282,366,920,938,463,374,607, 431,768,211,456 possible addresses (that’s “340 undecillion, 282 decillion, 366 nonillion, 920 octillion, 938 septil-lion, 463 sextillion, 463 quintillion, 374 quadrillion, 607 trillion, 431 billion, 768 million, 211 thousand and 456” — seriously).

This, in turn, causes other issues. For example, not all networks can natively support IPv6. When two clients want to communicate and one is on an

IPv4 network and the other on IPv6, something needs to get in the middle and help them communicate. An SBC resolves these issues in two ways:

▶✓ An SBC can be dual stacked, meaning it contains the network stack software (the basic network protocol software suite) for both IPv4 and IPv6. The SBC can com-municate using both versions of IP and can connect to an IPv6‐only smartphone using IPv6 while con-necting to an IPv4 server using IPv4.

▶✓ The SBC can act as an interwork-ing agent between an IPv4 net-work and an IPv6 network. In this case, the SBC can translate all traffic flowing between an IPv4 and an IPv6 network on‐the‐fly, as it crosses the network border.


Identifying the Key Requirements of an SBC

In This Chapter▶▶ Understanding SIP and call transcoding

▶▶ Translating NAT traversal

▶▶ Learning the facts about fax and tone detection

▶▶ Supporting video

▶▶ Ensuring performance, scalability, and resiliency in an SBC

A session border controller (SBC) does much more than just security. In fact, many in the industry say that it’s

the security that gets customers interested, but it’s the other functionality in an SBC that makes the sale. This other func-tionality is all about SBCs making Voice over Internet Protocol (VoIP) calls and real‐time communications (RTC) sessions work in situations where they may otherwise not work and, beyond that, SBCs simply make VoIP and RTC services work better.

In this chapter, you find out about all the “other” essential functions of an SBC.

Normalizing SIPSession Initiation Protocol (SIP) is the primary protocol that establishes the connection between two endpoints and closes the connection when the call is finished. At the most basic level, SIP is the VoIP equivalent of the dialing tones that directed old‐fashioned analog calls to the right switches and

Chapter 2



across private phone networks. SIP is critical to the capability of disparate network topologies from different vendors to be able to communicate with each other.

SIP is a communications standard drafted by the Internet Engineering Task Force (IETF). The standard, however, is more of a series of recommendations and suggestions on how SIP should be implemented. The actual SIP implementations are left up to individual engineers and vendors, resulting in a multiplicity of SIP variations that are technically in compli-ance with the published SIP standards, but not necessarily interoperable with one another.

Enough variations exist in SIP that sometimes two systems connecting to each other using SIP find that they aren’t speak-ing the same language — the basics are all there, but with differing syntax and dialects in what otherwise appears to be a common language (kind of like American English versus British English). There’s just enough difference to cause con-fusion. When two people are talking, that confusion can be overcome by context or by a simple “huh?”. But when two devices are talking, that simply isn’t going to happen.

An SBC must be able to speak all the different dialects of SIP and do on‐the‐fly translations in both directions. So, if a call is crossing a border between a system using Dialect X and another system using Dialect Y, the SBC must 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.

Transcoding CallsAnother one of the SBC’s jobs is to transcode, or change, codecs as media sessions pass through the SBC. The SBC knows which codecs are supported on each side of the net-work border and is required, using a combination of software (CPU or GPU‐based) and/or 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 — the encode/decode algorithms that compress voice and other signals (like video streaming across the network in a videoconferencing environment) — are in use in

Chapter 2: Identifying the Key Requirements of an SBC 11


various VoIP and unified communications (UC) systems. Low‐ and high‐bandwidth video and voice codecs are designed differently to work on various devices, such as

✓ Computers and tablets

✓ Dedicated VoIP phones

✓ Mobile smartphones

In a VoIP call (or any real‐time, session‐based communication, for that matter), there are always differing capabilities to sup-port codecs. So, if an enterprise’s private branch exchange (PBX) switch supports one specific codec and an incoming call 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. Some codecs may simply not be implemented on a device for a mixture of reasons:

✓ The developers haven’t gotten around to it yet.

✓ The software licensing fee is too high.

✓ The device has a relatively “slow” CPU and can’t handle the codec computationally.

Transcoding in SBCs frequently comes into play in two spe-cific instances covered in this section.

HD voiceThe sound quality of voice calls in general took a step back-wards over the years as convenience (mobile) and econom-ics (VoIP) have caused a movement away from traditional landline phones. However, high‐definition (HD) voice has reversed that trend. HD voice can reproduce a greater range of frequencies at higher clarity (known as a wideband codec) than traditional narrowband codecs (so called because they cut off both the top and bottom frequencies normally found in a person’s voice).

There’s a gotcha to HD voice: There’s no single codec used by every HD voice‐capable system, but having an appropri-ate SBC in the middle of the call (one with robust transcoding capabilities) solves the problem. The SBC can transcode and keep the call HD all the way (but there’s a lot of software and hardware doing some heavy lifting behind the scenes).



Bandwidth restrictionsSometimes a call is made to someone who’s connected to a mobile network outside of not only 4G but also 3G coverage. Other times, a call is made to a person in a home office or a hotel with a limited Wi‐Fi connection. To address bandwidth restrictions, there are codecs available that trade fidelity and audio/video quality for greater compression — thereby using less bandwidth.

You may not want to default to these low‐fidelity codecs all the time, but sometimes they’re necessary over at least part of the call’s path. An SBC sitting between network segments can recognize this situation and transcode to and from lower bandwidth codecs when required. This situation is much better than relying on the VoIP clients themselves to do this kind of calculation upfront, especially because not all clients support all codecs.

Dealing with NAT TraversalNetwork Address Translation (NAT) converts a public IP address to a private, non‐routable IP address. NAT is used because there aren’t enough public IP addresses available in the world to assign every device its own unique IP address.

The newer version of IP that will eventually replace today’s current IPv4 is IPv6 (Internet Protocol version 6). IPv6 increases the number of available IP addresses and reduces the need for NAT. The gradual adoption of IPv6 is another reason to use an SBC, because the SBC has intelligence that enables IPv4 and IPv6 network segments to talk to each other. See Chapter 1 to find out more about IPv6.

The challenge with NAT is that creating an end‐to‐end session is difficult because the IP address of a device using NAT isn’t a public, routable IP address. This creates issues with end‐to‐end sessions, like VoIP, and requires some translation to happen between public and private addresses — translation beyond what a network router 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

Chapter 2: Identifying the Key Requirements of an SBC 13


NAT router and to the actual device that’s at the other end of the session. NAT traversal requires a significant amount of processing power in the SBC because of the large number of devices participating in VoIP and other sessions that are located behind a NAT gateway.

Fax and Tone DetectionLegacy technologies sometimes linger on well past their “sell by” date, and the network needs to support them. A promi-nent example is facsimile (fax) technology. IP faxing has been “the next big thing” for at least 15 years. But that doesn’t change the fact that there are still people out there using fax machines every single day of the week. VoIP systems would, if they could form opinions, probably be opposed to this, but the reality remains.

An SBC, however, can come to the rescue here by incorporat-ing tone detection (the ability to recognize and act on stan-dard analog telephone touch tones) to recognize and then properly route that awful screech of a fax preamble.

Video SupportBusinesses regularly conduct virtual meetings using voice, video streaming, and other rich‐media communication services. Still, some challenges remain:

✓ Intercompany communication: Enterprise routers and firewalls are vital for securing a network, but they often wreak havoc on video communications because they block all incoming calls and session requests, hide the IP addresses of internal devices, and degrade performance by inspecting packets that traverse the firewall. You can get around NAT and firewall‐related issues by deploy-ing a video‐friendly firewall or a video bridge with dual network ports, but each of these options potentially com-promises security and performance and adds cost and complexity.

✓ Interoperability issues: A wide range of video confer-encing standards exists, but despite these standards, interoperability issues still prevail due to different protocols (SIP, H.323) or video/audio compression



(H.264, H.263, G.722, and so on). Some other issues also include basic connectivity and interoperability with devices that provide a less than optimal experience due to call speed and device type.

An SBC can provide video proxy services, NAT/firewall ser-vices, protocol conversion and transcoding, Quality of Service (QoS) monitoring and more. SBCs can also perform protocol translation between SIP and H.323 as well as H.264, H.263, G.722, and many other video and audio protocols.

Performance, Scalability, Resiliency

SBCs need to be powerful and robust with extra capacity and redundancy to handle not only the average number of calls coming through the system simultaneously, but also to scale up and handle peak loads. When evaluating an SBC’s per-formance, scalability, and resiliency, consider the following factors:

✓ CPU utilization: The SBC does a lot of computationally complex work, such as SIP translation, intelligent routing, centralized call recording (SIPREC), and other functions in real time; CPU utilization during both normal and peak periods should allow plenty of overhead.

✓ Concurrent calls (or sessions) supported: How many concurrent calls is the SBC rated for and how does this match your network’s usage patterns? If your usage grows and begins to exceed the capacity of your SBC, what are your upgrade options?

✓ Redundancy: Put a different way, this means “avoiding single points of failure.” SBCs perform a mission‐critical role for enterprises and service providers.

✓ Registration rate: How many clients can the SBC register in a fixed period? When a lot of users are connecting at once, make sure the SBC can handle it.

✓ QoS policies: The QoS policy of a network and priori-tization of data flow is implemented by the SBC. Often QoS policies perform such functions as traffic policing, resource allocation, rate limiting, call admission control (CAC), and others.


Virtualization and Cloud Optimization of the SBC

In This Chapter▶▶ Defining the virtual SBC

▶▶ Recognizing the key functions and benefits of a cloud‐optimized SBC

I n this chapter, you learn how virtualization and cloud optimization works and how your organization can benefit

from a virtualized or cloud‐optimized session border control-ler (SBC).

What’s a Virtual SBC?Virtualization technology abstracts software (such as an oper-ating system and installed applications) from the underlying physical hardware on which it is running. Server virtualization is perhaps the most well‐known and widely implemented vir-tualization technology. But wait, there’s more! Other common types of virtualization include

✓ Application virtualization

✓ Desktop virtualization

✓ Storage virtualization

✓ Network virtualization

Communications systems can also leverage virtualization technology. Network Functions Virtualization (NFV) helps design, deploy, and manage network services by separating network functions from hardware devices, so they can run in

Chapter 3



software. This process removes the need for you to purchase dedicated hardware such as routers, firewalls, and — SBCs, among others.

A virtual SBC is an SBC implemented entirely in software, that can be deployed on commercial, off‐the‐shelf servers. In many cases, the core of the SBC software is the same code that executes in a hardware‐based SBC. Because the SBC is implemented in software, it can be easily deployed on virtual machines in an on‐premises data center, or in a private or public cloud.

Some of the benefits of virtualization (and cloud optimization) include

✓ Efficient resource utilization: Before virtualization, many data centers used about 10 percent of their total capacity, meaning that nearly 90 percent of their capac-ity went unused. Virtualization enables organizations to run multiple virtual workloads on a physical host server, to maximize the utilization of resources for compute, memory, and storage purposes.

✓ Reduced operating expenses: The cost of rack space, power, cooling, and network connectivity in a data center is incrementally higher for each physical server, device, or appliance that is deployed. Virtualization enables SBCs and/or other applications or network functions to be deployed on a single physical server, thereby reduc-ing costs to the organization.

✓ Low total cost of ownership (TCO): Virtual, cloud‐optimized SBCs provide a much lower TCO than hardware‐based SBCs because they run on less expensive off‐the‐shelf server hardware. Virtual, cloud‐optimized SBCs also support a “pay as you grow” model, meaning businesses don’t have the inefficient costs of providing system capacity that isn’t yet needed.

✓ Faster time to market: Virtual, cloud‐optimized SBCs allow service providers to deploy new network services very quickly to support changing requirements and seize market opportunities as they arise. This flexibility also reduces risks associated with rolling out new services, as they can easily try out and modify new service offerings to meet the needs of their customers.

Chapter 3: Virtualization and Cloud Optimization of the SBC 17


✓ Greater agility: Service providers must be able to quickly scale their services up or down to meet changing market demands. They also need to innovate quickly and get those innovations to market as quickly and easily as possible. Virtual, cloud‐optimized SBCs allow for services to be delivered to customers in the cloud.

Knowing What to Look for in a Cloud‐Optimized SBC

Virtualization is a key enabling technology for Cloud, but to truly leverage Cloud means going beyond virtualization. A cloud‐optimized SBC enables

✓ Automated, rapid provisioning

✓ Elasticity or auto‐scaling on demand

✓ Efficient and reliable resource allocation

✓ Performance at scale

✓ The integration of analytics into decision making processes

✓ Flexible licensing models

✓ True orchestration and service chaining of Virtual Network Functions

When choosing a cloud‐optimized SBC, look for the following important capabilities and features:

✓ Run‐time ready instantiation: Deploying real‐time com-munications (RTC) in the cloud requires the ability to instantiate a virtual SBC as rapidly as the real‐time ser-vice itself. To achieve this level of responsiveness, the SBC needs to be run‐time ready instantiated, which is accomplished through the following two functions:

• Automatic registration: When an SBC Virtualized Network Function (VNF) is instantiated by either the Virtual Network Functions Manager (VNFM) or an OpenStack Heat Orchestration Template, it will show up within the management domain and will automatically receive its IP networking information,



such as network interface IPs, default gateways, and domain name server (DNS) IP addresses.

• Automatic configuration: This is done through a configuration catalog, where specific SBC VNF configurations are pre‐associated with a given SBC cluster. When an SBC VNF is instantiated within a given cluster, it’s provided the name of its configu-ration object and the parameters necessary for communicating with the configuration catalog. As part of the boot‐up process, the SBC automatically receives the appropriate configuration from the configuration catalog.

The result of being “run‐time ready” is service veloc-ity with operational efficiency, because it is possible to instantiate a running, configured SBC that is immediately capable of call processing without requiring operator intervention.

✓ Elasticity (auto‐scaling): The advantage of a cloud environment is the ease, the speed, and ultimately the cost‐effectiveness with which a virtual SBC can be auto‐scaled. With the ability to instantiate VNFs on‐demand, it becomes possible to match SBC sizing with actual demand, scaling up when load increases and scaling down when load subsides. This rapid scale‐up/scale‐down functionality is the very essence of elasticity.

Achieving elasticity also means that instantiation of a SBC VNF needs to be flexible enough to optimize both horizontal (adding more virtual instances) and vertical (adding more sessions within a virtual instance) scaling.

✓ Optimal load balancing: A virtual, cloud‐based SBC VNF is really a cluster of SBC VNF instances, where VNF instances are automatically added or removed based on traffic load. Load balancing is the mechanism that optimizes resource utilization, making sure it’s evenly balanced across multiple instances in alignment with this dynamic traffic load. With load balancing, variances in traffic are optimized across aggregate capacity, solution resiliency is increased by avoiding server overload situ-ations that could potentially cause processing failures, or by providing rebalancing of traffic in the event an instance has an outage.



Multiple load balancing methods exist, but for an SBC, load balancing must have knowledge of session per-sistence and the performance status of each virtual instance. More traditional methods like DNS‐based load balancing or even Session Initiation Protocol (SIP)‐aware front end load balancing can be used, but they aren’t optimal because they have issues with encrypted ses-sions, symmetric Network Address and Port Translation (NAPT), or possible uneven distribution of load immedi-ately after scale‐out.

✓ Resiliency and high availability: Certain attributes of an SBC are considered table stakes for deployment. Resiliency and high availability (HA) fit this designation. The goal of a virtual, cloud‐based deployment would be to replicate the fault tolerance that’s found in more traditional hardware appliance deployments. In addi-tion to the resiliency benefits of optimal load balancing described in the preceding bullet, a high availability implementation is also needed to be able to maintain ses-sion and media continuity in the event of the failure of a virtual SBC.

Most public cloud environments serve web‐based appli-cations, so the most commonly used HA solution is the floating IP address. While this works well for web‐based applications, it doesn’t meet the stringent requirements of RTC. A floating IP address solution provides failover within seconds, but in that duration of time, media con-tinuity is lost, which is unacceptable. Instead, a high availability solution based on the OpenStack Allowable Address pair construct extends the port attribute to enable the specification of arbitrary Media Access Control (MAC) address/IP address pairs allowed to pass through a port, regardless of the subnet associated with the network.

In practical terms, this means traffic can be sent directly to both a primary and secondary SBC VNF, enabling fast data plane failover, thus providing an HA solution that works for SBC signaling and media requirements.

✓ Performance at scale: Performance at scale gets to the very heart of how an ideal SBC is designed and why moving SBCs to the cloud is a viable deployment model versus using traditional, proprietary hardware appli-ances. Performance at scale is possible when SBC func-tions can be independently allocated to processors.



Turning on feature capabilities like encryption, inter-working for IPv4 to IPv6 or Real‐time Transport Protocol (RTP) to Secure RTP (SRTP), and SIP header manipula-tion have no impact on session performance. It also means the SBC is capable of handling sustained denial‐of‐service (DoS) attacks or registration floods without nega-tive impact on performance or call quality.

When extending this to the cloud deployment model, the adoption of a microservices architecture is the optimal way to deliver performance at scale. With a microser-vices architecture, the SBC breaks out “functions” or specific tasks into separate virtual instances. These discrete instances, when taken together, function as an SBC, yet they still allow optimization of each function. For example, the call control function scales based on the call rates/calls per second, which is a different measure than how the transcoding service needs to be optimized based on use case, such as access versus interconnection SBCs.

✓ Integrated analytics: A virtual SBC needs to provide two essential functions related to analytics. The first is a critical feedback loop of traffic utilization data needed to properly manage the VNF instantiation. The second is the key data needed for monitoring and troubleshooting both the RTC application and the virtual SBC itself.

Integrated analytics begins with a data agent running with the SBC VNF to forward resource and traffic utilization metrics to a VNFM or a service orchestration system. With these metrics, it’s possible to know when, or why, to create or tear down an SBC VNF. This feedback loop enables on‐demand elasticity. However, resource utilization statistics are not only for use by the VNFM/service orchestration. Real‐time measurement of resource utilization for each SBC VNF instance is also used for load balancing within a cluster of SBC VNF instances.

Application and VNF metrics are also used for monitoring and troubleshooting. Information traditionally captured in event logs, Call/Session Detail Records, trace logs, and telemetry are all valuable inputs for monitoring an appli-cation or platform troubleshooting.

Being able to fit virtual SBCs into business support systems (BSS) and operations support systems (OSS) solutions is a critical requirement to successfully deploy cloud‐optimized SBCs.



✓ Network‐wide licensing: A traditional node‐based licens-ing model that was appropriate for appliance‐based SBCs isn’t viable in a virtual, cloud deployment.

For a cloud deployment, where SBC VNFs are dynami-cally allocated, a new licensing model is required. This is because licensing needs to align with the dynamic real‐time aspect of being assignable across multiple SBC instances. By extension, in a cloud deployment, these licenses need to be available on a network‐wide basis, since virtual SBC instances remove the construct of a license tied to a physical device or location.

✓ Integration with service orchestration ecosystem: Although service providers could choose to implement and orchestrate multiple VNFs from a single supplier, in most situations, service orchestration will involve ser-vice chaining of multiple services from multiple suppli-ers. A significant reason to move to virtual cloud‐based solutions is to break away from single‐vendor solutions and take advantage of multiple vendors to deliver best‐in‐class solutions.

As outlined by the European Telecommunications Standards Institute (ETSI) NFV Management and Orchestration (MANO) working group, there are three functional blocks:

• NFV Orchestrator: Responsible for network ser-vices, global resource management, and overall VNF life cycle management

• VNFM: Oversees life cycle management of VNF instances, as well as coordination and adaptation for configuration and event reporting between NFV Infrastructure and Element/Network Management Software (E/NMS)

• Virtualized Infrastructure Manager (VIM): Controls and manages the NFVI compute, storage, and network resources

This framework is built around the concept of applica-tion programming interfaces (APIs) and templates for configuration of VNFs, yet it also requires a great deal of interoperability testing and verification to ensure multi‐vendor deployment.


Deploying SBCs for Different Use Cases

In This Chapter▶▶ Supporting unified communications

▶▶ Improving the customer experience in contact centers

▶▶ Connecting the enterprise

▶▶ Securing mobile communications

▶▶ Enabling WebRTC

S ession border controllers (SBCs) play a role in many different types of environments and configurations such

as unified communications (UC), contact centers, Session Initiation Protocol (SIP) trunking, mobile and IP Multimedia Subsystem (IMS) networks, and interworking with Web Real‐Time Communications (WebRTC). In this chapter, you discover the unique requirements and challenges for each of these use cases.

Unified CommunicationsGone are the days when enterprise communications meant a private branch exchange (PBX) switch (you can find more info on PBX in Chapter 2) and a phone on every employee’s desk. Today’s employees want it all — voice, video, instant messag-ing, and web‐based apps — and they want it wherever they are on whatever device they choose. The world is a mobile one, and enterprises need to harness the power of UC and the flexibility of Bring Your Own Device (BYOD) policies to increase employee productivity, reduce costs, and improve customer service.

Chapter 4



CIOs are looking to UC and cloud‐based services to meet the rising demand for real‐time communications (RTC), yet a fun-damental barrier to UC adoption is a lack of interoperability between the vendor‐specific voice, video, and messaging sys-tems that exist in most enterprise networks.

While SIP was meant to break down many of those barri-ers, even SIP‐based systems face their own issues and often require significant interworking and transcoding to provide acceptable levels of interoperability. Thus, most enterprises fall short of a truly unified model of communications and collaboration. Such a model allows users to consistently con-sume rich media services regardless of the underlying PBX, application server, or end‐user device.

The road to UC has been paved with wasted time and money: time spent on long service engagements and endless interop-erability testing, and money spent on PBX upgrades and new equipment. But an SBC can provide a session management framework (in addition to providing security) for UC and SIP communications that coordinates PBXs, video services, business collaboration tools, and a wide variety of IP devices (smartphones, tablets, and so on), so enterprises can more easily integrate and create a true UC environment.

As you move more services and applications into the cloud, the SBC‐based session management framework unifies cloud‐based services with your on‐premises based enterprise com-munications to ensure a rich, easy‐to‐manage UC experience.

Contact CenterThe contact center is vital to the success of many businesses because in a competitive marketplace, high‐quality customer service is essential. The contact center has evolved from simply a call center where customer service agents take voice calls, to a full‐fledged contact center where agents handle voice, e‐mail, chat, text messages, and video calls. Contact center efficiency is crucial to customer experience, so agent productivity and quality control are increasingly important. The SBC can add value in these areas:

✓ Call recording: Contact center managers use call record-ing as both an evaluation and training tool to ensure

Chapter 4: Deploying SBCs for Different Use Cases 25


contact center agents provide the utmost quality in cus-tomer service. In many cases, government regulations require calls to be recorded for legal reasons and con-sumer protection as well.

Traditionally, call recording in communications net-works was done by consuming an extra data port on a switch to replicate the call data to the recording system. Consuming an extra data port to record calls doesn’t scale well in many contact centers that need to record each call that comes into the system. The SBC simply replicates the SIP session for the call to send the call data to the recording system, providing reliable data transfer and freeing up data ports to allow more incoming calls from customers.

✓ Remote agents: Remote or “work at home” agents enable contact centers to be flexible and scale up or down as business requires, without the added expense of office space and facility expansion. Consider, for example, a retailer that sees dramatically higher sales during the holiday season. This retailer can add temporary remote agents to handle peak demand periods. Mobile technol-ogy allows workers to work out of their homes with flexible hours, making this arrangement appealing to workers.

Remote agent configurations do, however, present some challenges for the contact center. Contact centers require a scalable solution in which devices don’t need to be configured and agents don’t need to use a virtual private network (VPN, see Chapter 1). Security is also a very important factor with remote agent configurations because sensitive customer data is exchanged over the network during these interactions. An SBC eliminates the need for a VPN with IP phones, yet still provides the nec-essary security (see Chapter 1).

✓ Internal transfers: In many cases, calls need to be transferred to a different agent in another contact center within the organization. This can often lead to higher costs and increased security risks if these transfers must traverse public networks. SBCs can identify internal transfers and route the call appropriately to ensure it stays on the private network, avoiding additional costs and security risks inherent with traversing public networks.



One case to consider is a video kiosk in a store where a customer can make a video call to ask for assistance that is routed from a contact center to a remote agent. In a non‐SBC environment this setup is complicated because both voice and video data could travel across multiple networks, requiring each border traversal to be secured. An SBC provides the necessary security, call routing, and load balancing features to make this type of transfer secure and cost efficient.

Enterprise ConnectivitySBCs in the enterprise have gained renewed interest as busi-nesses replace their existing time‐division multiplexing (TDM) based systems with SIP‐based UC platforms for telephony, instant messages, presence, and video conferencing applica-tions. For the enterprise, an SBC is the first line of defense in the UC system providing cost‐effective and secure connec-tions to enterprise networks and branch offices. In addition, enterprises in various industries must comply with regulatory requirements such as the U.S. Health Insurance Portability and Accountability Act (HIPAA), and industry standards such as the Payment Card Industry’s Data Security Standards (PCI DSS). Enterprises must maintain the highest levels of security to protect their customers’ information and maintain regula-tory compliance.

Many companies also have branch offices and a mobile or virtual workforce that add to the requirement for reliable and secure communications. In all these areas, there’s a role for the SBC.

In the enterprise, SBCs perform connectivity, Quality of Service (QoS), prioritization of emergency 911 call routing, and call recording and accounting. SBCs also provide gate-way, VoIP mediation, access to public switched telephone net-works (PSTNs), and survivability features for the enterprise. The SBC is the secure boundary between the enterprise and service provider networks.

SBCs in the enterprise can be configured with various deployment options. SBCs can be hardware appliances or software‐only virtual machines, enabling deployment in a data center or in private or public clouds.



MobileRTC has changed rapidly from home and office phones to mobile smartphones. An increasing number of homes no longer have landline phones, and a growing number of busi-nesses are replacing their landline phones and even IP phones with mobile devices.

The proliferation of mobile devices introduces some new scalability and security challenges into an RTC architecture. From a scalability standpoint, there are concerns related to the volatility and growth of video traffic over the mobile net-work. Also, there are challenges for mobile operators associ-ated with the increased signaling impacts of these devices and messaging and presence applications that are common to these devices. A design challenge for the SBC is the impact of mobile devices on the signaling plane of the SBC. Mobile sessions are typically shorter in duration than other device sessions, but the signaling requirements of these devices translate into more concurrent sessions straining the SBC.

In many countries, mobile data communications are carried on systems supporting the 4G Long‐Term Evolution (LTE) standard. These systems allow for the latest in high‐speed data for mobile phones and other mobile devices for stream-ing voice calls, video, and data from social media and stream-ing services (such as Pandora or Spotify).

The LTE standard only supports IP packet switching, mean-ing that network links are shared by packets from multiple communications sessions. Older mobile phone standards such as Global System for Mobile communication (GSM), Universal Mobile Telecommunications Service (UMTS), and Code‐Division Multiple Access (CDMA2000) work on circuit‐switched networks, meaning that a dedicated network chan-nel from sender to receiver is maintained throughout the duration of the call. So how do mobile carriers re‐engineer their voice networks to take advantage of LTE? The mobile phone industry standards have settled on the approach of using Voice over LTE (VoLTE) for delivering voice as a data stream within the LTE data transmission. This approach is based on the IP Multimedia Subsystem (IMS) which provides for both voice and data transmission.



IMS NetworksThe IP Multimedia Subsystem (IMS) is an integrated frame-work for telecommunications providers to deliver voice, video, and data using the IP protocol. In recent years, the widespread deployment of LTE networks has revived the interest in IMS because VoLTE standards are based on using IMS for providing voice services over LTE networks. IMS doesn’t contain an SBC in its architecture, but many IMS func-tions are already inherent in SBCs.

Even though IMS standards such as 3rd Generation Partnership Project (3GPP) don’t include an SBC component, SBCs perform many of the following functions:

✓ Proxy‐Call Session Control Function (P‐CSCF): The entry point into the IMS subsystem from user endpoints. An SBC integrates the P‐CSCF with the Access Border Gateway Function (A‐BGF) to handle the media and sig-naling data appropriately. The SBC provides capabilities such as Network Address Translation (NAT)/firewall traversal, user identity privacy, encryption, and policy management.

✓ Access Transfer Control Function (ATCF) and Access Transfer Gateway (ATGW): The ATCF and ATGW func-tions ensure that the handoff of the call doesn’t intro-duce an unacceptable interruption of media flow.

✓ Interconnect Border Control/Gateway Function (I‐BCF/I‐BGF): Handles the signaling and media of calls. An interconnect SBC performs functions such as network topology hiding, monitoring and lawful intercept, routing of signaling into the core of the IMS, and policy manage-ment on a per‐trunk basis.

WebRTCWebRTC is a new technology that lets you use phone, video, or text right from a web page. You can also share screens (see the same web pages or files) and all sorts of things. The SBC plays an important role in WebRTC including



✓ Enterprise security: Because WebRTC applications run in a browser and will likely transmit application data across the Internet, there is a risk of attacks on enterprise servers. Consider a case where a customer initiates a cus-tomer support call from a WebRTC‐enabled web page. The SBC can secure the SIP network in the contact center by being placed between the WebRTC application server and the SIP network at the contact center. The SBC can also provide session control and management between the WebRTC server and the SIP server at the contact center.

✓ VoIP phone calls: In this scenario, consider a VoIP call from a WebRTC‐enabled web page to a VoIP phone. The SBC provides

• Security between the WebRTC application server and the SIP network, as well as session control

• Transcoding between Opus (the default codec for WebRTC) and G.729 telephony protocols, for example

✓ PSTN phone calls: In this scenario, consider a call from a WebRTC‐enabled web page to a landline phone on a PSTN. The SBC provides

• Security between the WebRTC application server and the TDM gateway

• Transcoding and internetworking between the WebRTC application server and the TDM network

✓ Video support: Consider a WebRTC‐enabled web page initiating a video chat with a non‐WebRTC‐enabled IP video phone. The SBC provides

• Transcoding between the VP8 and H.264 video con-ference codecs between the WebRTC application server and the IP video phone

• Protocol internetworking between IPv6 and IPv4 and Secure Real‐time Transport Protocol (SRTP) and Real‐time Transport Protocol (RTP) for video media transfer

• QoS and policy control, ensuring the real‐time media data get network priority

✓ Lawful intercept: The SBC supports lawful intercept of both signaling and media data transferred between the WebRTC server and the destination IP phone.


Multimedia MattersIn This Chapter

▶▶ Meeting customers’ video network requirements

▶▶ Deriving business value from SBCs in your video network

F rom the boardroom to the browser, video and audio con-ferencing have become essential elements of everyday

business communications for an increasingly mobile workforce. As business users move beyond simple voice calls to more sophisticated forms of real‐time communications (RTC), your Session Initiation Protocol (SIP) network needs to handle more than just audio and its related audio codecs (see Chapter 2).

In this chapter, you discover what businesses need to make their video and audio systems “just work,” the IT challenges that video and audio requirements bring, and how session border controllers (SBCs) provide a cost‐effective solution to these challenges.

Video Should “Just Work”Business users regularly collaborate with their colleagues, customers, and partners using video and audio communica-tions. Today’s smartphones and tablets have high‐resolution video screens that can send and receive high‐quality video over Wi‐Fi or 4G Long‐Term Evolution (LTE) mobile networks, and users expect their video and audio conferences to work flawlessly, without jitter or distortion. But making video and audio “just work” can be a real challenge. For example:

✓ Popular desktop communications applications like Microsoft Skype for Business and Cisco Jabber use different signaling protocols, so they need some translation to talk to each other.

Chapter 5



✓ Video meetings with people outside of an organization require video and audio traffic to pass through the orga-nization’s firewall to ensure the session can’t be inter-cepted by an attacker.

✓ A remote user or customer on a smartphone must pass video and audio traffic across the public Internet and through a firewall, which must then be routed to the cor-rect party in the organization.

✓ Geographically dispersed teams that collaborate over video can potentially flood the network with their video streams. Functions like call admission and bandwidth control are needed to ensure a quality experience — even with limited bandwidth capacity.

An SBC addresses these challenges to give businesses high‐quality conferences that just work. Video and audio systems have up to five components that are often designed as sepa-rate devices or servers, but that doesn’t always have to be the case. In a simple video system, for example, in which all the video endpoints use the same protocols and compression/decompression algorithms (codecs), only two components are required: a multi‐point contact unit (MCU) and a gate-keeper or SIP proxy.

Think of the MCU as a funnel that takes in all the video from the participants’ cameras and combines them into one video stream that is sent back to them. The gatekeeper or SIP proxy is like a traffic cop that makes sure all endpoints in the ses-sion are connected and handles requests (for example, to let new participants join and others hang up and leave a session).

This example of a simple video system works well when all the endpoints use the same protocols, but what happens if the call must pass through a network firewall or one of the endpoints uses a different protocol? You can configure firewall rules to allow traffic to pass through, but this can compromise security. In any case, the simple video system breaks down when you have devices with different protocols and the video traffic must pass through a Network Address Translation (NAT) gateway or network firewall.

In real‐world video systems, two additional video infrastruc-ture components working in parallel — firewalls and SBCs — are crucial. Firewalls handle normal IP traffic, while SBCs handle RTC traffic. SBCs understand media protocols and can

Chapter 5: Multimedia Matters 33


work side‐by‐side with firewalls. You can think of an SBC as an RTC firewall that makes a video system work securely and efficiently.

Adding Value to Video with SBCs

SBCs sit at the edge of a network and work as a boundary point on the network between endpoints on the trusted net-work and endpoints on an untrusted network (such as the Internet). SBCs provide session control and security whether the sessions are inside the trusted network or not. SBCs pro-vide several benefits to make the system “just work.”

Session managementThe SBC is the ideal element in a complex network to enforce call admission control (CAC) on a session‐by‐session basis. The SBC can perform CAC for multiple unified communica-tions (UC) and video devices. SBCs can perform QoS priori-tization (discussed in Chapter 2) to ensure audio and video traffic passes through the network as efficiently as possible. CAC helps to provide an optimal end‐user experience by regu-lating the number of endpoints allowed on the network and making sure there’s enough bandwidth for each video and audio stream.

Endpoint interoperabilityMany organizations have deployed communication endpoints created by different manufacturers or software developed by different vendors, such as Cisco Jabber and Microsoft Skype for Business. Different video systems may support different video codecs, so the SBC must be able negotiate with each device so the same video codec is used, thereby ensuring interoperability between devices.

Even if all the endpoints in a video call use the same video codec, the SIP protocol implementations used by Cisco, Microsoft, Avaya, Polycom, and others differ enough to require a translation device to make sure the signaling works to connect to all the devices.



SBCs solve this problem by modifying the signaling infor-mation contained in the SIP packets so that endpoints can communicate with each other through a process known as protocol normalization. Protocol normalization allows orga-nizations to keep their hardware and software investments, while making video solutions from different vendors work together so they don’t have to get all their network compo-nents from a single vendor.


Determining ROI and Value in an SBC

In This Chapter▶▶ Getting smart with intelligent routing policies

▶▶ Managing policies from a single pane of glass

▶▶ Keeping your critical systems up, to keep revenues and productivity up

▶▶ Doing more with less (devices)

▶▶ Leveraging virtualization and cloud‐optimization to lower costs

Y ou’re all hyped up. You’ve done all your research, and you know the benefits (Chapter 1) and services

(Chapter 2) you can get from a session border controller (SBC). Now it’s time to pitch the investment to your CFO (also known as your CF‐“No”).

While an SBC doesn’t require a massive investment, if your CFO sees a new item in your budget, he’s going to want some serious justification. You need to be prepared to demonstrate a return on investment (ROI) and the value of an SBC for your organization. In this chapter, I help you teach your CFO a new word: “Yes” — because while SBC means “session border controller” to you, it’ll mean “savings beyond compare” to your CFO!

Chapter 6



Reducing Costs with Intelligent Policies

The robust policy engine in an SBC enables enterprises and service providers to implement intelligent routing policies that can save millions of dollars annually in toll charges, for example, by routing calls based on least‐cost network paths, as well as avoiding transferring calls to external public net-works, whenever possible.

SBCs can also provide centralized policy control, so routing and policy changes can be delivered globally across multi‐vendor networks from a single management point. These policy engine capabilities enable organizations to implement and manage hundreds of policies, such as

✓ Intelligent call routing

✓ Custom dialing plans

✓ Call blocking and screening

✓ Emergency call routing

✓ Local number portability lookups

✓ Calling name delivery

Increasing Efficiency through a Single Point of Management

Localized policy management (see Chapter 3) in an SBC enables organizations to efficiently manage VoIP policies and media/signaling at a single point in your network — right at the network perimeter on the SBC. This means that you spend less time and money managing multiple devices like routers, firewalls, and transcoders.

If you have a large network — or if your network grows over time — you can further simplify SBC management with a centralized policy server. In this scenario, you perform your initial configuration and any future policy changes one time in one place — on the master policy server. Your changes are automatically distributed across the network to all your SBCs.

Chapter 6: Determining ROI and Value in an SBC 37


(continued)

Flying high with Sonus SBCsA U.S.‐based, international airline maintains a global call center to deal with reservations, rewards programs, flight changes, seating assignments, and other business‐critical calls. The airline also sup-ports numerous voice applications for maintenance and support teams, ground support (baggage, fueling, and so on), logistics, in‐cockpit and paging systems, airport ticket coun-ters, a highly mobile workforce, and even airport courtesy phones.

Challenges

The airline faced functional and expense‐related issues with its leg-acy telecommunications systems. Specifically, the airline needed to

▶✓ Move to an all‐IP voice infra-structure without discarding its installed base of legacy equipment

▶✓ Reduce costs

▶✓ Improve employee productivity

▶✓ Maintain voice security

▶✓ Improve customer experience across a variety of real‐time communications (RTC) applica-tions and devices

The legacy voice systems — time‐division multiplexing (TDM) private branch exchanges (PBXs) — and

circuit‐switched integrated services digital network (ISDN) primary rate interface (PRI) voice circuits were migrated to IP PBX and Session Initiation Protocol (SIP) trunking to reduce voice costs while still lever-aging their installed equipment base. At the same time, the airline wanted to centralize control of its voice communications to provide load balancing and least‐cost routing for inbound Interactive Voice Response (IVR) calls from customers.

Solution

The airline installed Sonus SBCs and a Sonus Policy Server. The SBC and policy server addressed several issues:

▶✓ Interoperability between legacy TDM and H.323 voice systems and SIP trunking

▶✓ Centralized call control and routing

▶✓ Secure access for both on‐campus and remote call center agents and mobile employees

Results

The airline achieved dramatic results with the Sonus solution, including

▶✓ Reduced call costs

▶✓ Least‐cost routing for all calls



Minimizing Costly Downtime with High Availability

Whether due to lost productivity or lost revenue, downtime of business‐critical systems — such as your RTC — is costly.

A robust, highly available solution is designed with redundant components to eliminate single points of failure in a critical system or network, providing available capacity during peak loads and seamless failover capability when a critical com-ponent inevitably fails. A well‐designed SBC architecture can seamlessly recover and has the capacity to restore its state and handle a potential flood of VoIP client re‐registrations when the network is restored.

A redundant, high‐availability architecture is important regardless of whether your SBCs (and other components) are hardware‐based, virtual, or cloud‐based.

Consolidating Multiple Functions in a Single Solution

Say you wanted all the features and benefits of an SBC, but you decided to build it yourself. You’d need to cobble together various firewalls, routers, servers, gateways, and switches to individually handle all the security, SIP transla-tion, media transcoding/transrating, and call admission control (CAC) functions that an SBC provides. But if you consolidated all that functionality into a single solution – the SBC — you’d realize significant cost savings, including

(continued)

▶✓ Keeping internal calls on the air-line’s multiprotocol label switch-ing (MPLS) network instead of a carrier’s network

▶✓ Reduced network operating expenses

▶✓ Lower capital expenditures

▶✓ Improved uptime and reliability for the call center

▶✓ Secure connectivity for remote workers and home‐based call center employees

Chapter 6: Determining ROI and Value in an SBC 39


✓ Reduced capital expenditures (CAPEX): Simply put, you have fewer things to buy. For those network elements that you need for other functionality, you don’t need to overbuild/over‐specify them to allow capacity for the SBC functionality that is handled elsewhere.

✓ Lower operating expenses (OPEX): You can save money on recurring expenses such as rack space, power, and cooling with a complete SBC solution — whether physi-cal or virtual — compared to multiple devices installed in your data center or telecom equipment room.

You’ll have your CF‐“No” foaming at the mouth and itching to write you a check when you explain that the choice of an SBC is a classic “buy or build” scenario that reduces CAPEX and lowers OPEX.

Getting Real about Cost Savings with a Virtual SBC

A virtual SBC can be a significant cost saver for a business by allowing you to use common server infrastructure to scale your SBC capacity up or down without adding proprietary hardware or requiring additional rack space, power, and cool-ing. In addition, virtual SBCs can be provisioned and config-ured via a software download, providing ease of configuration and deployment to remote locations or data centers, cus-tomer sites, or in the public cloud.

(continued)

Shopping for an SBC solutionA U.S.‐based retail chain needed to consolidate its voice management into a centralized system while migrating from legacy circuit‐switched TDM to SIP trunking to reduce costs. Additionally, the

retailer had specific functionality and security requirements associated with the Payment Card Industry’s Data Security Standards (PCI DSS), requiring functionality not available in all SBC solutions.



(continued)

Challenges

The retailer’s requirements included the following:

▶✓ Saving money with SIP trunking

▶✓ A centralized policy and call routing control for all stores

▶✓ A rapid roll‐out, with the ability to convert all stores to SIP trunking within a few years

▶✓ Specialized routing for inbound IVR calls directed to its in‐store pharmacies (specifically, the ability to provide dial tone to these calls)

▶✓ Data security restrictions related to its pharmacy business

▶✓ Maintaining security on all calls

Solution

The retailer deployed a Sonus SBC and Policy Server (PSX) in two data centers to provide a centralized dial plan for all stores. The retailer lever-aged Sonus to develop an installa-tion plan, perform configuration, and develop and implement a test plan. The initial deployment was success-fully defined, designed, tested, and implemented in just a few weeks.

Results

The deployment produced the fol-lowing results:

▶✓ Since implementing the first phase of its new SIP‐based com-munications network, the retailer has realized more than $500,000 in annual savings from reduced toll fees and TDM/PRI trunk leases.

▶✓ Unlike the dedicated TDM lines it had previously used, which required the company to buy its voice trunks in 23‐line bundles for every store, the new Sonus SIP trunking solution enables the retailer to buy its SIP sessions “in bulk” and distribute those sessions across its many stores.

▶✓ The Sonus PSX enabled the retailer to connect the multi‐vendor PBXs across its many stores and manage all of its dial plan and routing information in a single location through its master Sonus PSX server. The centralized dial plan manage-ment offered by the PSX solution will save the retailer hundreds of hours per week that normally went to PBX provisioning and upgrades, enabling the retail-er’s IT team to divert its inter-nal resources to more critical, revenue‐generating projects.

▶✓ Provides built‐in Transport Layer Security (TLS), Secure Real‐time Transport Protocol (SRTP), and Internet Protocol Security (IPsec) encryption with no deg-radation in session performance.

▶✓ Provides much‐needed protec-tion against potential network threats like denial‐of‐service (DoS) attacks, which can be particularly damaging to a large retail business during the holiday season—especially one that relies heavily on its communica-tions network for sales and cus-tomer service.


Ten Reasons to Choose a Sonus SBC

In This Chapter▶▶ Improving management efficiency and performing under pressure

▶▶ Securing the network and ensuring customer experience

▶▶ Playing well with others and deploying to the cloud

W hether you’re an enterprise with a Voice over Internet Protocol (VoIP) or unified communications (UC) solu-

tion or a service provider offering VoIP or UC services to your customers, your choice of session border controllers (SBCs) is integral to your real‐time communications (RTC) architec-ture and the success of those services. In this chapter, I give ten great reasons for you to choose a market‐leading Sonus SBC solution for your RTC needs.

Local Policy ConfigurationSonus SBCs offer local policy control systems via an embed-ded policy engine. That means no extra management equip-ment to install and a system that has all the intelligence needed to screen, route, and modify calls.

Networked Policy ManagementRather than manually managing a separate policy at each SBC, with a centralized policy server connecting all your SBCs, you only need to make changes once — in a single place. Your changes are automatically pushed to all your SBCs — which

Chapter 7



increases efficiency and reduces the risk of missing an SBC or making a critical error (and generating a resume updating event!).

Peak PerformanceThe proliferation of applications and devices has led to an explosion in the volume of Session Initiation Protocol (SIP) traffic on enterprise and service provider networks. Sonus SBCs are designed with sufficient capacity to deliver peak per-formance under different load scenarios. They’ve been tested under extreme conditions — including simulated large‐scale Distributed Denial‐of‐Service (DDoS) attacks.

High‐Scale Transcoding SupportBoth transcoding and transrating are computationally com-plex processes — imagine what it takes to completely disas-semble and reassemble a voice or video stream in real time, without inducing noticeable latency or delay into the stream. Many first‐generation SBCs don’t even include transcoding/transrating functionality, and not all SBCs can scale this fea-ture for thousands of simultaneous sessions.

Sonus SBCs can scale to support high levels of transcoding with-out any effect on other computational functions, such as secu-rity and call admission control (CAC), that an SBC must perform.

Robust SecuritySecuring the SIP network is an increasingly high priority for enterprises and service providers alike. Sonus SBCs are designed to

✓ Provide end‐to‐end encryption on both the media and the signaling components of network traffic.

✓ Hide the topology of the private portions of your net-work with Back‐to‐Back User Agent (B2BUA, discussed in Chapter 2).

Chapter 7: Ten Reasons to Choose a Sonus SBC 43


✓ Protect the network from DoS and DDoS attacks, while maintaining the capability to still connect legitimate ses-sions (DoS/DDoS attacks are covered in Chapter 1).

✓ Implement blacklists, greylists, and whitelists (these lists are covered in more detail in Chapter 1).

Advanced Media SupportToday’s SBCs need a robust media component that has both the computational horsepower and the sophisticated software to perform on‐the‐fly transcoding and transrating of all sorts of media. The trend in enterprise networks is moving away from segregated voice and data networks toward a single, converged network to handle all RTC traffic. The SBC is an important component to

✓ Secure converged networks

✓ Provide Quality of Service (QoS) to ensure an outstand-ing customer experience

✓ Perform the necessary transcoding to interoperate on all data streams

Proven Track RecordSBCs perform a mission‐critical role for enterprises and ser-vice providers. As such, you want to make sure you’re work-ing with a vendor who has the experience and expertise to deliver a resilient, high availability solution with no single point of failure. Whether you’re deploying an SBC as an appli-ance or in a virtual, cloud solution, you want to make sure your SBC vendor understands what you need for success. With almost 20 years of innovation and implementation expe-rience, Sonus knows how to deliver — and has the customer testimonials to prove it.

InteroperabilityDifferent vendors and different VoIP networks may speak in slightly incompatible ways when they use SIP (covered in Chapter 1). This incompatibility can result in calls that can’t



be completed or are degraded in some way (or perhaps miss-ing some functionality). The SBC plays a huge role in under-standing the different variants of SIP.

Sonus SBCs support all known variants of SIP through SIP nor-malization (translating between different SIP variants) using static rules configured on the SBC, or on-the-fly as different varieties of SIP are encountered by the SBC.

Seamless ScalabilitySonus uses a three‐dimensional approach by separating the processing functionality of the SBC so individual tasks, such as transcoding or encryption, can scale up or down without impacting the performance of other SBC tasks.

Sonus divides the SBC processing into three categories:

✓ Signaling and general computing for things like policy management, security, and call control

✓ Media processing for networking stuff like the inter-working among different IP protocols, Secure Real-time Transport Protocol (SRTP) encryption and routing packets

✓ Transcoding for things like audio codec transcoding and transrating

With this approach, when certain functions in your VoIP network need more horsepower, you have it. But you don’t lose capacity in other areas that already have a comfortable degree of overhead. Best of all, this architecture works for both hardware appliances as well as virtual, cloud‐optimized deployments.

Virtual and Cloud OptimizedSonus introduced the industry’s first full‐featured, software‐based SBC — with all the same features as a hardware‐based SBC — architected for a high degree of scalability on a virtual-ized platform in 2013. In 2016, Sonus optimized its virtual SBC for cloud deployments with dynamic orchestration of run‐time ready virtual SBC instances and automated cloud‐scale deployments with simple software downloads across a net-work of virtual SBCs that enable easy setup and configuration.

http://Dummies.com

WILEY END USER LICENSE AGREEMENTGo to www.wiley.com/go/eula to access Wiley’s ebook EULA.

http://www.wiley.com/go/eula

these materials are © 2017 john wiley & sons, inc. any ... · 26 session order controllers or...

Documents