Hi Chris,
> I just wondered if anyone would mine posting their successful jitter
> buffer settings here for me if they get a moment ??
Are you talking about settings for the iax buffer or something else?
For iax.conf, I'm using:
jitterbuffer=yes
maxjitterbuffer=200
maxexccessbuffer=100
but that is the result of trying to minimize a voice quality problem
associated with Cisco 7960 using iax connections (bug #1220). There was
a vary noticible improvement in the qualtiy for that specific case when
using the above verses a config with the above commented out. Still
working on defining the problem though.
> I've spent a few hours trying to set the jitter buffer up reasonably
> logically and can definitely tell it makes a difference and can introduce
> latency and echo if setup incorrectly but I can't see a good post
anywhere
> describing properly what the three settings actually really do or a
> typical range of settings for them.
I haven't attempted to read the asterisk source code, but jitter buffers
"should" have zero impact on echo (theoretically). Jitter buffers are
primarily used to store sufficient numbers of incoming bits/packets, and
even out the flow of that data (inbound) to the receiving device in such
a way as to minimize the impact of delayed or missing packets.
In theory, latency isn't the issue. Jitter is the "changes" that
happen
to latency. Latency of 500 milliseconds is not going to impact a voip
conversation, however if latency changes from 100 ms to 500 ms and then
back to 200 ms (or something like that), that will be an issue and _that_
is what jitter buffers are suppose to handle. From a 20,000 foot level
using those example numbers, we'd want a jitter buffer capable of handling
the largest swing (eg, 500 ms - 100 ms = 400 ms buffer).
Since I probably wouldn't understand * code if I did read it, I don't
know if
the maxjitterbuffer statement is actually specified in terms of milliseconds,
bits, or whatever. Regardless, the value set is relative to what you
"see"
for changes in latency when doing something like "show iax2 channels".
The
greater the latency swings, the larger the jitter bugger.
> I do roughly understand how a jitter buffer is supposed to work.
> But can it help against echos heard on the lines or just the
'clicks' -
> are they jitter?
Echo problems are the result of inefficiecies or inadaquacies when converting
from four-wire to two-wire anywhere along the end-to-end telephony path. Its
really no different then the Standing Wave Ratio (SWR) in radio transmission
lines. If the two-wire to four-wire conversion facility isn't 100% accurate,
some amount of transmitted energy is going to be "reflected" back, and
that
reflected energy will be heard as an echo. Asterisk attempts to identify that
reflected energy in software, and cancel out (or subtract) that amount from
the incoming audio during the balance of a conversation.
Since * can't afford to burn cpu cycles doing this on a constant basis (like
the echo cancellers in a T1 mux's can), I believe * does a quick sampling at
the start of a connection and then uses whatever it measured for the duration
of that connection. The approach works, but it is not anywhere near the
quality one gets from dedicated echo cancellers in mux's, etc. (I also
beieve
the * approach is negatively impacting transmission levels causing people
to complain about low volume, etc.)
In the perfect world, one should identify the root-cause for reflected energy
and fix that instead of relying on echo cancellers. However, in many cases
we don't have access to the location/device/hardware that "is" the
root
cause, so we're sort of stuck with cancelling instead. The root-cause is
usually associated with improper impedence matching, poor quality components
or design, leakage from tip to ground (or ring to ground), and just about
any other thing that impacts one side of the tip-ring pair more then the
other side (eg, impacting tip-side compared to ring-side).
> Usually my cross-IAX latency is under about 35ms (commonly only 5-6ms) and
> SIP latency (I know this doesn't really matter as there's no buffer
for
> SIP) as recorded by 'sip show peers' as about 70ms (but in reality
ping I
> think is about half this).
>
> My current setup is :
>
> SIP and IAX clients --> my * --> providers via IAX (one 5ms away, one
80ms
> away)
>
> jitterbuffer=yes
> dropcount=5
> maxjitterbuffer=100
> maxexcessbuffer=45
>
> If anyone can post any amplification on these settings apart from
what's
> in iax.conf or their experiences or maybe some adjustments I should try
> that'd be really really helpful.
Although Mark closed bug #1220, I don't think the actual problem is fixed
as yet. That particular bug really addresses a specific problem that is
associated with using Cisco 7940/7960 sip phones with a iax connection.
The issue "seems" to be that Cisco changed their digital signal
processing
method in v6 code, and this new code is sensitive to timestamps contained
within the rtp hearder. When * converts iax/gsm packets to sip/rtp packets,
the timestamps were apparently not being calulated properly (or something
like that), and the 7960 phone effectively drops the packet(s) that have
unreasonable timestamps. That causes incoming audio to stop (audio drop
outs), and I believe it then impacts the outgoing rtp data stream since
asterisk obtains its timing from that outgoing rtp data. As a result, both
ends of the c7960 -> iax connection hear choppy audio and audio drop outs.
I'm trying to use ethereal decodes to identify the issue, however its rather
tough to correlate the audio problems to exact packets within a trace of
thousands of packets. (My hearing verses finger response time is not as
quick as packet sniffers.)
Rich