Real-time communication (RTC) services have begun and will continue, to migrate to Cloud environments. As part of this migration network device, such as session border controllers (SBCs) are also moving to a virtual, cloud deployment model. However, there are a few common myths associated with this RTC transition. Some deal with promises of cloud functionality that do not really exist, while others deal with unrealistic expectations of how a cloud deployment will be simple and easily extensible. Fortunately, for each of these myths, there is a reality that clarifies exactly what a cloud native SBC can deliver.
Myth 1: Cloud infrastructure inherently provides the necessary redundancy mechanisms needed for any mission-critical application.
Reality: While this may be possible for web-based data applications, this is generally not true for real-time communications as it has highly stringent reliability and quality requirements to ensure no sessions get dropped, to assure minimal packet loss and jitter, and to handle failover on media streams within fifty milliseconds.
It’s important to ensure when RTC is provided in a Cloud infrastructure, a cloud native SBC is available to provide high availability for signalling and media sessions in order to meet these highly stringent fail-over requirements.
[easy-tweet tweet=”Firewalls are not designed to adequately protect real-time communications” hashtags=”Data, Firewall”]
Myth 2: Secure RTC in the Cloud does not exist.
Reality: Migration of applications to the Cloud expands possible attack surfaces, so it’s often believed that real-time communications delivered from the Cloud are not secure. And while firewalls do a great job protecting data, they are not designed to adequately protect real-time communications.
With a cloud-native SBC, it is possible to provide complete media, signalling and management security for real-time communication, all the way up to and including the application layer. This means that the solution will know how to terminate, initiate and re-initiate signalling and session description protocol (SDP) for media, including handling encryption.
Myth 3: High performance for RTC requires a trade-off with feature functionality.
Reality: Full performance should not be limited by features such as encryption, DOS/DDOS prevention or secure real-time transfer protocol (SRTP). Look for a cloud-native SBC that can go one step further with two complementary development efforts. The first is the adoption of microservices, where virtual SBC performance will scale separately for signalling, media processing and media transcoding functions. The second is a unified management process that enables alignment and optimisation of the scaling between these functions.
Myth 4: Cloud scaling is simply a model based on adding more central processing units (CPUs).
Reality: While this is often true for many applications, it, unfortunately, does not apply well to media transcoding for RTC. The fundamental problem is that CPUs are not designed to meet the processing requirements of media transcoding. They are not fast enough, nor can they scale when dealing with complex codec types. Simply adding more core processors is not effective. However, with the help of a cloud-native SBC, you can scale very effectively using a combination of microservice architecture and Graphical Processing Units (GPUs).
Microservices means that transcoding as a virtual SBC function can scale independently of signalling and media protocol processing. It also means that the processor can be chosen to optimise transcoding without impacting processor choices for signalling or media processing. A software framework that exploits GPUs for compute-intensive operations can run processing systems in parallel and at a large scale. This type of solution is just not possible using CPUs. Furthermore, tests have been conducted using GPUs to transcode versus CPUs and the results prove that GPU far exceeds CPU performance and approaches the level of performance found with Digital Signal Processors (DSPs) running on proprietary hardware.
Myth 5: Simply porting an application to a virtual machine makes it optimised for the Cloud.
Reality: While it is true that applications are virtualized to run in the Cloud, making them cloud-native is a complex task. Unfortunately, virtualization alone does not make an application optimised for the Cloud. This is especially true for real-time communications. The reality is that a lot of investment in software development and interoperability testing is required to ensure that a cloud-native SBC fits seamlessly into an orchestration model so that it can be instantiated as “run-time” ready to truly unlock automated, elastic scaling.
Myth 6: Moving to the Cloud simplifies multi-vendor deployment.
Reality: From a generic framework, simplifying multi-vendor deployment seems achievable, but unfortunately, no two service orchestrator solutions or VNF managers are quite the same. Custom work would be required for the VNF vendor to integrate with multiple service orchestration vendors, and for service orchestration vendors to interwork with multiple VNFs. In part, this is because open source solutions are still immature and are not yet well adapted. It is not likely that a true multi-vendor implementation will work without pre-qualified interoperability testing.
In order to ensure easier deployment, look for solutions that comply with ETSI interface standards and provide open Application Programming Interfaces (APIs) for integration.
Although moving RTC to the cloud will undoubtedly deliver benefits that will be passed along to end customers, it’s important to be mindful of the common myths that are often linked to this migration process. Identifying these myths and understanding how to separate them from reality will prove to be a key step in the successful migration of RTC to the Cloud.
Matt Hurst, Technical Director, Sonus provides technical focus and leadership for Sonus’ EMEA SE team, leading engagements both within the Service Provider and Enterprise space.
Responsible for Enterprise Channel education and alignment, Matt has over 10 years of experience working closely within the UC community, assisting partners and customers understand and realise the potential of Unified Communications, and how the eco-system of vendor solutions fit together to form the next generation network.
Matt’s role is that of a trusted advisor, to help enable integration of UC solutions to existing enterprise telephony environments and provide a smooth and seamless migration strategy. Matt is also responsible for building and developing the SE engagement model via the channel and partner network.
Comments are closed.