Dialogic is exhibiting at Connecting West Africa, taking place at
the Radisson Blu Hotel in Dakar, Senegal on Tuesday the 11th of June.
Jim Machi is the Vice President of Product Management at
Dialogic. Today he shares his views on software based session border
controllers.
Why would you want a
software based session border controller?
Why
would you ever want a software-based session border controller (SBC)? Is it even feasible? Right now, SBC’s are
boxes that often implemented at the edges of IP-based networks. It might seem unlikely for a hardware node of
that critical network element morph to become a piece of software.
If
the SBC sits on the border of two IP networks, then there are IP connections on
both sides of the box, while means there is a physical connection to an IP
network. However, that physical
connection doesn’t have to be at the exact demarcation point. In fact, it doesn’t have to be part of the
SBC box. Some other device could take care of the physical IP connection, and
the IP data stream could then pass through a software-based SBC function that
resides elsewhere. For example, a software-based SBC could be a resident in a commercial off-the-shelf (COTS) type chassis,
such as an ATCA chassis, where network interface cards (NIC) handle the
connection to the IP network. A series of single board computers could go into
the chassis where the software based elements could run as an application. The software-based
SBC could simply be connected and running on one of the single board computers.
It could be running in a virtualized environment in a single board computer, or
as part of a few applications in a 1U or 2U platform. Ultimately, it could also
be in a cloud environment. In this case,
the actual physical NIC could be thousands of miles away from the SBC software.
Now
that we’ve deemed it feasible, why would someone want to use a software-based
SBC? First of all, economics come into play. COTS hardware can enter the
picture, and when that happens, costs for that product set typically come down.
A related piece to this reasoning is savings on the chassis. If you put the SBC
on a single board computer that goes into a common chassis with multiple other
network notes, also on single board computers, then there is savings on the
chassis. There would also clearly be
sparing savings, since the COTS components are less expensive, and they would
be more commonly available, obviating the need to as much on-site sparing.
Software
based SBCs are also a great way to get started if you think you need one. If
you don’t know how many sessions you need, then you can get started using this
and scale it up relatively easily. And it may be more economically viable for
your situation if you need to scale as you go.
Additionally,
you can add more resources to the SBC easily. At Dialogic, we believe strongly
that media and multimedia transcoding will be required for the SBC, and not
because that is a strength of ours. We believe in that because if you buy into
the notion that an SBC is basically an IP-IP gateway, then it will be obvious
that transcoding would be required since transcoding is required in a TDM-IP
gateway. It’s simple if you think about
it from that perspective.
Let’s
get more specific now. From a service provider perspective, costs and CAPEX are
clearly important and we covered some of that above from the perspective of
using COTS hardware. However, another consideration of using COTS hardware is
some hardware (the base chassis say) will go away as part of using a software-based
network node, and then CAPEX will go down. This is clearly a driver as well for
a movement to software based elements.
Another
important consideration though is that service velocity is increasing. New
services are being rolled out quicker. Agility with respect to the network
elements are required to be able to meet these needs. Software-based network
elements enable this agility because of what I said above – ease of scalability
and ease of adding newer functions such as transcoding. It’s likely that the needs of the SBC will
continue to evolve over time. With transcoding right now, we see the needs to
transcode HD Voice codecs to the more “regular” codecs. But in the future I’m
sure we’ll see video transcoding needed as well. Even if you feel video
transcoding is covered now, what about when the H.265 video codec comes out in
a year? Will you need to buy a new SBC to cover that? Or can you upgrade a piece of software?
And
what about when WebRTC enters the scene? There is transcoding required there as
well because the WebRTC audio and video codecs are different than utilized in
the networks today. But there is also a signaling conversion required as the
HTTP to SIP signaling conversion needs to occur. Having a piece of software to
upgrade would also enable this support much easier. Transcoding and WebRTC are
just two ideas that come to mind right now. What is the future to hold in this
regard? Yes, you know that there will be a lot more!
For
enterprises, software-based SBCs offer many of the same benefits as above,
especially as it relates to WebRTC since I would expect WebRTC to enter the
enterprise first. Integration of enterprise apps, whether WebRTC apps or not,
could be a big differentiator with a software based SBC. And a software-based
SBC, with its ability to scale down, offers a cost effective alternative for
enterprises that don’t have one today, because the SBCs on the market are either
too expensive for them or because the ones on the market today offer “too much”
in terms of session capability.
So
you can see why a software-based SBC is convenient. But can it do what the
hardware based SBC’s can do? Obviously, that is dependent on your supplier, but
there is no reason that the software based and hardware based SBC cannot handle
the same functions. There might be hardware assist in a hardware based SBC, but
this would be to enable higher densities or more sessions, but shouldn’t be
there to add features. At Dialogic, this is what we believe anyway. Almost 13
years ago Dialogic really drove the concept of Host Media Processing as an
alternative to the Computer Telephony Integration (CTI) boards that drove
Dialogic’s early years. We know what is
possible as the technology transitions to software. And we know that you don’t have to lose functionality
in this transition. We are experts in this “software-ization” of hardware and
have applied this mantra to our software based SBC.
Software
based SBCs have entered the industry discussion, because there are use cases
where they make sense. If you are considering using one, or want to talk more
about this, let us know.
