Системы VoIP на базе стандарта Н.323

За последние годы объем речевого трафика увеличился незначитель-

но, в то время как трафик данных растет с очень высокой скоростью. На-

помним, что одной из причин является все большее применение Интернет

как для обмена информацией, так и для бизнес-приложений. Рост трафика

данных в квартирном секторе объясняется растущим числом ПК, подклю-

ченных к сети. В коммерческом секторе существует еще ряд причин, на-

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

работают вместе по всему земному шару и им требуется быстрый обмен

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

ным образом, созданием и использованием одного сайта, тогда как круп-

ные корпорации с множеством сайтов имеют потребность в применении

территориально распределенных сетей. Масштабы применения сетей IP по-

следние 15 лет постоянно растут (число пользователей, объемы трафика,

применимость для большого числа приложений) и поэтому в 90-х гг. про-

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

голосового трафика через Интернет.

Для передачи речи в сетях IP (Voice over IP, VoIP) был предложен

ряд международных стандартов как Международным союзом электросвязи

(МСЭ), так и Комитетом IETF. В настоящее время используются, в основ-

ном, два стандарта: один описан в рекомендации МСЭ Н.323; в стандарте RFC 2543 (IETF) описан протокол SIP Исторически первой для построения сетей IP-телефонии стала реко-мендация H.323, разработанная МСЭ для построения систем мультимедий-ной связи. Рекомендация Н.323 описывает несколько протоколов, основ-ными функциями которых являются организация, поддержание и разъеди-нение сеансов связи в мультимедийных сетях. Таким образом, рекоменда-ция Н.323 описывает процессы пятого уровня (сессионного) в эталонной модели взаимосвязи открытых систем (ВОС). В рекомендации Н.323 опре-делены основные элементы для построения систем мультимедийной связи (рис. 3.2): · терминал (Terminal); · шлюз (Gateway); · привратник (Gatekeeper); · устройство управления конференциями (Multicast Unit).

Рис. 3.2. Компоненты сети на базе H.323 В состав терминала, определяемого рекомендацией Н.323, входит блок управления, который обеспечивает функции сигнализации для уста-новления и управления вызовом, а также коммуникационные функции по отношению к привратнику. Для обработки голоса требуется речевой кодек, преобразующий голос в пакеты данных. Ряд кодеков был стандартизован для использования в терминалах Н.323. Выбор кодека обычно осуществля-ется на фазе установления соединения между терминалами. Кроме того, в терминале реализованы механизмы для транспортировки трафика данных реального времени через сети IP, такие как RTP (Real-Time Transport Proto-

col) и RTCP (Real-Time Control Protocol). В зависимости от приложений в терминале могут использоваться дополнительные функциональные устрой-ства, например видеокодек. Привратникявляется центральным блоком управления в системе Н.323. Привратник контролирует работу терминалов, подключенных к се-тям, и обеспечивает терминалам возможность регистрироваться внутри се-ти. Он также управляет распределением адресов между терминалами, отве-чающих рекомендации МСЭ-Т E.164, так что терминалы могут быть адре-сованы вне системы IP. Третьим компонентом является шлюз.Шлюз выполняет функции моста между сетями ТфОП и IP. Основной функцией шлюза является пре-образование информации, поступающей со стороны ТфОП, в формат, при-годный для передачи по IP-сетям и обратный процесс: кодирование ин-формации в соответствующем кодеке, подавление пауз в разговоре, упа-ковка информации в пакеты RTP/UDP/IP. Кроме того, шлюз должен уметь поддерживать обмен сигнальными сообщениями как с коммутационным или терминальным оборудованием ТфОП, так и с привратником или тер-миналом Н.323. Шлюз отвечает за отображение сигнального протокола Н.323 в про-токол, используемый в сети ТфОП. При соединении шлюза и сети ТфОП необходимо отобразить адреса Е.164, применяемые в телефонной сети, в адреса IP, используемые в системе Н.323. Существуют различные способы решения этой задачи, однако здесь описаны только основные принципы. Для адресации терминала Н.323 из сети общего пользования ему должен быть присвоен определенный номер в соответствии с рекомендацией Е.164. В общем, набор адресов Е.164 назначается в шлюзе и отображение Е.164 для терминала Н.323, т.е. IP-адресация, выполняется привратником во вре-мя фазы регистрации. При этом предполагается, что шлюз должен взаимо-действовать с привратником для поиска отображения адреса всякий раз, когда он получает вызов определенного адреса Е.164 из сети ТфОП. Шлюз затем получает соответствующий IP-адрес для этого вызова и может начать фазу установления вызова с терминалом Н.323. В обратном направлении к сети ТфОП шлюз может быть стандартной точкой назначения для всех вызовов, которые не могут быть обработаны внутри системы Н.323. Наконец, может возникнуть необходимость переко-дировать речь и видеосигналы из формата Н.323 в формат другой сети.

