[asterisk-dev] Jitter Buffer

[Slav Klenov]

Hello guys,

There are some posts about this at the bug tracker, at this mailing list 
and on some other voip related forums. However, no consistent 
documentation about this was made.

Well, as an author of the generic Asterisk jitterbuffer, I'll try to 
give a short explanation.

A general scenario looks like: chan1 <-> Asterisk <-> chan2.

Frames are traveling in two directions: chan1->*->chan2 and 
chan2->*->chan1. Let's consider the first one. As each Asterisk channel, 
chan1 has AST_CHAN_TP_CREATESJITTER flag (set or not), aiming to tell 
Asterisk whether the reading of frames from this channel can be 
considered reliable and order preserving (with no jitter, e.g. ZAP). 
This tells asterisk if theres any sense to do dejittering on this steram 
at all (no matter what the other leg is). However, chan1 doesn't know 
where the frames read will go - they can go to a channel that can handle 
jitter itself, or they just can get discarded. Thats the additional 
AST_CHAN_TP_WANTSJITTER flags stands for - it tells Asterisk if chan2 
can handle jitter itself and in this way, should it create jitterbuffer 
for the chan1->*->chan2 stream. Thats the most important part: *only* 
the receiving side (chan2) knows if it wants jitter or not (not the 
sending one).

Consider the following scenario: SIP <-> * <-> ZAP. You want 
jitterbuffer on the SIP -> * -> ZAP stream only, not on the ZAP -> * -> 
SIP one. If you set jbenable=yes in sip.conf that would mean dejitter 
all streams coming from SIP (including SIP->SIP, SIP->H323, SIP-> IAX, 
...). But thats not what you want. The right approach is to apply jb 
settings at the receiving side (that one on the right hand of 
chan1->*->chan2). Thats why you need to set jbenable=yes in zapata.conf 
- it doesn't sound illogical for me - if you want the audio to be 
received dejittered on the ZAP end (only if needed) you enable a 
jitterbuffer on the ZAP channel.

If you don't want jb on the ZAP end, you set jbenable=no in zapata.conf 
- that would disable all dejittering on the ZAP end. If you want to have 
jb on the ZAP end always, including the cases where not needed (if the 
other chan doesn't create jitter), you set jbforce=yes. The same is for 
the SIP channel - it has the flag AST_CHAN_TP_WANTSJITTER set, so it 
will never dejitter stream on its end (some chan -> * -> SIP), unless 
jbforce=yes (and jbenable=yes) in sip.conf.

The generic Asterisk jb is created mainly for VOIP <-> PSTN cases. In 
general, you won't need jb in VOIP <-> VOIP and PSTN <-> PSTN cases, but 
you *can* if you configure asterisk *appropriately*.

Pavel Jerek, Martin Vit: The jitterbuffer should work for all cases, 
however this doesn't stands for the IAX channel (from and to). The IAX 
channel has its own jb (newjb by stevek). You can disable it setting 
jitterbuffer=no in iax.conf, but in this case you will have the very old 
iax2 jitterbuffer, which is hardcoded in chan_iax2.c and cannot be 
disabled by configuration. Thats why I (and russell, when ported it to 
trunk) omitted to include jb code in chan_iax2.c - you just can *not* 
have jitterbuffer when doing [some chan <-> Asterisk <-> IAX chan] in 
both directions! nor any generic jb (jbenable, jbforce, ...) 
configuration properties are read from iax.conf - IAX cannot enable the 
use of generic jb for its end and IAX cannot provide generic timestamp 
information (in struct ast_frame) to be used for dejittering on the 
other channel's end. This http://bugs.digium.com/view.php?id=8189 bug 
report seems very strange to me - it is not supposed the generic jb to 
work in this case at all (no matter what settings you have).

Slav