[asterisk-dev] Jitter Buffer

Tue Oct 24 09:49:04 MST 2006

John Lange wrote:
> Specifically, callers trying to record their voicemail greetings will
> have jittered audio.
>
> Setting jbenable=yes in zaptel.conf in order to dejitter sip audio is
> very confusing and I know there will be a _lot_ of people wondering
> about this besides me.
>   
I strongly agree with John,
and also should be explicitly told, that generic jitterbuffer (jbenable, 
jbforce etc.) is useless in case bridging any voip channel with IAX channel,

also I found this behaviour:
when making SIP-SIP call (jb enabled/forced on both peers) jitterbuffer 
is created only on one side, not both:
[Oct 24 18:39:42]     -- fixed jitterbuffer created on channel 
SIP/743-081d5908
but we have two incomming direction (from both phones to asterisk, that 
bridges call legs) that should be dejittered, is this bug?

also strange: seems, that jb settings in [general] section have 
precedence over sip peer specific jb settings:
I tried set jbimpl adaptive in [general] and jbimpl fixed in peer 
configuration section, and when making call, asterisk creates adaptive 
jb on sip call leg in this case...
PJ

> John
>
> On Mon, 2006-10-23 at 20:57 +0300, Slav Klenov wrote:
>   
>> 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
>>
>> _______________________________________________
>> --Bandwidth and Colocation provided by Easynews.com --
>>
>> asterisk-dev mailing list
>> To UNSUBSCRIBE or update options visit:
>>    http://lists.digium.com/mailman/listinfo/asterisk-dev
>>     
>
>
> _______________________________________________
> --Bandwidth and Colocation provided by Easynews.com --
>
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
>    http://lists.digium.com/mailman/listinfo/asterisk-dev
>   