IP-телефония и основы мобильной связи

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

Групповая аудио-конференц-связь

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

Приложение аудио-конференц-связи, используемое каждым участником конференции, посылает звуковые данные малыми порциями, например, продолжительностью 20 мс. Каждой порции звуковых данных предшествует заголовок RTP; заголовок RTP и данные поочередно формируются (инкапсулируются) в пакет UDP. Заголовок RTP показывает, какой тип кодирования звука (например, ИКМ, АДИКМ или LPC) применялся при формировании данных в пакете. Это дает возможность изменять тип кодирования в процессе конференции, например, при появлении нового участника, который использует линию связи с низкой полосой пропускания, или при перегрузках сети.

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

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

Видео-конференц-связь

Если в телеконференции используются и звуковые, и видеосигналы, то они передаются отдельно. Для передачи каждого типа трафика независимо от другого спецификацией протокола вводится понятие сеанса связи RTP (см. список используемых сокращений и терминов). Сеанс определяется конкретной парой транспортных адресов назначения (один сетевой адрес плюс пара портов для RTP и RTCP). Пакеты для каждого типа трафика передаются с использованием двух различных пар портов UDP и/или групповых адресов. Никакого непосредственного соединения на уровне RTP между аудио- и видео сеансами связи не имеется, за исключением того, что пользователь, участвующий в обоих сеансах, должен использовать одно и то же каноническое имя в RTCP-пакетах для обоих сеансов, чтобы сеансы могли быть связаны.

Одна из причин такого разделения состоит в том, что некоторым участникам конференции необходимо позволить получать только один тип трафика, если они этого желают. Несмотря на разделение, синхронное воспроизведение мультимедийных данных источника (звука и видео) может быть достигнуто при использовании информации таймирования, которая переносится в пакетах RTCP для обоих сеансов.

Понятие о микшерах и трансляторах

Не всегда все сайты имеют возможность получать мультимедийные данные в одинаковом формате. Рассмотрим случай, когда участники из одной местности соединены через низкоскоростную линию связи с большинством других участников конференции, которые обладают широкополосным доступом к сети. Вместо того чтобы вынуждать каждого использовать более узкую полосу пропускания и звуковое кодирование с пониженным качеством, средство связи уровня RTP, называемое микшером, может быть размещено в области с узкой полосой пропускания. Этот микшер повторно синхронизирует входящие звуковые пакеты для восстановления исходных 20-миллисекундных интервалов, микширует эти восстановленные звуковые потоки в один поток, производит кодирование звукового сигнала для узкой полосы пропускания и передает поток пакетов через низкоскоростную линию связи. При этом пакеты могут быть адресованы одному получателю или группе получателей с различными адресами. Чтобы в приемных оконечных точках можно было обеспечивать правильную индикацию источника сообщений, заголовок RTP включает для микшеров средства опознавания источников, участвовавших в формировании смешанного пакета.

Некоторые из участников аудиоконференции могут быть соединены широкополосными линиями связи, но могут быть недостижимы посредством групповой конференц-связи с использованием протокола IP (IPM -- IP multicast). Например, они могут находиться за брандмауэром прикладного уровня, который не будет допускать никакой передачи 1Р-пакетов. Для таких случаев нужны не микшеры, а средства связи уровня RTP другого типа, называемые трансляторами. Из двух трансляторов один устанавливается вне брандмауэра и снаружи передает все групповые пакеты, полученные через безопасное соединение, другому транслятору, установленному за брандмауэром. Транслятор за брандмауэром передает их снова как мульти вещательные пакеты многопользовательской группе, ограниченной внутренней сетью сайта.

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



Протокол управления RTCP

Все поля пакетов RTP/RTCP передаются по сети байтами (октетами); при этом наиболее значащий байт передается первым. Все данные полей заголовка выравниваются в соответствии с их длиной. Октеты, обозначенные как дополнительные, имеют нулевое значение.

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

