Сокращение задержки голоса по IP

Несколько простых методов позволяют избежать разрыва соединения приложениями VoIP в результате задержек в сети.

Кроме того, тот, кто читает популярные финансовые издания, вероятно, знает о том, что несколько операторов связи создали инфраструктуру IP для транспорта как голоса, так и данных. Эти операторы связи выпускают акции и облигации для финансирования своей новой инфраструктуры.

Растущая популярность VoIP не означает, что его легко реализовать. На самом деле, все может быть совсем наоборот, особенно если те, кто этим занимается, не провели предварительно тщательную подготовительную работу. Некоторые недавно представленные продукты VoIP могут очень хорошо работать совместно с оборудованием того же поставщика, вместе с тем, эти же самые продукты будут работать плохо или вообще не работать при использовании с продуктами другого поставщика.

Даже если все продукты покупаются у одного поставщика, это еще не дает гарантии, что VoIP будет работать хорошо и корректно. Впрочем, проблемы совместимости могут, в конечном итоге, быть решены по мере приведения продуктов в соответствие с новыми и перспективными стандартами, между тем как тот факт, что VoIP зависим от задержки, означает, что инфраструктуру сети следует тщательно проанализировать на предмет качества поддержки VoIP.

В этой статье мы рассмотрим, как данные передаются через сеть, и познакомимся со всеми пунктами, где возможна задержка данных. Кроме того, мы познакомимся с различными способами сокращения задержки в сети, чтобы вы могли извлечь максимум возможного из своей реализации VoIP.

ПОВИСШЕЕ МОЛЧАНИЕ

Приложение VoIP можно рассматривать с точки зрения задержки в сети, поскольку вербальные диалоги в реальном времени чувствительны к задержке. Если задержка в один конец превосходит четверть секунды, т. е. 250 мс, то участникам диалога становится чрезвычайной трудно определить, когда другой человек закончил говорить. Это увеличивает вероятность того, что они станут говорить одновременно.

Один из способов избежать подобных накладок — это вести разговор в режиме диалога в гражданском диапазоне (Citizen?s Band, CB), используя термин «прием» для информирования другой стороны о том, что теперь она может говорить. Связь с помощью CB была чрезвычайно популярна в США в 70-х гг., но вряд ли какое-нибудь предприятие захочет сегодня вкладывать средства в реализацию приложений VoIP для получения возможности вести диалог в режиме CB.

Рекомендации ITU-T G.111 ограничивают допустимую задержку в оба конца величиной в 300 мс, т. е. задержка в один конец не должна превышать 150 мс. Если максимальная задержка в один конец в 150 мс еще как-то приемлема, то задержка свыше 250 мс вообще недопустима. Таким образом, задержку в один конец в 150 мс можно воспринимать как желтый флаг, а задержку в 250 мс — как красный предупредительный сигнал для приложения VoIP.

Теперь, дав общее представление о допустимых задержках для приложения VoIP, мы можем переходить к потокам данных, возникающим при реализации этой технологии.

ПОТОК ДАННЫХ

Типичное приложение VoIP функционирует в сети IP, будь то корпоративная сеть Intranet или Internet. Пример простейшей реализации VoIP приведен на Рисунке.

В данном примере голосовой вызов маршрутизируется с УАТС в пункте X — через шлюз, локальную сеть и маршрутизатор на этом узле — по сети IP на телефон, подключенный к УАТС в пункте Y. На этом пути задержка содержащих голос дейтаграмм может возникать в нескольких местах.

При маршрутизации аналогового диалога через УАТС на голосовой шлюз определенную задержку вносит алгоритм кодирования речи на шлюзе. Величина задержки зависит при этом от типа используемого голосового кодера (вокодера). После кодирования краткий фрагмент речи инкапсулируется в дейтаграммы для передачи на противоположный шлюз. Процесс инкапсуляции предусматривает добавление соответствующих заголовков UDP и IP для формирования дейтаграммы, а также потока дейтаграмм от шлюза на маршрутизатор через локальную сеть.

