Sorry, there might be some confusion in a statement that I made -
Setting the TOS flag is for matching packets that have the TOS flag set.
This should only be done if you're VOIP device has marked the packets
accordingly, otherwise they will not be classified into the correct queue.
> 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
> 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
> 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:
>> 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.