Четвертым элементом системы Н.323 является устройство управления конференциями. Рекомендация Н.323 предусматривает три вида конфе-ренций.

Первый вид – централизованная конференция, в которой оконечные устройства соединяются в режиме «точка-точка» с устройством управления конференциями, контролирующим процессы формирования и завершения

конференции, а также обрабатывающим потоки пользовательской инфор-мации. Второй вид – децентрализованная конференция, в которой каждый ее участник соединяется с остальными участниками в режиме «точка-группа точек», и оконечные устройства сами обрабатывают (переключают или смешивают) потоки информации, поступающие от других участников кон-ференции. Наконец, третий вид – смешанная конференция, т.е. комбинация двух предыдущих видов. Преимущество централизованной конференции – сравнительно про-стые требования к терминальному оборудованию, недостаток – большая стоимость устройства управления конференциями. Для децентрализован-ной конференции требуется более сложное терминальное оборудование; кроме того, желательно, чтобы в сети поддерживалась передача пакетов IP в режиме многоадресной рассылки (IP multicasting). Если сеть не поддер-живает этот режим, терминал может передавать информацию к каждому из остальных терминалов, участвующих в конференции, в режиме «точка-точка», но это становится неэффективным при числе участников более че-тырех. Большая часть стандартов кодирования, используемых в сети ТфОП для передачи речи, применяется в речевых кодеках Н.323, так что имеется возможность применять один и тот же стандарт на основе предварительных соглашений. Необходимо, однако, иметь в виду, что каждая процедура пе-рекодирования ухудшает качество речевых и видеосигналов, поэтому чис-ло таких преобразований должно быть сведено к минимуму. Во время фазы установления соединения терминалы должны регист-рироваться привратником, чтобы их адреса IP были известны. Для этого терминалы должны сначала обнаружить привратника. Это достигается пу-тем использования заранее определенного многоточечного адреса. Терми-налы передают в вещательном режиме сообщение по этому адресу, и при-вратник передает в ответ определенный набор служебных символов. Затем терминал регистрируется в привратнике и информация о новом терминале распределяется на все другие терминалы, подключенные к системе. При-вратник и шлюз обмениваются информацией с помощью протокола MGCP (Media Gateway Control Protocol), стандартизированного МСЭ/IETF. 3.3. Системы VoIP на базе протокола SIP 3.3.1. Архитектура сети SIP

Протокол инициирования сеансов протокола – Session Initiation Pro-tocol (SIP), является протоколом пятого (прикладного) уровня модели про-цессов IETF. Как и Рекомендация Н.323, протокол SIP решает те же задачи организации, поддержания и завершения сеансов связи в мультимедийных сетях, включая телефонную связь, передачу данных и распределение муль-

тимедийной информации. Протокол SIP может быть использован совмест-но с протоколом Н.323 и с системами сигнализации сети ТфОП.

Сеть SIP содержит следующие основные элементы:

· агент пользователя (User Agent или SIP client),

· прокси-сервер (proxy server),

· сервер переадресации (redirect server),

· сервер определения местоположения (location server).

