VoIP performance is the one data application that can suffer most from WAN issues. The right SD-WAN platform can protect you from the challenges of using the internet for voice.
If there’s one application that brings chills to the hearts of SD-WAN implementers it’s providing a predictable real-time voice service. So let’s talk about how SD-WANs might help.The problem with voice
The Problem with Voice: We need to separate from the theory of voice and the reality of voice. The theory goes something like this. The Internet is fine for email and web browsing. It’s even pretty good for personal voice. But if I want to deliver a voice service, day-in-day out without a hiccup, then I run into a problem. Voice is a real-time protocol with strict tolerances around latency, loss and jitter. Exceed those tolerances and symptoms common to a poor voice service set in. Increased delays from traffic routing or lost packets disrupt voice calls. Outages and brownouts can cause calls to drop.
With a story like that the only answer would seem to be MPLS or some other SLA-backed backbone from companies such as Aryaka or Cato Networks. The reality of voice is more complex. It’s not that you can’t run voice over the public Internet, services like Skype proved that’s possible, it’s just more challenging with business-class voice. Some Internet routes are in fact very predictable, particularly within North America. At the same time, MPLS availability is high, but not necessarily for the local loops where there is usually only one active connection per office.
How SD-WANs help:
SD-WANs use a number of techniques to improve voice. Application-based routing allows SD-WANs to steer voice traffic across the optimum path. Alone this is a big improvement over the general Internet. By running two active connections, SD-WANs can switch active calls to the secondary connection fast enough to preserve the call. How fast is fast enough? Conventional IP routing converges to alternate paths in about 30 to 40 seconds. Several SD-WAN solutions can detect an event and failover in a few seconds — fast enough for maintaining TCP sessions, but not fast enough for voice. Some SD-WAN solutions can offer sub-second failover, sufficient to keep the voice session. Voice quality is also improved by compensating for packet loss. Some SD-WANs will use Forward Error Correction to regenerate packets on the fly using a technique similar to erasure coding done for RAID systems. The system adds parity bits to packets and injects parity packets in the packet flow, allowing the receiving SD-WAN node to recover lost packets. Packet duplication is the safest way to quality voice. With packet duplication, the SD-WAN nodes mirrors packets between two or more paths. Should packet be lost on one link, the mirrored packet be delivered across secondary links. Packet duplication can make all the difference, but it’s not perfect. Duplicating packets consumes bandwidth on the secondary connection. Packet ordering can be an issue as well that the SD-WAN must address, but it is effective.
A call center client of mine, for example, had 1,500 people in Philippines connected to a phone switch in Los Angeles via the MPLS network. The company found that it needed to improve failover since seismic events, or other issues would interrupt calls, leading to dropped calls and forcing phones to re-register. While not frequent, the downtime and customer experience was costly. Using SD-WAN with duplication of packets eliminated this issue. By tweaking the percentage of duplication on the second circuit, they obtained a level of failover protection unmatched by BGP while reducing the bandwidth cost of duplication required.
Taken together these measure should enable you to deliver voice over reasonably well performing connections that are less costly than MPLS. But across very long distances or in underdeveloped internet regions, the only alternative may be an SLA-backed backbone. Even then when voice is working over the Internet there’s no guarantee you’ll have Five-Nines of reliability. If you’re fine with a service like that then you should have no problem running voice out across an Internet-based SD-WAN.
