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.
Application prioritization
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.
Packet duplication
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:
- Signaling
- Media
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.
Closing thoughts
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
Traditional SD-WANs do tend to just be glorified policy based load balancers.
What a waste of bandwidth!
What Evolving Networks do is wholly different. We aggregate bandwidth at the packet level, creating a single logical connection. Then, full bi-directional QoS is applied. This is zero-touch, so no need to tag packets first.
Traffic classes are created for time sensitive traffic such as VoIP, RDP, Citrix etc. Others are created for normal browsing, for email, for interactive applications, and for large traffic flows (file transfers).
By always prioritising VoIP over the others, VoIP calls are protected, while still allowing the remaining bandwidth of the entire connection to be used by the other applications, including large uploads and downloads. If no one is on the phone, then those apps have free reign on all bandwidth, so there is no waste dedicated single circuits.
Prioritising VoIP is definitely possible with SD-WAN solutions, but it just depends on the provider, and if they wrote their own software or not.
Hi Nic,
Thanks for commenting.
I agree with your comment that VoIP can be prioritized in SD-WAN. I also loved the image on your website, pretty much to the face (or to the toe :)).
Frankly most SD-WAN providers do that in some way or another. The typical way to prioritize VoIP in the application tagging level, not based on internal application data because SD-WAN providers typically work in layer 2-3 + general knowledge about application type.
My point in the post is that some claim for more than just this but that will not always hold for all types of VoIP traffic and it is required to look deeper into the details of how and what a specific provider does with regards to VoIP.
Amir
Hi Amir
I really appreciate the reply. You’re right there is far too much layer 2+3 at the moment. It’s something we are working hard to address ourselves.
Really glad you love the image and sentiment on the web page!
You’re right that ultimately the end users need VoIP to “just work” and not have to worry about how to configure it to make it so.
Having more access to flow meta data would absolutely help to bridge that gap.
It’s crazy that there also seems to be a trend of companies thinking that QoS is non-existent on SD-WAN though and that that’s a reason to stay with MPLS.
TalkTalk Business in the UK have just rejected SD-WAN, in part because of the lack of QoS.
https://www.linkedin.com/pulse/talktalk-business-reject-sd-wan-nic-elliott/
It’s crazy!