Why SD-WAN is limited when it comes to VoIP quality based routing
Let’s face it, the most important application for SD-WAN is real-time communications (aka VoIP). That’s why many SD-WAN vendors have special capabilities in their products for handling VoIP and many highlight VoIP and UC in their marketing material.
Here are a few examples:
- VeloCloud specifically handles Unified Communications (UC) traffic
- Versa Networks released Mean Opinion Score (MOS) based traffic steering for UC
- Silver Peak talks about the importance of reliability & quality for VoIP services and dedicates special functionalities for this application
And the list goes on.
How is the magic done?
SD-WAN solutions vary in the way they optimize delivery of VoIP traffic but basically it boils down to the combination of the following two techniques.
Simply sending VoIP over the “better” available network interface.
How does the SD-WAN system decide which network interface is “better” for VoIP?
Some would just prefer for example MPLS over broadband, others opt for the less utilized interface and the more advanced solutions would actually check parameters such as delay, jitter and packet loss for making this decision.
Sending the voice/video packets twice over 2 different network interfaces and removing this duplication at the other end. In cases where only one network interface is available some still duplicate VoIP packets and send them twice over the same network interface. This approach enhances VoIP quality of experience on account of other applications and increases bandwidth consumption which might get significant especially if video is involved.
SD-WAN limitations optimizing VoIP
To really optimize VoIP, 2 layers of the VoIP application should be addressed:
The signaling layer will allow to know the real and final destination (not just next hop of proxy) and the identity of source and destination users. It may also allow to understand which application has initiated the VoIP session, something that becomes important and hard to crack as WebRTC is being embedded into more and more applications from which users may initiate real-time communications (e.g. Slack, Workplace by Facebook, Hangouts and many many more, some proprietary and unknown).
The media layer will allow to not only understand the characteristics of the session (media types, codecs, frames dependencies…) but also analyze the receiver feedback provided in the RTCP packets which actually detail the experience the receiver has.
The complexity of this is twofold. Understanding the application level in these details is not something SD-WAN solutions are capable of today, even the most advanced ones that go beyond layer 2 & 3 don’t have this level of intimacy with the application layer.
The other challenge relates to being able to access this information. Naive VoIP services are still widely open for security attacks as they don’t encrypt media and signaling. This naïve approach is going away with WebRTC leading the pack. In WebRTC, all communication is encrypted so understanding what’s going on in the media level is not possible unless you are terminating the session.
The signaling part is also complex as WebRTC doesn’t define signaling. The most common approach to signaling in WebRTC services is proprietary so even if you want to work on the application level and terminate the signaling, it is not possible unless you are part of that specific service.
Coming back to the examples of VoIP optimization done by SD-WAN vendors, there is only so much SD-WAN vendors can do in this space. When a vendor claims for specific VoIP optimization that is based on quality of experience or similar considerations, I suggest to check the details of how this optimization is implemented and which applications it covers.
Image source: Frits Ahlefeldt
Why a SW defined network will foster WebRTC application innovation
Why your decision for premise vs. managed deployment of WebRTC service is not just about cost
Never miss a post. Subscribe for TheNewDialtone