Continuing this discussion of VOIP and m0n0wall traffic shaping...
(m0n0wall on Soekris net4801)
Using asterisk, all my outbound SIP are set with "qualify=yes".
At the asterisk command line, a "sip show peers" shows the latency to
I notice that with traffic shaping enabled, 40+ ms is added to the
peer latency in the "sip show peers", for all my SIP peers.
Question: Is this a true delay added by the shaper that adds to the
RTP traffic latency?
On Aug 19, 2006, at 9:57 PM, Lonnie Abelbeck wrote:
> From my testing, I seem to get slightly better results if I add a
> pipe #4 for my voip downstream... the same size as my voip
> upstream, reducing my pipe #2 (total download) by the size of the
> new pipe #4. Of course, your downstream voip rule is edited to
> point to pipe #4 instead of the high priority download queue.
> My theory is that pipes without queues have less jitter and
> latency, good for voip.
> On Aug 19, 2006, at 5:18 PM, Michael Graves wrote:
>> It's really just my poor math. However, the process isn't as
>> strict as
>> it might be.
>> In actuality, my 600 kbps should be broken into 216k and 384k. Since
>> the measured upstream 600 k is worst case there is a little latitude.
>> As far as I can tell there is now ability to "squeeze"....meaning
>> there's no elasticity to the traffic shaper. If you cap something at
>> 384k then that's all it ever gets.
>> Since my Asterisk server handles my office and home lines I rarely
>> more than three calls at one time. Using G.711 that would be around
>> 320k outbound in total (3 x 64k + IP overhead)
>> A few months back I installed G.729 codecs on my server and made
>> the prefered codecs. Using them each call consumes only 32k each leg.
>> This has given me some latitude in my tweaks. However, I used several
>> termination providers, a couple of which won't terminate G729 calls.
>> Thus I've not tried to recover any of the bandwidth assigned to the
>> voip side for general use.
>> After hours if I have a large upload to run, perhaps over the
>> I'll sometimes defeat the traffic shaper entirely and allow the data
>> side to use all the available bandwidth.
>> It's curious to note that Skype calls are not dealt with at all in my
>> scheme. I run Skype on my primary desktop, which is also the
>> source of
>> most of the uploads that I run. So I can't manage based upon IP
>> address. Skype uses various port so port based traffic management is
>> not an option. Occasionally, when I'm very busy Skype calls are
>> actually worse that calls placed through the Asterisk server. A sweet
>> On Sat, 19 Aug 2006 12:24:20 -0500, Lonnie Abelbeck wrote:
>>> I was studying your traffic shaping rules.
>>> You specified an upstream speed of 600 kb/s, that would result in a
>>> 540 kb/s bandwidth for pipe #1.
>>> You then added pipe #3 with 256 kb/s.
>>> You then reduced pipe #1 from 540 to 384 kb/s.
>>> Question: Shouldn't the reduced value for pipe #1 be 284? not 384 as
>>> you show. (256 + 284 = 540)
>>> Or, does this let you 'squeeze' your pipe #3 smaller if pipe #1
>>> demands it?
>>> On Aug 17, 2006, at 11:39 AM, Lonnie Abelbeck wrote:
>>>>> Since this question has come up several times recently I've made
>>>>> shots of my m0n0 traffic shaper settings available via the
>>>> A most excellent sharing of information.
>>>> Thanks you... very much appreciated.
>> Michael Graves mgraves at pixelpower dot com
>> Sr. Product Specialist www.pixelpower.com
>> Pixel Power Inc. mgraves at mstvp dot com
>> fwd 54245
>> 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