Общая задержка в результате этих действий составляет задержку между процессами на отправителе. Как видно из Рисунка, при прибытии дейтаграммы на шлюз адресата процесс повторяется в обратном порядке. Таким образом, дейтаграмма сталкивается с задержкой между процессами на получателе.

Достигнув маршрутизатора на узле X, поток дейтаграмм не попадает немедленно в облако (представляющее сеть IP). Он задерживается на время, зависящее от длины дейтаграммы и скорости линии доступа.

Попав наконец в сеть IP, дейтаграмма маршрутизируется через один или более маршрутизаторов до точки выхода из сети. Этот процесс вносит непредсказуемую задержку. Величина задержки будет зависеть от числа маршрутизаторов на пути от точки входа до точки выхода, вычислительных ресурсов каждого маршрутизатора и текущей нагрузки на каждый из них. Аналогичные задержки имеют место и при прохождении дейтаграммы через локальную сеть и добавляются к задержкам при путешествии дейтаграммы через глобальную сеть IP.

Описанные выше задержки суммируются в Таблице. Кроме того, в ней приводится диапазон типичных задержек вследствие влияния каждого из перечисленных факторов. Заметим, что типичная общая задержка составляет от 80,5 до 314 мс.

Если задержка в 80,5 мс вполне приемлема, то задержка свыше 150 мс не способствует разборчивости разговора, в особенности если она оказывается близка к верхней границе в 314 мс.

Для задержки на входе и выходе из сети в Таблице указывается один и тот же диапазон значений, однако для задержек между процессами на отправителе и получателе это, вообще говоря, неверно. Аналогично, задержки на компрессию и декомпрессию несимметричны. Не вдаваясь в причины, мы вместо этого обсудим каждый из видов задержки и возможные меры для сокращения каждой из них. Сэкономив несколько миллисекунд на одном стыке, еще несколько на другом, приложение VoIP можно заставить функционировать с приемлемым качеством воспроизведения речи.

КОДИРОВАНИЕ РЕЧИ

В среде VoIP большинство шлюзов конфигурируется на оцифровку речи с помощью гибридных методов кодирования. Гибридный кодер сочетает кодирование формы сигналов с кодированием речи.

При гибридном методе кодирования голосовой сигнал дискретизируется, и из него извлекаются параметры речи. Однако вместо непосредственного кодирования высоты, модуляции и др. характеристик речи эти параметры используются для синтеза фрагмента речи, из которого они были извлечены. Синтезированный фрагмент речи, обычно длительностью 20 мс, сравнивается затем с исходным образцом. Если они совпадают с приемлемым допуском, то параметры речи остаются без изменений. Если же реальный и синтезированный фрагменты отличаются более чем на заданную величину, то параметры речи корректируются для достижения «лучшего совпадения».

Конечным результатом этого механизма обратной связи является анализ посредством синтеза: попытка скорректировать извлекаемые параметры речи для обеспечения синтеза как можно более близкого к исходной форме сигнала. После окончательного определения значений параметров речи кодер сопоставляет характеристики с ранее «узнанными» из шифровальной книги. При обнаружении совпадения вместо значения параметра используется его положение в шифровальной книге, что еще больше сокращает объем данных, которые требуется передавать.

Такой гибридный метод кодирования используется в семействе вокодеров под общим названием Code Excited Linear Prediction (CELP). В целом, скорость передачи данных для различных представителей семейства CELP обратно пропорциональна их алгоритмической задержке. Другими словами, чем выше скорость кодированной речи, тем меньше задержка на кодирование фрагмента речи.

Тремя наиболее популярными вокодерами, используемыми во многих шлюзах VoIP, являются G.728, G.729 и G.723.1. G.728 представляет собой разновидность CELP с малой задержкой. Алгоритмическая задержка кодера G.728 составляет приблизительно 2,5 мс, однако результирующая скорость передачи оцифрованных данных равняется 16 Кбит/с. Вокодер G.729 функционирует со скоростью 8 Кбит/с и вносит задержку в 10 мс. Вокодер G.723.1 является многоскоростным кодером, так как он может поддерживать скорости 5,3 или 6,3 Кбит/с. В обоих случаях алгоритм вносит задержку на кодирование приблизительно около 30 мс. Ввиду того, что каждый вокодер обрабатывает фрагмент речи длительностью 20 мс, общая задержка составляет приблизительно 22,5, 30 и 50 мс соответственно.

