|
||||||||||
You'll have problems setting up QoS based on SIP call control ports alone. The actual SIP conversations occur on randomized ports (they stay static per call, but are dynamic for each call). I prefer to filter by the VOIP units IP address when other VOIP protocols are not possible. If your VOIP units utilize DHCP, you might want to assign their addresses permanently within your DHCP host address assignments database. If you utilize a maskable range, you can reduce the number of classification rules required. For example, if your DHCP scope is 192.168.2.64-.191, you could restrict static VOIP assignments to 192.168.2.128-.191. This would show up as 192.168.2.128/26 within the classification rules. All other hosts would be assigned out of the remainder of the scope, 192.168.2.64/26. 1) Set your pipes to the right Bandwidth, this is important. If you're utilizing a cable modem or other sporadic service, you might want to try adjusting the bandwidth values lower by testing as you decrement by 32k until you find a decent value. 2) You'll need at least two pipes, one for VOIP and one for everything else. I have three, where the last one is scavenger traffic (ftp, etc.) 3) You'll need at least two Queues, one for each upstream direction of at least two pipes. Traffic policing of received packets is of little value here. For the generic queue, utilize a weight of 1. This is commonly known as the scavenger class. 4) For the VoIP queues, do the following: 4.1 - Figure out the per call bandwidth utilization. If you don't know what your codec uses, either monitor it for a while or take some guesses. Common values that work are 96kbps and 128kbps 4.2 - Divide your bandwidth requirement by your upstream circuits bandwidth. 4.3 - Multiply the result of step 4.2 by 100 and round to the next highest integer. You want to insure that all of your traffic is prioritised instead of leaving a little bit out, so never round down. This is the weight that you will use (percentage of guaranteed bandwidth). If you adjusted the bandwidth in step 1 to reflect unstable service, readjust the weight of your VOIP queue as well. This exercise results in a queue setup that eliminates jitter. All of your VOIP conversation traffic must fit within the priority packet queue or you will likely encounter jitter when other packets are competing for bandwidth. 5) Create rules that source your VOIP units (ATA's, etc.) IP addresses for outbound traffic. Place these rules at the very top of your Traffic Shaper rules list. Assign the VOIP queue to these rules. Optionally, set the TOS flag for lowdelay. This does not affect m0n0walls packet priority queueing to my knowledge. 6) Create rules that match all of the other outbound traffic and assign the other queue to it. Test test test... If you have other regular traffic patterns that require dedicated bandwidth portions, add in more queues and classifications. padraig at premierbb dot ie wrote: > Hi > > > I have posted this question on several bulletin boards, but all suggestions failed to fix my problem. Basically I have a dsl connection, then monowall, then the lan network consisting of 60+ machines. What I am trying to do is prioritise port 5060-5062 for voip traffic only. When the network is congested, I want the voip quality to be as near as perfect as possible. could someone please show me the "true" way of setting this up? BTW the dsl connection is 6 meg down, 512k up. > > Paddy |