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, 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.

Related Articles to 'Why would you want a software based session border controller?'

"The contact center use case looks like a natural

WebRTC Webinar Q&A #1 "Is WebRTC 10 years too

"How Does Dialogic Fit In with WebRTC?"

"Where do IMS and WebRTC Intersect?"

Why would you want a software based session border controller?

\n

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.

\n

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.

\n

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.

\n

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.

\n

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.

\n

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, then CAPEX will go down. This is clearly a driver as well for a movement to software based elements.

\n

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?

\n

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!

\n

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.

\n

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.

\n

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.