Протоколы RTP, RTCP, UDP

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

Рис. 2.5. Взаимодействие Softswitch с остальным оборудованием

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

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

Рис. 2.6. Уровни протоколов RTP/UDP/IP

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

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

Доставка RTP-пакетов контролируется специальным протоколом RTCP (Real Time Control Protocol).

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

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

Протокол Н.323

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

Сети, построенные на базе протоколов H.323, ориентированы на интеграцию с телефонными сетями и могут рассматриваться как сети ЦСИС (цифровая сеть с интеграцией служб), наложенные на сети передачи данных. В частности, процедура установления соединения в таких сетях IP-телефонии базируется на рекомендации МСЭ-Т Q.931 и практически идентична той же процедуре в сетях ЦСИС. При этом рекомендация H.323 предусматривает применение разнообразных алгоритмов сжатия речевой информации, что позволяет использовать полосу пропускания ресурсов передачи гораздо более эффективно, чем в сетях с коммутацией каналов.

Рис. 2.7. Структура сети Н.323

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

Терминал H.323 – оконечное устройство сети IP-телефонии, обеспечивающее 2-стороннюю речевую или мультимедийную связь с другим терминалом, шлюзом или устройством управления конференциями.

Шлюзявляется соединяющим мостом между ТфОП и IP. Основная функция шлюза — преобразование речевой (мультимедийной) информации, поступающей со стороны ТФОП с постоянной скоростью, в вид, пригодный для передачи по IP-сетям, т. е. кодирование информации, подавление пауз в разговоре, упаковка информации в пакеты RTP/UDP/IP, а также обратное преобразование. Кроме того, шлюз должен преобразовывать аналоговую абонентскую сигнализацию, сигнализацию по 2ВСК и сообщения систем сигнализации DSS1 и OKC7 в сигнальные сообщения Н.323. При отсутствии в сети привратника должна быть реализована еще одна функция шлюза: преобразование номера ТфОП в транспортный адрес IP-сети.

Привратниквыполняет функции управления зоной сети IP-телефонии, в которую входят терминалы и шлюзы, зарегистрированные у данного привратника. Разные участки зоны сети H.323 могут быть территориально разнесены, но соединяться друг с другом через маршрутизаторы (рис. 2.8).

Рис. 2.8. Зоновая архитектура сети H.323

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

преобразование alias-адреса (имени абонента, телефонного номера, адреса электронной почты и др.) в транспортный адрес сетей с маршрутизацией пакетов IP (IP-адрес и номер порта RTP);

контроль доступа пользователей системы к услугам IP-телефонии при помощи сигнализации RAS (Registration, Admission and Status);

контроль, управление и резервирование пропускной способности сети;

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

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

Протокол SIP

Вторым вариантом построения сетей стал протокол SIP, разработанный комитетом IETF (Internet Engineering Task Force); спецификации протокола представлены в документе RFC 2543

Протокол инициирования сеансов – Session Initiation Protocol (SIP ) – является протоколом прикладного уровня и предназначается для организации, модификации и завершения сеансов связи: мультимедийных конференций, телефонных соединений и распределения мультимедийной информации, в основу которого заложены следующие принципы:

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

масштабируемость сети (характеризуется в первую очередь возможностью увеличения количества элементов сети при ее расширении);

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

Протокол SIP может быть использован совместно с протоколом H.323. Возможно также взаимодействие протокола SIP с системами сигнализации ТфОП – DSS1 и ОКС7.

Одной из важнейших особенностей протокола SIP является его независимость от транспортных технологий. В качестве транспорта могут применяться протоколы Х.25, Frame Relay, AAL5, IPX и др. Структура сообщений SIP не зависит от выбранной транспортной технологии. Но в то же время предпочтение отдается технологии маршрутизации пакетов IP и протоколу UDP. Пример построения сети SIP представлен на рис. 2.9.

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

Агент пользователя (User Agent или SIP client) является приложением терминального оборудования и включает в себя две составляющие: клиент агента пользователя (User Agent Client – UAC) и сервер агента пользователя (User Agent Server – UAS), иначе называемые клиент и сервер. Клиент UAC инициирует SIP -запросы, т.е. выступает в качестве вызывающей стороны. Сервер UAS принимает запросы и отвечает на них, т.е. выступает в качестве вызываемой стороны.Запросы могут передаваться не прямо адресату, а на некоторый промежуточный узел (прокси-сервер и сервер переадресации).

