sai wrote:
> From someone using Asterisk:
> http://www.mollien.net/index.php?main=articles&article_id=24

	I can't imagine that this setup actually works.  Not to be overly 
critical, but he makes two HUGE mistakes:

1) He is prioritizing TCP ACK's for VoIP traffic.  There are a couple of 
problems with this:

1a)  RTP never uses TCP, always UDP.
1b)  There are some implementations of SIP that use TCP, but Asterisk 
doesn't currently support SIP-TCP.

2)  He makes the very mistake I pointed out at the end of my post - 
prioritizing port 5060 thinking that is is improving call quality. 
Impossible.  He also is prioritizing 16384 and 16484, which could help 
if you can make for certain that your device/asterisk is actually using 
these ports for RTP.

	Prioritizing TCP ACKS is important (not for VoIP, though) if you are 
expecting on doing a lot of uploading/serving on an asymmetric 
connection.  The author also says that there isn't anything you can do 
about the router at the "other end" when it comes to QoS.  This isn't 
exactly true.

	I actually wrote a decent document describing all of this for an 
upcoming O'Reilly book "VOIP Hacks".  It should be out in a couple of 
months, but I am pretty sure that I retain copyright on my material and 
can re-distribute it if I wish.  Let me look at my contract again and 
I'll hopefully post the doc on my website.  I'll send the link when I 
find out, because traffic shaping tends to be confusing (especially with 
VoIP) and I'd like to do what I can to clear it up...  (I'd actually 
like to CC: the author of this page if I could find his e-mail address).

> The m0n0wall Traffic Shaper (as far as I can grok it) by  Adam Nellemann
> http://m0n0.ch/wall/list/?action=show_msg&actionargs%5B%5D=49&actionargs%5B%5D=99

	This seems to be wrapping terribly in my browser and I'm too lazy to do 
anything about it.  It's late :).

> sai

--
Kristian Kielhofner