На главную
Методические материалы
по курсу
"СЕТЕВЫЕ ТЕХНОЛОГИИ"


» В основное меню »

Материал заимствован с сайта INTUIT
IP-ТЕЛЕФОНИЯ В КОМПЬЮТЕРНЫХ СЕТЯХ
1. Общие вопросы технологии IP-телефонии

1.1. Терминология

IP-телефония (или VoIP - Voice over Internet protocol) - технология, которая использует сеть с пакетной коммутацией сообщений на базе протокола IP для передачи голоса в режиме реального времени.

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

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

1.2. Особенности IP-телефонии

Почему IP-телефония привлекает к себе внимание?

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

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

Интернет-телефония частично использует существующие сети закрепленных за абонентами телефонных линий. Но в них она дополнительно применяет прогрессивную технологию сжатия (см. "Передача речи по IP-сети" ) передаваемых сигналов, которая более полно использует емкость телефонных линий.

При обычном способе передачи речи (аналоговой телефонии) используется канал пропускной способностью 64 кбит/с независимо от того, разговаривает абонент или молчит во время соединения. В случае передачи речи по IP-сетям, за счет оцифровки и компрессии (сжатия), речь передается в виде цифровой информации, причем если абонент молчит или делает паузы в разговоре, цифровая информация в канал не передается и канал не заполняется. Это позволяет в одном канале 64 кбит/с передавать от 8 и более соединений одновременно, что в свою очередь обеспечивает снижение тарифов, и, соответственно, оплата уменьшается.

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



Рис. 1.1. Компьютерная сеть с наложенной на нее IP-телефонией

На рисунке показаны:

Открытая архитектура - еще одна важная особенность VoIP. Положительным свойством IP-телефонии является также и наличие общих протоколов для IP-телефонии: H.323, MGCP, SIP и т. д.

1. Общие вопросы технологии IP-телефонии

1.3. Принципы пакетной передачи

Для проведения сеанса связи мы набираем номер вызываемого абонента, после чего происходит соединение с сетевым шлюзом, как показано на рис. 1.2.



Рис. 1.2. Соединение с сетевым шлюзом

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



Рис. 1.3. Оцифровка голосового сигнала

После оцифровки цифровой сигнал, занимающий изначально, как и наша речь, канал в 64 кбит/с, сжимается в соответствии с выбранным кодеком (см. "Передача речи по IP-сети" ) и разбивается на пакеты сигналов в соответствии с выбранным типом кодирующего устройства (кодеком) ( рис. 1.4 и 1.5.). В преобразовании участвуют как аппаратные, так и программные средства со стороны абонента А.



Рис. 1.4. Сжатие канала



Рис. 1.5. Разбиение на пакеты

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



Рис. 1.6. Соединение с приемной стороной

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

Архитектура технологии VoIP может быть упрощенно представлена в виде двух плоскостей:

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

Таким образом, иерархия протоколов RTP/UDP/IP представляет собой своего рода транспортный механизм для речевого трафика. Отметим, что в сетях с маршрутизацией пакетов IP для передачи данных всегда предусматриваются механизмы повторной передачи пакетов в случае их потери. При передаче голосовой информации в реальном масштабе времени этот прием неприменим, т. к. речевая информация очень чувствительна к задержкам, но менее чувствительна к потерям, поэтому для передачи речи (как и видеоинформации) используется механизм негарантированной доставки информации RTP/UDP/IP. Рекомендации ITU-Т допускают задержки в одном направлении, не превышающие 150 мс.

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

1. Общие вопросы технологии IP-телефонии

1.4. Виды соединений и взаимодействие с компьютерной сетью

Можно выделить три наиболее часто используемых сценария IP-телефонии:

Первый сценарий "компьютер-компьютер" реализуется на базе стандартных компьютеров, оснащенных средствами мультимедиа и подключенных к сети Интернет. Компоненты сценария "компьютер-компьютер" показаны на рис. 1.7.