* Главная функция -- обеспечение обратной связи для оценки качества распределения данных. Это неотъемлемая функция RTCP как транспортного протокола, она связана с функциями управления потоком и перегрузками других транспортных протоколов. Обратная связь может быть непосредственно полезна для управления адаптивным кодированием, но эксперименты с IP-мультивещанием показали, что обратную связь с получателями также важно иметь для диагностики дефектов при распространении информации. Посылка отчетов обратной связи о приеме данных всем участникам позволяет при наблюдении проблем оценивать, являются они локальными или глобальными. С механизмом распределения IPM для таких объектов, как поставщики услуг сети, можно также получать информацию обратной связи и действовать при диагностике проблем сети как монитор третьей стороны. Эта функция обратной связи обеспечивается отчетами отправителя и приемника RTCP.

* RTCP поддерживает устойчивый идентификатор источника данных RTP на транспортном уровне, называемый «каноническим именем» (CNAME -- canonical name). Так как идентификатор SSRC может изменяться, если обнаружен конфликт или перезапущена программа, то получателям для отслеживания каждого участника требуется каноническое имя CNAME. Получатели также требуют CNAME для отображения множества потоков информации от данного участника на множество связанных сеансов RTP, например, при синхронизации звукового и видеосигнала.

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

* Четвертая, дополнительная, функция RTCP должна обеспечивать информацию управления сеансом (например, идентификацию участника), которая будет отражена в интерфейсе пользователя. Наиболее вероятно, что это будет полезным в «свободно управляемых» сеансах, где участники вступают в группу и выходят из нее без контроля принадлежности или согласования параметров.

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

Интенсивность передачи пакетов RTCP

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

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

Вычисления полосы пропускания для трафика управления и данных выполняются с учетом нижележащих протоколов транспортного и сетевого уровней (например, UDP и IP). Заголовки уровня звена передачи данных (ЗПД) при вычислениях не учитываются, так как пакет по мере его передачи может инкапсулироваться с различными заголовками уровня ЗПД.

Трафик управления должен быть ограничен малой и известной частью полосы пропускания сеанса: малой настолько, чтобы не пострадала основная функция транспортного протокола -- передача данных; известной так, чтобы трафик управления мог быть включен в спецификацию полосы пропускания, данную протоколу резервирования ресурсов, и так, чтобы каждый участник мог независимо вычислить свою долю. Предполагается, что часть полосы пропускания сеанса, выделяемая для RTCP, должна быть установлена равной 5 %. Все участники сеанса должны использовать одинаковую величину полосы пропускания RTCP, так, чтобы вычисленные значения интервала передачи пакетов управления были одинаковыми. Поэтому эти константы должны быть установлены для каждого профиля.

Алгоритм вычисления интервала между посылками составных пакетов RTCP для разделения среди участников полосы пропускания, выделенной для трафика управления, имеет следующие основные характеристики:

* отправители коллективно используют по крайней мере 1/4 полосы пропускания трафика управления так, как в сеансах с большим количеством получателей, но с малым числом отправителей; едва установив соединение, участники в течение короткого интервала времени получают CNAME передающих сайтов;

* требуется, чтобы расчетный интервал между пакетами RTCP, как минимум, превышал 5 секунд, чтобы избежать пачек пакетов RTCP, превышающих дозволенную полосу пропускания, когда число участников мало и трафик не сглаживается согласно закону больших чисел;

* интервал между пакетами RTCP изменяется случайно в пределах от половины до полутора расчетных интервалов во избежание не непреднамеренной синхронизации всех участников. Первый пакет RTCP, посланный после вступления в сеанс связи, также задерживается случайным образом (до половины минимума интервала RTCP) в случае, если приложение начато во множестве сайтов одновременно, например, при объявлении о начале сеанса связи;

* для автоматической адаптации к изменениям в объеме передаваемой информации управления вычисляется динамическая оценка среднего размера составного пакета RTCP с использованием всех полученных и посланных пакетов;

* этот алгоритм может использоваться для сеансов, в которых передача пакетов допустима для всех участников. В этом случае параметр полосы пропускания сеанса -- это произведение полосы пропускания индивидуального отправителя на число участников, и полоса пропускания RTCP составляет 5 % от этой величины.

