Системы 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). ![](http://konspekta.net/megapredmetru/baza1/21692372302.files/image074.gif) Рис. 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 Сервер опреде- ления местопо- ложения Запрос Ответ Передача Речи ![](http://konspekta.net/megapredmetru/baza1/21692372302.files/image076.jpg) Рисунок 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 ![](http://konspekta.net/megapredmetru/baza1/21692372302.files/image078.jpg) Рис. 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-фактора |