В этом сценарии аналоговые речевые сигналы от микрофона абонента А преобразуются в цифровую форму с помощью аналого-цифрового преобразователя (АЦП). Отсчеты речевых данных в цифровой форме затем сжимаются кодирующим устройством для сокращения нужной для их передачи полосы в отношении 4:1, 8:1 или 10:1.

Выходные данные после сжатия формируются в пакеты, к которым добавляются заголовки протоколов, и затем пакеты передаются через IP-сеть в систему IP-телефонии, обслуживающую абонента Б. Когда пакеты принимаются системой абонента Б, заголовки протокола удаляются, а сжатые речевые данные поступают в устройство, развертывающее их в первоначальную форму, после чего речевые данные снова преобразуются в аналоговую форму с помощью цифро-аналогового преобразователя (ЦАП) и попадают в динамик телефона абонента Б.



Рис. 1.7. Сценарий IP-телефонии "компьютер-компьютер"

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

Рассмотрим представленный на рис. 1.7 сценарий установления соединения "компьютер-компьютер" более подробно. Для проведения телефонных разговоров друг с другом абоненты А и Б должны иметь доступ к Интернету или к другой сети с протоколом IP. Разберем возможный алгоритм организации связи между этими абонентами на примере протокола H.323.

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

В этом примере не показаны некоторые служебные детали, которые необходимы поставщику услуг для развертывания сети IP-телефонии.

Для поддержки сценария "компьютер-компьютер" поставщику услуг Интернет необходимо иметь отдельный сервер (GateKeeper), преобразующий имена пользователей в динамические адреса IP. Сам сценарий ориентирован на пользователя, которому сеть нужна в основном для передачи данных, а программное обеспечение IP-телефонии требуется лишь иногда для разговоров с коллегами. Эффективное использование телефонной связи по сценарию "компьютер-компьютер" обычно связано с повышением продуктивности работы крупных компаний, например, при организации виртуальной презентации в корпоративной сети с возможностью не только видеть документы на веб-сервере, но и обсуждать их содержание с помощью IP-телефона.

1. Общие вопросы технологии IP-телефонии

1.5. Сценарий соединения "телефон-компьютер"

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



Рис. 1.8. Упрощенный сценарий IP-телефонии "компьютер-компьютер"

Замена изображений имеет и более глубокий смысл. Название сценария "компьютер-компьютер" отнюдь не означает, что в распоряжении пользователя обязательно должен быть стандартный PC с микрофоном и колонками (рис. 1.8). Главным требованием такой схемы является то, что оба пользователя должны иметь подключенные к сети персональные компьютеры - и эти PC должны быть всегда включены, подсоединены к сети и иметь в запущенном виде программное обеспечение IP-телефонии для приема входящих вызовов.

Принимая во внимание эти обстоятельства, под названием "компьютер" во всех сценариях мы будем понимать терминал пользователя, включенный в IP-сеть, а под названием "телефон" - терминал пользователя, включенный в сеть коммутации каналов любого типа: ТфОП, ISDN или GSM.

Сценарий "телефон-компьютер" находит применение в разного рода справочно-информационных службах Интернета, в службах сбыта товаров или в службах технической поддержки. Пользователь, подключившийся к cepвepy WWW какой-либо компании, имеет возможность обратиться к оператору справочной службы. Это вполне соответствует стилю жизни современных потребителей, связанному с потребностью в дополнительных удобствах и экономии времени.

При сценарии "телефон-компьютер" соединение устанавливается между пользователем телефонной сети общего пользования (ТфОП) и пользователем IP-сети (рис. 1.9). Предполагается, что установление соединения инициирует пользователь сети коммутации каналов.



Рис. 1.9. Пользователя IP-сети вызывает абонент ТфОП по сценарию "телефон-компьютер"

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

Возможна и иная разновидность второго сценария, когда соединение устанавливается между пользователем IP-сети и абонентом ТфОП, но инициирует его создание абонент ТфОП.

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

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

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

1.6. Сценарий соединения "телефон-телефон"

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

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

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