Взаимодействие RTP с протоколами сетевого и транспортного уровней

Если не установлено иначе спецификациями других протоколов, то при передаче «голосовых» пакетов применяются следующие основные правила.

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

Информационные пакеты RTP не содержат никакого поля длины, следовательно, RTP полагается на нижележащий протокол и для обеспечения индикации длины. Максимальная длина пакетов RTP ограничивается только протоколами нижележащих уровней.

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



ЛЕКЦИЯ 3. ПЕРЕДАЧА РЕЧИ ПО 1Р-СЕТИ

* Взаимодействие протоколов VoIP

телефония мобильная связь

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

Рис. 3.1. Стек протоколов VoIP

Технология VoIP может работать в любой физической среде, которая может использоваться обычным протоколом IP. Такие среды могут быть представлены в виде кабеля витой пары (используемой в традиционном Ethernet), телефонных проводов, беспроводных соединений (протокол IEEE 802.11) и др.

Второй уровень этой модели -- канальный уровень -- указывает, что протокол IP для создания фреймов может использовать различные форматы. Как показано на рис. 3.1, он включает многоканальный РРР (Multilink РРР), Frame Relay (FR) и ATM. Е1ри проектировании сети возможны и другие варианты, поскольку передавать голос могут также Ethernet, Wi-Fi и другие технологии локальных сетей.

На третьем, сетевом уровне используется протокол IP в качестве способа передачи голоса, однако обычный IP должен быть дополнен специальными средствами. Поскольку существуют проблемы с задержкой, протоколу IP требуется использовать какой-либо способ установления очередности для того, чтобы голосовым данным не пришлось ожидать передачи в условиях конкуренции с обычными данными. На маршрутизаторах должна быть использована очередность с малой задержкой (Low- Latency queuing -- LLQ) или какая-либо иная современная схема установки очередности, чтобы голосовые данные отправлялись раньше обычных данных. Кроме того, должны использоваться схемы маркировки (marking) с заданием приоритетов (coloring), называемые IP-приоритетами, для обеспечения того, чтобы голосовые данные рассматривались системой как более важные для первоочередной передачи, чем обычные данные.

Следующим уровнем является транспортный. Поскольку для передачи голоса используется протокол UDP, системе не хватает механизма установки очередности пакетов, чтобы пакеты доставлялись в требуемой последовательности. Транспортный протокол реального времени (Real-Time Transport Protocol -- RTP) для выполнения этого требования добавляет номер пакета в последовательности передачи и механизм расстановки временных меток. Также может использоваться протокол резервирования (Resource Reservation Protocol -- RSVP) для резервирования полосы пропускания вдоль пути вдоль следования голоса по IP-сети. Данный протокол исключает применение пакетами обычных данных зарезервированной полосы пропускания.

Пятый уровень модели -- сеансовый. На сегодняшний день сети VoIP переходят со стандарта ITU-T Н.323 на другой протокол инициирования сеанса (Session Initiation Protocol -- SIP) и протокол описания сеанса (Session Description Protocol -- SDP).

Шестым уровнем модели является уровень представлений. Как определено в модели OSI, уровень представлений анализирует и интерпретирует форматы данных. В терминах передачи голоса уровень представлений обеспечивает методы кодирования и сжатия, используемые для передачи голоса.

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

* Качество передачи речевой информации по 1Р-сети

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

Хорошо изучены факторы, влияющие на качество 1Р-телефонии. Они могут быть разделены на две категории:

* Качества IP-сети характеризуют:

* максимальная пропускная способность -- максимальное количество данных, которая она передает;

* задержка -- промежуток времени, требуемый для передачи пакета через сеть;

* джиттер -- задержка между двумя последовательными пакетами;

* потеря пакета -- пакеты или данные, потерянные при передаче через сеть.

* Качества шлюза характеризуют:

* требуемая полоса частот пропускания;

* задержка -- время, необходимое сигнальному процессору DSP для кодирования и декодирования речевого сигнала;