Один из способов сокращения задержки в один конец состоит в смене метода кодирования речи. Например, замена вокодера G.723.1 на G.728 приведет к сокращению задержки в один конец на 27,5 мс. Большинство шлюзов поддерживает от шести до десяти типов вокодеров. Таким образом, тщательно подобрав вокодер, задержка в один конец можно существенно сократить.

Если информацию о задержке на кодирование речи для стандартных кодеров получить сравнительно легко, то в случае нестандартных кодеров это может оказаться не так просто. Моя собственная попытка определить задержку некоторых нестандартных «усовершенствованных» кодеров CELP потребовала целой серии телефонных звонков и определенной настойчивости, так как подобная информация обычно не включается производителем в публикуемые спецификации.

ЗАДЕРЖКА МЕЖДУ ПРОЦЕССАМИ В ИСХОДНОМ ПУНКТЕ

Как ранее кратко упоминалось, задержка между процессами в исходном пункте имеет несколько составляющих. Это формирование дейтаграммы с фрагментом оцифрованной речи, отправка дейтаграммы в локальную сеть и ее извлечение из сети маршрутизатором. Хотя задержка между процессами в исходном пункте варьируется в незначительных пределах, ее все же можно сократить на несколько миллисекунд с помощью ряда методов.

Так, если уровень загруженности вашей локальной сети высок, то в ней, скорее всего, часто возникают коллизии, а это ведет к задержке передачи кадров по сети. В такой ситуации вы можете либо модернизировать, либо сегментировать локальную сеть, а также пустить трафик в обход сети.

Что касается последнего решения, то вместо использования шлюза, для которого необходимо отдельное соединение через локальную сеть, вы можете оснастить маршрутизатор голосовыми модулями. При этом линии УАТС будут выходить на маршрутизатор напрямую, и дейтаграммам не придется пересекать локальную сеть. Хотя такое изменение в локальной инфраструктуре экономит всего несколько миллисекунд, однако в совокупности экономия нескольких миллисекунд здесь, нескольких миллисекунд там позволит добиться того, чтобы приложения VoIP работали в соответствии с вашими ожиданиями.

НА ВХОДЕ И ВЫХОДЕ ИЗ СЕТИ

Задержка, связанная с передачей дейтаграммы в сеть IP и ее приемом из сети, в значительной мере зависит от скорости линии доступа в каждом из двух конечных пунктов. Однако она также зависит от используемого метода кодирования речи. Например, предположим, что метод кодирования речи порождает цифровой поток данных со скоростью 8 Кбит/с. В этом случае каждый фрагмент длительностью 20 мс занимает 8000 бит/с * 20 мс, или 160 бит, которые должны быть инкапсулированы в дейтаграмму IP.

Если кто подзабыл взаимосвязь заголовков в среде VoIP, напомним, что каждый оцифрованный фрагмент речи снабжается префиксом в виде заголовка транспортного протокола реального времени (Real-Time Transport Protocol, RTP). RTP содержит информацию о времени, на основании которой полученный голосовой фрагмент помещается в синхронизирующий буфер на узле получателя для компенсации вариаций во времени прибытия дейтаграмм.

Заголовок RTP состоит из 16 байт, ему предшествуют 8 байт заголовка UTP. Наконец, дейтаграмма снабжается заголовком IP, а это еще 20 байт. Таким образом, 160 бит, или 20 байт, оцифрованной речи транспортируются в дейтаграмме размером 64 байт.

