Введение
Jitter (джиттер или дребезг) — это неравномерность периодов времени, отведенных на доставку пакета. джиттер присущ только сетям с пакетной коммутацией. Задержка в доставке пакета и джиттер обычно исчисляется в миллисекундах, и на первый взгляд, не являются столь критичными и едва ли могут быть замечены человеком. Это так, до тех пор, пока это не касается передачи голоса или видео, другими словами, до тех пор, пока мы не столкнемся с передачей контента в реальном режиме времени.
В протоколе RTP, который еще называют «протоколом потока передающей среды» (media stream), есть поле для метки точного времени передачи относительно всего RTP потока. Принимающее устройство использует эти временные метки для выяснения того, когда следует ожидать пакет, соблюден ли порядок пакетов. Исходя из этой информации приемная сторона выясняет, как следует настроить свои параметры, чтобы замаскировать потенциальные сетевые проблемы, как задержки и джиттер. Если ожидаемое время на доставку пакета от отправителя к приемнику на протяжении всего периода разговора строго равно определенному значению, например 50 мс, можно утверждать, что в такой сети джиттера нет. Но зачастую пакеты задерживаются в сети и временной интервал доставки может колебаться в довольно большом (с точки зрения трафика, критичного ко времени) временном диапазоне. В случае, если приложение-приемник такого звука или видео будет воспроизводить его в том временной порядке, в котором приходят пакеты, мы получим заметное ухудшения качества голоса/ видео. Например, если это касается голоса, то мы услышим прерывание в голосе, бульканье и прочие дискомфорты.
Причины джиттера
Причиной джиттера могут быть разные факторы, обусловленные спецификой передачи информации в пакетных сетях: это и большая загрузка узлов коммутации, где пакеты выстраиваются в очередь и ожидают своей отправки в следующую точку агрегации и маршрутизации сетевого трафика, это и диверсификация маршрутов следования пакетов (пакеты, следовавшие друг за другом в источнике, могут быть переданы разными маршрутами к получателю, а значит, и вероятно обработаны разным количеством сетевых узлов, каждый из которых вносит свою, случайную задержу обработки пакета).
В виду критичности влияния джиттера на качество воспроизведения звука, в разных VoIP реализациях, применяют разные методики и технологии устранения или де-джиттирования сетевого медиа трафика. Практически все реализации сводятся к применения так называемого джиттер-буфера (jitter-buffer). Механизм де-джиттирования в Астериске реализован не только в RTP-ориентированных каналах (chan_sip, chan_iax и т.п.), но и в ZAP канале chan_zap, который обслуживает интерфейсы ISDN PRI и аналоговые телефонные интерфейсы PSTN. На первый взгляд может показаться странным, зачем реализован JB в каналах, для которых джиттер не свойственен по определению. Но об этом далее.
JB в Asterisk
Начиная с версии 1.4, для Астериска был разработан патч JB, который позволяет применять JB не только в случае бридживания каналов (bridge channels), но и применим к таким приложениям, как голосовая почта и конференция, которые реализованы в Астериске в виде приложений. Ранее с JB в связке с приложениями можно было работать только через псевдо-канал local_chan, используя в вызове приложения конструкцию «j», тем самым имитируя формирования бриджа.
Чтобы понять, как работает JB в Астериске, необходимо глубже понять концепцию организации каналов в Астериске. Канал в Астериске возникает тогда, когда приходит звонок. Причем, для звонящего через Астериск, этот звонок будет исходящим, а для Астериск — входящим. Далее, пришедший звонок помещается в номерной план обработки вызова. Если образованный канал запускает приложение Dial(), тогда создается второй канал (исходящий с точки зрения Астериска) для совершения звонка к вызываемому. Если второй исходящий канал отвечен, Астериск соединяет эти два канала в бридж (bridge). Два канала позволяют передавать голос между собой: фреймы голоса, принятые в один канал, передаются в другой канал с помощью бриджа.
Пример 1. Рассморим сценарий вызова, когда sip-клиент звонит на zap-канал PSTN-интерфейса:
Канал1 - SIP/myphone (входящий) Канал2 - Zap/1 (исходящий)
(Рот) Rx ============||--------||============ Tx (Ухо)
SIP || Bridge || ZAP
(Ухо) Tx ============||--------||============ Rx (Рот)
В этом примере Канал 1 является входящим с точки зрения Астериска, а Канал 2 — исходящим. Rx — прием звука в Астериск, а Tx — передача звука от Астериска. Звук, пришедший из zap-канала Tx передается через бридж в sip-канал Rx и, очевидно, не нуждается в де-джитировании в Астериске, так как для канальной коммутации (zap-канал) джиттер не характерен. В этом случае, де-джиттирование необходимо применять как можно ближе к sip Rx, т.е. в самом ip телефонном аппарате.
Когда звук приходит с sip-канала Tx, например от ip-телефона, пройдя пакетную сеть, в котором есть вероятность возникновения джиттера, попадает в Астериск и уже с джиттером попадает в zap-канал (см.рис 2).
Канал1 - SIP/myphone (входящий) Канал2 - Zap/1 (исходящий)
Rx ============||--------||(JB)======== Tx
SIP || Bridge || ZAP
Tx ============||--------||============ Rx
Вот здесь и необходимо применить де-джиттирование. В силу того, что в zap-канал нельзя отправлять голосовые пакеты с джиттером (что приведет к ухудшению качества воспроизводимой речи в zap-канале), именно в zap-канале необходимо применить де-джиттирование. Делается это в настройках zapata.conf (chan_dahdi.conf) посредством включения опции jbenable=yes. Эта опция говорит: «Для трафика, попадающего в zap-канал включить JB».
JB можно применить и для sip-канала. Но это возможно только на исходящем канале и только с применением опции jbforce=yes. Это объясняется тем, что бридж будет «смотреть», что входящий де-джиттированный трафик снова возвращается в канал, в котором есть вероятность появления джиттера. Поэтому, в идеале применять JB в каналах с пакетной коммутацией необходимо в конечной точке, т.е. в ip-телефоне. В противном случае, например при звонках sip ⇒ sip, создавалось бы два JB, что вносило бы дополнительные задержки в одной голосовой сессии и отрицательно влияло на качество голоса. Другими словами, JB следует применять только на исходящем (с точки зрения Астериска ) Tx канале, а применение JB «посредине» голосового канала — крайне нежелательно.
Следует помнить, что JB работает только для каналов в бридже (sip ⇒ zap и пр.), причем в одном из каналов должна существовать вероятность появления джиттера, а во втором канале бриджа джиттер недопустим. Реализация его во входящем канале (sip ⇒ application Meetme() )допустима только в версии 1.6 или посредством патча, а также вызовом приложения через local-канал.
Из вышесказанного можно сделать вывод, что джиттер может возникать только в канале с пакетной коммутацией. Применять де-джиттирование (посредством джиттер-буфера) можно только, когда каналы находятся в бридже, более того, необходимым условием включения JB должно быть то, что для одного из каналов в бридже недопустима работа с джиттером (только в канале с канальной коммутацией). JB будет отрабатываться только на исходящем канале (с точки срения Астериска, Tx) в котором недопустимо появление джиттера (например, zap — канал).