* объем буфера джиттера для сохранения пакетов данных до тех пор, пока все пакеты не будут получены; затем можно будет передать часть речевой информации в требуемой последовательности и таким образом минимизировать джиттер;

* возможность потери пакетов -- потеря пакетов при сжатии и/или передаче в оборудовании 1Р-телефонии;

* наличие функции подавления эха, возникающего при передаче речи по сети.

В сетях IP протокол управления передачей (Transport Control Protocol -- TCP) может решить проблему нарушения порядка следования пакетов данных из-за установления последовательности передачи и использования подтверждений, однако для передачи голоса используется протокол дейтаграмм пользователя (User Datagram Protocol -- UDP), а не TCP. Применение протокола UDP в технологии \ЫР обусловлено тем, что у посылающего устройства нет необходимости перед отправкой последующих пакетов дожидаться подтверждения от принимающего устройства. Данные \ЫР отправляются тем же способом, который используется при отправке аудио- или видеоданных в сети Интернет. Потеря небольшого количества голосовых пакетов считается приемлемой и может быть компенсирована с помощью механизма кодирования/декодирования, а также различных методов интерполяции речи, то есть посредством заполнения отсутствующих звуков с помощью DSP-технологии, которая анализирует форму звукового колебания и предсказывает отсутствующий звук.

* Задержка и меры по уменьшению ее влияния

Организация ITU-T серьезно занималась исследованием проблем, связанных с задержками при передаче голоса по сети. В результате был разработан стандарт ITU-T G.114, который рекомендует, чтобы задержка при передаче голоса в одном направлении не превышала 150 миллисекунд. Также стандарт рекомендует рассматривать задержку от 150 до 400 миллисекунд как приемлемую, если говорящий и слушающий понимают наличие задержки и готовы с ней смириться. В том случае, когда задержка достигает 400 миллисекунд и более, она становится заметной. Для сравнения можно привести общение через спутник: задержка при передаче по спутниковой связи в одном направлении составляет примерно 170 миллисекунд; при этом не учитывается задержка, возникающая в устройствах, расположенных на земле. Стандарт также устанавливает, что при передаче голоса задержка более чем 400 миллисекунд является неприемлемой.

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

Можно выделить следующие причины задержки при передаче речи от источника к приемнику.

* Задержка накопления (иногда называется алгоритмической задержкой): эта задержка обусловлена необходимостью сбора кадра речевых отсчетов, выполняемая в речевом кодере. Величина задержки определяется типом речевого кодера и изменяется от небольших величин (0,125 мкс) до единиц миллисекунд.

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



Рис. 3.2. Источники задержки при передаче речи по 1Р-сети

* Сетевая задержка: задержка обусловлена физической средой и протоколами, применяемыми для передачи речевых данных, а также буферами, используемыми для удаления джиттера пакетов на приемном конце.

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

* Явление джиттера, меры уменьшения его влияния

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

* Джиттер, зависимый от данных (Data Dependent Jitter -- DDJ) -- происходит в случае ограниченной полосы пропускания или при нарушениях в сетевых компонентах.

* Искажение рабочего цикла (Duty Cycle Distortion -- DCD) -- обусловлено задержкой распространения между передачей снизу вверх и сверху вниз.

* Случайный джиттер (Random Jitter -- RJ) -- является результатом теплового шума.

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

Можно выделить следующие причины появления джиттера:

* Влияние сети.

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

* Влияние операционной системы.

Большинство приложений IP-телефонии (особенно клиентских) представляет собой обычные программы, выполняемые в среде какой- либо операционной системы, например, Windows или Linux. Эти программы обращаются к периферийным устройствам (платам обработки речевых сигналов, специализированным платам систем сигнализации) через интерфейс прикладных программ для взаимодействия с драйверами этих устройств, а доступ к IP-сети осуществляют через Socket-интерфейс.

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

Из сказанного следует, что выбор операционной системы является фактором, влияющим на общую величину задержки. Чтобы минимизировать влияние операционной системы, некоторые производители шлюзов и IP-телефонов применяют так называемые ОС реального времени (VxWorks, pSOS, QNX Neutrino и т. д.), которые используют более сложные механизмы разделения времени процессора, действующие таким образом, чтобы обеспечивать более быструю реакцию на прерывания и более эффективный обмен потоками данных между процессами.

