[ previous ] [ next ] [ threads ]
 
 From:  "Chris Bagnall" <m0n0wall at minotaur dot cc>
 To:  "'Paul Dugas'" <paul at dugas dot cc>, <m0n0wall at lists dot m0n0 dot ch>
 Subject:  RE: [m0n0wall] Traffic Shaper for VoIP
 Date:  Mon, 20 Jun 2005 15:01:36 +0100
> I've currently got a couple sites setup with Asterisk PBXs 
> and m0n0wall routers.  I used the "wizard" on each then added 
> a rule to send IAX traffic to the "High Priority" queues.  
> Seems to work but the traffic levels aren't too high so I've 
> not really stressed it.

I've also deployed similar setups at client premises. I tend to run the
magic shaper, then modify the config a little bit. I get rid of the high
priority upload #3 option, drop the "tcp ack" rule (since "small packets"
should catch anything first), then move all vpn stuff to high priority #2. I
then use HP#1 for IAX (port 4569 UDP).

Likewise on download I define a second high-priority queue for VPN traffic,
then prioritize IAX traffic above that.

In general it works fairly well. I found the key to getting it working at
its best was to make sure not to overestimate the up/down pipe sizes
(particularly upstream). Use an online speed meter to measure the true speed
- I use adslguide.org.uk, but you might want to find one a bit more local to
you. I found the magic shaper wizard was overestimating my upstream
bandwidth by about 10kb/sec, which unfortunately makes the difference
between an 80ms ping and a 900ms ping on my connection under load.

> I'm curious as to how others are doing traffic shaphing for 
> their VoIP traffic.  Are you setting up dedicaed pipes or are 
> you using queues within single pipes in each direction?  How 
> well is it working for you?  How have you tested it?

As regards testing it, get a couple of clients running busy torrents
(popular linux iso images are a good start if you need to keep it legit,
I'll leave the less legit stuff up to people's imagination :-) ). Then try
making a number of simultaneous calls through Asterisk and see what the
quality is like (and particularly the delay). If bandwidth is tight, try to
use IAX trunking and a bandwidth efficient codec (GSM and G729 come to
mind).

Hope that helps. If anyone's got rules for these scenarios, please let us
know how you're doing it - I'm deploying quite a few of these setups to
clients at the moment and it'd be great to improve on the setup as much as
possible.

Regards,

Chris
-- 
C.M. Bagnall, Director, Minotaur I.T. Limited
Tel: (07010) 710715   Mobile: (07811) 332969   Skype: minotaur-uk
ICQ: 13350579   AIM: MinotaurUK   MSN: msn at minotaur dot cc   Y!: Minotaur_Chris
This email is made from 100% recycled electrons