Hi,
I thought I'd repost this to the -users list for some background on the
jitter buffer and its workings and remaining issue.s
I'll also pu a little executive summary here at the top:
Where a channel is native bridged to another iax2 channel:
1) Lag is not measured and will usually show 0ms. Any other number is an
old measurement from the start of the call
2) The jitter buffer on this machine is not used. Any
jitter/jitterbuffer measurement shown is left over from the start of
the call.
Steve
---------- Forwarded message ----------
Date: Thu, 12 Aug 2004 00:02:26 +0200 (SAST)
From: steve@daviesfam.org
To: asterisk-dev@lists.digium.com
Subject: Re: [Asterisk-Dev] CVS HEAD (20040807) jitter buffer questions
On Wed, 11 Aug 2004, Steve Kann wrote:
>
> The LAG measurement is pretty meaningless in the present implementation,
> if the clocks skew between both sides. Unless both ends of the
> connection are using ntp (for a while, and have stabilized), you can't
> trust it. [even then, I don't remember if ntp is accurate enough for
this].
>
>
>
> Andrew Kohlsmith wrote:
>
> >I've been keeping an eye on the jitter buffer ever since upgrading
and using
> >Steve's patch to fix the 65s dead air problem but I've been
noticing
> >something...
> >
> >... Asterisk frequently gets "lag" and "jitter"
mixed up.
> >
> >This directly affects the jitter buffer, as the jitter buffer only
grows when
> >jitter grows.
> >
Hi Andrew,
Please send logs to me. Or put them somewhere where I can get them.
You need to understand that lag and jitter are measured completely
independently, and need to be interpreted with care...
First lag: Lag is measured by sending a "LAGRQ" frame from the one
(final) end to the other (final) end.
This frame has "our" timestamp time at which it was sent. When it
arrives
at the other (final) end it is immediately sent back. When it arrives
back at the starting point, the echoed timestamp is compared with
"now"
and a lag is derived.
Notice that the compared timestamp is our own - so I don't agree with
Steve's claim that the two ends need synchronised clocks.
Each end of the IAX call send LAGRQs every 10 seconds, so the measurements
are just a snapshot and not some sort of super accurate smoothed figure or
anything.
Its important to understand about the impact of native bridging (see
chan_iax2.c, forward_packet). If an IAX2 call goes over multiple hops.
(eg callerA <-> server1 <-> callerB), Asterisk servers in the middle
of
the path just blindly forward frames, and don't themselves process the
LAGRQ packets. (There is a little tweak done to the timestamp so they
have the right "0-point" for each leg, but that should have a nett
zero
effect) So you will find lag as 000msec on machines in the "middle"
of
the call (eg server1 here), and you also need to understand that the lag
reported on callerA and callerB machines is actually the lag for the whole
path.
So this is most likely the explanation for the 0ms lag. Perhaps we should
change the iax2 show channels to highlight this situation in a special
way.
It is possible I suspect for a lag measurement to slip in before the call
is completely established and the native bridging kicks in. So I suppose
you might see an initial measurement left over.
The -1ms is probably some sort of rounding error which should be looked
at.
The same principle applies to the jitter buffer. Asterisk servers in the
middle of a call do not do de-jittering, they leave it all to the end
machines. Or, at least, that is so once native-bridging kicks in.
Again, the jitter buffer on an intermediate machine will be used whilst
the call is establishing but will stop being used once the call is
established. So I wouldn't expect meaningful jitter figures reported for
calls being native bridged on this box. Perhaps again we should hide them
and mark N/A or something?
Jitter is measured quite separately to lag. It is done by comparing the
delay that arriving frames have experienced. You see (more of less) the
biggest variation in delay seen over the last 2 seconds.
Its quite possible for the jitter to show as more than the lag. The lag
is a snapshot as seen by one frame going there and back. The jitter is
measured by looking at 100 frames. And is, more or less again, the delay
seen by the most delayed frame minus the delay seen by the least delayed
frame.
The jitter buffer only has a relative view of things and doesn't know the
absolute delay - because it only has the other side's timestamps to look
at.
So you can see that you could get a 20msec lag and even a 10000msec
jitter.
I'd just comment that the jitter buffer only needs to account for jitter.
It matters nowt to the jitter buffer if the packets have been 2 hours in
transit as long as they arrive at a steady pace.
Sometimes timestamps on an iax call do jump rather than incrementing
steadily. This can happen for example where voice starts coming from a
new source. The jitter buffer sees this as a sudden jitter; so you might
see the jitter figure jump for a couple of seconds at such a point. This
is fairly harmless (though not ideal).
Lastly - I would like to look at the trunking problem - If you have debug
traces from that I'd be happy to receive them.
Regards,
Steve