People don't typically get excited about networks. They're the pipes underneath everything else, while the applications running across them get the attention. Email, video, data, and voice all depend on the network. When it works, nobody gives it much thought.
The problem is that those applications don't all react the same way when network performance drops. Email can tolerate a delay without anyone noticing. Voice can't.
A voice call is fanatical about network performance. Packet loss, latency, or jitter can quickly affect call quality because the conversation is happening in real time.
Which is why, when we talk about SD-WAN in 2026, we should also be asking whether the network carrying your voice traffic is optimized for voice. In many deployments, it isn't.
SD-WAN did one job well. Voice is a different job.
SD-WAN was designed to make enterprise networks more efficient and intelligent for traffic routing. Instead of one large and costly MPLS circuit, you have multiple paths (fiber, broadband, cellular, satellite), and the SD-WAN controller decides which path each packet should take based on policy, which was a profound step forward from the networks of previous decades. This is why most enterprises now run some type of SD-WAN.
The reason is that voice has a different tolerance profile from other applications, defined by three key metrics:
- Latency - the time it takes for a data packet to travel from a source to destination across a network.
Target: < 150 ms. -
Jitter - the variation in delay for data packets traveling across a network, < 30 ms
-
Packet loss - the amount of data packets lost traveling across a network, < 1%
All three need to remain inside their narrow tolerance bands throughout the call which requires real time network performance visibility. If any of these tolerance are not met, calls will be subjected to garbled audio, awkward silence, or even a dropped call.
Voice AI makes those tolerances even more important. When two people are on a call and the network stumbles, we can often compensate. We ask someone to repeat themselves or use the context of the conversation to work out what we missed.
Voice AI has a different challenge. Packet loss and jitter can result in missing phonemes, distorted words, audio gaps, and unstable transcripts. That can affect what the AI understands and how it responds. Research into network performance and AI voice agents shows that network degradation can interfere with speech recognition and turn detection, even when the AI models themselves are performing as expected.
Latency matters too. A voice AI interaction has to account for speech recognition, AI processing, and text-to-speech, alongside the latency already present across the network. Those delays accumulate across the interaction, making consistent network performance important for natural, real-time conversations.
As more AI agents start handling live calls, network performance can affect more than whether the conversation sounds good. It can affect whether the AI understands the caller correctly in the first place.
What voice-optimized means in practice
A voice-optimized SD-WAN deployment is one where the controller and the edge routers are meticulously tuned for application policy and then monitored in real time for traffic behavior. Here are the features that do the heavy lifting.
-
Application-aware routing in milliseconds: the edge routers are directed by a decision-making network controller about where to send each packet. The edge routers react within milliseconds to shifting network conditions which is much quicker than legacy routing protocol reaction times.
-
Forward error correction: when a voice packet is lost in transit, a voice-optimized network can rebuild it. The audio data is sent with mathematical redundancy that the receiving end can use to reconstruct lost data. On a link that's struggling, forward error correction can make the difference between a low and high quality conversation.
-
Continuous link probing: the SD-WAN edge sends frequent probes to every available path to measure latency, jitter, and packet loss. When a path degrades below a quality threshold, the controller directs the edge router to send traffic over a healthier path. This failover mechanism keeps calls which would have been dropped in legacy networks, connected.
-
Quality-of-service enforcement: voice packets are favored over non-real-time traffic and receive preferential handling across the network.
-
Packet Duplication: is an SD-WAN loss-protection technique in which the sending edge router replicates each packet of a selected flow, typically voice, and transmits the copies simultaneously across two different WAN paths. The receiving edge forwards whichever copy arrives first and discards the duplicate. This prevents call disruption should a path go down during a call.
These SD-WAN features are not new, however they are rarely implemented on most SD-WAN networks.
Why this should be in your next SD-WAN conversation
MPLS networks were commonly designed to prioritize voice traffic, but their cost pushed many organizations toward less expensive internet-based connectivity. During that transition, the same attention to voice prioritization did not always follow.
That can create problems when an SD-WAN is configured primarily around connectivity and failover rather than the performance thresholds voice needs. Calls may drop or become difficult to hear. Teams or Zoom calls can become unreliable for branch employees. Yet the SD-WAN may be doing exactly what it was configured to do: routing traffic according to its policies and switching paths when links fail.
The problem is that a voice call can deteriorate before a link fails completely. If latency, jitter, or packet loss moves outside acceptable thresholds, the call can suffer even though the underlying connection remains available.
The cost of that degradation adds up. A poor-quality sales call can disrupt an opportunity. A dropped support call creates a frustrating customer experience. Internal meetings affected by poor audio waste time and often need to be repeated. Across enough calls, network performance problems can become a real operational cost.
What to ask when SD-WAN comes up
If you're evaluating a new SD-WAN infrastructure, refreshing an existing one, or inheriting one from a predecessor, voice optimization should be a specific request of the vendor. Ask the following questions during vetting:
- How does your platform handle application-aware routing for voice, and how fast does the network react?
- Do you support forward error correction on voice traffic, and under what conditions does it engage?
- What's the failover window on your SD-WAN when a link degrades or fails, and how does that interact with an in-progress voice call?
- Is packet duplication an option?
If voice is treated like any other application, or failover takes several seconds, it’s worth asking more questions. Look for capabilities such as sub-second failover, voice-prioritized path selection, and forward error correction. These are better indicators that the SD-WAN has been designed with real-time voice in mind.
Networks are supposed to be boring. The applications that ride on top of them are where the user experience lives. But voice is the one application your organization can't fake its way through, and the SD-WAN underneath it has to be designed for that. Treating voice as a first-class concern on the network has moved from edge case to mandatory requirements.
Read more about Pure IP's new voice-optimized SD-WAN here.
