[asterisk-dev] Jitter Buffer

[John Lange]

Thanks for the clarification Slav. I appreciate the work you've done on
this. A decent JB is very important.

So, the bottom line is you set jbenable=yes on channels you want to send
dejittered audio too. In most cases this would be any channel which can
not handle its own dejitter such as Zap channels.

While I now understand where you are coming from I still think this
seems backwards.

jbenable=yes in sip.conf should tell Asterisk to dejitter incoming audio
FROM SIP channels when the receiving leg can not handle dejitter on its
own.

jbenable=yes + jbforce=yes in sip.conf should tell Asterisk to dejitter
incoming audio from SIP channels no matter what the receiving leg can
handle.

One simple example demonstrates why this makes sense; in the case where
the sip channel is talking to an application inside Asterisk or
otherwise connecting to a something which doesn't have jbenable option
there is no way to activate the JB and therefore audio is jittered.

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.

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