WAN AckQueue on VOIP Shaping
-
No, I don't believe so. First off, that post reply is describing any stateful firewall such as pfSense. Also, from what I understand, floating rules are evaluated before all others which contradicts what this thread reply said. I'm fairly sure pfSense isn't failing to recognize ACK packets as its a basic part of TCP.
Can I see a screenshot of your floating rules page?
-
Is it classifying the UDP response (to my initial connections) as ACK?
If nothing else, this is forcing me to consider how our phone systems work. Thanks for answering, btw.
edit: The first 3 rules are for IPSEC - and don't apply to the relevant interfaces.
-
In your two VoIP rules, change the protocol from any to UDP, and get rid of the qACK queue redirect.
-
I doubt that any udp packet is being classified as ack, it is probably something else in that queue.
Just curious but what method of traffic shaping are you using?
When I was initially setting my voip stuff up I tried HFSC but had issues getting it right. I switched to PRIQ and things went much smoother. PRIQ is so much easier to config.
My needs are VOIP over everything else and it seems your needs are similar. You might want to run the wizard again and try PRIQ. If you are using PRIQ already then I typed that for nothing :)Do you have a local pbx and you are trunking to an upstream provider or is your pbx itself hosted elsewhere? Not that it makes a huge difference, just wondering. FWIW once I got traffic shaping working I noticed a huge jump in call quality, so it is worth it to keep at it. No more weird dropouts and stuttering.
-
Why is qACK named qACKph? Did you rename it after creation or did you manually create all your queues?
-
I'll make those changes to UDP and eliminating the qAckph soon enough.
We originally used the wizard, and then went back in and created the queues manually (trying to understand how this all works), so renamed the queue.
I originally had Firewall rules under specific instances, but wanted to move them to Floating so that we don't have any confusion with Gateway policy routing, etc.
And I'm using PRIQ - was going to look into HFSC but it's probably not worth the effort.
As far as VOIP needs are concerned, we're actually using a hosted solution so the PBX is offsite (with the vendor). All I need to do is provide the phone with power and an internet connection, and the rest is cloud-managed. Because of this, part of me thinks that limiting to just UDP traffic might get actual call traffic, but I would think that there's more than that. (edit: This is why I have all traffic to the subnet hitting the queue).
-
For the record, we're using RingCentral which is exactly the same type of cloud-based VoIP provider you're likely using. All I have are a bunch of phones and an Internet connection. My VoIP queues are busy when people are on the phones, and everything works well. We have two IPs that our phones talk to, and I have a pair of floating rules that move traffic from the RingCentral IP alias to their respective queues.
If you've been playing around and trying various things, including manually creating your shaper and queues, I might suggest blowing it all away and starting off fresh with a simple PRIQ queue with VoIP support only. Create an alias for your upstream cloud IP address(es) and then use that alias as your generic VoIP provider in the Voice Over IP section of the wizard.
-
Out of curiosity, could I see your floating rules? You also don't have ackQueues and UDP only?
-
Here you go, and yes I don't have any VoIP traffic using an ACK queue.
-
I assume you are using Jive based on your alias.
According to their docs their phones need tcp traffic, so maybe that acks were to your provider. https://wiki.getjive.com/display/COREMAN/2.0+Network+Requirements+and+Best+PracticesI agree with KOM you should blow your config away and start again. I would do it real basic and make sure it works, then massage the rules if needed. I would only worry about sip and rtp traffic at this point which is udp so no ack queue is needed.
-
Thanks for all of your help.
-