WHITE PAPER

Are Software SBCs Ready for
the Cloud Era?

The cloud has quite rightly been hailed as a game changer
for business applications of all types – and in every vertical– because it delivers on demand usage, scalability, flexibility
and resiliency with a minimal capital outlay.
After all, the use of cloud infrastructure eliminates the needfor spending huge sums of money on buying hardware andmaintaining it.

The cloud has quite rightly been
hailed as a game changer for businessapplications of all types – and inevery vertical – because it delivers on
demand usage, scalability, flexibility
and resiliency with a minimal capitaloutlay.

In the telecommunications industry, one excellent use case for cloud-based technology currently
attracting a lot of interest is virtual, or software, session border controllers (SBCs).
Software SBCs are gaining momentum as more and more organizations are
moving their voice and unified communications infrastructure into the cloud.
There are considerable advantages to using software SBCs, such as reduced
CAPEX and OPEX, longer lifecycle, quick deployment and greater flexibility
around usage. However, there are also many challenges to overcome, such as
the increasing number of complex services that SBCs are being asked to manage
as well as concerns around security, interworking and scalability.
Bearing all this in mind, it seems fair to ask if software SBCs can fully replace hardware SBCs and if they
are appropriate in all deployments.
This white paper examines the question of whether software SBCs are ready for the cloud era, and inwhich situations they are most appropriate to replace their hardware SBC counterparts.

Defining a Software SBC
What, exactly, is a software SBC? A software SBC is an SBC application running on a dedicated common offthe-shelf x86 server or, alternatively, an SBC application running on a virtual machine on top of a hypervisor.
Hardware SBCs, on the other hand, are proprietary hardware products purposely built for SBC
applications. Hardware SBCs usually include a network processor for handling the data layer, DSPs for
implementing transcoding and, occasionally, an x86 CPU for the signaling layer as well.

Advantages of the Software SBC
The advantages of using pure software-based products (including SBCs) for the telecom segment havebeen stressed by the Network Function Virtualization ETSI Specification Group.
According to the NFV, the advantages include:••••••

Reduced operator CAPEX and OPEX through reduced equipment costs and reduced
power consumption
Reduced time-to-market to deploy new network services
Improved return on investment from new services
Greater flexibility to scale up, scale down or evolve services
Openness to the virtual appliance market and pure software entrants
Opportunities to trial and deploy new innovative services at lower risk

In addition to the above, software SBCs are likely to enjoy a longer lifecycle since the software can beinstalled on a new server if the underlying server has reached its end-of-life.

2Are Software SBCs Ready for the Cloud Era?

How Do Software SBCs Compare to Hardware SBCs?
To reap the software-related benefits listed above, we need to determine whether the software
SBC’s effectiveness in terms of the different layers of SBC functionality can fully replace its hardware
counterpart.
In addition to comparing capabilities and feature sets between these two SBC implementations, we alsoneed to take into consideration the total cost of ownership for comparable configurations.
To reap the software-related benefits listed above, we need to determine whether the software
SBC’s effectiveness in terms of the different layers of SBC functionality can fully replace its
hardware counterpart.

The Signaling Layer
The signaling layer (sometimes called the control layer) handles SIP signaling. It takes care of all the SIP
interoperability functions, routing, denial of service protection, NAT traversal, SIP encryption and more.
Software SBCs utilize x86 CPUs, which are highly capable of handling SIP messages. In fact, many of thehardware SBCs also use an x86 CPU for the same purpose. Intel’s high CPU frequency, large caches,
advanced pipelines and hardware accelerators make them ideal for tasks such as large table lookups,
hashing, parsing etc. which are required for signaling layer processing.
Another signaling layer task that SBCs are required to handle is encryption (exp. SIP over TLS). Network
processors and Intel x86 both offer accelerators which optimize these highly complex encryption
operations.

The Data LayerThe data layer deals with the handling of the RTP packets which traverse the SBC.
The SBC is required to replace IP and RTP headers (for example, for topologyhiding), fork an incoming RTP stream into two or more streams (for example,
when using cognitive services or for recording), and route the incoming streams todifferent targets. Traditionally, this area has been the bread and butter of network
processors. However, Intel has substantially improved its data layer throughput
over time, enabling software SBCs to compete on equal terms with their hardwarebased cousins.
RTP packets are handled by multiple means, one of which is bypassing some of the Linux operating
system’s ‘heavy lifting’ networking code (which is usually unnecessary with simple packet switching, as
in the case of the SBC data layer). By using network acceleration techniques such as SR-IOV and ENA, thedata layer is no longer a bottleneck for software SBCs.

The Media Layer
The third layer, which is probably the most challenging, is the media layer. This layer is in charge ofhandling the RTP payload and performs tasks such as voice codec transcoding, DTMF detection andinjection, etc.

3Are Software SBCs Ready for the Cloud Era?