Другой, более плодотворный подход -- переложить все функции, которые необходимо выполнять в жестких временных рамках (обмен данными между речевыми кодеками и сетевым интерфейсом, поддержку RTP и т. д.), на отдельный быстродействующий специализированный процессор. При этом пересылка речевых данных осуществляется через выделенный сетевой интерфейс периферийного устройства, а операционная система рабочей станции поддерживает только алгоритмы управления соединениями и протоколы сигнализации, т. е. задачи, для выполнения которых жестких временных рамок не требуется. Этот подход реализован в платах для приложений IP-телефонии, производимых фирмами Dialogic, Audiocodes, Natural Microsystems.

* Влияние джиттер-буфера.

Проблема джиттера весьма существенна в пакетно-ориентированных сетях. Отправитель речевых пакетов передает их через фиксированные промежутки времени (например, через каждые 20 мс), но при прохождении через сеть задержки пакетов оказываются неодинаковыми, так что они прибывают в пункт назначения через разные промежутки времени. Это иллюстрирует рис. 3.3.

Рис. 3.3. Различие интервалов между моментами прибытия пакетов (джиттер)

Задержка прохождения пакетов по сети Tj может быть представлена как сумма постоянной составляющей Т (время распространения плюс средняя длительность задержки в очередях) и переменной величины), являющейся результатом джиттера: Т) = T±j.

Для того чтобы компенсировать влияние джиттера, в терминалах используется так называемый джиттер-буфер. Этот буфер хранит в памяти прибывшие пакеты в течение времени, определяемого его объемом. Пакеты, прибывающие слишком поздно, когда буфер заполнен, отбрасываются. Интервалы между пакетами восстанавливаются на основе значений временных меток RTP-пакетов. В функции джиттер-буфера обычно входит и восстановление исходной очередности следования пакетов, если при транспортировке по сети они оказались «перепутаны».

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

* Влияние кодека и количества передаваемых в пакете кадров

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

На первый взгляд кажется, что чем меньше длина кадра, тем меньше должна быть задержка. Однако из-за значительного объема служебной информации, передаваемой в RTP/UDP/IP-пакетах, передача маленьких порций данных очень неэффективна, так что при применении кодеков с малой длиной кадра приходится упаковывать несколько кадров в один пакет. Кроме того, кодеки с большей длиной кадра более эффективны, поскольку могут «наблюдать» сигнал в течение большего времени и, следовательно, могут более эффективно моделировать этот сигнал.

ITU-T в рекомендации G.114 определил требования к качеству передачи речи. Оно считается хорошим, если сквозная задержка при передаче сигнала в одну сторону не превышает 150 мс (рис. 3.4). Современное оборудование IP-телефонии при включении «спина к спине» (два устройства шлюза соединяются напрямую) вносит задержку порядка 60-70 мс. Таким образом, остается еще около 90 мс на сетевую задержку при передаче IP-пакета от отправителя к пункту назначения, что говорит о возможности обеспечить при современном уровне технологии передачу речи с достаточно хорошим качеством.

Рис. 3.4. Задержка при передаче

Временные задержки -- проблема исключительно 1Р-телефонии. Именно поэтому на рис. 3.4 приведены отдельные характеристики спутниковой передачи, при которой требуется примерно 170 мс для того, чтобы сигнал достиг спутника и вернулся обратно к Земле (без учета затрат времени на обработку сигнала). Таким образом, полное время задержки превышает 250-300 мс. Согласно рекомендации G.114, такая задержка выходит за границы диапазона, приемлемого для передачи речи. Тем не менее, ежедневно значительное количество разговоров ведется по спутниковым линиям связи. Следовательно, приемлемое качество речи определяется также и требованиями пользователей, которые вынуждены согласиться с обстоятельствами.

* Эхо, устройства ограничения его влияния

