[ previous ] [ next ] [ threads ]
 
 From:  krt <kkrrtt at gmail dot com>
 To:  padraig at premierbb dot ie
 Cc:  m0n0wall at lists dot m0n0 dot ch
 Subject:  Re: [m0n0wall] Voip Quality
 Date:  Tue, 16 Jan 2007 17:14:50 -0800
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