Как показано на рис. 1.10, поставщики услуг IP-телефонии предоставляют услуги "телефон-телефон" путем установки шлюзов IP-телефонии на входе и выходе IP-сетей. Абоненты подключаются к шлюзу поставщика услуг IP-телефонии через ТфОП, набирая специальный номер доступа. Абонент получает доступ к шлюзу, используя персональный идентификационный номер (PIN) или услугу идентификации номера вызывающего абонента (Calling Line Identification). После этого шлюз просит ввести телефонный номер вызываемого абонента, анализирует этот номер и определяет, какой шлюз имеет лучший доступ к нужному телефону. Как только между входным и выходным шлюзами устанавливается контакт, дальнейшее установление соединения к вызываемому абоненту выполняется выходным шлюзом через его местную телефонную сеть.

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



Рис. 1.10. Соединение абонентов ТфОП через транзитную IP-сеть по сценарию "телефон-телефон"

Одним из алгоритмов организации связи по сценарию "телефон-телефон" является выпуск поставщиком услуги своих телефонных карт. Имея такую карту, пользователь, желающий позвонить в другой город, набирает номер поставщика данной услуги, затем в режиме донабора вводит свой идентификационный номер и PIN-код, указанный на карте. После процедуры аутентификации он набирает телефонный номер адресата.

2. Использование протоколов Интернета в IP-телефонии

2.1. Адресация в IP-сетях

Каждый терминал в сети TCP/IP имеет адреса трех уровней.

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

Подавляющее большинство сетей сейчас использует протокол IPv4 (интернет-протокол версии 4), хотя уже разработана шестая версия протокола IP. Схема адресации протокола IPv4 предусматривает размер адресного поля 32 бита, что дает 232 (или 4 294 967 296) потенциальных адресов.

2.2. Протокол IP версии 6

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

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

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

В результате было решено подвергнуть протокол IP модернизации, преследуя следующие основные цели:

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

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

FEDC:0A96:0:0:0:0:7733:567A

Для сетей, поддерживающих обе версии протокола IPv4 и IPv6, имеется возможность использовать для младших 4 байтов традиционную десятичную запись, а для старших - шестнадцатеричную:

0:0:0:0:FFFF 194.135.75.104

В рамках системы адресации IPv6 имеется также выделенное пространство адресов для локального использования, то есть для сетей, не входящих в Интернет. Существует две разновидности локальных адресов: для "плоских" сетей, не разделенных на подсети (Link-Local), и для сетей, разделенных на подсети (Site-Local), которые различаются значением префикса. Основной заголовок дейтаграммы IPv6 длиной 40 байтов имеет следующий формат (рис. 2.1).



Рис. 2.1. Формат основного заголовка дейтаграммы IPv6

Поле Класс трафика (Traffic Class) эквивалентно по назначению полю Тип обслуживания (Type Of Service), а поле Лимит переходов (Hop Limit) - полю Время жизни (Time To Live) протокола IPv4.

Поле Метка потока (Flow Label) позволяет выделять и особым образом обрабатывать отдельные потоки данных без необходимости анализировать содержимое пакетов. Это очень важно с точки зрения снижения нагрузки на маршрутизаторы.

Поле Следующий заголовок (Next Header) является аналогом поля Протокол (Protocol) IPv4 и определяет тип заголовка, следующего за основным. Каждый следующий дополнительный заголовок также содержит поле Next Header.

2.3. Протоколы TCP и UDP

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

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

Протокол передачи пользовательских дейтаграмм (User Datagram Protocol - UDP) предназначается для обмена дейтаграммами между процессами компьютеров, расположенных в объединенной системе компьютерных сетей.

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

2. Использование протоколов Интернета в IP-телефонии

2.4. Протоколы RTP и RTCP

2.4.1. Основные понятия