Феномен эха вызывает затруднения при разговоре и у говорящего, и у слушающего. Говорящий слышит с определенной задержкой свой собственный голос. Если сигнал отражается дважды, то слушающий дважды слышит речь говорящего (второй раз -- с ослаблением и задержкой).

В телефонных сетях существуют два вида эха:

* Эхо говорящего. Когда абонент говорит по телефону и слышит собственный голос, такое явление называется эхом говорящего.

* Эхо слушающего. Когда абонент слышит голос собеседника дважды, то такая ситуация называется эхом слушателя.

В той или иной степени эхо присутствует всегда. Однако серьезной проблемой оно становится только при большой громкости. Эхо также представляет собой проблему в том случае, когда интервал между моментом, когда абонент говорит, и моментом появления отраженного сигнала становится достаточно большим. Если абонент слушает речь собеседника, то эхо мешает пониманию разговора -- речь собеседника звучит в трубке дважды.

Эхо может иметь электрическую и акустическую природу.

Отражения часто проявляются при взаимодействии ТфОП и 1Р-сетей.

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

Если задержка распространения сигнала в сети невелика (что обычно и бывает в местных сетях), такой отраженный сигнал попросту незаметен и не вызывает неприятных ощущений. Если задержка достигает величины 15-20 мс, возникает эффект «огромного пустого помещения». Е1ри дальнейшем увеличении задержки субъективная оценка качества разговора резко ухудшается, вплоть до полной невозможности продолжать беседу.

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

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

Существуют два типа устройств, предназначенных для ограничения вредных эффектов эха: эхозаградители и эхокомпенсаторы.

Эхозаградители появились в начале 70-х годов. Е1ринцип их работы прост и состоит в отключении канала передачи, когда в канале приема присутствует речевой сигнал. Такая техника широко используется в дешевых телефонных аппаратах с громкоговорящей связью (speakerphones), однако простота не обеспечивает нормального качества связи -- перебить говорящего становится невозможно, т. е. связь, по сути, становится полудуплексной.

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

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

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

По изложенным причинам эхокомпенсаторы являются неотъемлемой частью шлюзов IP-телефонии. Алгоритмы эхокомпенсации реализуются обычно на базе тех же цифровых сигнальных процессоров, что и речевые кодеки, и обеспечивают подавление эхо-сигналов длительностью до 32-64 мс. К эхокомпенсаторам терминалов громкоговорящей связи предъявляются гораздо более строгие требования, которые здесь рассматриваться не будут, так как проблема акустического эха не входит в число проблем, специфических для 1Р-телефонии.

* Принципы кодирования речи

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

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

При преобразовании речевого сигнала в цифровую форму так или иначе имеют место два процесса -- дискретизация (sampling), то есть формирование дискретных во времени отсчетов амплитуды сигнала, и квантование, то есть дискретизация полученных отсчетов по амплитуде (кодирование непрерывной величины -- амплитуды -- числом с конечной точностью). Эти две функции выполняются аналого-цифровыми преобразователями (АЦП), которые размещаются в современных АТС на плате абонентских комплектов, а в случае передачи речи по 1Р-сетям -- в терминале пользователя (компьютере или 1Р-телефоне).

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

При квантовании непрерывная величина отображается на множество дискретных значений, что, естественно, приводит к потерям информации.

Рис. 3.5. Дискретизация и квантование аналогового речевого сигнала

Для того чтобы обеспечить в такой схеме достаточный динамический диапазон (способност передавать без искажений как сильные, так и слабые сигналы), дискретная амплитуда сигнала кодируется 12/13-разрядным двоичным числом по линейному закону.

Процесс аналого-цифрового преобразования получил применительно к системам связи название импульсно-кодовой модуляции (ИКМ).

Чтобы снизить необходимую скорость передачи битов, применяют нелинейный (логарифмический) закон квантования, т. е. квантованию подвергается не амплитуда сигнала, а ее логарифм. В данном случае происходит процесс «сжатия» динамического диапазона сигнала, а при восстановлении сигнала -- обратный процесс.

На сегодня применяются две основные разновидности ИКМ:

* с кодированием по т-закону;

* с кодированием по А-закону.

