[Asterisk-Dev] CVS HEAD (20040807) jitter buffer questions

[steve at daviesfam.org]

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