ТЕХНОЛОГИЯ ПЕРЕДАЧИ ГОЛОСА ЧЕРЕЗ IP-СЕТИ
Терминалы VoIP
Технология передачи голоса через IP-сети уже прочно вошла в
жизнь современного человека. Кто-то не задумывается, что егоголос добирается в виде непрерывного аналогового сигнала поТфОП только до ближайшего шлюза, а далее продолжает свойпуть в виде потока голосовых пакетов. Некоторые использует длямеждународного разговора дешевые карты провайдера VoIP. Другие сознательно покупают гарнитуру и устанавливают у себя наПК специальные программы (Skype, Google Talk…) для того, чтобы осуществлять телефонную связь с использованием технологииVoIP по всему миру, снижая свои затраты. Крупные и средние
корпорации устанавливают у себя офисные VoIP АТС, которые
позволяют использовать IP-телефонию для внутренних переговоров, а исходящий телефонный трафик может быть направлен, как вобычную телефонную сеть, так и провайдеру VoIP.
Попробуем разобраться, какие общие технологические особенности VoIP объединяют этих пользователей и в чем проявляются отличия, присущие только определенным группам пользователей.
Начнем с классификации терминалов. Все терминалы VoIP делятся на программные реализации для ПК и отдельные полнофункциональные устройства. Естественно, что для ПК тоже потребуется дополнение в виде гарнитуры (телефон + микрофон).
Однако основную работу будет выполнять аппаратный комплекс
ПК под управлением специализированной программы, поэтомучасто такие терминалы VoIP называют программными. Существует большое количество программных реализаций VoIP-терминалов, которые следует разделять на стандартные и специализированные. Стандартные программные пакеты ориентированы на реализацию стандартизованных протоколов сигнализации
VoIP: H.323 или SIP (например, SJPhone или eyeBeam), тогда как
специализированные используют нестандартную сигнализацию ичасто нестандартные протоколы передачи речи (например, Skypeили Cisco IP Communicator). Каждая программа эмулирует на экране компьютера образ некоего телефонного устройства IP-телефона (eyeBeam, SJPhone, Skype), на котором обычно отражаютсяклавиши набора номера, функциональные кнопки, телефонныйсправочник, меню сервисов и пр. (рис. 1.1).
Рисунок 1.1. Пример интерфейсов программных VoIP-терминалов
Как правило, экран управления программного IP-телефона (IPPhone)содержит общепонятные обозначения стандартных функций телефонного аппарата: поднятую и положенную телефоннуютрубку, клавиши набора цифр телефонного номера, изображениемикрофона и панели управления уровнем громкости. При этом,даже программы известных производителей могут иметь определенные отличия в реализации сигнальных протоколов H.323 илиSIP, что, как правило, не приводит к нарушениям в процессе установления обычного соединения, но может приводить к некорректной реализации дополнительных видов обслуживания (ДВО).
Необходимо отметить, что сигнализационные протоколы
H.323 не совместимы с протоколами SIP, поэтому взаимодействие соответствующих терминалов обычно организуется на уровне программного коммутатора SX (Interworking Function).
Аппаратные терминалы VoIP можно подразделить на так на-
зываемые USB-Phone и аппаратные IP-Phone. USB-Phone – этоотдельное функциональное устройство (рис. 1.2), которое подключается к разъему USB стандартного ПК. Как видно из рис. 1.2, поформе оно напоминает телефонный аппарат и содержит все необходимые клавиши управления.
Однако для своего функционирования этому устройству требуется ПК, подключенный к IP-сети сустановленными драйверами. То есть USB-Phone, по своей сути,является упрощённым интерфейсом программного IP-телефона.
Рисунок 1.2. Аппаратный USB-Phone
Аппаратный IP-Phone представляет из себя отдельное полнофункциональное устройство, которое имеет встроенный Ethernet
интерфейс, и выполняет все функции по установлению и разъединению телефонных соединений и передачи голоса (рис. 1.3).
Рисунок 1.3. Аппаратный IP-телефон Alcatel-Lucent
Существует большое количество разнообразных моделей аппаратных IP-Phone различных компаний производителей, например, IP-телефоны компании Cisco или Alcatel-Lucent.
Шлюзы VoIP обеспечивают возможность подключения обычных аналоговых телефонных аппаратов или цифровых телефоновISDN к пакетным сетям. Для подключения к IP-сети используетсяIP-интерфейс, а все функции по установлению и разъединениюсоединений в пакетной сети выполняются самим шлюзом. Шлюзтакже может поддерживать аналоговую сигнализацию и ЦАС №1(DSS1) на абонентских портах.
Офисные АТС (УПАТС) выполняют все функции по поддержке сигнализации и передачи голосового трафика в пакетной сетипосредством встроенных шлюзов VoIP и отличаются от последнихобязательной возможностью внутренних соединений между локальными абонентами и наличием большого набора ДВО.
Таким образом, все перечисленные терминалы VoIP должныобязательно выполнять следующие функции:
- обеспечивать кодирование голоса для преобразования в цифровой вид (кодеки);
- выполнять упаковку фрагментов речи в пакеты по стеку протоколов RTP/UDP/IP;
- поддерживать непрерывный поток голосовых пакетов (RTP-сессию);
- сглаживать неравномерность поступления пакетов (антиджиттерный буфер);
- обеспечивать установление и разъединение голосовых соединений (сигнализационные протоколы H.323 или SIP);
- поддерживать ДВО.
Последовательно рассмотрим реализацию всех перечисленныхфункций.
Кодеки
Задача преобразования аналогового телефонного сигнала вцифровой поток и его восстановление из непрерывного цифровогопотока в аналоговый сигнал, воспроизводимый в телефоне, быларешена еще на заре создания первых цифровых систем передачи спомощью кодеков, построенных по Рекомендации МСЭ-Т G.711.
Для кодирования использовался метод импульсно-кодовой модуляции (ИКМ), который предполагал, что поступающий аналоговый голосовой сигнал сначала дискретизируется с частотой 8 кГц,а затем амплитуда полученных отсчетов проходит процедуру нелинейного квантования по уровню в соответствии с квазилогарифмическим законом (А-закон для Европы). В результатеэтих действий каждый отсчет представляется одной 8-битной двоичной комбинацией. Таким образом, скорость передачи на выходе
кодека составляет 64 кбит/с (8 кГц х 8 бит). Этот кодек отличаетсяпростотой реализации и достаточно высоким качеством передачиречи, что обусловливает его широкое применение и в технологииVoIP.
К недостаткам кодеков G.711 следует отнести относительновысокую скорость передачи, необходимую для одного голосовоговызова.
Рекомендация G.726 описывает технологию кодирования сприменением адаптивной дифференциальной импульсно-кодовоймодуляции (АДИКМ).
Метод основан на кодировании не абсолютных значений аналогового сигнала, а на передачи информацииоб изменении сигнала по сравнению с его предыдущим значением,что позволяет снизить требуемую скорость передачи до 32 кбит/с(24 кбит/с, 16 кбит/с). Такие кодеки часто используются в системах видеоконференции. В приложениях VoIP кодеки такого типапрактически не нашли применения из-за недостаточной устойчи-
вости к потерям пакетов.
В кодеках, основанных на Рекомендации G.728, используетсятехнология LD-CELP (LowDelay – CodeExcitedLinearPrediction).
Данная технология предполагает, что передается информация необ одном отсчете, а о группе из 5 отсчетов. Таким образом, длительность кадра составляет 0,625 мс, а задержка кодирования непревышает 2,5 мс.
Недостатками кодека G.728 являются высокиетребования к производительности процессора обработки (40 MIPS)и относительно высокая чувствительность к потерям кадров.
Данный тип кодеков предназначен для использования в терминалах
видеоконференцсвязи и в терминалах VoIP применяется достаточно редко.
Семейство кодеков G.729 реализовано с применением технологииCS-ACELP (ConjugateStructure – AlgebraicCodeExcitedLinearPrediction).
Алгоритм сопряженной структуры с управляемымалгебраическим кодом и линейным предсказанием достаточносложен (подробнее см. в [13]). Кодек формирует кадры голосовогосигнала длительностью 10 мс, при стандартной частоте дискретизации 8 кГц. Скорость передачи на выходе кодека составляет 8кбит/с. В терминалах VoIP данный кодек применяется очень часто,поскольку обеспечивает достаточно высокое качество передачи
речи и устойчив к потерям кадров.
Рекомендация G.723 описывает технологию MP-MLQ (MultiPulse – Multi Level Quantization). Алгоритм множественной импульсной многоуровневой квантизации предполагает, что сначаларечь кодируется кодеком G.711, а затем применяется вокодер.
Процесс обработки речи предполагает формирование кадров дли-
тельностью 30 мс. Данный алгоритм позволяет снизить скоростьпередачи на выходе кодера до 5,6-6,3 кбит/с. Кодек имеет два варианта кодирования: с алгоритмом MP-MLQ, работающем на скорости 6,3 кбит/с, и с алгоритмом CELP, обеспечивающем скорость5,6 кбит/с. Такой кодек обеспечивает наименьшую скорость насвоем выходе, однако чувствителен к потерям пакетов. Применение кодеков этого типа в терминалах VoIP ограничено относительно невысоким качеством кодирования речи.
Наилучшее качество передаваемой речи обеспечивают широкополосные кодеки, которые позволяют кодировать весь диапазончастот человеческой речи 0,05 – 7 кГц. Одним из таких кодековявляется кодек G.722, использующий технологию субдиапазоннойадаптивной дифференциальной импульсно-кодовой модуляции(sub-band ADPCM). Для кодирования речи в семействе кодековG.722 дискретизация происходит на частоте 16 кГц (иногда на 8кГц для обеспечения обратной совместимости) и каждый отсчёт
кодируется при помощи 14 бит. Далее поток бит проходит вторичное кодирование на SB-ADPCM кодере, который снижает скоростьпередачи до 64 кбит/с. Таким образом, кодеки семейства G.722обеспечивают передачу речи в высоком качестве (в некоторых источниках используется термин «HD quality») при требованиях кполосе пропускания не выше 64 кбит/с (не выше, чем у кодекаG.711).
Последней версией семейства кодеков G.722 является кодек с
функционаломAMR-WB (AdaptiveMultirateWideband), позволяющему производить адаптивное изменение скорости передачи взависимости от условий сетевого окружения. В случае обнаружения насыщения сети пакетами, кодек автоматически снижает скорость передачи. За счёт механизма адаптации происходит снижение требования к занимаемой полосе пропускания.
Скорость передачи составляет 6,6-23,85 кбит/с. Преимуществами данного кодекаявляется высокое качество передаваемой речи. Недостатками –сложный механизм кодирования речи, который поддерживается невсеми терминалами и системами.
Наряду с перечисленными кодеками [13], традиционно применяемыми в сетях фиксированной связи, стремительное развитиетехнологий кодирования речи нашло свое отражение в сетях связис подвижными объектами. Типичным кодеком, используемым донедавнего времени во всех мобильных телефонах, является кодекпо Рекомендации GSM 06.02, который обеспечивает скорость навыходе 13 кбит/с. В последнее время в мобильных терминалах устанавливаются кодеки с алгоритмом AMR (AdaptiveMultiRate). Укоторых скорость передачи на выходе составляет 4,7-11 кбит/с придостаточно высоком качестве передачи речи.
Кроме стандартизованных кодеков некоторые компании разрабатывают собственные корпоративные кодеки (например, известный кодек NetCoder компании AudioCodes). Однако, применение таких кодеков резко ограничено их несовместимостью состандартными кодеками. Это является существенным недостатком, кроме тех случаев, когда такое ограничение является стратегической целью компании (например, Skype).
Многие из перечисленных кодеков используют дополнительные механизмы повышения эффективности передачи речи, например, алгоритм обнаружения активных фрагментов речи и паузVAD (Voice ActivityDetector). Он позволяет уменьшить требуемую скорость передачи в 4-9 раз.
Однако, в связи с быстрым развитием транспортных сетей,приводящих к многократному уменьшению стоимости передачиданных, многие критерии, по которым ранее проводился отбор иклассификация кодеков, теряют свою значимость. Так в современных сетях NGN на первое место выдвигаются показатели качествапередачи речи, а способы уменьшения требуемой полосы пропускания становятся менее востребованными. Развитие микропроцессорной техники в области построения все более мощных цифро-
вых сигнальных процессоров (DSP) снижает значимость требований по быстродействию, необходимому для обработки речевыхсигналов. Оно еще недавно было очень существенным фактором.
Применение различных кодеков в сетях VoIP выдвигает сле-
дующие критерии, расположенные по степени значимости:
1. Качество передачи речи, определяемое как характеристиками кодера, так и показателями пакетной сети (задержки пакетов, джиттер, потери пакетов).
2. Требуемая полоса пропускания в пакетных сетях с учетомзаголовков.
Качество передачи речи, обеспечиваемое свойствами конкретного кодека, обычно оценивается по характеристике MOS (MeanOpinionScore).
Усредненное экспертное мнение оценивается попятибалльной шкале, в которой значения в пределах 4-5 балловсоответствуют высокому качеству, 3-4 баллов – хорошему качеству, менее 3 баллов – неудовлетворительному качеству.
В пакетных сетях важными характеристиками, влияющими накачество передачи речи являются:
а) задержка, вносимая кодером (поскольку общая задержка передачи не должна превышать 150 мс);
б) типовой размер полезной (голосовой) части пакета;
в) требуемая скорость передачи в пакетной сети с учетом заголовков.
В кодеках время задержки, вносимой кодированием, и размеркадра определяются применяемой технологией. Типовой размерполезной части голосового пакета не может быть меньше, чемразмер кадра, но в одном пакете могут размещаться несколькокадров речи. Выбор оптимальной длины полезной части голосового пакета также зависит от свойства кодека по минимизации влияния потерянных пакетов на качество воспроизводимой речи. Чембольше отрезок речи передавался в одном пакете, тем труднее
сглаживать эффект от его потери в сети. Таким образом, сведемвсе характеристики кодеков в общую сравнительную таблицу 1.1.
Таблица 1.1. Сравнительные характеристики кодеков
Протокол передачи в реальном времени (RTP)
Для того, чтобы обеспечить передачу непрерывного потока через пакетную сеть, необходимо использовать такой протокол, который мог бы решать следующие проблемы:
- контроль и восстановление порядка поступления пакетов;
- устранение неравномерности задержки поступления пакетов;
- сглаживание эффекта потери пакетов.
Следовательно, протокол, обеспечивающий решение этих проблем должен:
- вести последовательность пакетов (нумеровать и перенумеровывать);
- обнаруживать потерю пакетов и синхронизировать во времени.
Основой для такого протокола может служить как стек TCP/IP,так и стек UDP/IP.
Вариант с TCP/IP практически невозможен, так как протоколTCP, хоть и обеспечивает нумерацию пакетов, но абсолютно неподходит к передаче трафика в реальном масштабе времени. Протокол TCP (глава 3 в [6]) распознаёт потерю пакетов и осуществляет переспрос, что значительно увеличивает время поступлениянеобходимых данных и исключает возможность работы в реальном масштабе времени. Протокол TCP обеспечивает сложный механизм контроля скорости передачи потока данных, что негативносказывается на работе приложений реального времени.
Более подходящим для таких приложений является протоколUDP. Он действует по упрощённой схеме без установления и поддержания логического соединения, что позволяет ему работатьбыстрее. Протокол UDP осуществляет только доставку пакета внужный порт и сверку контрольной суммы. Функции обработкипоследовательности пакетов и их синхронизации по временнымотметкам добавляются уже в протоколе RTP (Real-time TransportProtocol – транспортный протокол в реальном времени).
Протокол RTP, описанный в RFC 1889, работает вместе с протоколом управления RTCP (Real-TimeTransferControlProtocol –протокол контроля передачи в реальном времени). RTP осуществляет передачу закодированного аудио- и видеосигнала, а RTCPобеспечивает мониторинг доставки пакетов и сбор статистическихданных.Для того, чтобы обеспечить передачу непрерывного потока через пакетную сеть, необходимо использовать такой протокол, который мог бы решать следующие проблемы:
- контроль и восстановление порядка поступления пакетов;
- устранение неравномерности задержки поступления пакетов;
- сглаживание эффекта потери пакетов.
Следовательно, протокол, обеспечивающий решение этих проблем должен:
- вести последовательность пакетов (нумеровать и перенумеровывать);
_ обнаруживать потерю пакетов и синхронизировать во времени.
Основой для такого протокола может служить как стек TCP/IP,
так и стек UDP/IP.
Рисунок 1.4 Сессии RTP и RTCP
За счет буферизации на приеме RTP позволяет:
- устранить отклонение задержек передачи пакетов (джиттер);
- восстановить порядок следования пакетов.
Каждая RTP-сессия (рис. 1.5) идентифицируется следующимипараметрами: IP-адресами участников (IP_src=x, IP_dst=y) и четными номерами UDP-портов (Port_src=2m, Port_dst=2n). Для контроля и управления RTP-сессией организуется сессия протоколаRTCP.
Идентификация RTCP-сессии включает те же IP-адресаучастников и нечетные номера портов (Port_src=2m+1,Port_dst=2n+1).
RTP-сессия допускает большое число участников, соединениемежду которыми возможно в одном из трех режимов (рис. 1.5).
Рисунок 1.5 Конфигурации RTP сессий
При соединении точка-точка обеспечивается двустороннийобмен между двумя участниками. При широковещательной передаче несколько участников получают RTP-поток от одного участника. В конференции обеспечивается равноправный обмен междувсеми участниками.
Для описания участников RTP-сессии используются следующие понятия:
- SSRC (SynchronizationSouRCe – источник синхронизации) –это уникальный 32-битный идентификатор единый для всехпакетов в одном направлении в рамках одной RTP-сессии.
Следовательно, назначение пакета однозначно определяетсяIP-адресом назначения (IP_dst), портом назначения (Port_dst) иидентификатором SSRC;
- Mixer (Микшер, смеситель) – это промежуточная система, которая получает RTP-пакеты от одного или нескольких источников, комбинирует пакеты по-своему, возможно, меняет формат данных и передает как новый RTP-пакет со своим SSRC;
- CSRC (ContributingSouRCe – содействующий источник) – этоисточник потока RTP-пакетов, который участвует в общей сессии, формируемой смесителем.
- Транслятор (translator) – это промежуточная система, которая
пропускает RTP пакеты без изменения SSRC, но изменяя каким-либо образом содержание пакета (например, изменяет аудио/видео кодек).
Функционирование трансляторов и смесителей представлено
на рис. 1.6.
Рисунок 1.6 Функционирование трансляторов и смесителей
Каждый источник передает RTP-пакеты с идентификаторомSSRC, который является случайным числом, устанавливаемым вначале сессии. Трансляторы обеспечивают преобразование речевых сигналов с изменением типа кодека.
Пусть участки сети A и C обеспечивают достаточную скоростьпередачи данных, и на этих участках возможно применение кодеков G.711, при этом участок B не обеспечивает необходимой скорости передачи данных, там применяется кодек G.729.
При получении пользователем данных из нескольких источников необходимо объединение нескольких RTP-потоков в один. Этафункция выполняется микшерами. При этом возможна такжетрансляция, так как различные источники информации могут использовать различные кодеки.
В примере, представленном на рис. 1.6, RTP-пакеты передаются от трех источников (SSRC1, SSRC2, SSRC3) в микшер, которыйсобирает принятые пакеты и отправляет их к получателю в объединенном пакете. При этом, пакет имеет SSRC4, а включенные внего пакеты сохраняют свои идентификаторы как содействующихисточников (CSRC1, CSRC2, CSRC3).
Заголовок RTP
Заголовок RTP-пакета формируется из нескольких 32-битных
строк как показано на рисунке рис. 1.7.
Рисунок 1.7 Формат заголовка RTP-пакета
Рассмотрим назначение полей заголовка:
- V (Version) – 2 бита поля зарезервированы для указания версииRTP. На данный момент используется версия 2;
- P-бит (Padding) – указывает на, то что пакет содержит одинили несколько октетов заполняющих бит для выравнивания.
Последний октет точно указывает, сколько заполняющих октетов было добавлено к первоначальной нагрузке. Это необходимо, поскольку нет поля для указания длины нагрузки;
- X-бит (eXtension) – указывает на наличие расширения заголовка пакета после поля CSRC в фиксированном заголовке.
Цель этих расширений – ввести дополнительные возможности,которых нет в стандартном заголовке;
- CC (CSRC Count) – 4 бита указывают на число CSRC, следующих дальше в заголовке;
- M-бит (Marked) – обозначает определенные события, например, границу кадра. Этот бит используется опционально. Онможет быть использован для обозначения всплеска разговорной речи при использовании механизма подавления пауз, как,например, в кодеке G.723.1;
- PT (Payload Type) – 7 бит используются для идентификацииформата поля полезной нагрузки. Эти биты могут приниматьзначения, указанные в табл. 1.2.
Таблица 1.2. Коды протоколов в поле «Тип нагрузки» (PT)
- Sequence number (16 бит) – определяет последовательный номерпакета и увеличивается на один с каждым посланным пакетомRTP. Используется получателем для определения порядка отправки пакетов и обнаружения потери пакетов. Начальный номер последовательности выбирается случайным образом;
- Timestamp (32 бита) – указывает относительную временнуюотметку.
Например, при передаче видеоданных первая отметкавставляется (и далее отсчитывается) при кодировании первогокадра в полезную нагрузку пакета, а при передаче аудиоданных первая отметка вставляется, когда первый аудио отрезокпомещается в поле полезной нагрузки. Начальное значениеэтой отметки выбирается случайным образом;
- SSRC (32 бита) – определяет источник синхронизации, который подробно уже был описан ранее. Идентификатор выбирается случайно;
- CSRC (32 бита) – определяет идентификатор содействующегоисточника.
Всего может быть идентифицировано до 15 распределенных источников. Большее количество CSRC можетбыть использовано, но их невозможно указать в заголовке пакета. (Если не используется технология смешивания (mixer), тобиты СС устанавливаются в 0 и отсутствуют биты CSRC).
Таким образом, в заголовке RTP пакета размещается информация о типе протокола, при помощи которого выполнялось кодирование, о метке относительного времени (времени кодирования), обидентификаторе источника синхронизации и о числе и идентификаторах содействующих источников (участников конференции),если таковые имеются.
В зависимости от типа используемого кодека меняется соот-
ношение между полезным содержимым (Payload) пакета VoIP и
заголовками.
На рис. 1.9 наглядно представлено сравнение длятрех типов кодеков.
Как видно из приведенного примера, суммарная длина заголовков составляет IP + UDP + RTP = 20 + 8 + 12 = 40 байт. Это составляет существенное значение даже для кодеков G.711, а длякодеков G.729 превышает полезную часть. Поэтому в современных сетях применяются меры по уменьшению размера заголовковв RTP сессиях (cRTP – compressedRTP). С помощью механизмаcRTP полный стек IP/UDP/RTP сжимается до 2-4 байт. Количествобайт зависит от наличия контрольной суммы.
Рисунок 1.9. Соотношение длины заголовков и полезной части в
пакетах VoIP
Протокол RTP не имеет механизмов выстраивания пакетов вправильном порядке. При этом, заголовки RTP-пакетов несут всюнеобходимую информацию (порядковый номер пакета и метку относительного времени). Для реализации данной функции используется анти-джиттерный буфер.
Пакеты от источника всегда передаются последовательно и через равные отрезки времени. Однако,проходя через IP-сеть, пакеты могут продвигаться по разным путям и задерживаться на маршрутизаторах на различное время. Этоозначает, что некоторые пакеты будут приходить раньше предыдущих, а некоторые – позже, чем их ожидают на приеме. Антиджиттерный буфер позволяет накапливать пакеты и восстанавливать их порядок следования по параметрам заголовков RTP-пакетов.
Кроме задержек в IP-сети возможны потери пакетов, которыеприводят к необходимости заполнения пауз, образованных отсутствием голосовогопакета. Обычно такие паузы заполняются комфортным шумом, поскольку на человеческом восприятии отрицательно сказывается внезапная полная тишина. Аналогичная ситуация возникает и в том случае, когда пакет задерживается на столько, что вместо его содержания уже начата передача комфортногошума. Такие слишком задержавшиеся пакеты стираются в анти-
джиттерном буфере. Разные типы кодеков обладают различнойчувствительностью к потерям пакетов. В среднем, считается, чтопотери пакетов в IP-сети не должны превышать 1%.