Uploaded by dvdgnwn03

Session Border Controllers for Dummies

These materials are © 2017 John Wiley & Sons, Inc. Any dissemination, distribution, or unauthorized use is strictly prohibited.
Session Border
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
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 trademarks 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.
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 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
Acquisitions Editor: Katie Mohr
Editorial Manager: Rev Mengle
Business Development Representative:
Sue Blessing
Key Sonus Contributor: Daniel Teichman
These materials are © 2017 John Wiley & Sons, Inc. Any dissemination, distribution, or unauthorized use is strictly prohibited.
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
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 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
These materials are © 2017 John Wiley & Sons, Inc. Any dissemination, distribution, or unauthorized use is strictly prohibited.
oday’s real‐time communications (RTC) no longer just
consists of voice calls, but now includes video conferencing, instant messaging, desktop sharing, team collaboration,
and presence management. Making these different applications 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 functions, 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 enterprises 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)
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 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
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 optimize their SBCs. If you want to talk to someone, instead of just
looking at the website, please call 1‐855‐GO‐SONUS.
These materials are © 2017 John Wiley & Sons, Inc. Any dissemination, distribution, or unauthorized use is strictly prohibited.
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
eal‐time communications (RTC) in modern businesses
includes phone calls, video conferencing, chat, text messaging, 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 directing 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 sessions for both enterprises and service providers. An SBC performs 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
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 for bad actors to gain access to potentially vulnerable parts of the network
••Encryption of both the signaling and media to
prevent communications from being illegally intercepted or tampered with as well as maintaining
••Detecting and preventing DoS attacks before they
impair network performance
••Enabling call admission control and dynamic blacklisting 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 connection 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 service between different network devices.
Typical savings from SIP trunking, trunking consolidation, 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 protocols: An SBC provides a smooth experience in terms of
interconnecting and interworking between different networks 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.
These materials are © 2017 John Wiley & Sons, Inc. Any dissemination, distribution, or unauthorized use is strictly prohibited.
Chapter 1: Protecting Real‐Time Communications with SBCs
••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 multiple network borders, the task of individually configuring 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 networks. 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
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 that are out of the control of an enterprise or a network provider. 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 private 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 vulnerable 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 without paying for them
✓✓Spoofing: Deliberately modifying or disguising an identity (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 networks, 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).
These materials are © 2017 John Wiley & Sons, Inc. Any dissemination, distribution, or unauthorized use is strictly prohibited.
Chapter 1: Protecting Real‐Time Communications with SBCs
✓✓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 potentially 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 exposure. 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 accessible 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 function 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)
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 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
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 septillion, 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 communicate using both versions of IP
and can connect to an IPv6‐only
smartphone using IPv6 while connecting to an IPv4 server using
✓✓ The SBC can act as an interworking agent between an IPv4 network 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.
These materials are © 2017 John Wiley & Sons, Inc. Any dissemination, distribution, or unauthorized use is strictly prohibited.
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
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 functionality 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
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
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 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 compliance 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 speaking 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 confusion. 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 network 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
These materials are © 2017 John Wiley & Sons, Inc. Any dissemination, distribution, or unauthorized use is strictly prohibited.
Chapter 2: Identifying the Key Requirements of an SBC
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 support 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 specific instances covered in this section.
HD voice
The sound quality of voice calls in general took a step backwards over the years as convenience (mobile) and economics (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 appropriate 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).
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 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
These materials are © 2017 John Wiley & Sons, Inc. Any dissemination, distribution, or unauthorized use is strictly prohibited.
Chapter 2: Identifying the Key Requirements of an SBC
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 prominent 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 incorporating tone detection (the ability to recognize and act on standard 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 deploying a video‐friendly firewall or a video bridge with dual
network ports, but each of these options potentially compromises security and performance and adds cost and
✓✓Interoperability issues: A wide range of video conferencing standards exists, but despite these standards,
interoperability issues still prevail due to different
­protocols (SIP, H.323) or video/audio compression
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 (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 services, 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,
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 performance, scalability, and resiliency, consider the following
✓✓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 prioritization 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.
These materials are © 2017 John Wiley & Sons, Inc. Any dissemination, distribution, or unauthorized use is strictly prohibited.
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
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 controller (SBC).
What’s a Virtual SBC?
Virtualization technology abstracts software (such as an operating 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 virtualization 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
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 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)
✓✓Efficient resource utilization: Before virtualization,
many data centers used about 10 percent of their total
capacity, meaning that nearly 90 percent of their capacity 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 reducing 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.
These materials are © 2017 John Wiley & Sons, Inc. Any dissemination, distribution, or unauthorized use is strictly prohibited.
Chapter 3: Virtualization and Cloud Optimization of the SBC
✓✓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
✓✓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 communications (RTC) in the cloud requires the ability to
instantiate a virtual SBC as rapidly as the real‐time service 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,
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 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 configuration 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 velocity with operational efficiency, because it is possible to
instantiate a running, configured SBC that is immediately
capable of call processing without requiring operator
✓✓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 situations that could potentially cause processing failures,
or by providing rebalancing of traffic in the event an
instance has an outage.
These materials are © 2017 John Wiley & Sons, Inc. Any dissemination, distribution, or unauthorized use is strictly prohibited.
Chapter 3: Virtualization and Cloud Optimization of the SBC
Multiple load balancing methods exist, but for an SBC,
load balancing must have knowledge of session persistence 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 sessions, symmetric Network Address and Port Translation
(NAPT), or possible uneven distribution of load immediately 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 addition 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 session and media continuity in the event of the failure of a
virtual SBC.
Most public cloud environments serve web‐based applications, 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 continuity 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 appliances. Performance at scale is possible when SBC functions can be independently allocated to processors.
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 Turning on feature capabilities like encryption, interworking for IPv4 to IPv6 or Real‐time Transport Protocol
(RTP) to Secure RTP (SRTP), and SIP header manipulation 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 negative 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 microservices 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 application 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.
These materials are © 2017 John Wiley & Sons, Inc. Any dissemination, distribution, or unauthorized use is strictly prohibited.
Chapter 3: Virtualization and Cloud Optimization of the SBC
✓✓Network‐wide licensing: A traditional node‐based licensing model that was appropriate for appliance‐based SBCs
isn’t viable in a virtual, cloud deployment.
For a cloud deployment, where SBC VNFs are dynamically 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 service chaining of multiple services from multiple suppliers. 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 services, 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 application 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.
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 These materials are © 2017 John Wiley & Sons, Inc. Any dissemination, distribution, or unauthorized use is strictly prohibited.
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
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 messaging, 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.
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 CIOs are looking to UC and cloud‐based services to meet the
rising demand for real‐time communications (RTC), yet a fundamental barrier to UC adoption is a lack of interoperability
between the vendor‐specific voice, video, and messaging systems that exist in most enterprise networks.
While SIP was meant to break down many of those barriers, 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 consume 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 interoperability 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 communications 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 recording as both an evaluation and training tool to ensure
These materials are © 2017 John Wiley & Sons, Inc. Any dissemination, distribution, or unauthorized use is strictly prohibited.
Chapter 4: Deploying SBCs for Different Use Cases
contact center agents provide the utmost quality in customer service. In many cases, government regulations
require calls to be recorded for legal reasons and consumer protection as well.
Traditionally, call recording in communications networks 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 technology allows workers to work out of their homes with
flexible hours, making this arrangement appealing to
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 necessary 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
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 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 businesses replace their existing time‐division multiplexing (TDM)
based systems with SIP‐based UC platforms for telephony,
instant messages, presence, and video conferencing applications. For the enterprise, an SBC is the first line of defense in
the UC system providing cost‐effective and secure connections 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 regulatory 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 gateway, VoIP mediation, access to public switched telephone networks (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.
These materials are © 2017 John Wiley & Sons, Inc. Any dissemination, distribution, or unauthorized use is strictly prohibited.
Chapter 4: Deploying SBCs for Different Use Cases
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 businesses 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 network. Also, there are challenges for mobile operators associated 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 streaming voice calls, video, and data from social media and streaming services (such as Pandora or Spotify).
The LTE standard only supports IP packet switching, meaning 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 channel 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.
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 IMS Networks
The IP Multimedia Subsystem (IMS) is an integrated framework 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 functions 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 signaling data appropriately. The SBC provides capabilities
such as Network Address Translation (NAT)/firewall
traversal, user identity privacy, encryption, and policy
✓✓Access Transfer Control Function (ATCF) and Access
Transfer Gateway (ATGW): The ATCF and ATGW functions ensure that the handoff of the call doesn’t introduce 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 management on a per‐trunk basis.
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
These materials are © 2017 John Wiley & Sons, Inc. Any dissemination, distribution, or unauthorized use is strictly prohibited.
Chapter 4: Deploying SBCs for Different Use Cases
✓✓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 customer 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
✓✓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 conference 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.
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 These materials are © 2017 John Wiley & Sons, Inc. Any dissemination, distribution, or unauthorized use is strictly prohibited.
Chapter 5
Multimedia Matters
In This Chapter
▶▶Meeting customers’ video network requirements
▶▶Deriving business value from SBCs in your video network
rom the boardroom to the browser, video and audio conferencing 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 communications. 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.
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 ✓✓Video meetings with people outside of an organization
require video and audio traffic to pass through the organization’s firewall to ensure the session can’t be intercepted 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 correct 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 separate 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 gatekeeper 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 session 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 infrastructure 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
These materials are © 2017 John Wiley & Sons, Inc. Any dissemination, distribution, or unauthorized use is strictly prohibited.
Chapter 5: Multimedia Matters
work side‐by‐side with firewalls. You can think of an SBC as
an RTC firewall that makes a video system work securely and
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 network 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 provide 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 communications (UC) and video devices. SBCs can perform QoS prioritization (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 regulating 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.
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 SBCs solve this problem by modifying the signaling information contained in the SIP packets so that endpoints can
communicate with each other through a process known as
protocol normalization. Protocol normalization allows organizations 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 components from a single vendor.
These materials are © 2017 John Wiley & Sons, Inc. Any dissemination, distribution, or unauthorized use is strictly prohibited.
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
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!
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 Reducing Costs with Intelligent
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 networks, 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.
These materials are © 2017 John Wiley & Sons, Inc. Any dissemination, distribution, or unauthorized use is strictly prohibited.
Chapter 6: Determining ROI and Value in an SBC
Flying high with Sonus SBCs
A 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 supports numerous voice applications
for maintenance and support teams,
ground support (baggage, fueling,
and so on), logistics, in‐cockpit and
paging systems, airport ticket counters, a highly mobile workforce, and
even airport courtesy phones.
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 leveraging 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.
The airline faced functional and
expense‐related issues with its legacy telecommunications systems.
Specifically, the airline needed to
The airline installed Sonus SBCs
and a Sonus Policy Server. The SBC
and policy server addressed several
✓✓ Move to an all‐IP voice infrastructure without discarding
its installed base of legacy
✓✓ Interoperability between legacy
TDM and H.323 voice systems
and SIP trunking
✓✓ Reduce costs
✓✓ Improve employee productivity
✓✓ Maintain voice security
✓✓ Improve customer experience
across a variety of real‐time
communications (RTC) applications and devices
The legacy voice systems — time‐
division multiplexing (TDM) private
branch exchanges (PBXs) — and
✓✓ Centralized call control and
✓✓ Secure access for both on‐
campus and remote call center
agents and mobile employees
The airline achieved dramatic results
with the Sonus solution, including
✓✓ Reduced call costs
✓✓ Least‐cost routing for all calls
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 (continued)
✓✓ Keeping internal calls on the airline’s multiprotocol label switching (MPLS) network instead of a
carrier’s network
✓✓ Reduced network operating
✓✓ Improved uptime and reliability
for the call center
✓✓ Secure connectivity for remote
workers and home‐based call
center employees
✓✓ 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 component 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 translation, 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
These materials are © 2017 John Wiley & Sons, Inc. Any dissemination, distribution, or unauthorized use is strictly prohibited.
Chapter 6: Determining ROI and Value in an SBC
✓✓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 physical 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 cooling. In addition, virtual SBCs can be provisioned and configured via a software download, providing ease of configuration
and deployment to remote locations or data centers, customer sites, or in the public cloud.
Shopping for an SBC solution
A 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.
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 (continued)
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
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 leveraged Sonus to develop an installation plan, perform configuration, and
develop and implement a test plan.
The initial deployment was successfully defined, designed, tested, and
implemented in just a few weeks.
The deployment produced the following results:
✓✓ Since implementing the first
phase of its new SIP‐based communications 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 management offered by the PSX solution
will save the retailer hundreds
of hours per week that normally
went to PBX provisioning and
upgrades, enabling the retailer’s IT team to divert its internal 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 degradation in session performance.
✓✓ Provides much‐needed protection 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 communications network for sales and customer service.
These materials are © 2017 John Wiley & Sons, Inc. Any dissemination, distribution, or unauthorized use is strictly prohibited.
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
hether you’re an enterprise with a Voice over Internet
Protocol (VoIP) or unified communications (UC) solution 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) architecture 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 embedded policy engine. That means no extra management equipment 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
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 increases efficiency and reduces the risk of missing an SBC
or making a critical error (and generating a resume updating
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 performance 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 complex processes — imagine what it takes to completely disassemble 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 feature for thousands of simultaneous sessions.
Sonus SBCs can scale to support high levels of transcoding without any effect on other computational functions, such as security 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 network with Back‐to‐Back User Agent (B2BUA, discussed in
Chapter 2).
These materials are © 2017 John Wiley & Sons, Inc. Any dissemination, distribution, or unauthorized use is strictly prohibited.
Chapter 7: Ten Reasons to Choose a Sonus SBC
✓✓Protect the network from DoS and DDoS attacks, while
maintaining the capability to still connect legitimate sessions (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 outstanding customer experience
✓✓Perform the necessary transcoding to interoperate on all
data streams
Proven Track Record
SBCs perform a mission‐critical role for enterprises and service providers. As such, you want to make sure you’re working 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 appliance 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 experience, Sonus knows how to deliver — and has the customer
testimonials to prove it.
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
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 be completed or are degraded in some way (or perhaps missing some functionality). The SBC plays a huge role in understanding the different variants of SIP.
Sonus SBCs support all known variants of SIP through SIP normalization (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 interworking among different IP protocols, Secure Real-time
Transport Protocol (SRTP) encryption and routing packets
✓✓Transcoding for things like audio codec transcoding and
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
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 virtualized 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 network of virtual SBCs that enable easy setup and configuration.
These materials are © 2017 John Wiley & Sons, Inc. Any dissemination, distribution, or unauthorized use is strictly prohibited.
These materials are © 2017 John Wiley & Sons, Inc. Any dissemination, distribution, or unauthorized use is strictly prohibited.
Go to www.wiley.com/go/eula to access Wiley’s ebook EULA.
Random flashcards
Arab people

15 Cards


39 Cards


30 Cards


17 Cards

Create flashcards