Агент пользователяреализуется в терминальном оборудовании и состоит из двух подсистем: клиента агента пользователя (User Agent Client – UAC) и сервера агента пользователя (User Agent Server – UAS), часто на-зываемых клиентом и сервером. Клиент UAC инициирует SIP-запросы, т.е. выступает в качестве вызывающей стороны. Сервер UAS принимает запро-сы и отвечает на них, т.е. выступает в качестве вызываемой стороны. За-просы могут передаваться не прямо адресату, а на некоторый промежуточ-ный узел. Этот узел может быть реализован в виде двух основных типов: прокси-сервер и сервер переадресации. Прокси-серверпринимает запросы, обрабатывает их и отправляет дальше на следующий сервер, который может быть как другим прокси-сервером, так и терминалом UAS. Приняв запрос от UAC, прокси-сервер самостоятельно действует от имени этого UAC. Прокси-сервер может реа-лизовать два режима: с сохранением состояний (stateful) и без сохранения состояний (stateless). Сервер первого типа хранит в памяти входящие за-просы, которые находятся в памяти сервера только до окончания транзак-ций (сеансов). Сервер без сохранения состояний просто ретранслирует за-просы и ответы, которые получает. Он работает быстрее, чем сервер перво-го типа, так как ресурс процессора не тратится на запоминание состояний, вследствие чего сервер этого типа может обслужить большее количество пользователей. Сервер переадресации (redirect server)передает клиенту в ответе на запрос адрес следующего сервера или клиента, с которым первый клиент связывается затем непосредственно. Сервер переадресации не может ини-циировать собственные запросы и только выполняет функции поиска те-кущего адреса пользователя. Сервер определения местоположенияиспользуется для фиксации местоположения пользователя при перемещении последнего от одной око-нечной системы к другой. Сервер является базой адресов, к которой имеют доступ SIP-серверы, описанные выше. Приняв запрос, SIP-сервер обраща-ется к серверу определения местоположения, чтобы узнать адрес, по кото-рому можно найти пользователя. В ответ тот сообщает либо список воз-можных адресов, либо информирует о невозможности найти их. На рис. 3.3 представлена архитектура сети на базе протокола SIP.

Сообщения SIP

Согласно архитектуре «клиент-сервер» все сообщения делятся на за-

просы, передаваемые от клиента к серверу, и на ответы сервера клиенту.

Чтобы инициировать установление соединения, вызывающий пользователь

должен сообщить серверу адрес вызываемого пользователя, параметры ин-

формационного канала и др. Эти данные передаются в специальном запро-

се. От вызываемого пользователя к вызывающему передается ответ на за-

прос. Вся информация, необходимая для установления соединения, поме-

щается в заголовке. Заголовок содержит адреса вызываемого и вызываю-

щего пользователей, пройденный сообщением путь, размер сообщения и

т.д.

Клиент SIP Клиент SIP

Прокси-

сервер SIP

Прокси-

сервер SIP

Сервер пере-

адресации SIP

Сервер опреде-

ления местопо-

ложения

Запрос Ответ

Передача

Речи

Рисунок 3.3. Архитектура сети SIP

Запросы. С помощью запросов клиент сообщает о текущем местопо-

ложении, приглашает пользователей принять участие в сеансах связи, мо-

дифицирует уже установленные сеансы, завершает их и т.д. Рассмотрим

описание некоторых запросов:

INVITE – приглашение со стороны вызывающего пользователя при-

нять участие в сеансе связи. В приглашении указываются тип сообщения и

параметры, необходимые для приема сообщения.

В ответе на запрос INVITE указывается тип информации, которая бу-

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

формации, которую вызываемый пользователь собирается передавать:

· ACK – подтверждение приема от вызываемой стороны на команду

INVITE и завершение транзакцию;

· BYE – разъединение соединения;

· REGISTER – применяется клиентами для регистрации данных о местоположении с использованием серверов SIP.

Ответы. После приема запроса, адресат (сервер) передает ответ на этот запрос. Ответы могут включать в себя подтверждение установления соединения, передачу запрошенной информации, сведения о неисправно-стях и т.д. Определено шесть типов ответов; каждый тип ответа кодируется трехзначным числом. Первая цифра определяет вид ответа, остальные две цифры лишь дополняют первую. Все ответы делятся на две группы: информационные и финальные. Информационные ответы начинаются с единицы и показывают, что запрос находится в стадии обработки. Финальные ответы начинаются с цифр 2, 3, 4, 5 и 6: они означают завершение обработки запроса и содержат результат обработки запроса. Примеры различных ответов:

· 1хх (информационный) – запрос принят, продолжается его обра-ботка;

· 2хх (успех) – запрос принят, понят и успешно обработан;

· 3хх (переадресация) – для завершения обработки запроса нужны дальнейшие действия;

· 4хх (ошибка клиента) – запрос содержит ошибку и не может быть выполнен;

· 5хх (ошибка сервера) – сервер не может выполнить явно правиль-ный запрос;

· 6хх (глобальный сбой) – запрос не может быть обработан никаким сервером.

Протокол RTP

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

· обнаружение ошибок;

· защита информации;

· контроль времени нахождения пакета в сети;

· идентификация схемы кодирования;

· контроль доставки.

Шлюзы VoIP используют протокол RTP для доставки речевого тра-фика. В системах VoIP протокол RTP используется поверх протокола UDP

и относится к протоколам, не ориентированным на соединения. Несмотря

на это свойство, протокол поддерживает систему упорядочения пакетов,

что позволяет обнаруживать потерянные пакеты. Протокол RTP может ис-

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

протоколов, ориентированных на установление соединений (например,

протокола TCP).

Протокол RTP используется вместе с протоколом управления RTCP

(RTP Control Protocol), обеспечивающим управляющую информацию для

протокола RTP. Протокол RTCP используется периодически для передачи

пакетов управления к участникам сеанса VoIP. Основная функция протоко-

ла состоит в том, чтобы информировать участников об уровне качества об-

служивания, поддерживаемом протоколом RTP. Протокол RTCP собирает

информацию о числе переданных и потерянных пакетов, о значениях за-

держки и джиттера. Например, получив информацию о снижении показа-

телей качества обслуживания, механизмы контроля QoS могут ограничить

поток сообщений VoIP. После восстановления требуемых значений показа-

телей QoS интенсивность потока может восстановиться.

На рис. 3.4 показана общая схема организации сеанса VoIP. Пользо-

ватель вызывающего ТА набирает номер вызываемого ТА, и шлюз на пере-

дающей стороне с помощью сигнальных сообщений информирует сервер

обработки вызовов (ОВ) о входящем вызове. Сервер ОВ анализирует при-

нятый номер и, используя сигнальные сообщения, информирует шлюз на

приемной стороне о поступлении вызова. Затем сервер ОВ дает команду

шлюзам установить прямое соединение RTP через сеть IP. Шлюзы откры-

вают сеанс RTP, когда пользователь ТА пункта назначения поднимает

трубку. В зависимости от выбранной системы сигнализации в качестве сер-

вера ОВ могут использоваться привратник (H.323, МСЭ-Т), контроллер

шлюза (MEGACO/H.248, IETF, МСЭ-Т) или прокси-сервер (SIP, IETF RFC

3261).

Сервер

обработки

вызовов

Шлюз

Вызывающий ТА

Шлюз

Вызываемый ТА

Сеть IP

Сигнальные

сообщения

Сообщения RTP

Рис. 3.4. Общая схема организации сеанса VoIP

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

• пакеты речи и данных имеют различные длины;

• пакеты речи и данных передаются с разными скоростями;

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

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

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

До недавнего времени согласованные количественные оценки, опре-деляющие качество передачи речи в сетях связи с учетом того, как это вос-принимается пользователем, отсутствовали. Первоначально МСЭ предло-жил подход (рекомендации МСЭ P.800), в основе которого лежали субъек-тивные оценки качества передачи речи (такие, как «отличное качество», «хорошее качество», «приемлемое качество» и т.д.). Субъективные оценки, к сожалению, не могут быть точно соотнесены с сетевыми характеристика-ми, которые используются при проектировании и эксплуатации сетей. Не могут быть они точно сопоставлены и процессам, реализуемым в терми-нальном оборудовании (т.е. вне сети). Речь идет об алгоритмах сжатия,

