[asterisk-dev] Jitter Buffer

[John Lange]

Another reason I don't think it makes sense to define jitter buffer on
the receiving leg;

What if you want SIP jitter buffer on the incoming audio that is
destined for ZAP except there are some SIP clients that you don't want
it for?

The specific example is; for some reason Asterisk 1.2.x boxes get no
audio when an asterisk 1.4b3 box is doing SIP with jitter. But all our
VoIP phones are fine.

So I need jitter on all the phones but not to the Asterisk peer. AFAIK
there is no way to do this under the current configuration method?

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