Сети VoIP – голос в пакетах. Проблемы измерения и настройки
Но вместе с первоначальным восхищением новой технологией все большее беспокойство вызывает возможная деградация качества речи. Поскольку это – весьма критичный фактор для распространения услуг VoIP, актуальной становится проблема измерения и оптимизации параметров, влияющих на передачу голоса, а также наличие для этого инструментальных средств. Авторы рассматривают основные элементы передачи голоса по сетям пакетной коммутации и показатели, влияющие на его качество. Техника измерения этих показателей и возможные пути их улучшения продемонстрированы на примере анализаторов компании RADCOM.
Одно из основных требований, предъявляемых к сетям VoIP – способность подключаться к традиционным коммутируемым телефонным сетям общего пользования (ТфОП). Международный союз электросвязи (ITU) решил эту проблему, создав H.323 – комплект стандартов для мультимедийных сетей пакетной коммутации.
Стек протоколов Н.323 показан на рис. 1. Для передачи служебных сообщений между терминалами и привратником использован протокол сигнализации RAS (Registration, Admission, Status). Для установления и разрыва соединений между двумя терминалами H.323, а также между терминалом и шлюзом используется протокол сигнализации Q.931. Протокол управления H.245 обеспечивает согласование возможностей компонентов сети, установление и разрыв логических каналов, передачу запросов на установление приоритета, управление потоком.
Как видно из рисунка, наиболее важные сообщения передаются по протоколу ТСР (Transmission Control Protocol). Это гарантирует их повторную доставку в случае потери. Сам трафик передается без гарантии доставки посредством протокола UDP (User Datagram Protocol). Его применяют из-за того, что при передаче речи повторная доставка потерянных пакетов не имеет смысла – они прибудут слишком поздно, чтобы их использовать в речевой реконструкции. Доставку информации в режиме реального времени обеспечивают два протокола, как это определено в IETF RFC 1889: RTP (Real-time Transport Protocol), который передает аудио/видео-потоки, и RTCP (RTP control protocol), включающий периодическую трансляцию управляющих сообщений и данных о состоянии сессий.
Компоненты сети H.323 приведены на рис. 2. Это – терминалы H.323, которые являются конечными точками в локальной вычислительной сети; шлюзы, связывающие ЛВС с другими сетями (ТфОП, ISDN, беспроводные и выделенные корпоративные сети); привратник, реализующий функции управления доступом, и многоточечное управляющее устройство (MCU, Multipoint Control Unit), для управления конференциями между тремя и более точками.
Терминалы H.323 представляют собой устройства, с помощью которых пользователи могут взаимодействовать друг с другом в режиме реального времени (рис. 3). Типичный пример терминалов – клиентские персональные компьютеры (ПК) с программным обеспечением аудио- или видеоконференций типа NetMeeting от Microsoft. В последнее время появились специализированные устройства – так называемые Internet-телефоны. Все терминалы обязательно должны поддерживать стандарты G.711 для сжатия голоса, H.245 для согласования параметров соединения, Q.931 для установления и контроля соединения, канал RAS для взаимодействия с привратником, а также протоколы RTP/RTCP для оптимизации доставки аудио- (видео-) потоков. Кроме этого, терминалы могут поддерживать и другие аудиокодеки, а также видеокодеки и конференции документами по протоколу T.120.
Шлюзы позволяют связать терминалы H.323 с другими оконечными устройствами, не поддерживающими данный стандарт. Их основная функция – согласование систем сигнализации, а также кодирование и декодирование голоса. Шлюзы располагают на стыке традиционных телефонных сетей и устройств пакетной коммутации. Яркий пример – шлюз ТфОП/IP (рис. 4), соединяющий терминалы H.323 с сетью коммутации каналов (SCN, Switched Circuit Network). Существует много типов шлюзов, отличающихся числом поддерживаемых терминалов, соединений, конференций и протоколов.
Привратник является необязательным устройством сети H.323. Тем не менее, если он включен в сеть, то должен выполнять определенный набор функций. Привратники выступают в качестве центра обработки вызовов внутри своей зоны и выполняют важнейшие функции управления ими. (Зона определяется как совокупность всех терминалов, шлюзов и MCU под юрисдикцией данного привратника.) Эти устройства можно использовать для балансировки сети или быстрого подключения резервных возможностей.
Основное назначение привратника как устройства сетей Н.323 заключается в разделении функций шлюза и функций сетевого управления. Типичный привратник реализуют на ПК, в то время как шлюзы часто базируются на специальных аппаратных платформах. Привратники, прежде всего, обеспечивают для устройств в своей зоне преобразование псевдонимов (имен) терминалов и шлюзов в IP-адреса, а также перевод между внутренними и внешними системами нумерации. Другая важная функция привратников – обеспечение управления доступом, т. е. идентификация вызовов с помощью RAS. Они также контролируют полосу пропускания канала. Привратники реализуют и дополнительные возможности, например управление по SNMP-протоколу (Simple Network Management Protocol).
Привратник может поддерживать ряд моделей сигнализации. Модель сигнализации определяет, какие сигнальные сообщения проходят через привратник, а какие передаются непосредственно между оконечными устройствами. На рис. 5 приведены две таких модели. Прямая модель сигнализации (рис. 5а) подразумевает обмен сигнальными сообщениями, минуя привратника. В другой, маршрутизирующей модели (рис. 5б) все сигнальные сообщения проходят через привратник и только основной трафик передается непосредственно между станциями.
Многоточечное управляющее устройство (MCU) поддерживает многосторонние (трех- и более) конференции. Логически оно содержит две части: многоточечный контроллер (MC, Multipoint controller), который использует сигнализацию и управляющие сообщения для установки и управления конференциями, а также многоточечный процессор (MP, Multipoint Рrocessor), который принимает аудио- и видеопотоки из конечных точек, обрабатывает их и пересылает требуемым устройствам. MCU может осуществлять функции как MC, так и MP. В этом случае он называется централизованным MCU (децентрализованный MCU выполняет только функции MC, передавая функции MP конечным точкам).
Важно иметь в виду, что определение всех сетевых устройств H.323 – чисто логическое. Никаких спецификаций на их физическое разделение нет. Например, MCU может быть как автономным устройством, так и интегрироваться в терминал, шлюз или привратник.
Что влияет на качество речи
Первостепенными факторами, определяющими качество голоса, являются: выбор аудиокодека, время задержки, джиттер и потери пакетов.
Аудиокодеки – важнейший элемент терминалов H.323. Они позволяют уменьшать необходимую ширину голосового канала при сохранении требуемого качества речи. Различных схем сжатия достаточно много, но большинство устройств H.323 используют кодеки, стандартизированные ITU. Пользовательские приложения (например, NetMeeting) могут поддерживать различные кодеки, выбирая тот или иной посредством протокола H.245. Аудиокодеки можно сравнить по четырем параметрам (табл. 1):
· Скорость оцифровки – определенная битовая скорость, до которой кодек сжимает голосовой канал 64 Кбит/с. Для большинства кодеков она составляет 8; 6,4 и даже 5,3 Кбит/с. Однако следует иметь в виду, что это – только скорость сжатия речи. При передаче пакетированного голоса по сети за счет потерь протоколов (например, RTP/UDP/IP/Ethernet) скорость увеличивается, вплоть до скорости передачи данных;
· Сложность реализации кодека: чем она выше, тем больше требований к ресурсам процессора;
· Качество речи;
· Задержка оцифровывания. Каждый алгоритм требует, чтобы до сжатия речь буферизовалась. Эта задержка добавляется к общей сквозной задержке. Сеть с чрезмерной сквозной задержкой заставляет людей общаться в режиме полудуплексного разговора вместо нормального дуплексного диалога.
Идеального кодека не существует. Выбор нужной схемы сжатия зависит от важности тех или иных параметров кодека. Сейчас наиболее популярны аудиокодеки G.723 и G.729.
Время задержки оказывает заметное влияние на дуплексный телефонный разговор, который в отличие от широковещательной передачи (например, RealAudio) или передачи данных очень чувствителен к задержкам. Полная задержка становится заметной, когда она превышает 250 мс. Поэтому в рекомендации ITU-T G.114 максимальная односторонняя задержка, при которой сохраняется высокое качество голоса, определяется как 150 мс. При превышении этого порога поддерживать дуплексный разговор трудно – голоса абонентов накладываются друг на друга. Двусторонняя задержка более 500 мс делает телефонные разговоры практически невозможными. Для справки: типичная задержка при разговоре через геостационарный спутник – 150–500 мс.
Задержка имеет фиксированную и переменную составляющие. Например, фиксированная задержка определяется расстоянием, тогда как переменная зависит от меняющихся сетевых условий. Общая задержка складывается из различных компонентов. Рассмотрим наиболее значимые из них:
Сетевая задержка вносится узловыми элементами сети VoIP. Для ее минимизации необходимо сократить число узлов сети на пути пакетов между абонентами. Определить это число можно с помощью утилиты “traceroute”. Некоторые провайдеры способны обеспечить задержки на своих сетях, не превышающие определенный уровень. Кроме того, для уменьшения сетевой задержки речевому трафику задают высший приоритет по отношению к нечувствительному к задержкам потоку данных.
Задержка кодека вносится каждым алгоритмом сжатия. Например, G.723 добавляет фиксированную задержку в 30 мс. У других кодеков встроенная задержка может быть меньше, но при этом возможно снижение качества речи или увеличение требуемой полосы пропускания.
Буфер компенсации джиттера также вносит свою задержку. Джиттером называют отклонения от средней задержки следования пакетов. Задержка может быть различной для каждого пакета, в результате чего, отправленные через равный интервал, они прибывают неравномерно, а то и не в исходной последовательности (рис. 6). Так как алгоритм декомпрессии требует фиксированного интервала между поступлением пакетов, в шлюзе необходим буфер компенсации джиттера. Он задерживает поступающие пакеты, чтобы передавать их устройству декомпрессии с заданным интервалом. Кроме того, он также фиксирует любые ошибки, контролируя номер последовательности в полях сообщений протокола RTP. Однако буфер компенсации зачастую вносит весьма значимую задержку. Его размер задают таким, чтобы буферизовать целое количество пакетов с учетом ожидаемого значения джиттера. Как правило, для каждого направления задержка буфера составляет 80 мс.
Типичная структура общей односторонней задержки приведена в табл. 2.
Измерение задержки
Часто бывает важно определить, какую задержку вносит то или иное сетевое устройство и от каких его параметров она более всего зависит. Например, как влияет размер буфера компенсации на время задержки шлюза. Инструментальные средства компании RADCOM позволяют измерять задержку, посылая контрольную информацию через один порт и захватывая ее через другой. Анализаторы протоколов могут функционировать в двух средах одновременно (например, в локальной и глобальной вычислительных сетях), с жесткой синхронизацией, которая позволяет точно измерять задержку между соответствующими портами.
Кроме того, можно измерить задержки и потери непосредственно в трафике. Анализатор подключают к двум портам какого-либо устройства, например шлюза, в режиме мониторинга, не внося при этом изменений в текущий трафик (рис. 7). Шлюз продолжает работать, пропуская через себя поток пакетов. Анализатор RADCOM с помощью эвристического алгоритма идентифицирует одинаковые сегменты во входном и выходном потоке данных и определяет время прохождения устройства определенным сегментом. Таким образом анализатор отображает графическую и цифровую информацию о задержках и потере пакетов в устройстве для каждого направления (рис. 8). Используя аналогичный метод, можно измерить задержку прохождения через всю сеть.
Когда два объекта географически разнесены, для определения задержки распространения в одну сторону необходима точная синхронизация двух отдаленных анализаторов, добиться которой проблематично. Гораздо проще измерить двустороннюю задержку (туда и обратно) с помощью анализатора протоколов или используя утилиту “ping”.
Измерение джиттера
Измерение джиттера базируется на определении интервала между прибытием пакетов. Чаще всего вычисляют среднее значение джиттера и его среднеквадратичное отклонение, которые в идеальной сети равны нулю. При проведении измерений джиттера для аудиопотоков необходимо учитывать три явления: подавление пауз, потери пакетов и нарушение последовательности пакетов.
Чтобы уменьшить скорость оцифровки, кодеки не передают “нулевые” отсчеты, соответствующие паузам в разговоре. Это позволяет сократить объем передаваемых данных на 50% без потери информации. В протоколе реального времени RTP первый пакет после периода тишины передается с установленным битом подавления паузы. При вычислении джиттера этот бит контролируется и длинный промежуток между пакетом перед паузой и сразу после паузы игнорируется.
Интервал между двумя последовательно прибывшими пакетами увеличивается и при потере пакета. Например, если три пакета были посланы в моменты 0, 20 и 40 мс, и второй пакет был потерян при передаче, то интервал прибытия пакетов составит 40 мс, даже если бы сеть не породила никакого джиттера. При правильном измерении джиттера такие случаи должны быть выявлены посредством контроля нумерации пакетов.
Пакеты с нарушенной нумерацией также могут исказить измерение джиттера. Пусть пакет 1 был послан в момент 0 и прибыл в момент 100 мс, пакет 2 был послан в момент 20 мс и прибыл в момент 140 мс, а пакет 3 был послан в момент 40 мс и прибыл в момент 120 мс. Пакеты прибыли получателю во время 100, 120 и 140 мс, так что джиттер нельзя обнаружить, если не обращать внимание на их номера. Если же учесть нумерацию пакетов, то значение джиттера будет 40 мс на интервале между пакетами 1 и 2, и –20 мс между пакетами 2 и 3.
Компания RADCOM предлагает решения для измерения джиттера на любом физическом интерфейсе. К примеру, программный пакет AudioPro, работающий в составе программного обеспечения анализаторов RADCOM, способен анализировать каналы VoIP, выделять индивидуальные аудиопотоки и измерять для них джиттер, учитывая при этом подавление пауз, потери пакетов и нарушение последовательности их поступления (рис. 9).
Потери пакетов
Потеря пакета – это нормальное явление в сетях пакетной коммутации. Причины потери – перегрузка каналов связи, чрезмерные коллизии в локальной сети, сбои на физическом уровне и многое другое. Протоколы транспортного уровня, например TCP, принимают во внимание потери пакетов и допускают их повторную передачу. Поскольку данные RTP передаются по ненадежному протоколу UDP, типичный аудиокодек делает случайную потерю пакета незаметной для пользователя. Так, вместо потерянного пакета кодек может использовать предшествующий ему или выполнить более сложную интерполяцию, чтобы устранить прерывания в звуковом потоке.
Потери пакетов становятся реальной проблемой, когда превышают определенный порог – приблизительно 5% от всех пакетов или когда пропадают соседние пакеты. В таких ситуациях наилучший кодек не в состоянии компенсировать потери пакетов, что приводит к ухудшению качества передаваемого голоса. Таким образом, важно знать не только процент потерянных пакетов, но и группируются ли они в потоке.
RADCOM AudioPro не только собирает статистику для всего аудиопотока (рис. 10), но и анализирует каждую конкретную потерю пакета (рис. 11). В результате легко проверить, обеспечивают ли текущие сетевые условия требуемое качество голоса.
Влияние сети на качество голоса
Одним из важных показателей состояния сети является общая сетевая загрузка. Когда она высока, особенно для сетей со статистическим доступом (например, Ethernet), джиттер и потери пакетов достаточно велики. Так, высокая загрузка в Ethernet ведет к росту числа коллизий. Даже если вступившие в противоречие кадры в конечном счете будут переданы, они не поступят к получателю вовремя – следовательно, возрастет джиттер. При превышении определенного уровня коллизий происходят и потери пакетов.
Поэтому даже в неперегруженных сетях желательно применять схемы присваивания приоритетов или использовать протоколы резервирования полосы пропускания, например RSVP (Resource Reservation Protocol – протокол резервирования ресурсов).
Регулируемые параметры оборудованиЯ VoIP
Установки буфера компенсации
Буфер компенсации можно конфигурировать на большинстве устройств VoIP. Его размер должен быть таким, чтобы соблюдался оптимальный баланс между задержкой и качеством голоса: слишком маленький буфер может привести к нежелательным звуковым эффектам, а слишком большой способен превратить дуплексный разговор в полудуплексный, при отличном качестве голоса.
Определить оптимальный размер буфера поможет AudioPro. На рис. 12 показан анализ аудиопотока с ожидаемым интервалом между пакетами в 20 мс. В таблице на экране столбцы имеют следующие значения:
Sequence number – номер поступающего RTP-пакета;
Absolute time – абсолютное время прибытия пакета;
Delta time – интервал после прибытия предшествующего пакета;
Delay-Expected Inter-Arrival time – отклонение времени реального поступления пакетов от ожидаемого (при интервале 20 мс);
Bias – смещение, эмулирующее буфер компенсации. Оно показывает суммарное отклонение времени поступления каждого последующего пакета. Таким образом можно увидеть, будут накапливаться пакеты в буфере или нет. Если смещение превышает размер буфера, то поступающие пакеты будут сброшены.
Normalized bias – столбец смещения нормализуется вокруг нуля. Зная смещение, можно определить размер желаемого буфера компенсации. Если не должен пропасть ни один пакет, размер буфера компенсации устанавливают равным максимальной величине смещения.
Размер пакета
Выбор размера пакета также влияет на качество речи. Пакеты большого размера значительно уменьшают необходимую ширину полосы пропускания, но добавляют задержку пакетирования, так как передатчик тратит больше времени, чтобы заполнить пакет. “Накладные расходы” при пакетной передаче VoIP достаточно высоки. Рассмотрим сценарий, где голос сжимается до 8 Кбит/с, а пакеты посылаются каждые 20 мс. Таким образом, размер речевой информации в каждом пакете – 20 байт. Однако чтобы передать эти пакеты по RTP, к ним нужно добавить: заголовок Ethernet – 14 байт, заголовок IP – 20 байт, заголовок UDP – 8 байт и дополнительные 12 байт для RTP. В общей сложности 54 лишних байта, чтобы передать 20 байт голоса.
Как повысить содержание полезной информации в трафике? Во-первых, можно увеличить размер пакетов, например отправляя их каждые 40 мс. Однако при этом возникнет дополнительная задержка. Другой подход – сжатие заголовка. Этот метод использован в ряде устройств, особенно в работающих на медленных каналах связи, таких как PPP (Point-to-Point Protocol), FR (Frame Relay) или ISDN. Данный протокол обычно называют CRTP (Compressed RTP). Он сжимает заголовок до нескольких байт. AudioPro отображает эффективность загрузки пакета и среднюю скорость передачи (пакет/с и бит/с) для каждого потока, что позволяет определить оптимальный размер пакета для любой сети.
Другие характеристики сетей VoIP
До сих пор речь шла о проблемах, связанных с передачей речи после установления соединения. Однако в технологии VoIP не менее важен и сам процесс установления соединения. Его основные параметры: время установления соединения – интервал от начала вызова (набор цифр) ответа абонента до установления голосового соединения, коэффициент успешных вызовов – отношение числа установленных соединений к числу всех попыток соединения абонента, а также важный для провайдера показатель – интенсивность установления соединений, т.е. сколько соединений в секунду может быть установлено в сети.
Измерение данных параметров включает просмотр сообщений Q.931 и анализ их последовательности. Эти сообщения чередуются с передачей обычных данных, и иногда трудно выловить пакеты Q.931 из общего потока. Однако сообщения Q.931 имеют поле “call reference”, которое позволяет различать одно соединение от другого. Инструментальные средства, подобные AudioPro, выделяют сигнальные сообщения из речевых потоков, а также представляют их в “call-oriented”-формате. В результате возможно проанализировать коэффициент успешных вызовов (отдельно для входящих и исходящих вызовов); просмотреть список вызовов для идентификации проблематичных попыток соединения, увидеть декодированные пакеты H.323 определенного вызова; наконец, проанализировать статистику – например, время установки вызова и т.п.
Как измерить качество голоса?
Для количественной оценки качества речи ITU утвердил две важные рекомендации – P.800 (MOS, Mean Opinion Score) и P.861 (PSQM, Perceptual Speech Quality Measurement). В соответствии с P.800 проводится тест, включающий запись различных заранее выбранных речевых фрагментов и их последующее воспроизведение смешанной группе мужчин и женщин. Оценки, данные этой группой, усредняются, и в результате получают значение MOS в диапазоне от 1 (наихудший) до 5 (наилучший). MOS 4 считается голосом удовлетворительного качества.
В методике P.861 (PSQM) сделана попытка автоматизации процесса измерения. В ней определен алгоритм, посредством которого компьютер может получить оценки, которые коррелируют с MOS. Однако многие специалисты высказывают сомнение в применимости данной рекомендации к оценке пакетной речи. Дело в том, что методика PSQM разрабатывалась для коммутируемых сетей и не анализирует такие важные в VoIP параметры, как, например, джиттер и потери пакетов.
Предлагают и другие подходы к измерению качества речи. Один из них – система восприимчивого анализа/измерения (PAMS, Perceptual Analysis/Measurement system), разработанная British Telecom (BT). Тесты, проведенные BT, показали хорошую корреляцию между автоматизированным PAMS-методом и результатами MOS.
Отметим, что инструментальные средства, подобные RADCOM AudioPro, позволяют прослушать разговор в любой точке речевого маршрута. Благодаря этому можно не только контролировать качество голоса, но и определить, в какой точке сети происходит его ухудшение.
Имитация сети
Поскольку сеть полна скрытых ловушек, желательно сымитировать поведение сети, прежде чем устанавливать оборудование. С этой целью созданы такие инструментальные средства, как RADCOM Internet Simulator. Он позволяет имитировать поведение глобальной сети Интернет или корпоративной Intranet для чувствительного к задержкам трафика. При этом можно вводить управляемые задержки, джиттер, создавать нарушения последовательности, а также потери пакетов.
Internet Simulator работает совместно с AudioPro, что позволяет измерить параметры сети клиента и передать их в Internet Simulator для моделирования – подбор параметров оборудования происходит до его установки и эксплуатации.
Технология VoIP обладает рядом существенных достоинств. Но как и у любой новой технологии, у нее есть свои проблемы. Чтобы их разрешить, необходимы соответствующие инструментальные средства, примером которых служат продукты фирмы RADCOM.
По материалам компании RADCOM