Транспортный протокол реального времени RTP (англ. Real-time Transport Protocol) обеспечивает сквозную передачу в реальном времени мультимедийных данных, таких как интерактивное аудио и видео. Этот протокол реализует распознавание типа трафика, нумерацию последовательности пакетов, работу с метками времени и контроль передачи.

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

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

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

Хотя протокол RTP считается протоколом транспортного уровня, он функционирует обычно поверх другого протокола транспортного уровня UDP (User Datagram Protocol). Оба протокола вносят свои доли в функциональность транспортного уровня. Следует отметить, что RTP и RTCP являются независимыми от нижележащих уровней - транспортного и сетевого, поэтому протоколы RTP/RTCP могут использоваться с другими подходящими транспортными протоколами.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  1. Главная функция - обеспечение обратной связи для оценки качества распределения данных. Это неотъемлемая функция RTСP как транспортного протокола, она связана с функциями управления потоком и перегрузками других транспортных протоколов. Обратная связь может быть непосредственно полезна для управления адаптивным кодированием, но эксперименты с IP-мультивещанием показали, что обратную связь с получателями также важно иметь для диагностики дефектов при распространении информации. Посылка отчетов обратной связи о приеме данных всем участникам позволяет при наблюдении проблем оценивать, являются они локальными или глобальными. С механизмом распределения IPM для таких объектов, как поставщики услуг сети, можно также получать информацию обратной связи и действовать при диагностике проблем сети как монитор третьей стороны. Эта функция обратной связи обеспечивается отчетами отправителя и приемника RTCP.
  2. RTCP поддерживает устойчивый идентификатор источника данных RTP на транспортном уровне, называемый "каноническим именем" ( CNAME - canonical name). Так как идентификатор SSRC может изменяться, если обнаружен конфликт или перезапущена программа, то получателям для отслеживания каждого участника требуется каноническое имя CNAME. Получатели также требуют CNAME для отображения множества потоков информации от данного участника на множество связанных сеансов RTP, например, при синхронизации звукового и видеосигнала.
  3. Первые две функции требуют, чтобы все участники посылали пакеты RTCP, следовательно, для предоставления возможности масштабирования числа участников протоколом RTP должна регулироваться частота передачи таких пакетов. При посылке каждым участником телеконференции управляющих пакетов всем остальным участникам, каждый может независимо оценивать общее число участников.
  4. Четвертая, дополнительная, функция RTCP должна обеспечивать информацию управления сеансом (например, идентификацию участника), которая будет отражена в интерфейсе пользователя. Наиболее вероятно, что это будет полезным в "свободно управляемых" сеансах, где участники вступают в группу и выходят из нее без контроля принадлежности или согласования параметров.

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

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

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

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

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

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

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

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

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

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

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

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

3. Передача речи по IP-сети

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

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



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

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

Второй уровень этой модели - канальный уровень - указывает, что протокол IP для создания фреймов может использовать различные форматы. Как показано на рис. 3.1, он включает многоканальный PPP (Multilink PPP), Frame Relay (FR) и ATM. При проектировании сети возможны и другие варианты, поскольку передавать голос могут также 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 H.323 на другой протокол инициирования сеанса (Session Initiation Protocol - SIP) и протокол описания сеанса (Session Description Protocol - SDP).

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

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

3.2. Качество передачи речевой информации по IP-сети

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

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

  1. Качества IP-сети характеризуют:
    • максимальная пропускная способность - максимальное количество данных, которая она передает;
    • задержка - промежуток времени, требуемый для передачи пакета через сеть;
    • джиттер - задержка между двумя последовательными пакетами;
    • потеря пакета - пакеты или данные, потерянные при передаче через сеть.
  2. Качества шлюза характеризуют:
    • требуемая полоса частот пропускания ;
    • задержка - время, необходимое сигнальному процессору DSP для кодирования и декодирования речевого сигнала;
    • объем буфера джиттера для сохранения пакетов данных до тех пор, пока все пакеты не будут получены; затем можно будет передать часть речевой информации в требуемой последовательности и таким образом минимизировать джиттер;
    • возможность потери пакетов - потеря пакетов при сжатии и/или передаче в оборудовании IP-телефонии;
    • наличие функции подавления эха, возникающего при передаче речи по сети.

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

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

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

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

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



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

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

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

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

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

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

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

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

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

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

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

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

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

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

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



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

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

    Ti = T±j.

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

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

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

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

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

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


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

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

