Give this a try:

1. setup a dhcp lease so your VOIP adapter will always have the same IP.
2. add a "VOIP" alais for the above IP.
3. setup a single traffic shaper pipe with a size of ~90% of your upstream 
bandwith.
4. setup 4 Queues: 60 (60/W up), 30 (30/W up), 8 (8/W up) and 2 (2/W up).
5. setup traffic shaper rules:
    WAN <-   *   VOIP   *   60/W up
    WAN <-   *   ????   *   60/W up   ; other high priority traffic
    WAN <-   *   ????   *    8/W up   ; low priority traffic
    WAN <-   *   ????   *    2/W up   ; very low priority traffic
    WAN <-   *    *      *   30/W up   ; the default med priority traffic

Roy...
-----------------------------------

That's great advice, I did try that earlier and I think I may have found the 
source of the issue.

I created (2) download pipes and (2) upload pipes.  One set of pipes is 
tweaked for the maximum bandwidth I can get from my ISP which is (1.5MB 
Down/ 768 K/b Up).  The second set of download/upload pipes are set at a 
static 256 K/bs limit, both upload and download.  I assigned my workstation 
a static IP address. I assigned my VoIP gizmo another separate static IP 
address.  I create a set for rules for my VoIP gizmo, I give it the maximum 
bandwidth pipe.  I create another set of rules for my workstation, giving it 
the much more limited and slower pipes.  I run a speed test on my 
workstation and it confirms I'm limited to 256 K/bs both up and down.  I 
dial up a generic phone number that has a really long automated attendant 
menu for testing.  With the VoIP only, everything is nice and smooth.  If I 
go to cnn.com on my workstation and begin watching one of their news clips. 
At the same time, I dial that number again.  This time, it's terrible lag 
and gaps.  I check the m0n0wall CPU monitor, only 5% max CPU being used.  I 
check the m0n0wall traffic monitor and I can see a problem there.  While 
watching the streaming movie, it's "breaking" through the 256 K/bs barrier 
in spots, when this happens, it causes my VoIP phone to gap and lag.  I 
think the problem is in the traffic shaping feature, it doesn't seem to be 
able to "enforce" the pipe cap properly and this I believe is what causes 
the VoIP problems that show up whether it's on or off.  Since this doesn't 
involve using the packet queue, it's possible that the original setup I had 
would work properly if the pipes could hold back the bandwidth properly.  I 
haven't had a chance to test the queue system with two workstations to see 
if the weights really make a difference yet or not.  So far it seems the 
traffic shaping system is broken or not working the way it was designed 
(generic 1.21 PC image) because it doesn't seem to always enforce the pipes, 
which it maybe why the VoIP packets get "bumped" out so to speak.

Any feedback on my findings would be greatly appreciated.

Thanks,
Michael

RP Smith wrote:
>The trick to traffic shaping is setting your upstream pipe size.  I use the 
>"Traffic Graph" to monitor outgoing traffic and under a saturated outgoing 
>file transfer.  I then lower the pipe size a little bit at a time until the 
>graph changes from a wavy line to a fairly straight line.  The wavy line 
>indicates you are not the one limiting your outgoing traffic where as the 
>straight line indicates you are the one controlling the maximum amount of 
>outgoing traffic.  Also, I only traffic shape outgoing and not incoming 
>traffic and my Vonage VoIP adapter works flawlessly 95% of the time.
>
>Roy...
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: m0n0wall dash unsubscribe at lists dot m0n0 dot ch
>For additional commands, e-mail: m0n0wall dash help at lists dot m0n0 dot ch
>

---------------------------------------------------------------------
To unsubscribe, e-mail: m0n0wall dash unsubscribe at lists dot m0n0 dot ch
For additional commands, e-mail: m0n0wall dash help at lists dot m0n0 dot ch