В результате сжатия сигнал с амплитудой, кодируемой 12-13 битами, описывается всего восемью битами. Различаются эти разновидности ИКМ деталями процесса сжатия (m-закон кодирования предпочтительнее использовать при малой амплитуде сигнала и при малом отношении сигнал/шум). Исторически сложилось так, что в Северной Америке используется кодирование по m-закону, а в Европе -- по А-закону. Поэтому при международной связи во многих случаях требуется преобразование m-кодирования в А-ко- дирование, ответственность за которое несет страна, где используется т-за- кон кодирования. В обоих случаях каждый отсчет кодируется 8 битами, или одним байтом, который можно считать звуковым фрагментом. Для передачи последовательности таких фрагментов необходима пропускная способность канала, равная 64 кбит/с. Это определяется простыми арифметическими действиями: 4 ООО Гц * 2 = 8 ООО отсчетов/с; 8 ООО отсчетов/с * 8 битов = 64 кбит/с, что является базовой частотой для цифровой телефонии. Поскольку ИКМ была первой стандартной технологией, получившей широкое применение в цифровых системах передачи, пропускная способность канала, равная 64 кбит/с, стала всемирным стандартом для цифровых сетей всех видов, причем стандартом, который обеспечивает передачу речи с очень хорошим качеством. Соответствующие процедуры кодирования и декодирования стандартизованы ITU-T в рекомендации G.711.

Подчеркнем, что такое высокое качество передачи речевого сигнала (принимается за эталон при оценке качества других схем кодирования) достигнуто в системах ИКМ за счет явно избыточной, при современном уровне технологии, скорости передачи информации.

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

Существует множество подходов к «сжатию» речевой информации, все их можно разделить на три категории: кодирование формы сигнала (waveform coding), кодирование исходной информации (source coding) и гибридное кодирование, представляющее собой сочетание двух предыдущих подходов.

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

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

При построении алгоритмов кодирования названная закономерность используется двумя способами.

Во-первых, есть возможность изменять параметры квантования в зависимости от характера сигнала.

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

Простейшей реализацией последнего подхода является так называемая дельта-модуляция (ДМ), алгоритм которой предусматривает кодирование разности между соседними отсчетами сигнала только одним информационным битом, обеспечивая передачу, по сути, только знака разности.

Наиболее совершенным алгоритмом является алгоритм адаптивной дифференциальной импульсно-кодовой модуляции (АДИКМ). Он предусматривает формирование сигнала ошибки предсказания и его последующее адаптивное квантование.

Подобные методы кодирования часто используются в современных устройствах кодирования речи.

* Требования к алгоритмам кодирования сигнала

* Использование полосы пропускания канала.

Скорость передачи, которую предусматривают имеющиеся сегодня узкополосные кодеки, лежит в пределах 1.2--64 кбит/с. Естественно, что от этого параметра прямо зависит качество воспроизводимой речи. Существует множество подходов к проблеме определения качества. Так, например, для прослушивания экспертам предъявляются разные звуковые фрагменты -- речь, музыка, речь на фоне различного шума и т. д. Искажения оценивают путем опроса разных групп людей по пятибалльной шкале единицами субъективной оценки MOS (Mean Opinion Score). Оценки интерпретируют следующим образом:

* 4-5 -- высокое качество; аналогично качеству передачи речи в ISDN, или еще выше;

* 3,5-4 -- качество ТфОП (toll quality); аналогично качеству речи, передаваемой с помощью кодека АДИКМ при скорости 32 кбит/с. Такое качество обычно обеспечивается в большинстве телефонных разговоров. Мобильные сети обеспечивают качество чуть ниже toll quality;

* 3-3,5 -- качество речи по-прежнему удовлетворительно, однако его ухудшение явно заметно на слух;

* 2,5-3 -- речь разборчива, однако требует концентрации внимания для понимания. Такое качество обычно обеспечивается в системах связи специального применения (например, в вооруженных силах).

В рамках существующих технологий качество ТфОП (toll quality) невозможно обеспечить при скоростях менее 5 кбит/с.

