I’ve seen a few threads here asking about SD-WAN failover for real-time traffic, usually after someone’s quarterly all-hands call drops. Most solutions treat all packets the same, which is fine for web browsing but a disaster for VOIP. If you’re using Versa and paying for multiple underlays (like MPLS + broadband), you should be steering your critical SIP/RTP traffic based on the actual *application*, not just a destination IP.
Here’s a condensed guide for setting up application-aware policy-based routing for VOIP. This assumes you already have your WAN links and basic routing in place.
First, you need a proper application definition. Versa has a built-in DB, but for custom SIP servers, define your own:
```xml
CUSTOM_SIP
udp
5060
5061
```
The key is the routing policy. You’ll create a match rule for this application, then a path-preferred action pointing to your low-latency, low-jitter underlay (e.g., MPLS). Don’t forget to also match the associated RTP media ports (usually 10000-20000 UDP).
A few pitfalls I’ve hit:
* **Asymmetric routing:** If your firewalls are stateful, ensure the return path is forced back the same way. Use a PBR policy on the return direction as well.
* **Cost bloat:** It’s tempting to send *all* real-time traffic over the premium link. Use QoS marking (DSCP EF/CS5) and policing so your VOIP traffic doesn’t get greedy and eat the whole circuit.
* **Vendor nuance:** Versa’s path monitoring (BFD) is separate from the application steering. Just because the path is up doesn’t mean it’s fit for VOIP. Consider adding jitter/latency thresholds to the path quality check if your license supports it.
The real test is during a failover. Does the call drop, or just degrade? With this setup, a link failure should trigger a reselect to the next-best path that meets the quality criteria, but some session persistence might be needed depending on your SIP platform.
Has anyone else tried this with a blended cloud (like SBC in Azure + on-prem)? I’m curious how the policies hold up when the “application” is split across regions.
—L
Every cloud has a dark cost.
> The key is the routing policy... Use a PBR p
That asymmetric routing point is huge. We had calls dropping at the moment of failover because the state table on our firewall didn't see the return flow on the new path.
A related gotcha: you can't just rely on port ranges for RTP. Some systems (looking at you, WebRTC) use ephemeral ports all over the place. We had to supplement the app definition with DPI signatures to catch the media streams properly. Versa's classifier works, but it adds a tiny bit of latency on the first packet.
System calls per second matter.
Oh, that's a good point about the state tables. Our setup is in AWS with Transit Gateway, and I'm trying to think if we'd hit the same thing with a VPC route table update during a failover. If the path changes, wouldn't the security group state just time out and drop the call anyway? Or is that different from a firewall's stateful inspection?
Also, the DPI latency bit is scary for VOIP. How much is "a tiny bit"? Even 20ms on the first packet feels risky.
Oh, that part about matching the RTP media ports is super relevant. I'm trying to set this up for our new cloud PBX, and their documentation says the audio ports are dynamic, not in a fixed range. So if I just define 10000-20000, I might miss traffic, right?
You mentioned the app definition at the start. For a situation like that, would you skip the port match entirely and just rely on Versa's own SIP/RTP classifier to identify all of it? Or do you still define the known SIP ports and then let DPI catch the audio streams?