[asterisk-users] SIP devices with packet loss tolerance
Eric "ManxPower" Wieling
eric at fnords.org
Mon Apr 23 23:58:38 MST 2007
>> 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
>> 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.
More information about the asterisk-users