next »

[datafirm]

Trying to get our VoIP shaping dialed in right now and I noticed a few anomalies.  I have VoIP adapter set to a static IP address so the VoIPUp and VoIPDown queues are directly tied to that. 

Making calls outboud the VoIP queue appears to be working when one checks the output of pfctl -vsq.  But inbound calls get mapped to the qwandef queue and not hte VoIPDown.  Any ideas of what needs to get tweaked to fix this?

I'll do some more playing around on my side.

TIA

[Leoandru]

OK, check again! You wont see traffic flow for inbound lan connections appear in qwandef, thats an outbound queue on the wan side. use status -> queues or since you seem to like shell pftop -s1 -v qeueu will give you a curses-based view of the queues. -s1 will cause it to update every second.

[sullrich]

Also, try pressing 0 in pftop to switch to a alternate altq view.

0-9 are different views in pftop.

Also, if this is a full installation then run cvs_sync.sh releng_1 and rerun the traffic shaping wizard to ensure you are on the latest code.

[bruor]

i am using release beta2 and have been trying to find the release snapshots to try out the traffic shaping since i am still having the same issues with bittorrent traffic using the voipUP queue.
the pfsense.com/~sullrich/RELENG.../   folders do not show up for me,  is there a different place these are stored?

[sullrich]

If you have a full installation simply run cvs_sync.sh releng_1 from a shell prompt.

[datafirm]

OK, check again! You wont see traffic flow for inbound lan connections appear in qwandef, thats an outbound queue on the wan side. use status -> queues or since you seem to like shell pftop -s1 -v qeueu will give you a curses-based view of the queues. -s1 will cause it to update every second.

Thanks for the pftop tricks

I am on RELENG_1_SNAPSHOT_03-19-2006 and have re-run the traffic shaper.  When incoming VoIP traffic comes in the only two queues that seem to have traffic are qwandef and qlandef.  qVOIPDown never seem to get hit. 

All traffic needs to run through our Asterisk box so altq should see traffic hitting  that address and delegate accordingly.

Any ideas or help is appreciated.


BTW your team should add UDP 4569 IAX2 to the VoIP ruleset when one does not implicitly set the ip address.

Thanks

[sullrich]

Then the VOIP traffic is not being tagged correctly.  Double check the inputted IP during the wizard.

[datafirm]

Then the VOIP traffic is not being tagged correctly.  Double check the inputted IP during the wizard.

I think the issue is that we are using IAX2 to connect to our providers.  IAX uses persistent connections when you register with them.  Does altq monitor the already established connections when using these queues?

Thanks

[hoba]

you need to reset states (the wizard says that at the final step btw). traffic is assigned to a queue on initialization of the connection.

[datafirm]

you need to reset states (the wizard says that at the final step btw). traffic is assigned to a queue on initialization of the connection.

Thanks!  Sorry I missed that.

Now I have all voip traffic going through voipup, still does not route to voipdown which is traffic coming from the asterisk box to the outside world.  Perhaps that is because the IAX2 connection.

BTW I wanted to mark your response as problem solved, but then I could no longer reply to this thread!

[hoba]

ok, fixed