Hi,

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  
the peers.

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?

Thanks,

Lonnie

On Aug 19, 2006, at 9:57 PM, Lonnie Abelbeck wrote:

> Michael,
>
> 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.
>
> Lonnie
>
> On Aug 19, 2006, at 5:18 PM, Michael Graves wrote:
>
>> Lonnie,
>>
>> 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  
>> that
>> 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  
>> have
>> 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  
>> those
>> 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  
>> weekend,
>> 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
>> irony.
>>
>> Michael
>>
>>
>> On Sat, 19 Aug 2006 12:24:20 -0500, Lonnie Abelbeck wrote:
>>
>>> Michael,
>>>
>>> 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?
>>>
>>> Thanks,
>>>
>>> Lonnie
>>>
>>> On Aug 17, 2006, at 11:39 AM, Lonnie Abelbeck wrote:
>>>
>>>> Michael,
>>>>
>>>>> Since this question has come up several times recently I've made
>>>>> screen
>>>>> shots of my m0n0 traffic shaper settings available via the  
>>>>> following
>>>>> links.
>>>>
>>>> A most excellent sharing of information.
>>>>
>>>> Thanks you... very much appreciated.
>>>>
>>>> Lonnie
>>>>
>>>>
>>>
>>>
>>
>> --
>> Michael Graves                           mgraves at pixelpower dot com
>> Sr. Product Specialist                          www.pixelpower.com
>> Pixel Power Inc.                                 mgraves at mstvp dot com
>>
>> o713-861-4005
>> o800-905-6412
>> c713-201-1262
>> 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
>
>