* Подавление периодов молчания.

При диалоге один его участник говорит в среднем только 35 процентов времени. Таким образом, если применить алгоритмы, которые позволяют уменьшить объем информации, передаваемой в периоды молчания, то можно значительно сузить необходимую полосу пропускания. В двустороннем разговоре такие меры позволяют достичь сокращения объема передаваемой информации до 50 %, а в децентрализованных многоадресных конференциях (за счет большего количества говорящих) -- и более. Нет никакого смысла организовывать многоадресные конференции с числом участников больше 5--6, не подавляя периоды молчания.

* Генератор комфортного шума (Comfort Noise Generator -- CNG) служит для генерации фонового шума. В момент, когда в речи активного участника беседы начинается период молчания, терминалы слушающих могут просто отключить воспроизведение звука. Однако это было бы неразумно. Если в трубке возникает «гробовая тишина», т. е. фоновый шум (шум улицы и т. д.), который был слышен во время разговора, внезапно исчезает, то слушающему кажется, что соединение по каким- то причинам нарушилось, и он обычно начинает спрашивать, слышит ли его собеседник.

Генератор CNG позволяет избежать таких неприятных эффектов.

* Размер кадра.

Большинство узкополосных кодеков обрабатывает речевую информацию блоками, называемыми кадрами (frames), и им необходимо производить предварительный анализ отсчетов, следующих непосредственно за отсчетами в блоке, который они в данный момент кодируют.

Размер кадра важен, так как минимальная теоретически достижимая задержка передачи информации (алгоритмическая задержка) определяется суммой этого параметра и длины буфера предварительного анализа.

С другой стороны, кодеки с большей длиной кадра более эффективны, так как здесь действует общий принцип: чем дольше наблюдается явление (речевой сигнал), тем лучше оно отображается на объеме дополнительной служебной информации, которая добавляется к кадру

* Чувствительность к потерям кадров

Потери пакетов являются неотъемлемым атрибутом IP-сетей. Но потери пакетов и потери кадров не обязательно напрямую связаны между собой, так как существуют подходы, например, применение кодов с исправлением ошибок («forward error correction»), позволяющие уменьшить число потерянных кадров при заданном числе потерянных пакетов. Необходимая для этого дополнительная служебная информация распределяется между несколькими пакетами, так что при потере некоторого числа пакетов кадры могут быть восстановлены.

Кодеры типа G.723.1 разработаны так, что они функционируют без существенного ухудшения качества в условиях некоррелированных потерь до 3 % кадров, однако при превышении этого порога качество ухудшается катастрофически.



* Кодеки 1Р-телефонии

Наибольшее распространение получили кодеки следующих типов.

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

Рекомендация G.723.1 утверждена ITU-T в ноябре 1995 г. Кодек G.723.1 является базовым для приложений 1Р-телефонии.

Кодек G.723.1 предусматривает две скорости передачи: 6.3 кбит/с и 5.3 кбит/с. Режим работы может меняться динамически от кадра к кадру

Для этих кодеков оценка MOS (Mean Opinion Score) составляет 3,9 в режиме 6.3 кбит/с и 3,7 в режиме 5.3 кбит/с.

Кодек G.726 обеспечивает кодирование цифрового потока со скоростью 40, 32, 24 или 16 кбит/с, гарантируя оценки MOS на уровне 4,3 (32 кбит/с), что принимается за эталон уровня качества телефонной связи (toll quality). Однако в приложениях IP-телефонии этот кодек практически не используется, так как он не обеспечивает достаточной устойчивости к потерям информации (см. выше).

Кодек G.728 специально разрабатывался для оборудования уплотнения телефонных каналов, при этом было необходимо обеспечить возможно малую величину задержки (менее 5 мс), чтобы исключить необходимость применения эхокомпенсаторов.

Кодек G.729 очень популярен в приложениях передачи речи по сетям Frame Relay. Кодек использует кадр длительностью 10 мс и обеспечивает скорость передачи 8 кбит/с. Однако для кодера необходим предварительный анализ сигнала продолжительностью 5 мс.

...