I tackled this same issue last year with m0n0wall, but soon found that 
it's not m0n0wall but just the way TCP/IP is built along with ISP and 
your Internet connection.  When you get into a phone call, your vonage 
service is using about 90 K/bs of bandwidth.  While you are on the 
phone, you go download your favorite linux distro and then all of sudden 
you can't hear what the other guy is saying.  The problem is not 
m0n0wall or Vonage or anything else in the hardware setup you have. The 
problem is, as soon as you start the download of that file, the server 
tries to send the data as fast as it can.  If it can send more than you 
can receive, then TCP/IP kicks in to start cutting things down until a 
more stable rate is achieved.  The problem with this means that m0n0wall 
can't traffic shape data when the connection you are on is over 
saturated.  So if you have a 1 MB  connection to the Internet and a 
server starts to chuck a file at 2 MB then there is nothing m0n0wall can 
do to stop this until the send server finally let's it transfer speed 
drop down low enough to pass through your hardware limitation on 
bandwidth.  Then m0n0wall has a chance to apply some traffic shaping 
rules. So it doesn't matter if you make one pipe for 56K for everything 
else and the other for 900 K for Vonage, the rules just won't have any 
effect against over saturation. Now when it comes to sending traffic 
shaping rules, m0n0wall has the advantage because it's the start point 
of the packets and thus can traffic shape those perfectly.  So if you 
have a send pipe limited to 512 K/bs, m0n0wall isn't going to try to 
send things out at 900 K/bs just for the heck of it, it will stay within 
the rules you set.

Basically, m0n0wall is not "first in line" when it comes to traffic 
shaping data being received because your ISP, Internet, etc all come 
before it. It is first in line when it comes to sending data and traffic 
shaping because on the opposite side of the Internet, it can control how 
much is being sent to begin with.  That doesn't mean m0n0wall is useless 
at traffic shaping inbound data, only that real time applications like 
VoIP will suffer because of this.  M0n0wall is great, but if the data is 
already being over crowded before it even gets to m0n0wall, traffic 
shaping won't solve the issue. That's where you get into ISP issues, but 
good luck trying to get them to do you a favor.

Basically, m0n0wall is great, but if packets are being dropped before it 
even reaches m0n0wall, there is nothing you can do about it.

Hope this saves some hair pulling like I had.

Thanks,
Michael


Richard Deno wrote:
> Ive just added a set of 150K pipes for Vonage to directly use, and 
> have been
> checking on port forwarding (the 10000-20000 block is forwarded, and I've
> tried forwarding the other ports but with no change in quality).  
> However I
> still am getting some fairly poor voice quality and not able to 
> complete the
> data transmissions.  If someone could find that dialing prefix that 
> would be
> great.
>
> Thanks a bunch--
>
> Richard
>
>