[ previous ] [ next ] [ threads ]
 From:  Aaron <lists at mycommunitynet dot net>
 To:  "John ." <jvoigt at gmail dot com>
 Cc:  'm0n0wall' <m0n0wall at lists dot m0n0 dot ch>
 Subject:  Re: [m0n0wall] VOIP issues/can't specify a particular pipe.
 Date:  Tue, 12 Apr 2005 20:09:44 -0700
I understand about the pipes and used the Magicshaper wizard to create 
most of it. That already works fine and I do not need help with that. 
The issue is that no matter what I do with just 2 pipes, I will have 
issues with viop. The upstream p2p traffic will always fill whatever 
size pipe is available.

So the easy solution seems to shape the upstream traffic down more. 
Nope, because when I do that, it reduces the total amount of 
bandwidth...including to the machine running voip and things get even 

My idea was to give general traffic a small upstream pipe, but give the 
device doing voip, a much larger, separate pipe. Sure it reduces the 
outbound potential for most people, but that is not the biggest issue. 
I would much rather have VOIP working well than allow people to send 
large amounts of data.

So is it not possible to have more than 2 pipes?

On Apr 12, 2005, at 5:57 PM, John . wrote:

> You need to create 2 pipes - 1 for inbound data and 1 for outbound.
> Each should be about 95% of your total bandwidth in that direction (to
> leave some slop for TCP overhead.)
> You need to create queues inside these 2 pipes - 1 for your VoIP in
> (in the inbound pipe) and 1 for VoIP out (in the outbound pipe) each
> with weight 100.
> You need to create appropriate queues in the 2 pipes for your other
> traffic types. (normal, bulk etc.)  Each should have an appropriate
> weight.
> You need rules to make the traffic go the right places.
> I think your problem is you have too many pipes.  You really only want
> 2 - 1 inbound and 1 outbound.
> On 4/12/05, Aaron <lists at mycommunitynet dot net> wrote:
>> VOIP Traffic Shaping. Can't I specify certain pipes?
>> Hello all. Sorry for the length.
>> I have read through the archives and there is a lot of information in
>> there about VOIP. However I have found that giving voip stuff priority
>> does not seem to fight audio issues well enough.Outgoing traffic at
>> more than 175Kbps causes serious issues on the far end of the call and
>> I can't seem to reduce the m_total_upload pipe and send voip out
>> another pipe that I create. This is on a Soekris Net4501 100mHz/32MB
>> with m0n0 v1.1 (It works GREAT BTW. hundreds of days of uptime with no
>> issues).
>> Here is what I have. I have an ADSL connection with actual throughput
>> of about 550Kbps upstream and 2800 downstream. There are up to 30
>> people using the network at any one time. It all runs through m0n0wall
>> and all addresses are private. Traffic shaping is turned on and I have
>> P2P set to lowest priority. I have an asterisk box at
>> that works with my VOIP provider Broadvoice. I am using 1:1 nat to 
>> give
>> me connectivity to the asterisk box outside my LAN at a WAN IP of
>> x.y.z.90 .
>> This all works, but outgoing traffic (P2P, FTP, HTTP) begins to cause
>> issues with VOIP. I test this by calling a landline that I still have
>> and playing the radio into the voip line and listening on the PSTN 
>> side
>> while I do different things such as using P2P, FTP etc). Downstream 
>> has
>> little effect on it.
>> Things I have tried:
>> 1) Create a voip queue with a priority of 100 using pipe
>> m_Total_upload. Rules to send all traffic from to the
>> VOIP queue. This didn't really do anything. I also tried to prioritize
>> all traffic destined for the ip of sip.bradvoice.com.
>> 2) Create 3rd pipe 400Kbps, Changed VOIP queue to use pipe3 as its
>> target and priority of 100, and a rule sending all traffic from
>> through the voip queue (which is supposed to be using
>> pipe 3). I also tried directing all traffic, UDP traffic and traffic 
>> to
>> sip.broadvoice.com through this pipe.
>> This didn't work. When I shrunk the  m_Total Upload pipe down, it
>> would cause issues for voip, so it seems voip traffic was going 
>> through
>> it rather than the voip pipe. Was the rule was not catching the
>> traffic? I even tried sending ALL udp traffic from any
>> source/destination through the voip queue. Still no change as when I
>> would shrink the m_total Upload down, it would cause voip issues.
>> Does anyone have something that works well to control upstream traffic
>> while still allowing voip access to more bandwidth?
>> Rules - http://www.scs.wsu.edu/~arobinso/tmp/SafariScreenSnapz010.jpg
>> Pipes - http://www.scs.wsu.edu/~arobinso/tmp/SafariScreenSnapz012.jpg
>> Queues- http://www.scs.wsu.edu/~arobinso/tmp/SafariScreenSnapz011.jpg
>> ---------------------------------------------------------------------
>> 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