Если линия доступа в сеть IP имеет скорость 64 Кбит/с, то задержка на размещение дейтаграммы с фрагментом речи длительностью 20 мс при скорости 8000 бит/с будет составлять (64 байт * 8 бит/байт)/64 Кбит/с или 8 мс. В случае линии доступа T-1 задержка в ней будет равняться (64 байт * 8 бит/байт)/1,536 Мбит/с или 0,334 мс. (В качестве скорости линии T-1 взята величина 1,536 Мбит/с, а не 1,544 Мбит/с, потому что 8 Кбит/с используются для обрамления и недоступны для передачи данных.)

В связи с озабоченностью по поводу задержки первый пример указывает, что задержка может отличаться на 7,67 мс в зависимости от того, какая линия доступа используется — на 64 Кбит/с или T-1. Ввиду того, что выход из сети также осуществляется по линии доступа, задержку можно сократить приблизительно на 15 мс только за счет аренды более скоростной линии доступа на каждом из пунктов на Рисунке.

ЗАДЕРЖКА МЕЖДУ ПРОЦЕССАМИ В КОНЕЧНОМ ПУНКТЕ

Поток дейтаграмм поступает из сети IP в частную сеть (пункт Y на Рисунке). При этом маршрутизатор, скорее всего, имеет список доступа. Это список содержит перечень предложений с разрешениями/запретами, с которыми сравниваются различные поля в каждой из пребывающих дейтаграмм. Цель списков доступа — защита внутренней сети; однако они могут использоваться и для ускорения обработки потоков данных в зависимости от типа транспортируемых дейтаграмм.

Так, маршрутизаторами Cisco Systems поддерживается два типа списков доступа, так называемые «стандартные» и «расширенные». В случае стандартных списков доступа проверяется только адрес отправителя дейтаграммы. Для сравнения, в случае расширенных списков доступа для каждой дейтаграммы проверяется адрес отправителя/получателя, протокол, номер порта и другая информация. Многие заботящиеся о защите своей сети организации составляют весьма подробные расширенные списки доступа, при этом предложения для защиты от подмены адресов помещаются обычно в начале списка.

Предложения для защиты от подмены адресов сравнивают адрес отправителя каждой дейтаграммы с адресами RFC 1918, а также с адресом целевой сети и шлейфовым адресом. Прибывающие в сеть дейтаграммы не должны иметь таких адресов в поле адреса отправителя, поэтому они с легким сердцем удаляются из обращения.

За эти необходимые меры защиты приходится платить. Эта плата — задержка на буферизацию прибывающих дейтаграмм и проверку значений ее полей по списку доступа до нахождения совпадений. При обнаружении совпадения маршрутизатор либо отбрасывает дейтаграмму, либо пропускает ее дальше.

Длинный список может вносить значительную задержку, особенно если маршрутизатор приобретен несколько лет назад, потому что дейтаграммы последовательно сравниваются с каждым предложением в списке доступа, пока не будет найдено совпадение или достигнут конец списка.

Конечно, старый маршрутизатор можно заменить на новый, с более быстрым процессором, однако минимизировать задержку можно и другими, более привлекательными способами. Это решение состоит в перемещении соответствующих разрешающих предложений о допуске дейтаграмм с оцифрованной речью в начало списка.

В худшем случае, содержимое дейтаграммы с поддельным адресом и вирусами будет рассматриваться как фрагмент оцифрованной речи, и участник диалога услышит малоприличное рыгание или тому подобный неприятный звук. Таким образом, перемещение разрешений о пропуске на шлюз в начало списка позволит сократить задержку еще на несколько миллисекунд без отрицательных последствий для защиты.

КОМПЕНСИРУЮЩИЙ БУФЕР

Компенсирующий буфер — это область временного хранения дейтаграмм на шлюзе на принимающей стороне. Он реализует механизм компенсации случайных вариаций задержки во времени прибытия дейтаграмм. Большинство шлюзов предоставляет администратору возможность задавать размер буфера для хранения речи в дейтаграммах от 0 мс (буфер отключен) до 225 мс.

Перед помещением дейтаграммы в буфер заголовки IP и UDP удаляются. Однако заголовок RTP изымается только при извлечении реальных данных. Это связано с тем, что заголовок RTP содержит информацию о времени для каждого фрагмента речи. Данная информация служит для определения момента извлечения фрагмента из буфера для восстановления правильной очередности воспроизводимых фрагментов.

