Current Location ：
SD-WAN and Voice: What Changes for Real-Time Traffic
SD-WAN is sold as an improvement for everything, and for most application traffic it is. Voice is the exception that deserves specific attention, because the mechanisms that make an overlay good for data can work against a real-time stream. Automatic path selection reacts to conditions it measures, tunnelling adds overhead, and failover changes the path mid-call. Each of those is fine in principle and consequential in practice. This article covers what an overlay changes for voice, where the benefits are real, and what to verify before live calls depend on it.
What Overlays Do Well for Voice
The genuine benefit is path diversity. A site with two transport options and an overlay that can move traffic between them is better placed than a site with a single circuit, provided the movement happens for the right reasons and at the right speed. Branch sites that previously had no backup path gain one, and that is a real availability improvement.
| Capability | Benefit for voice | Condition for it to help |
|---|---|---|
| Multiple transports | A second path exists when the primary degrades | The second path independently meets voice requirements |
| Continuous measurement | Degradation is detected without waiting for user complaints | Detection thresholds are set for real-time sensitivity, not throughput |
| Application awareness | Voice can be steered deliberately rather than by accident | Voice is actually identified and classified correctly |
| Central policy | Consistent behaviour across many sites | Policy is reviewed when sites or carriers change |
Where Overlays Work Against Voice
Three mechanisms cause most of the trouble. The first is failover timing: an overlay that detects a problem and switches path is doing the right thing, but live calls on the old path are usually already damaged and may drop during the transition. The second is overhead: tunnelling consumes capacity and can push a contended link past the point where voice fits. The third is reordering: packets arriving out of order look like loss to a real-time receiver even when nothing was actually lost.
- Failover thresholds tuned for throughput may never trigger for the conditions that damage voice
- A backup path that is technically available but poor will preserve the call and ruin its quality
- Tunnelling overhead is often omitted from capacity calculations and appears as intermittent quality loss at peak
- Reordering across parallel paths can be worse for audio than the failure that caused the switch
- Encryption added by the overlay may duplicate encryption already applied by the voice platform, adding cost for no benefit
Local Breakout Is a Real Decision
Should calls leave the site directly to the carrier, or travel across the overlay to a central breakout? Central breakout gives consistent policy and often simpler carrier arrangements. Local breakout gives shorter paths and avoids hauling media across a WAN to reach a network that is geographically close. The right answer depends on where your carrier interconnects sit, what regulatory or recording requirements apply, and how your sites are distributed. It should be a decision, not a default inherited from the data design.
What to Verify Before Live Calls Move
Verification has to include the failure case, because the failure case is the whole point of having two paths. Place calls while the primary path is degraded and observe what happens to audio, to call survival, and to the time it takes for the switch to settle. A configuration that has only ever been tested on a healthy network is untested where it matters.
- Call quality on each path independently, not only on the combined result
- Behaviour of an established call during a forced path change
- Time to detect degradation and time to complete the switch
- Whether emergency calls and location-dependent routing survive a path change
- Overhead measured at peak, including tunnelling, against the real capacity of each transport
- Recording and monitoring paths, which often take a different route than the media they observe
Redstone Approach
Redstone works with network and voice teams to plan voice behaviour on overlay networks. Our teams can help classify voice traffic correctly, review failover thresholds and breakout design, coordinate testing with your SD-WAN vendor, and verify call behaviour during controlled path failures. These engagements support platforms including the Redstone REX IP-PBX and RGW gateway lines, in designs that mix on-premises, cloud, and hybrid components. Specific configuration recommendations are scoped in writing against your transport contracts and site topology.
Redstone Systems, Inc. founded in Delaware, USA in December 2002, has been the ODM vendor for many well-known communications companies, serving the Southeast Asian market. In 2020, Redstone Systems will begin to return to the North America market with its self-developed brand.
Redstone has a complete product line of intelligent voice gateways, providing IP-PBXs, analog VoIP gateways (FXS/FXO), digital VoIP gateways (E1/T1), border appliances, and session boundary controllers (SBCs).
With advanced technology in digital signal processor (DSP), speech coding and speech processing, as well as efficient operational tools such as cloud remote management, auto provisioning, Redstone gateways are widely used in markets of enterprise communications, cloud communications, call centers, operators’ IMS/SIP trunks, bringing users friendly, efficient and reliable communication experience.
For more information about Redstone, You can follow us on Facebook, Linkedin, and Youtube to be the first to get the latest news.