Hardware SBCs use Digital Signal Processor chips to handle media layer activities and are highly
optimized for this application. DSPs also perform mathematical filters on the voice samples, which
involves vector arithmetic where a vector is a series of numbers.
DSPs support very long vectors and also wide and fast memory buses to ‘feed’ these vectors andprevent memory access bottlenecks. These make DSPs optimal media handling devices.
Intel x86, on the other hand, is a general-purpose CPU which, in addition to doing vector calculations,
supports a wide set of additional instructions unrelated to the handling of media. As such, the x86 is
generically less efficient, both power and performance wise, as compared to DSPs.
Intel has been strengthening the vector arithmetic capabilities on its recent CPU architecture evolutions.
Vector arithmetic engines have evolved over time, using technologies such as AVX and AVX2, up to thelatest AVX512.
Intel cores are also unbalanced when comparing their signaling and media throughput with theirtranscoding throughput. A single Intel core can handle 10 times or more SBC sessions (which include
SIP signaling and RTP) than the number of transcoded voice sessions.

When Is a Software SBC the Right Choice?
SBC applications can be divided into three main categories: enterprise SBCs, service provider access
SBCs and service provider peering SBCs. Today’s software SBCs can fit almost any voice and unified
communications use case.
Starting with enterprise SBCs, these usually require no more than a few hundred sessions. Full session
transcoding is required when the carrier’s SIP trunk uses a different vocoder than the one on the LANside. A typical transcoding use case would be Microsoft Teams Direct Routing, where G.711 needs tobe transcoded to the SILK codec.
In other cases, most service providers offer G.711 SIP trunks which are compatible with all IP phones
served on the LAN side. As a result, full session transcoding is not required (some transcoding may stillbe needed for remote workers that use a different vocoder, but these require transcoding on only asmall portion of the calls). Software SBCs, especially virtualized ones, are a good a fit in this case.
Service provider access SBCs, in most cases, do not require transcoding, mainly because they enforce
the service provider media policy rather than convert the media coming from the customers. Since
these SBCs are mostly large, they make an excellent fit for software SBCs that can scale out horizontallyby adding more virtual resources.
In contrast, service provider peering SBCs do require transcoding in many cases, as different service
providers may use different vocoders and fax transports. In such cases where transcoding is a must, asoftware SBC with a scalable media cluster makes a good choice.
As mentioned, a main performance factor determining a software SBC fit or unfit for an application isthe need for transcoding. The advent of technologies such as WebRTC and Microsoft Teams introduces
additional vocoders, specifically Opus and SILK, into widespread use. This means that large-scaletranscoding will still be needed in the foreseeable future.

4Are Software SBCs Ready for the Cloud Era?

Cloud-Based Elastic SBCs Are Changing the Game – and Cutting Costs
A newer type of software SBC, called an elastic SBC, can strike abalance between the requirement to transcode the media andthe cost of the x86 compute resources that are needed for thetask.
With an elastic SBC deployed in the cloud, the amount ofresources the SBC consumes can change dynamically over time,depending on the traffic needs. When traffic increases, the SBC
allocates more virtual resources (CPUs, memory and bandwidth)
to sustain the load. Conversely, at low-traffic times these resources are released so you are not charged
for them. AudioCodes has entered the elastic SBC market with its Mediant Cloud Edition (CE) model,
which is fast becoming a popular option for organizations moving their voice infrastructure to the cloud.
A newer type of software SBC, called an elastic SBC, can strike a balance between the requirement totranscode the media and the cost of the x86 compute resources that are needed for the task.
For more information on the Mediant Cloud Edition (CE), please visit our website athttps://www.audiocodes.com/solutions-products/products/session-border-controllers-sbcs/mediant-ce-sbc

About AudioCodes
AudioCodes Ltd. (NASDAQ, TASE: AUDC) is a leading vendor of advanced communications software,products and productivity solutions for the digital workplace. AudioCodes enables enterprises andservice providers to build and operate all-IP voice networks for unified communications, contact centers,
and hosted business services. AudioCodes offers a broad range of innovative products, solutions andservices that are used by large multi-national enterprises and leading tier-1 operators around the world.

International Headquarters
1 Hayarden Street,
Airport City
Lod 7019900, Israel
Tel: +972-3-976-4000
Fax: +972-3-976-4040

5AudioCodes Inc.
200 Cottontail Lane,
Suite A101E,
Somerset NJ 08873
Tel:+1-732-469-0880
Fax:+1-732-469-2298

Are Software SBCs Ready for the Cloud Era?

Contact us: www.audiocodes.com/contact
Website: www.audiocodes.com©2020 AudioCodes Ltd. All rights reserved. AudioCodes, AC, HD VoIP,HD VoIP Sounds Better, IPmedia, Mediant, MediaPack, What’s Inside
Matters, OSN, SmartTAP, User Management Pack, VMAS, VoIPerfect,
VoIPerfectHD, Your Gateway To VoIP, 3GX, VocaNom, AudioCodes One
Voice, AudioCodes Meeting Insights, AudioCodes Room Experience
and CloudBond are trademarks or registered trademarks of AudioCodes Limited. All other products or trademarks are property of theirrespective owners. Product specifications are subject to change without notice.