Господа инженеры, а кто-то может объяснить зачем нужен сабж?
Прекрасно понимаю, зачем джиттер буфер в пакетной передаче голоса, но какой в нем смысл на Zap каналах!?

если вы про опцию
jitterbuffers
в zapata.conf

то она скорее относиться к zaptel чем как к таковому jitter'у
беглым взглядом
меняет что то в zaptel

Это ты про опцию в конфиге? :) Мало кто понимает.
Просто так устроена реализация Джиттер-буфера в астериске - джиттер буфер включенный для какого-то канала в действительности включает его для ответного канала.

То есть если установить jbenable=yes в zaptel.conf, то джиттербуфер будет использоваться на соединениях ZAP<->SIP, ZAP<->SCCP и пр.

Был документ, где эта особенность архитектуры расписывалась подробнее (кажется на asterisk.org)

Вот тут:
http://www.voip-forum.com/asterisk/2008-01/discover-asterisk-14-jitterbuffers/
и тут:
http://www.asterisk.org/node/48317

опция jitterbuffer в zapata.conf
никак вообще несоотноситься с опциями jb....

она устанавливает количество буфферов в zaptel
по умолчанию 4
для PRI 32
в заптел можеть быть минимум 2 и максимум 32

Век живи - век учись. Я знал, что в 1.4 вынесли джиттеры из каналов в ядро астериска,
но надо было лучше читать. Я вижу, что установки jbenable в sip/iax мало влияют на
качество на плохом канале, и никак не пойму почему. Я уже в пол секунды его установил,
а разницы нет :-)
А оказывается надо было в zapata.conf включать jbenable, так как схема SIP->ZAP...
Я дочитал весь пост Russel'а, где он объясняет почему так.
Так что будем ждать, пока в 1.6 настройки джиттера снова не вынесут в тот канал, для которого его надо включать.

P.S. У кого-то есть опыт тунинга jitterbuffers? Может ли это оказать влияние на производительность?

P.P.S. Кто-то видит смысл в джиттере на исходящие? Мне кажется, это в таком случае теряется весь смысл джиттера,
который используется как временный буфер для сборки приходящих пакетов...

И все же меня смущает слово jitter... Игорь, можешь просветить?

Вообще организация jitter буфера в астериске ну очень странная. Вот например такой пример: звонок с SIP на voicemail. Я так понимаю буфера не будет. Или будет? Если пакеты будут приходить в неправильной последовательности тогда качество оставленного сообщения будет не на высоте.

Не будет, для таких схем, чтобы был буфер, нужно использовать Local канал с опцией j ;)

2litnimax: Поведение jbenable в 1.6 не изменится, никто не взялся менять нынешнюю реализацию. jitterbuffers регулирует количество внутренних буферов в zaptel:

jitterbuffers in zapata.conf is the number of READ_SIZE buffers necessary to buffer voice. The total size must typically be at least as large as the packet size of any VoIP codecs - ie gsm=30ms (effective 240 samples). using READ_SIZE 40 works well with jitterbuffers = 6. if you haven't fooled with READ_SIZE (using stock 160) jitterbuffers=2 can make a _very_ noticable improvement versus default =4.

again, if your system's realtime performance sucks, you'll need more jitterbuffers. zttest doesn't have to read 100, it needs to be consistent. arrange your PCI cards and IRQ s as per the old-skool 286 IRQ routing rules (IRQ 9,10,11, (12 esta bad if shared with PS2, but why would you have a mouse on your PBX anyway). hdparm -u1 -c1 -m8 your IDE drives.

Отсюда: http://www.binrev.com/forums/index.php?showtopic=22805

Во во. Непонимаю почему бы не влепить jitter буффер напрямую в канал и при чтении из канала сначала читать frame из RTP сокета и совать в буфер а потом читать из верхушки буфера и отдавать назад. Ну или наоборот.