Dummies Book Session Border Controllers For Dummies 4th Edition

These materials are © 2017 John Wiley & Sons, Inc.
Any dissemination, distribution, or unauthorized use is strictly prohibited.

Session Border
Controllers
4th Sonus Special Edition
by Lawrence C. Miller
These materials are © 2017 John Wiley & Sons, Inc. Any dissemination, distribution, or unauthorized use is strictly prohibited.
Session Border Controllers For Dummies®, 4th Sonus Special Edition
Published 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 info@dummies.biz, or visit www.wiley.com/go/custompub. For
information about licensing the For Dummies brand for products or services, contact
BrandedRights&Licenses@Wiley.com.
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 Acknowledgments
We’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 Business Development Representative:
Acquisitions Editor: Katie Mohr Sue Blessing
Editorial Manager: Rev Mengle Key Sonus Contributor: Daniel Teichman
Table of Contents
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
About This Book......................................................................... 1
Foolish Assumptions.................................................................. 2
Icons Used in This Book............................................................. 2
Beyond the Book......................................................................... 2
Chapter 1: Protecting Real‐Time Communications

with SBCs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
Looking at the SBC’s Role.......................................................... 3
Understanding the Need for SBCs............................................ 5
Chapter 2: Identifying the Key Requirements

of an SBC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Normalizing SIP........................................................................... 9
Transcoding Calls..................................................................... 10
HD voice........................................................................... 11
Bandwidth restrictions.................................................. 12
Dealing with NAT Traversal..................................................... 12
Fax and Tone Detection........................................................... 13
Video Support........................................................................... 13
Performance, Scalability, Resiliency...................................... 14
Chapter 3: Virtualization and Cloud Optimization

of the SBC. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
What’s a Virtual SBC?............................................................... 15
Knowing What to Look for in a Cloud‐Optimized SBC......... 17
Chapter 4: Deploying SBCs for Different

Use Cases. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Unified Communications.......................................................... 23
Contact Center.......................................................................... 24
Enterprise Connectivity........................................................... 26
Mobile......................................................................................... 27
IMS Networks............................................................................. 28
WebRTC..................................................................................... 28
iv Session Border Controllers For Dummies, 4th Sonus Special Edition
Chapter 5: Multimedia Matters. . . . . . . . . . . . . . . . . . . . . 31

Video Should “Just Work”........................................................ 31
Adding Value to Video with SBCs........................................... 33
Session management...................................................... 33
Endpoint interoperability.............................................. 33
Chapter 6: Determining ROI and Value in an SBC. . . . . 35

Reducing Costs with Intelligent Policies................................ 36
Increasing Efficiency through a Single Point
of Management...................................................................... 36
Minimizing Costly Downtime with High Availability............ 38
Consolidating Multiple Functions in a Single Solution......... 38
Getting Real about Cost Savings with a Virtual SBC............. 39
Chapter 7: Ten Reasons to Choose a Sonus SBC. . . . . . 41

Local Policy Configuration....................................................... 41
Networked Policy Management.............................................. 41
Peak Performance..................................................................... 42
High‐Scale Transcoding Support............................................ 42
Robust Security......................................................................... 42
Advanced Media Support........................................................ 43
Proven Track Record................................................................ 43
Interoperability......................................................................... 43
Seamless Scalability.................................................................. 44
Virtual 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 Book

Session 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)
2 Session Border Controllers For Dummies, 4th Sonus Special Edition
Foolish Assumptions
It’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 Book

Throughout 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 Book

I’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.
Chapter 1
Protecting Real‐Time
Communications with SBCs
In 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 Role

An 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
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
••Greylists: People and devices that sometimes have
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) here

The IP variant (IPv4) that has powered IPv4 network and the other on IPv6,
the Internet for as long as most of us something needs to get in the middle
can remember has an issue. IPv4 uses and help them communicate. An SBC
a 32‐bit address space, which means resolves these issues in two ways:
it’s limited to only about 4.3 billion
✓✓ An SBC can be dual stacked,
addresses — and it just ran out of
meaning it contains the network
available addresses (not literally just
stack software (the basic network
now; it happened in 2015).
protocol software suite) for both
IPv6 increases the address space to IPv4 and IPv6. The SBC can com-
128 bits, which means that there are municate using both versions of IP
now 340,282,366,920,938,463,374,607, and can connect to an IPv6‐only
431,768,211,456 possible addresses smartphone using IPv6 while con-
(that’s “340 undecillion, 282 decillion, necting to an IPv4 server using
366 nonillion, 920 octillion, 938 septil- IPv4.
lion, 463 sextillion, 463 quintillion, 374
✓✓ The SBC can act as an interwork-
quadrillion, 607 trillion, 431 billion,
ing agent between an IPv4 net-
768 million, 211 thousand and
work and an IPv6 network. In this
456” — seriously).
case, the SBC can translate all
This, in turn, causes other issues. For traffic flowing between an IPv4
example, not all networks can natively and an IPv6 network on‐the‐fly,
support IPv6. When two clients want as it crosses the network border.
to communicate and one is on an
Chapter 2
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 SIP
Session 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
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 Calls
Another 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 voice
The 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 restrictions
Sometimes 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 Traversal