Прокси-сервер (proxy server) принимает запросы, обрабатывает их и отправляет дальше на следующий сервер, который может быть как другим прокси-сервером, так и последним UAS. Таким образом, прокси-сервер принимает и отправляет запросы и клиента, и сервера. Приняв запрос от UAC, прокси-сервер действует от имени этого UAC;

Рис. 2.9. Пример построения SIP-сети

Сервер переадресации (redirect server) передает клиенту в ответе на запрос адрес следующего сервера или клиента, с которым первый клиент связывается затем непосредственно. Он не может инициировать собственные запросы. Адрес сообщается первому клиенту в поле Contact сообщений SIP. Таким образом, этот сервер просто выполняет функции поиска текущего адреса пользователя.

Сервер местоположения (location server) – база адресов, доступ к которой имеют SIP -серверы, пользующиеся ее услугами для получения информации о возможном местоположении вызываемого пользователя. Приняв запрос, сервер SIP обращается к серверу местоположения, чтобы узнать адрес, по которому можно найти пользователя. В ответ тот сообщает либо список возможных адресов, либо информирует о невозможности найти их.

Протокол MGCP

Рабочая группа MEGACO комитета IETF разработала протокол управления шлюзами – Media Gateway Control Protocol (MGCP).

При разработке протокола управления шлюзами рабочая группа MEGACO опиралась на принцип декомпозиции, согласно которому шлюз разбивается на отдельные функциональные блоки (рис. 2.10):

транспортный шлюз – Media Gateway, который выполняет функции преобразования речевой информации, поступающей со стороны ТфОП с постоянной скоростью, в вид, пригодный для передачи по сетям с маршрутизацией пакетов IP: кодирование и упаковку речевой информации в пакеты RTP/UDP/IP, а также обратное преобразование;

Рис. 2.10. Архитектура сети, базирующейся на протоколе MGCP

устройство управления – Call Agent, выполняющее функции управления шлюзом;

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

Таким образом, весь интеллект функционально распределенного шлюза размещается в устройстве управления, функции которого в свою очередь могут быть распределены между несколькими компьютерными платформами. Шлюз сигнализации выполняет функции STP – транзитного пункта системы сигнализации по общему каналу – ОКС7. Транспортные шлюзы выполняют только функции преобразования речевой информации. Одно устройство управления обслуживает одновременно несколько шлюзов. В сети может присутствовать несколько устройств управления. Предполагается, что эти устройства синхронизованы между собой и согласованно управляют шлюзами, участвующими в соединении. Рабочая группа MEGACO не определяет протокол синхронизации работы устройств управления, однако в ряде работ, посвященных исследованию возможностей протокола MGCP, для этой цели предлагается использовать протоколы H.323, SIP или ISUP/IP.

Перенос сообщений протокола MGCP обеспечивает протокол UDP.

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

Протокол MGCP является внутренним протоколом, поддерживающим обмен информацией между функциональными блоками распределенного шлюза. Протокол MGCP использует принцип master/slave (ведущий/ведомый), причем устройство управления шлюзами является ведущим, а транспортный шлюз – ведомым устройством, которое выполняет команды, поступающие от устройства управления.

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

Рабочей группой MEGACO предложена следующая классификация транспортных шлюзов (Media Gateways):

Trunking Gateway – шлюз между ТфОП и сетью с маршрутизацией пакетов IP, ориентированный на подключение к телефонной сети посредством большого количества цифровых трактов (от 10 до нескольких тысяч) с использованием системы сигнализации ОКС 7;

Voice over ATM Gateway – шлюз между ТфОП и АТМ-сетью, который также подключается к телефонной сети посредством большого количества цифровых трактов (от 10 до нескольких тысяч);

Residential Gateway – шлюз, подключающий к IP-сети аналоговые, кабельные модемы, линии xDSL и широкополосные устройства беспроводного доступа;

Access Gateway – шлюз для подключения к сети IP-телефонии небольшой учрежденческой АТС через аналоговый или цифровой интерфейс;

Business Gateway – шлюз с цифровым интерфейсом для подключения к сети с маршрутизацией IP-пакетов учрежденческой АТС при использовании, например, системы сигнализации DSS1;

Network Access Server – сервер доступа к IP-сети для передачи данных;

Circuit switch или packet switch – коммутационные устройства с интерфейсом для управления от внешнего устройства.