[asterisk-users] SIP devices with packet loss tolerance

[Michael Graves]

On Tue, 24 Apr 2007 07:18:50 -0600, Stephen Bosch wrote:

>Eric "ManxPower" Wieling wrote:
>> 
>>>> Hoping someone might have experience with poorly-performing net
>>>> connections and which devices work best over them.
>>>
>>>> One of our clients has a number of employees that work from home, and
>>>> are given a SIP phone to take with them and hook up to their
>>>> broadband. For the most part, this works fine, but 
>>> there are an increasing number where sound quality is poor ("chops" in
>>> and out, generally only noticeable to the listener at the other end,
>>> not the employee). Logic suggests it's an upstream bandwidth issue, so
>>> we asked them to try when all other devices were turned off (to cut
>>> out the "kids using bitTorrent" issues), but even with the phone the
>>> only device, call quality was still poor.
>>>
>>>> Since the connections aren't paid for by the client, we aren't in a
>>>> position to mandate particular providers or speeds, but in each case,
>>>> the minimum was a 1mb/256k up ADSL. We asked 
>>> the employees to run some speed tests to determine real-world speeds,
>>> and in each case upstream was around 220-235k (a little off the
>>> "official speed" but not bad). Certainly way more than the ~35kbps
>>> necessary for a g729 call, even with packet overheads.
>> 
>> PSTN <-> Asterisk <-> Internet <-> SIP Phone.
>> 
>> If the person on the PSTN side is having audio quality problems then the
>> issue is not with the jitter buffer on the phone.  The problem in this
>> case is the jitter buffer in Asterisk.  SIP is a signalling protocol.
>> Audio is sent using the RTP protocol.  In versions of Asterisk before
>> 1.4 there was no RTP jitter buffer in Asterisk.
>> 
>> Lack of an RTP jitter buffer in Asteirsk is why none of my clients have
>> deployed phones off the corporate network.
>> 
>> If the person on the SIP phone side is having audio problems (not the
>> case if I read your message correctly) then you have to look at the
>> jitter buffer settings on the phone.
>> 
>> Remember jitter buffers (and QoS actually) is only applied to and is
>> only effective for INCOMING traffic.
>> 
>> Yes, applying QoS to the outbound traffic of the internal interface of
>> your router can give the illusion of limited QoS.  This happens because
>> of the nature of TCP and will do nothing for non-TCP traffic.
>> 
>> Jitter is not the packet latency, but of the VARIANCE in latency.  Also,
>> dejittering audio requires buffering and this buffering adds to the
>> audio latency.  If you had a jitter buffer that could handle 3000ms of
>> jitter (on a HughesNet satellite connection, for example) your audio
>> would generally be great, the tradeoff is that you have just added 3
>> seconds of latency to your audio and in anyone's book that sucks.

Ah, of course you are completely correct. My use of the term QoS was in error and out of context.

That said, at the remote user end they will most certainly suffer poor voip performance if there is no form of traffic prioritisation. In my home office I rely upon the traffic shaping feature found 
in m0n0wall to ensure that oubound traffic from my Asterisk server gets priority over general outbound internet activity. Strictly speaking this is not QoS at all since it has nothing to do with 
packet tagging.

Michael