[ previous ] [ next ] [ threads ]
 From:  "Michael Graves" <mgraves at mstvp dot com>
 To:  "m0n0wall at lists dot m0n0 dot ch" <m0n0wall at lists dot m0n0 dot ch>
 Subject:  Re: [m0n0wall] VOIP issues/can't specify a particular pipe.
 Date:  Wed, 13 Apr 2005 12:13:24 -0500
I run an Asterisk server through m0n0wall. It's not a matter of how
many pipes. It's a matter of setting up the rules and assigning them to
the properly weighted ques. I've uploaded a screen shot of my router

TrafficShaper copy.png (111614 bytes


Michael Graves

On Tue, 12 Apr 2005 20:09:44 -0700, Aaron wrote:

>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
>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

Michael Graves                           mgraves at pixelpower dot com
Sr. Product Specialist                          www.pixelpower.com
Pixel Power Inc.                                 mgraves at mstvp dot com