Jitter Buffer
В последних CVS-версиях появилась поддержка нового jitter-буфера и PLC.
Основная особенность нового jitter-буфера — универсальность, он работает не только с IAX2 (как раньше), а с любым кодеком, в котором используются соответствующие функции. Сейчас идёт доработка реализации SIP.
Кроме того, ранее нельзя было использовать одновременно IAX2 trunking вместе с jitterbuffer, теперь появилась feature “trunktimestamps”, которая позволяет использовать jitterbuffer совместно с IAX2 trunking.
Использование нового jitterbuffer
Добавьте «jitterbuffer=yes» в раздел [general] iax.conf, или в настройки конкретного устройства.
Также вы можете задать «maxjitterbuffer=n», который задаёт максимальный размер буфера в миллисекундах.
Эта функция может использоваться на любой из сторон, или обеих вместе — она влияет только на код приёма пакетов.
PLC — packet loss correction (восстановление потеряных пакетов)
Новый jitterbuffer обнаруживает потерю пакетов, и использует PLC-код из spandsp для того, чтобы попытаться пересоздать потеряные пакеты на этапе декодирования.
Эта функция включена по-умолчанию для кодеков iLBC и speex, так как не требует дополнительных ресурсов.
Для включения её в кодеках adpcm, alaw, g726, gsm, lpc10 нужно установить genericplc => true в разделе [plc] конфигурационного файла codecs.conf.
trunktimestamps
Для его использования обе стороны должны использовать Asterisk v1.1dev и выше.
Установка trunktimestamps=yes в iax.conf заставить asterisk посылать 16-и битный timestamp для каждого передаваемого кадра (frame). Это позволит использовать jitterbuffer в IAX2 транке.
Эту опцию обязательно устанавливать на обеих сторонах.
Рекомендации
Если вы используете jitterbuffer, обязательно устанавливайте maxjitterbuffer в более-менее разумное значение (порядка 10 в локальной сети, порядка 50–100 в Internet).
Тестирование и мониторинг
iax2 test losspct — симуляция потери n% принимаемых пакетов, при порядка 10% потери пакетов должно работать корректно (лёгкие искажения звука при включеном PLC)
iax2 show netstats — статистика по каждому IAX2-вызову
The columns are “RTT” which is the round-trip time for the last PING, and then a bunch of s tats for both the local side (what you’re receiving), and the remote side (what the other end is telling us they are seeing). The remote stats may not be complete if the remote end isn’t using the new jitterbuffer.
The stats shown are:
* Jit: The jitter we have measured (milliseconds)
* Del: The maximum delay imposed by the jitterbuffer (milliseconds)
* Lost: The number of packets we’ve detected as lost.
* %: The percentage of packets we’ve detected as lost recently.
* Drop: The number of packets we’ve purposely dropped (to lower latency).
* OOO: The number of packets we’ve received out-of-order
* Kpkts: The number of packets we’ve received / 1000.
Джиттер-буфер
Иногда мы можем встретиться с проблемой задержки голоса во время разговора. В некоторых случаях одним из решений может послужить включение и настройка джиттер-буфера.
Задержка зачастую происходит из-за неравномерности передачи голосовых пакетов по протоколу RTP. В данном случае буфер несет смысл выравнивания передачи пакетов. Т.е. в некотором случае уменьшает задержку.
В веб интерфейсе FreePBX настройку джиттера можно выполнить по пути:
Settings -> SIP Settings – вкладка Chan SIP Settings
Vanila asterisk:
Рассмотрим основные параметры:
Vanila asterisk:
- Принудительное использование jitter buffer принимающей стороной SIP канала.
Vanila asterisk:
- Использовать фиксированный или подстраиваемый (адаптивный) jitter buffer. Если указано fixed будет использоваться значение указанное в jbmaxsize. Если adaptive, то размер может изменяться до максимального jbmaxsize. По умолчанию «fixed»
Vanila asterisk:
Режим «adaptive» не рекомендуется из-за возможных негативных последствий.
- Использовать jitter buffer лог. По умолчанию «no»
Vanila asterisk:
- Установите максимальную длину буфера в миллисекундах. По умолчанию «200». Основной параметр для калибровки jitter buffer
Vanila asterisk:
С одной стороны значение не может быть слишком большим, чтобы искусственно не увеличивать задержку. С другой стороны, маленький размер буфера вызовет потери пакетов. Отсюда и происходит одно из главных противоречий, между интернет провайдерами и пользователями IP телефонии.
Рекомендуемые значения для локальной сети от 50-100. Для интернета 150-200. Так же стоит учитывать используемые кодеки, т.к. в зависимости от кодека зависит размер пакета.
- Порог синхронизации. Полезно для некоторых устройств или софтфонов при прерывистой передачи голоса. По умолчанию «1000». Значение «-1» отключает данную функцию.
На FreePBX:
Vanila Asterisk:
Джиттер и джиттер-буфер в Астериске
Введение
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 является входящим с точки зрения Астериска, а Канал 2 — исходящим. Rx — прием звука в Астериск, а Tx — передача звука от Астериска. Звук, пришедший из zap-канала Tx передается через бридж в sip-канал Rx и, очевидно, не нуждается в де-джитировании в Астериске, так как для канальной коммутации (zap-канал) джиттер не характерен. В этом случае, де-джиттирование необходимо применять как можно ближе к sip Rx, т.е. в самом ip телефонном аппарате.
Когда звук приходит с sip-канала Tx, например от ip-телефона, пройдя пакетную сеть, в котором есть вероятность возникновения джиттера, попадает в Астериск и уже с джиттером попадает в zap-канал (см.рис 2).
Канал1
— SIP/myphone (входящий) Канал2
— Zap/1 (исходящий)
Вот здесь и необходимо применить де-джиттирование. В силу того, что в 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 — канал).
