Two Critical Features Service Providers Need to Unleash Real-Time Communication Services in the Cloud


What’s holding service providers back from making a more complete migration of real-time communication services to the Cloud? Is it concerns about how to deploy and manage these services in the Cloud? Fear of the unknown? Or how about simply a slow start on the eventual migration path? It could be a combination of the above or a number of other legitimate reasons. However, as we look at our customer’s POCs, field trials and live networks, it shouldn’t be because it’s too difficult to dynamically deploy and manage a virtual Session Border Controllers (SBC).

A virtual SBC is an integral part of any real-time communication service in the Cloud. By using service orchestration, it’s now possible to have on-demand instantiation of an SBC as a Virtual Network Function (VNF). One significant advantage of this virtualized, Cloud environment is the ease and speed with which a VNF can be deployed. With the ability to instantiate a VNF on-demand, it becomes possible to very closely match service sizing with actual demand, scaling up when load increases and scaling down when load subsides. This is what we call cloud elasticity.

When I think about the benefits of cloud elasticity in the context of a virtual SBC, I think about how it enables rapid support of new services or enhancement of existing ones. I also think about how it enables the handling of temporary bursts in high traffic volumes, such as those that might be seen during Mother’s Day. By capitalizing on the flexibility of virtualized SBCs, service providers can reinvent how they deliver their real-time communication services in the Cloud.

However, in order to become truly cloud elastic and derive the greatest benefit from on-demand scaling, the instantiation of SBC VNFs need to be automated and each SBC instance needs to be turned-up as run-time ready.

So, how would this work? Let’s get a bit technical.

When a new SBC VNF is instantiated, there needs to be a mechanism for automatic registration with its associated management domain to support a seamless notification to discover and register each newly created SBC instance. This means that each newly created SBC instance will automatically show up in the management domain and get provisioned without any user intervention.

More specifically, when an SBC VNF is instantiated, its IP networking information, such as network interface IPs, default gateways and DNS servers, must be provided by the management domain to the SBC without manual intervention. Because dynamic startup and shutdown is possible, the size of an SBC cluster can be transparently and dynamically increased and decreased from a service orchestration solution in order to match variable traffic demand.

Yet, automated registration and discovery is only the first step. In addition to IP network information, achieving a run-time ready SBC means the instantiation of an SBC VNF must also have access to its feature configuration information. Because there could be multiple cloud environments, platforms and SBC feature configurations, it’s imperative to have support for a configuration catalog so the necessary configurations are created offline and pre-associated with a given cloud or 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 will automatically receive the appropriate configuration from the configuration catalog.

The end result: the instantiation of a running, configured SBC that is immediately capable of call processing requiring no operator intervention.

For Sonus, it has been our priority to ensure our virtual cloud-based SBC delivers this automatic configuration capability so customers can maximize the achievable value of cloud elasticity. Without these automatic configuration capabilities, instantiating a virtual SBC would require manual processing that consumes time and resources. This would substantially reduce the value of the dynamic, virtualized cloud deployment model. With Sonus, it’s possible to unleash real-time communications in the Cloud and finally free the SBC deployment model from hardware constraints.


  • MathWorks estimates that through the automated provisioning and call routing features of the Sonus solution, the company has freed up more than 250 IT staff hours per week for more important projects.

    MathWorks is the leading developer of mathematical computing software for engineers and scientists. Founded in 1984, MathWorks employs 2800 people in 15 countries, with headquarters in Natick, Massachusetts, U.S.A.
  • The industry-leading performance and scale of Sonus' SBC 5100 allows us to maintain a competitive edge in the market while delivering exceptional customer service. 

    Smart Tel is a major player in the Singapore telecommunications industry and aims to develop its global presence with new offices in Australia, Thailand, Indonesia, Philippines, India, South Africa, the US and the UK, with cost effective, easy-to-use and scalable telephony solutions.
  • We wanted to work with an industry-leading SBC vendor and our market analysis indicated that Sonus was the clear choice for this partnership.

    (GCS) is a software company founded in 2006 by Neal Axelrad and Jay Meranchik. GCS' goal is to be the best company in the marketplace. We are privately held and have offices in New York & New Jersey USA.
  • Sonus made the deployment, integration and migration to Microsoft Lync easy. 

    We are experts in identifying and delivering flexible communication solutions that scale and adapt to your business demands, empowering your business to do more, faster and with less effort and cost.