причини джиттера
Причиною джиттера можуть бути різні фактори, зумовлені специфікою передачі інформації в пакетних мережах: це і велике завантаження вузлів комутації, де пакети вибудовуються в чергу і чекають своєї відправки в наступну точку агрегації і маршрутизації мережевого трафіку, це і диверсифікація маршрутів проходження пакетів (пакети, які слідували один за одним в джерелі, можуть бути передані різними маршрутами до одержувача, а значить, і ймовірно оброблені різною кількістю мережевих вузлів, кожен з яких вносить свою, випадкову затримаю обр лення пакета).
З причини критичності впливу джиттера на якість відтворення звуку, в різних [VoIP] реалізаціях, застосовують різні методики і технології усунення або де-джіттірованія мережевого медіа трафіку. Практично всі реалізації зводяться до застосування так званого джиттер-буфера (jitter-buffer).
JB в Asterisk
Щоб зрозуміти, як працює JB в Астеріск, необхідно глибше зрозуміти концепцію організації каналів в Астеріск. Канал в Астеріск виникає тоді, коли приходить дзвінок. Причому, для того, хто дзвонить через Астеріск, цей дзвінок буде вихідним, а для Астеріск - входять. Далі, що прийшов дзвінок поміщається в номерний план обробки виклику. Якщо утворений канал запускає додаток Dial (), тоді створюється другий канал (вихідний з точки зору Астеріск) для здійснення дзвінка до викликається. Якщо другий вихідний канал відповідаючи, Астеріск з'єднує ці два канали в бридж (bridge). Два каналу дозволяють передавати голос між собою: фрейми голосу, прийняті в один канал, передаються в інший канал за допомогою бриджу.
Приклад 1. Рассморім сценарій виклику, коли sip-клієнт дзвонить на zap-канал PSTN-інтерфейсу:
Канал1 - SIP / myphone (вхідний) Канал2 - Zap / 1 (вихідний)
SIP || Bridge || ZAP
- SIP / myphone (вхідний) Канал2
SIP || Bridge || ZAP
Ось тут і необхідно застосувати де-джіттірованіе. В силу того, що в zap-канал не можна відправляти голосові пакети з джиттером (що призведе до погіршення якості відтвореної мови в zap-каналі), саме в zap-каналі необхідно застосувати де-джіттірованіе. Робиться це в налаштуваннях zapata.conf (chan_dahdi.conf) за допомогою включення опції jbenable = yes. Ця опція говорить: «Для трафіку, що потрапляє в zap-канал включити JB».
Слід пам'ятати, що JB працює тільки для каналів в бриджі (sip => zap та ін.), Причому в одному з каналів повинна існувати ймовірність появи джиттера, а в другому каналі бриджу джиттер неприпустимий. Реалізація його у вхідному каналі (sip => application Meetme ()) допустима лише в версії 1.6 або за допомогою патча, а також викликом додатки через local-канал.
З вищесказаного можна зробити висновок, що джиттер може виникати тільки в каналі з пакетною комутацією. Застосовувати де-джіттірованіе (за допомогою джиттер-буфера) можна тільки, коли канали перебувають в бриджі, більш того, необхідною умовою включення JB має бути те, що для одного з каналів в бриджі неприпустима робота з джиттером (тільки в каналі з канальної комутацією). JB буде відпрацьовуватися тільки на вихідному каналі (з точки сренія Астеріск, Tx) в якому неприпустимо поява джиттера (наприклад, zap - канал).