Hi everyone, new to the forum and to managing our Barracuda CloudGen Firewall. I've been tasked with improving our VoIP call quality, and I'm hitting a wall.
We have the traffic shaper configured with a rule to prioritize our VoIP provider's traffic (SIP and RTP) to a "high priority" queue. The calls connect fine, but about 30-60 seconds in, they become choppy and robotic. It happens consistently during our busier afternoon hours. Our internet link has plenty of bandwidth headroom overall.
My understanding is the shaper should prevent this, so I'm clearly missing something. I have a few basic questions before I start changing things:
1. Could this be a mis-match in the rule? We're prioritizing based on the service objects (SIP, RTP). Should we also be looking at specific DSCP markings from our phones, or is service-based usually sufficient?
2. I'm curious about the interaction between the "high priority" queue and the overall bandwidth limits on the rule. If the rule itself has a bandwidth cap, does the priority queue still guarantee latency within that slice, or does it just get priority for whatever bandwidth is left under the cap?
3. Has anyone found that enabling "Adaptive Response" for the VoIP rule helps with this kind of intermittent choppiness, or does it usually make things less predictable?
I want to make sure I'm troubleshooting the right layer. Any insights on where to look first would be super helpful. The vendor docs explain how to set it up, but not as much on fine-tuning for real-world issues.
Absolutely on the right track with question 2. That's the most likely culprit. If your rule has an absolute bandwidth cap, your high priority queue is only high priority *within that capped slice of bandwidth*. It doesn't get to jump ahead of other traffic outside that rule's allocation. You're creating a tiny VIP room that still gets crowded.
> Should we also be looking at specific DSCP markings
Service objects are a blunt instrument. You must match on DSCP (likely EF for RTP, CS3 or AF31 for SIP) *and* ensure your firewall is honoring/not remarking them. Your provider's traffic might not match your internal service definitions, especially if it's encrypted or uses non-standard ports.
The "Adaptive Bandwidth" feature can be a disaster for real-time traffic. It dynamically adjusts rule limits based on link utilization, which introduces jitter. For VoIP, you need predictable, fixed allocations. Turn it off.
Pull your traffic shaper statistics during the problem period and look for packet drops on that specific queue. The data won't lie.
—davidr
Agreed, but missing the forest for the trees. The first place you need to look isn't the rule, it's the shaper's own logs for drops. Find your VoIP rule's queue and check the drop counter. If it's incrementing, your "high priority" traffic is being discarded anyway because you've probably set the queue depth absurdly low in the name of low latency. A shallow bucket is still empty fast.
Also, "plenty of bandwidth headroom overall" is a red flag. The shaper only matters when there's contention. If your calls degrade at busy times but total utilization is low, you've likely got bufferbloat on your ISP handoff *outside* the firewall's control. The shaper is policing politely in the driveway while a riot happens at the gate. Try a continuous ping to 8.8.8.8 during the choppy period and watch for latency spikes.