схемах кодирования, механизмах защиты информации, восстановления данных и т.д. Тем не менее, субъективные оценки использовались в тече-ние многих лет как единственный подход к оценке качества в телефонных сетях и в определенной степени сохраняют свое значение сегодня. В 1998 г. МСЭ стандартизировал подход, основанный на объективных оценках каче-ства обслуживания, который позволяет описать показатели качества при передаче речи в пакетной форме (рекомендация G.107). Далее рассматри-ваются оба подхода, но основное внимание уделяется анализу рекоменда-ции G.107. 3.4.1. Субъективная оценка качества обслуживания при передаче речиПервичным критерием качества аудио и видео информации является восприятие (перцепция) качества услуги пользователем. Определение каче-ства услуг может базироваться как на субъективных, так и на объективных оценках. Наиболее широко используемая методика субъективной оценки качества описана в рекомендации МСЭ P.800 и известна как методика MOS (Mean Opinion Score). В соответствии с методикой MOS качество речи, по-лучаемое при прохождении сигнала от говорящего (источник) через систе-му связи к слушающему (приемник), оценивается как арифметическое среднее от всех оценок, выставляемых экспертами после прослушивания тестируемого тракта передачи. Экспертные оценки определяются в соответствии со следующей 5-балльной шкалой: 5 – отлично, 4 – хорошо, 3 – приемлемо, 2 – плохо, 1 – неприемлемо. Оценки 3,5 балла и выше соответствуют стандартному и вы-сокому телефонному качеству, 3,0…3,5 – приемлемому, 2,5…3,0 – синте-зированному звуку. Для передачи речи с хорошим качеством целесообраз-но ориентироваться на значения MOS не ниже 3,5 баллов. Хотя методика MOS, основанная на субъективных оценках, является достаточно надежным инструментом в телефонных сетях, получение таких оценок связано с большими затратами – как временными, так и финансо-выми. Кроме того, при использовании пакетных сетей для передачи речи возникают проблемы с прямым применением модели MOS, разработанной для телефонных сетей. Естественно, что эта модель не учитывает ряд явле-ний, типичных для сетей передачи данных и влияющих на качество речи в системах VoIP. В модели MOS отсутствует возможность количественно учесть влияющие на качество речи факторы. В частности, не учитываются:

· сквозная (end-to-end) задержка между говорящим по телефону и слушающим;

· влияние вариации задержки (джиттера);

· влияние потерь пакетов.

Кроме того, модель MOS представляет оценку качества в однона-правленном соединении, а не в двух направлениях реального телефонного соединения. Все это потребовало разработки новых моделей оценки каче-ства передачи речи, учитывающих особенности пакетных сетей. 3.4.2. Объективная оценка качества обслуживания при передаче речи в пакетных сетяхДля преодоления указанных недостатков в 1998 г. МСЭ принял реко-мендацию G.107, в которой был описан подход к объективной оценке каче-ства услуг в телекоммуникациях. В основу подхода положена так называе-мая Е-модель, которая открыла новое направление в оценке качества услуг, связанное с измерением характеристик терминалов и сетей. После создания Е-модели было проведено большое число испытаний, в которых менялся уровень воздействия искажающих сетевых факторов. Данные этих тестов были использованы в Е-модели для вычисления объективных оценок. Ре-зультатом вычислений в соответствии с Е-моделью является число, назы-ваемое R-фактором (так называемым «коэффициентом рейтинга»). Значе-ния R-фактора однозначно сопоставляются с оценками MOS (см. табл. 3.1 и рис. 3.5). В соответствии с Е-моделью R-фактор определяется в диапазоне зна-чений от 0 до 100, где 100 соответствует самому высокому уровню качест-ва. При расчете R-фактора учитываются 20 параметров. В состав этих параметров входят:

· однонаправленная задержка,

· коэффициент потери пакетов,

· потери данных из-за переполнения буфера джиттера,

· искажения, вносимые при преобразовании аналогового сигнала в цифровой и последующем сжатии (обработка сигнала в кодеках),

· влияние эха и др.

Таблица 3.1. Оценка QoS на основе R-фактора и оценок MOS

Значение R-фактора