Network 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 Detection

Legacy 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 Support
Businesses 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.
Chapter 3
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
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.
Chapter 4
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 Communications
Gone 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.
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 Center
The 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 Connectivity
SBCs 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.
Mobile
RTC 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 Networks
The 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.
WebRTC
WebRTC 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.
Chapter 5
Multimedia Matters
In 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.
✓✓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 management
The 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 interoperability
Many 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.
Chapter 6
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!
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
Flying high with Sonus SBCs

A U.S.‐based, international airline circuit‐switched integrated services
maintains a global call center to digital network (ISDN) primary rate
deal with reservations, rewards interface (PRI) voice circuits were
programs, flight changes, seating migrated to IP PBX and Session
assignments, and other business‐ Initiation Protocol (SIP) trunking to
critical calls. The airline also sup- reduce voice costs while still lever-
ports numerous voice applications aging their installed equipment base.
for maintenance and support teams, At the same time, the airline wanted
ground support (baggage, fueling, to centralize control of its voice
and so on), logistics, in‐cockpit and communications to provide load
paging systems, airport ticket coun- balancing and least‐cost routing for
ters, a highly mobile workforce, and inbound Interactive Voice Response
even airport courtesy phones. (IVR) calls from customers.
Challenges Solution
The airline faced functional and The airline installed Sonus SBCs
expense‐related issues with its leg- and a Sonus Policy Server. The SBC
acy telecommunications systems. and policy server addressed several
Specifically, the airline needed to issues:
✓✓ Move to an all‐IP voice infra- ✓✓ Interoperability between legacy
structure without discarding TDM and H.323 voice systems
its installed base of legacy and SIP trunking
equipment
✓✓ Centralized call control and
✓✓ Reduce costs routing
✓✓ Improve employee productivity ✓✓ Secure access for both on‐
campus and remote call center
✓✓ Maintain voice security
agents and mobile employees
✓✓ Improve customer experience
Results
across a variety of real‐time
communications (RTC) applica- The airline achieved dramatic results
tions and devices with the Sonus solution, including
The legacy voice systems — time‐ ✓✓ Reduced call costs
division multiplexing (TDM) private
✓✓ Least‐cost routing for all calls
branch exchanges (PBXs) — and
(continued)
(continued)
✓✓ Keeping internal calls on the air- ✓✓ Improved uptime and reliability

line’s multiprotocol label switch- for the call center
ing (MPLS) network instead of a
✓✓ Secure connectivity for remote
carrier’s network
workers and home‐based call
✓✓ Reduced network operating center employees
expenses
✓✓ Lower capital expenditures
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
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.
Shopping for an SBC solution

A U.S.‐based retail chain needed to retailer had specific functionality and
consolidate its voice management security requirements associated
into a centralized system while with the Payment Card Industry’s
migrating from legacy circuit‐ Data Security Standards (PCI DSS),
switched TDM to SIP trunking to requiring functionality not available
reduce costs. Additionally, the in all SBC solutions.
(continued)
(continued)
Challenges ✓✓ Unlike the dedicated TDM lines

it had previously used, which
The retailer’s requirements included
required the company to buy its
the following:
voice trunks in 23‐line bundles
✓✓ Saving money with SIP trunking for every store, the new Sonus
SIP trunking solution enables the
✓✓ A centralized policy and call
retailer to buy its SIP sessions
routing control for all stores
“in bulk” and distribute those
✓✓ A rapid roll‐out, with the ability to sessions across its many stores.
convert all stores to SIP trunking
✓✓ The Sonus PSX enabled the
within a few years
retailer to connect the multi‐
✓✓ Specialized routing for inbound vendor PBXs across its many
IVR calls directed to its in‐store stores and manage all of its dial
pharmacies (specifically, the plan and routing information
ability to provide dial tone to in a single location through its
these calls) master Sonus PSX server. The
centralized dial plan manage-
✓✓ Data security restrictions related
ment offered by the PSX solution
to its pharmacy business
will save the retailer hundreds
✓✓ Maintaining security on all calls of hours per week that normally
went to PBX provisioning and
Solution
upgrades, enabling the retail-
The retailer deployed a Sonus SBC er’s IT team to divert its inter-
and Policy Server (PSX) in two data nal resources to more critical,
centers to provide a centralized dial revenue‐generating projects.
plan for all stores. The retailer lever-
✓✓ Provides built‐in Transport Layer
aged Sonus to develop an installa-
Security (TLS), Secure Real‐
tion plan, perform configuration, and
time Transport Protocol (SRTP),
develop and implement a test plan.
and Internet Protocol Security
The initial deployment was success-
(IPsec) encryption with no deg-
fully defined, designed, tested, and
radation in session performance.
implemented in just a few weeks.
✓✓ Provides much‐needed protec-
Results
tion against potential network
The deployment produced the fol- threats like denial‐of‐service
lowing results: (DoS) attacks, which can be
particularly damaging to a large
✓✓ Since implementing the first
retail business during the holiday
phase of its new SIP‐based com-
season—especially one that
munications network, the retailer
relies heavily on its communica-
has realized more than $500,000 in
tions network for sales and cus-
annual savings from reduced toll
tomer service.
fees and TDM/PRI trunk leases.
Chapter 7
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 Configuration

Sonus 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 Management

Rather 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
increases efficiency and reduces the risk of missing an SBC

or making a critical error (and generating a resume updating
event!).
Peak Performance
The 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 Support

Both 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 Security
Securing 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 Support

Today’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 Record

SBCs 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.
Interoperability
Different 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 Scalability
Sonus 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 Optimized

Sonus 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.
WILEY END USER LICENSE AGREEMENT
Go to www.wiley.com/go/eula to access Wiley’s ebook EULA.

Dummies Book Session Border Controllers For Dummies 4th Edition

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Dummies Book Session Border Controllers For Dummies 4th Edition

Uploaded by

Copyright:

Available Formats

These materials are © 2017 John Wiley & Sons, Inc.

Any dissemination, distribution, or unauthorized use is strictly prohibited.

4th Sonus Special Edition

LIMIT OF LIABILITY/DISCLAIMER OF WARRANTY: THE PUBLISHER AND THE AUTHOR MAKE

Chapter 1: Protecting Real‐Time Communications

Chapter 2: Identifying the Key Requirements

Chapter 3: Virtualization and Cloud Optimization

Chapter 4: Deploying SBCs for Different

Chapter 5: Multimedia Matters. . . . . . . . . . . . . . . . . . . . . 31

Chapter 6: Determining ROI and Value in an SBC. . . . . 35

Chapter 7: Ten Reasons to Choose a Sonus SBC. . . . . . 41

As powerful as SIP is, it isn’t without challenges that include

About This Book

✓✓What SBCs are and why they’re needed to protect RTC

Icons Used in This Book

This icon points out information that you should commit to

This information tells you to steer clear of things that may

Beyond the Book

R eal‐time communications (RTC) in modern businesses

Looking at the SBC’s Role

✓✓Securing the RTC network: An SBC protects and secures

for bad actors to gain access to potentially vulner-

✓✓RTC traffic is properly routed between network providers

As VoIP adoption became more common in the enterprise,

that are out of the control of an enterprise or a network pro-

Like other IP applications, VoIP can be carried over public

Some common VoIP attacks include

✓✓Service theft and fraud: Attackers accessing a VoIP

An SBC employs various techniques to protect enterprises

✓✓Media and signaling encryption: Encryption prevents

Alternatives to SBCs include virtual private network (VPN)

✓✓VPN tunnels: A VPN can cause trouble when there’s a

sessions are exceedingly dynamic. Sessions are set

IPv6 is (finally) here

A session border controller (SBC) does much more than

across private phone networks. SIP is critical to the capability

SIP is a communications standard drafted by the Internet

Enough variations exist in SIP that sometimes two systems

An SBC must be able to speak all the different dialects of SIP

Many codecs — the encode/decode algorithms that compress

✓✓Computers and tablets

In a VoIP call (or any real‐time, session‐based communication,

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

Transcoding in SBCs frequently comes into play in two spe-

There’s a gotcha to HD voice: There’s no single codec used

You may not want to default to these low‐fidelity codecs all

Dealing with NAT Traversal

The newer version of IP that will eventually replace today’s

The challenge with NAT is that creating an end‐to‐end session

Many SBCs explicitly support what’s known as NAT traversal,

Fax and Tone Detection

An SBC, however, can come to the rescue here by incorporat-

✓✓Intercompany communication: Enterprise routers and

(H.264, H.263, G.722, and so on). Some other issues also

An SBC can provide video proxy services, NAT/firewall ser-

✓✓CPU utilization: The SBC does a lot of computationally

I n this chapter, you learn how virtualization and cloud

What’s a Virtual SBC?

Communications systems can also leverage virtualization

software. This process removes the need for you to purchase

A virtual SBC is an SBC implemented entirely in software,

Some of the benefits of virtualization (and cloud optimization)

✓✓Efficient resource utilization: Before virtualization,