Всем привет! Участник сообщества betman написал статью про jitter в Asterisk.
http://asteriskpbx.ru/wiki/asterisk-jitterbuffer
Так как он настоящий лентяй, сделав 99%, всей работы, последний 1% оставил другому, мне пришлось выступить главредом и поправить несколько (какие нашел) незначительных ошибок, и создать страницу на вики (хотя там есть переключатель в wysiwyg режим!).
Betman, спасибо! Пиши еще!

я бы чуть чуть уточнил

«Для трафика, попадающего в zap-канал ,со стороны бридж соединения, включить JB на sip-канале».

если я правильно понял

ddkprog, я тоже так изначально подумал, по логике так и должно быть, но в том то и дело, что де-джиттирование происходит как раз на канале для которого джиттер не свойственен (don't accept jitter, как-то так)! То беж в Zap

я имел ввиду
что если судить по тексту вики
то правильнее будет звучать

что опция джитер на Zap будет говорить о том что канал который соеденяеться в бридж с Zap должен будет создать джитер буффер

тоесть
Sip - бридж - Zap
опция на jb на Zap
будет заставлять создавать джитер на Sip

а как такового джитера в заптеле ж нет
и вообще повторю сотый раз
глупо и неправильно "разработат" астериск

ddkprog, в исходниках не искал где именно реализованна функция де-джиттирования, имею ввиду в каком модуле, но:

"опция на jb на Zap
будет заставлять создавать джитер на Sip "

надо поправить -- не джиттер, а JB

Более того, если вникнуть в тему JB, то в принципе логично реализовывать de-jitter имеено в zaptel, так как смысла нет его реализовывать в RTP-каналах, потому как в схеме:

SIP => [bridge] => IAX2

применять JB в SIP-канале, т.е. так:

SIP => (JB) [bridge] => IAX2

вполне логично, так как трафик приходит с jitter'ом, но Астериск "смотрит", что де-джиттированный трафик снова идет в RTP-канал, в котором может возникнуть джиттер и не применяет JB.

если же сделать так:

SIP => (JB) [bridge] (JB)=> IAX2

получим два JB, каждый из которых внесет свою задержку и толку от этого будет мало, так как в конечную точку IAX2 он все-равно прийдет с джитером!!!

Таким образом, JB вполне логично реализован на исходящем канале и этот канал должен быть не RTP!!! Если происходит бриджевание двух RTP-каналов, то JB рекоммендуют использовать в end-point, тоесть в ip-телефонаx!!!

что то и я уже запутался

а чем jb от джитера отличаеться?

джитер наскоко я знаю
это очередь в которой происходит сортировака пакетов

и нужен он токо на входе к примеру
SIP(jb) -> bridge -> ZAP
ZAP -> bridge -> SIP сдесь джитер ненужен


или астериск уже в этом плане так поламали
что еще и деджитер ввели ))))

и вообще нужно лезть в сорусы
а то я чет уже сам начинаю непонимать
как они его нам накрутили
и когда он включаеться

нужен он токо на входе канала который ловит пакеты по ненадежному соединению

пакет сортируеться - через бридж и на выход дальше и там никакого дж буффера ненадо уже

1) джиттер -- явление, имеющее отрицательное действие на QoS; JB (jitter-buffer) -- механизм "борьбы" с оным;
2) Определение "джиттера" было дано в статье;
3) на входе он не нужен, так как если бы было так, как вы говорите, тогда при включении в sip.conf, например, jbenable=yes он бы бетон де-джиттировал входящий трафик, и только после этого загонял бы его в бридж. Если бриджевание происходит с RTP каналом, с тем же SIP, тогда де-джиттированный трафик снова попадает в среду, в которой возможен джиттер!!! Следовательно, толку его было де-джиттировать (вносить задержку) на входе, если в конечную точку end-point он уже прийдет с джиттером!!!
4) JB собиралась сделать на входящих в версии 1.6 Астериска, но я еще не сэтапил его, поэтому не могу сказать, реализовано оно там или нет. Лучше пусть поделятся опытные этой инфой. Реализация джиттера на входящем канале RTP-канале полезна для связки: RTP => Asterisk application, для которой не создается (по крайней мере в версии 1.4) бридж. Поэтому JB в таком варианте можно было сделать через local-канал с опцией j, о чем я писал в статье....

ладно...дискутировать мне что то неохотно
но по 3) не совсем согласен...
но это уже путь разработчиков астериска если они так сделали..

betman, ты хоть статью поправить то сможешь сам? :-)

Дык, а че там поправлять? Там все правильно! Я тут просто повторил большим количеством слов тоже самое. Не, ну поправить смогу, конечно ;) Вот только что?