Хотя допустимый диапазон размеров буфера составляет от 0 до 255 мс, в действительности он обычно задается равным 10—20 мс. Чем больше размер буфера, тем выше качество воспроизводимой речи, но если размер буфера задать слишком большим, то задержка дейтаграмм может превысить 150 мс.

ДЕКОМПРЕССИЯ

Если задержка на компрессию речи сильно зависит от применяемого алгоритма сжатия, то время декомпрессии речи практически одинаково для всех алгоритмов. Таким образом, смена метода кодирования речи обычно имеет минимальное влияние на время декомпрессии.

ЗАДЕРЖКА ПРИ ПЕРЕДАЧЕ ПО СЕТИ

Мы намеренно откладывали обсуждение вопроса о задержке при передаче по сети до самого последнего момента. Если пользователь может непосредственно контролировать большую часть составляющих задержки, перечисленных в Таблице, то на задержку при передаче по сети он обычно повлиять не в силах.

Задержка при передаче по сети — это задержка в сети IP в одном направлении, как показано на Рисунке. Если сетью IP является Internet, то на поток дейтаграмм влияет множество переменных, большая часть которых неподконтрольна пользователю. Эти переменные включают: трафик, поступающий на каждый маршрутизатор на пути передачи дейтаграмм с оцифрованной речью; вычислительные ресурсы каждого маршрутизатора; пропускную способность каналов между маршрутизаторами и число маршрутизаторов между точками входа и выхода из сети.

В зависимости от того, кто является его провайдером Internet, заказчик может заключить с ним соглашение об уровне сервиса (Service Level Agreement, SLA) для получения гарантии относительно сквозной задержки при передаче трафика через сеть. Вне зависимости от заключения SLA возможность реализации приложения VoIP через Internet следует оценить при помощи утилит ping и traceroute.

Ping позволит определить задержку в оба конца: поделенная на два, она даст приблизительную задержку в один конец, если вы произведете ping маршрутизатора в целевой локальной сети. Если задержка в один конец окажется чрезмерной по сравнению с общей допустимой задержкой, то придется воспользоваться traceroute.

Помимо отслеживания маршрута до адресата это приложение TCP/IP сообщает задержку на каждом транзитном узле на пути до адресата. В результате анализа маршрута до целевой локальной сети вам, возможно, удастся выявить один или более перегруженных маршрутизаторов, вносящих чрезмерную задержку. Позвонив провайдеру раз-другой, вам, может быть, удастся получить альтернативный маршрут через его сеть. По крайней мере, постоянные жалобы могут заставить провайдера Internet заменить устаревший маршрутизатор или увеличить пропускную способность сети.

Ping и traceroute следует применить не один раз, а запускать периодически в течение дня в продолжение нескольких дней, чтобы измерения представляли репрезентативную статистическую выборку. Поэтому ping лучше не использовать во время рождественских каникул и вообще в выходные дни, когда активность в сети заметно отличается от обычной. Кроме того, первые несколько результатов могут дать искаженное значение задержки. Это связано с тем, что маршрутизация в Internet осуществляется в соответствии с IP-адресами получателей. Если же вы указываете имя хоста, IP-адрес которого не известен, то он должен быть вначале определен с помощью DNS, а это вносит некоторый дополнительный вклад в первые вычисления задержки.

ПРОСТАЯ МАТЕМАТИКА

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

Например, если маршрутизаторы являются пограничными устройствами, подключенными к сети IP, то маршрутизацию можно задать статически для устранения ненужных обновлений таблиц. Если ранее вы использовали RIP, то эта мера приведет к прекращению обновлений таблиц RIP, происходящих обычно каждые 30 с и приводящих к остановке передачи данных на все то время, пока происходит обновление таблиц.

Тщательно проанализировав различные составляющие задержки, вы можете заранее определить, насколько удовлетворительно будет функционировать VoIP. Как гласит лозунг бойскаутов — будь готов.

Задержка дейтаграмм в сети