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
_______________________________________________
--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