3. Передача речи по IP-сети

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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



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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3. Передача речи по IP-сети

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

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

    Скорость передачи, которую предусматривают имеющиеся сегодня узкополосные кодеки, лежит в пределах 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 кбит/с.

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

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

  3. Генератор комфортного шума (Comfort Noise Generator - CNG) служит для генерации фонового шума.

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

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

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

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

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

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

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

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

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

3.8. Кодеки IP-телефонии

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

Таблица 3.1. Основные характеристики кодеков 
Кодек   Метод 	    Скорость 	   Сложность 	           Качество	              Задержка
        компрессии  кодирования    реализации
G.726	ADPCM	    32/24/16 кб/с  Низкая (8 MIPS)	   Хорошее(32К), плохое(16К)  Очень низкая (0,125 мс)
G.729	CS-ACELP    8 кб/с         Высокая (30 MIPS)	   Хорошее	              Низкая (10 мс)
G.729A	CA-ACELP    8 кб/с         Умеренная (20 MIPS)	   Среднее	              Низкая (10 мс)
G.723.1	MP-MLQ	    6.4/5.3 кб/с   Умеренная (16 MIPS)	   Хорошее(6,4), среднее(5,3) Высокая (37 мс)
G.728	LD-CELP	    16 кб/с        Очень высокая (40 MIPS) Хорошее	              Очень низкая (3-5 мс)

Количественными характеристиками ухудшения качества речи являются единицы QDU (Quantization Distortion Units): 1 QDU соответствует ухудшению качества при оцифровке с использованием стандартной процедуры ИКМ; значения QDU для основных методов компрессии приведены в таблице 3.2.

Таблица 3.2. Единицы ухудшения качества речи QDU для различных методов компрессии 
Метод компрессии	QDU
ADPCM 32 кбит/с	        3,5
ADPCM 24 кбит/с	        7
LD-CELP 16 кбит/с	3,5
CS-CELP 8 кбит/с	3,5

Дополнительная обработка речи всегда ведет к дальнейшей потере качества. Согласно рекомендациям МСЭ-Т, для международных вызовов величина QDU не должна превышать 14, причем передача разговора по международным магистральным каналам ухудшает качество речи, как правило, на 4 QDU. При передаче разговора по национальным сетям должно теряться не более 5 QDU. Поэтому для качественной передачи речи процедуру компрессии/декомпрессии желательно применять в сети только один раз. В некоторых странах это является обязательным требованием регулирующих органов по отношению к корпоративным сетям, подключенным к сетям общего пользования.

Современная аппаратура IP-телефонии применяет разные кодеки, как стандартные, так и нестандартные. Конкурентами являются кодеки GSM (13,5 кбит/с) и кодеки МСЭ-Т серии G, использование которых предусматривается стандартом H.323 для связи по IP-сети.

3.9. Оценка качества воспринимаемой информации

Значения MOS для различных стандартов кодеров приведены в таблице 3.3. Таблица 3.3. Средние субъективные оценки качества различных методов кодирования 

Кодек	              Скорость передачи, кбит/с	  MOS	Размер кадра, мс
G.711 РСМ	             64	                  4,3	      0,125
G.726 Multi-rate ADPCM	     16-40	          2-4,3	      0,125
G.723 MP-MLQ ACELP	     5.3; 6.3	          3,7; 3,8   30
G.728 LD-CELP	             16	                  4,1	      0,625
G.729 CS-ACELP	              8	                  4,0	     10
G.729A CA-ACELP	              8	                  3,4	     10
GSM RPE-LPC	             13	                  3,9	     30

В каналах Интернета важными для IP-телефонии параметрами являются следующие: