MEGACO/H.248 и MGCP
Прежде всего, MEGACO имеет более общую модель обслуживания вызовов, что позволяет ему лучше работать с такими соединениями как TDM-TDM, TDM-ATM, и TDM-IP, а также более гибко управлять конференциями. Еще одно различие касается транзакций. MEGACO в транзакциях содержит команды раздельно друг от друга, в то время как МGCP позволяет использовать вложенные команды, что усложняет процесс поиска команды. MEGACO может применять в целях обеспечения безопасности заголовки аутентификации, которых нет у MGCP. Что касается мультимедиа, MEGACO позволяет микшировать аудио/видеоданные и таким образом поддерживает мультимедийный трафик, а MGCP ориентирован только на поддержку аудиоинформации. Если шлюз обнаруживает аварию на управляющем им Softswitch при помощи команд, протокол MEGACO позволяет назначить новый управляющий Softswitch. В MGCP это делается гораздо более сложным способом.
поскольку тоже является протоколом, обеспечивающим
Как и SIP, протокол H.323 может дополнять MEGACO/ H.248, поскольку тоже является протоколом, обеспечивающим взаимодействие одноранговых устройств. В таком случае MEGACO/H.248 позволит Н.323 избавиться от присущих ему проблем с масштабируемостью, доступностью и возможностью взаимодействовать с ОКС7. В этих условиях Н.323 будет протоколом терминалов для взаимодействия друг с другом и с сетью, а MEGACO будет использоваться привратниками для управления большими шлюзами, обеспечивающими взаимодействие IP-сети, построенной согласно Н.323 с сетью ТфОП.
MEGACO/H.248 и SIP
MEGACO/ H.248 и SIP не соперничают друг с другом, т.к. MEGACO – это протокол, предназначенный для взаимодействия Softswitch и медиашлюзов, а SIP – это протокол взаимодействия одноранговых устройств (Softswitch или SIP-телефон). Взаимодействие транспортных шлюзов ограничено областью одного домена, т.к. они контролируются одним Softswitch. Таким образом, можно сказать, что MEGACO не определяет систему связи в целом, ему нужен протокол для взаимодействия Softswitch, которым может быть SIP.
Пользовательский уровень адаптации ISDN (IUA)
Существует необходимость доставки сообщений сигнальных протоколов сети с коммутацией каналов от сигнального шлюза (SG) ISDN к контроллеру шлюза среды передачи (MGC). Механизм доставки должен поддерживать:
транспортировку пограничных примитивов Q.921/Q.931;связь между модулями управления уровнями SG и MGC;управление активными связями между SG и MGC.
Данным уровнем предусматривается поддержка первичного и базового доступов ISDN (PRA и BRA) как для режима "точка-точка", так и для разветвленного режима "точка – несколько точек". Процедуры уровня адаптации QSIG не отличаются от аналогичных процедур Q.931.
Пользовательский уровень адаптации М2РА
Пользовательский уровень адаптации М2РА (MTP2 Peer-to-Peer Adaptation Layer) также обеспечивает адаптацию SCTP к МТР3, но уже в другой области. Аналогично случаю с M2UA, уровень МТР3 в узле сети IP (Softswitch, в частности) обменивается информацией с М2РА, как если бы он был обычным МТР2. Различия между М2UA и М2РА определяются их ролями в сетевой архитектуре: если Softswitch соединяется с сетью ОКС7 просто на правах терминала сигнализации ОКС7, то достаточно применения М2UA. Шлюз SG, который использует М2РА, сам фактически является транзитным пунктом сигнализации STP на базе IP, у него есть собственный код пункта сигнализации (DCP), он может также выполнять функции сигнализации верхнего уровня, такие как функции SCCP.
Пользовательский уровень адаптации МТР уровня 2 (M2UA – MTP2 –User Adaptation Layer)
Пользовательский уровень адаптации МТР уровня 2 обеспечивает эмуляцию одного звена МТР между двумя узлами ОКС7.
Избыточность звеньев достигается посредством многоточечного подключения собственно в пределах SCTP. В направлении к DPC (Destination Point Code – Код пункта назначения ОКС7) может иметься несколько звеньев. Избыточность приложений поддерживается на пользовательских уровнях адаптации посредством переключения с одного соединения на другое при необходимости.
При необходимости доставки сообщений сигнальных протоколов сети КК от сигнального шлюза (SG) к контроллеру шлюза среды передачи (MGC) или пункту сигнализации IP (IPSP) механизм доставки должен поддерживать:
интерфейс на границе МТР уровня 2 и МТР уровня 3;связь между модулями управления уровнями SG и MGC;управление активными связями между SG и MGC.
Рис. 3.10. Функции M2UA в Softswitch
Другими словами, SG будет иметь возможность транспортировать сообщения МТР уровня 3 к MGC или IPSP. В случае доставки от SG к IPSP, SG и IPSP функционируют как традиционные узлы ОКС7, используя сеть IP в качестве нового типа звена ОКС7. Этим обеспечивается полномасштабная обработка сообщений МТР уровня 3 и соответствующие возможности управления сетью (рис. 3.10).
Пользовательский уровень адаптации МТР уровня 3 (M3UA)
Обеспечивает интерфейс между SCTP и теми протоколами ОКС7, которые используют услуги МТР3, например ISUP и SCCP. Благодаря M3UA эти протоколы не ощущают, что вместо типичной транспортировки МТР3 применяется транспортировка SCTP поверх IP. Однако M3UA – просто адаптационный уровень между протоколами верхнего уровня и SCTP, он не является полной копией МТР3 в IP-сети и не реализует некоторые стандартные управляющие сообщения сетевой сигнализации МТР3 (рис. 3.11).
Рис. 3.11. Протокол M3UA
Для выхода на нужный сервер приложений (Application Server – AS) в SG должна осуществляться строгая процедура присвоения.
Уровень M3UA должен обслуживать несколько соединений SCTP (или по крайней мере одно). Выбор соединения SCTP может производиться по одной или нескольким частям полей DPC (код пункта назначения ОКС7).
Пользовательский уровень адаптации SCCP (SUA)
Пользовательский уровень адаптации SCCP (SUA)
Средствами сети IP возможна доставка сообщений подсистем пользователей SCCP. Архитектура такой доставки может представлять собой связь от SG OKC7 к сигнальному узлу IP (например резидентной базе данных IP) или связь между двумя оконечными точками, расположенными в пределах сети IP. (рис. 3.12). Механизм доставки должен поддерживать:
передачу сообщений пользователей SCCP; услугу SCCP, не ориентированную на соединение; услугу SCCP. ориентированную на соединение;взаимодействие равноуровневых объектов пользователей SCCP в полном объеме; управление транспортными связями SCTP между SG и одним или несколькими сигнальными узлами IP; функционирование сигнальных узлов IP с распределенной структурой;
Рис. 3.12. Протокол SUA
в целях управления – выдачу отчетов об изменении состояний конфигурации в асинхронном режиме.
Протокол BICC
Для взаимодействия Softswitch между собой теоретически должен применяться протокол BICC (Bearer Independent Call Control), разработанный МСЭ. И хотя на практике более популярным становится второй протокол – SIP (SIP-T), разработанный IETF, протокол BICC успешно используется до сих пор, например в решениях Ericsoon.
При разработке данного протокола обязательным требованием являлась поддержка сигнальных сообщений ISUP, поскольку протокол должен был облегчить операторам переход к ССП и обеспечить взаимодействие новой мультисервисной сети с существующими сетями ISDN. Фактически протокол BICC рассматривался как еще одна прикладная подсистема сигнализации ОКС7, обеспечивающая экономичный переход к мультисервисной сети с сохранением большей части сигнального оборудования ISUP сетей с временным разделением каналов TDM. В свое время данный протокол позволил операторам, не желавшим вкладывать инвестиции в дальнейшее развитие TDM-сетей, предоставлять уже существующие услуги ТфОП/ISDN в пакетных сетях, а также поддерживать взаимодействие имеющихся узлов коммутации TDM узлами пакетной сети и взаимодействие узлов коммутации TDM через пакетную сеть.
Архитектура BICC предусматривает, что вызовы будут входить в сеть и выходить из нее с поддержкой BICC через интерфейсы узлы обслуживания – Interface Serving Nodes (ISN), – предоставляющие сигнальные интерфейсы между узкополосной ISUP (сетью ТфОП/ISDN с коммутацией каналов) и одноранговым узлом ISN (находящимся в пакетной сети). Также определены:
транзитный узел обслуживания (Transit Serving Node (TSN)) – этот тип узла обеспечивает транзитные возможности в пределах одной сети. Служит для обеспечения возможности предоставления услуги ТфОП/ISDN внутри своей сети;пограничный узел обслуживания (Gateway Serving Node (GSN)) – этот тип узла обеспечивает выполнение функций межсетевого шлюза для информации вызова и транспортировки, используя BICC-протокол. Обеспечивает соединение двух областей BICC, принадлежащих двум разным операторам, и это соединение состоит из двух узлов GSN, непосредственно связанных друг с другом.
Рис. 3.8. Протокол BICC
На рис. 3.8 представлены узлы всех рассмотренных типов. Имеются также промежуточные коммутаторы, через которые тракт проключается при помощи сетевой сигнализации. Эти коммутаторы характерны для сетей АТМ и в терминах BICC называются узлами ретрансляции носителя – Bearer Relay Nodes (BRN) или коммутирующими узлами – Switching Nodes (SWN), но не все сетевые технологии требуют их наличия.
Рабочая группа MEGACO комитета IETF,
Рабочая группа MEGACO комитета IETF, продолжая исследования, направленные на усовершенствование протокола управления шлюзами, создала более функциональный (по сравнению с рассмотренным в предыдущей главе протоколом MGCP) протокол MEGACO. Но разработкой протоколов управления транспортными шлюзами, кроме комитета IETF, занималась еще и исследовательская группа SG 16 Международного союза электросвязи. Спецификации адаптированного протокола приведены в рекомендации ITU-T H.248.
Рассмотрим кратко основные особенности протокола MEGACO/ H.248. Для переноса сигнальных сообщений MEGACO/ H.2488 могут использоваться протоколы UDP, TCP, SCTP или транспортная технология ATM. Поддержка для этих целей протокола UDP – одно из обязательных требований к контроллеру шлюзов. Протокол TCP должен поддерживаться и контроллером, и транспортным шлюзом, а поддержка протокола SCTP, так же как и технологии ATM, является необязательной.
При описании алгоритма установления соединения с использованием протокола MEGACO комитет IETF опирается на специальную модель процесса обслуживания вызова, отличную от модели MGCP. Протокол MEGACO оперирует с двумя логическими объектами внутри транспортного шлюза: порт (termination) и контекст (context), которыми может управлять контроллер шлюза (рис. 3.7).
Порты являются источниками и приемниками речевой информации. Определено два вида портов: физические и виртуальные.
Физические порты, существующие постоянно с момента конфигурации шлюза, — это аналоговые телефонные интерфейсы оборудования, поддерживающие одно телефонное соединение, или цифровые каналы, также поддерживающие одно телефонное соединение и сгруппированные по принципу временного разделения каналов в тракт Е1.
Виртуальные порты, существующие только в течение разговорной сессии, являются портами со стороны IP-сети (RTP-порты), через которые ведутся передача и прием пакетов RTP.
Контекст – это отображение связи между несколькими портами, то есть абстрактное представление соединения двух или более портов одного шлюза.
В любой момент времени порт может относиться только к одному контексту, который имеет свой уникальный идентификатор. Существует особый вид контекста – нулевой. Все порты, входящие в нулевой контекст, не связаны ни между собой, ни с другими портами. Например, абстрактным представлением свободного (не занятого) канала в модели процесса обслуживания вызова является порт в нулевом контексте.
Рис. 3.7. Примеры модели процесса обслуживания вызова
Порт имеет уникальный идентификатор (TerminationID), который назначается шлюзом при конфигурации порта. Например, идентификатором порта может служить номер тракта Е1 и номер временного канала внутри тракта.
При помощи протокола MEGACO контроллер может изменять свойства портов шлюза. Свойства портов группируются в дескрипторы, которые включаются в команды управления портами.
Сведем основные характеристики протоколов IP-телефонии в одну таблицу (таблица 3.1).
| Назначение | Для IP-коммуникаций | Для IP-телефонии | Для управления транспортными шлюзами | Для сетей с BPK | |
| Архитектура | Peer-to-Peer | Peer-to-Peer | Master-Slave | Peer-to-Peer | |
| Интеллект | Рассредоточен по элементам сети | В ядре сети | В ядре сети | В ядре сети | |
| Сложность | Простой | Сложный | Простой | Сложный | |
| Масштабируемость | Высокая | Средняя | - | Средняя | |
| Тип данных | Речь, данные, видео | Речь, данные, видео | Управление передачей речи, данных | Речь и данные | |
| QoS | Поддерживается | Поддержка диффиринцированного обслуживания | Контроль QoS на уровне IP | Не требуется | |
| Адресация | Поддержка IP-адресов и имен доменов, через DNS | Поддержка IP-адресов, мультизонная, многодоменовая поддержка через привратник | Цифровая адресация терминалов пользователей, поддержка IP-адресов и имен доменов для транспортных шлюзов | Статические | |
Протокол MGCP
Рабочая группа MEGACO комитета IETF разработала протокол управления шлюзами – Media Gateway Control Protocol (MGCP).
При разработке протокола управления шлюзами рабочая группа MEGACO опиралась на принцип декомпозиции, согласно которому шлюз разбивается на отдельные функциональные блоки (рис. 3.6):
транспортный шлюз – Media Gateway, который выполняет функции преобразования речевой информации, поступающей со стороны ТфОП с постоянной скоростью, в вид, пригодный для передачи по сетям с маршрутизацией пакетов IP: кодирование и упаковку речевой информации в пакеты RTP/UDP/IP, а также обратное преобразование;
Рис. 3.6. Архитектура сети, базирующейся на протоколе 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 – коммутационные устройства с интерфейсом для управления от внешнего устройства.
которая является также первой зонтичной
Для построения сетей IP-телефонии первой стала рекомендация H.323 МСЭ-Т, которая является также первой зонтичной спецификацией систем мультимедийной связи для работы в сетях с коммутацией пакетов, не обеспечивающих гарантированное качество обслуживания (рис. 3.3).
Сети, построенные на базе протоколов H.323, ориентированы на интеграцию с телефонными сетями и могут рассматриваться как сети ЦСИС (цифровая служба с интеграцией служб), наложенные на сети передачи данных. В частности, процедура установления соединения в таких сетях IP-телефонии базируется на рекомендации МСЭ-Т Q.931 и практически идентична той же процедуре в сетях ЦСИС. При этом рекомендация H.323 предусматривает применение разнообразных алгоритмов сжатия речевой информации, что позволяет использовать полосу пропускания ресурсов передачи гораздо более эффективно, чем в сетях с коммутацией каналов.
Рис. 3.3. Структура сети Н.323
Основными устройствами сети являются: терминал, шлюз, привратник. В отличие от устройств ТфОП, устройства Н.323 не имеют жестко закрепленного места в сети, а подключаются к любой точке IP-сети. Однако при этом сеть Н.323 разбивается на зоны, а каждой зоной управляет привратник.
Терминал H.323 – оконечное устройство сети IP-телефонии, обеспечивающее 2-стороннюю речевую или мультимедийную связь с другим терминалом, шлюзом или устройством управления конференциями.Шлюз является соединяющим мостом между ТфОП и IP. Основная функция шлюза — преобразование речевой (мультимедийной) информации, поступающей со стороны ТФОП с постоянной скоростью, в вид, пригодный для передачи по IP-сетям, т. е. кодирование информации, подавление пауз в разговоре, упаковка информации в пакеты RTP/UDP/IP, а также обратное преобразование. Кроме того, шлюз должен преобразовывать аналоговую абонентскую сигнализацию, сигнализацию по 2ВСК и сообщения систем сигнализации DSS1 и OKC7 в сигнальные сообщения Н.323. При отсутствии в сети привратника должна быть реализована еще одна функция шлюза: преобразование номера ТфОП в транспортный адрес IP-сети. Привратник выполняет функции управления зоной сети IP-телефонии, в которую входят терминалы и шлюзы, зарегистрированные у данного привратника.
Разные участки зоны сети H. 323 могут быть территориально разнесены, но соединяться друг с другом через маршрутизаторы (рис. 3.4).
Рис. 3.4. Зоновая архитектура сети H.323
В число наиболее важных функций, выполняемых привратником, входят:
преобразование alias-адреса (имени абонента, телефонного номера, адреса электронной почты и др.) в транспортный адрес сетей с маршрутизацией пакетов IP (IP-адрес и номер порта RTP); контроль доступа пользователей системы к услугам IP-телефонии при помощи сигнализации RAS (Registration, Admission and Status); контроль, управление и резервирование пропускной способности сети; маршрутизация сигнальных сообщений между терминалами, расположенными в одной зоне.
Привратник также обеспечивает для пользователя возможность получить доступ к услугам любого терминала в любом месте сети и способность сети идентифицировать пользователей при их перемещении из одного места в другое.
Протокол передачи информации управления потоком (SCTP)
Протокол передачи информации управления потоком (SCTP) обеспечивает транспортировку сообщений сигнализации через сеть IP между двумя оконечными пунктами, с избыточностью доставки информации и повышенной степенью надежности. Для этого применяется стандартизованный метод, отличающийся встраиванием в протокол повышенной надежности доставки в реальном времени информации от нескольких источников по нескольким информационным потокам.
Также обеспечивается самоотключение в случае перегрузки соединения Интернет, по которому функционирует этот протокол. Интерфейс между SCTP и его сигнальными приложениями управляется через адаптационные уровни, которые образуют промежуточный уровень таким образом, чтобы сигнальные протоколы высших уровней конкретной архитектуры стека протоколов не меняли свой интерфейс с транспортной средой и внутренние функциональные возможности, когда начинают использовать SCTP вместо другого транспортного протокола. Другой аспект состоит в том, что поддерживаемая архитектура стека протоколов согласована с архитектурой Интернет без нарушения собственных правил.
Протокол 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 представлен на рис. 3.5.
Сеть SIP содержит следующие основные элементы.
Агент пользователя (User Agent или SIP client) является приложением терминального оборудования и включает в себя две составляющие: клиент агента пользователя (User Agent Client – UAC) и сервер агента пользователя (User Agent Server – UAS), иначе называемые клиент и сервер. Клиент UAC инициирует SIP-запросы, т.е. выступает в качестве вызывающей стороны. Сервер UAS принимает запросы и отвечает на них, т.е. выступает в качестве вызываемой стороны.
Запросы могут передаваться не прямо адресату, а на некоторый промежуточный узел (прокси-сервер и сервер переадресации).
Прокси-сервер (proxy server) принимает запросы, обрабатывает их и отправляет дальше на следующий сервер, который может быть как другим прокси-сервером, так и последним UAS. Таким образом, прокси-сервер принимает и отправляет запросы и клиента, и сервера. Приняв запрос от UAC, прокси-сервер действует от имени этого UAC;
Рис. 3.5. Пример построения SIP-сети
Сервер переадресации (redirect server) передает клиенту в ответе на запрос адрес следующего сервера или клиента, с которым первый клиент связывается затем непосредственно. Он не может инициировать собственные запросы. Адрес сообщается первому клиенту в поле Contact сообщений SIP. Таким образом, этот сервер просто выполняет функции поиска текущего адреса пользователя. Сервер местоположения (location server) – база адресов, доступ к которой имеют SIP-серверы, пользующиеся ее услугами для получения информации о возможном местоположении вызываемого пользователя. Приняв запрос, сервер SIP обращается к серверу местоположения, чтобы узнать адрес, по которому можно найти пользователя. В ответ тот сообщает либо список возможных адресов, либо информирует о невозможности найти их.
Протоколы RTP, RTCP, UDP
Основным транспортным протоколом для мультимедийных приложений стал протокол реального времени RTP (Real Time Protocol), предназначенный для организации передачи пакетов с кодированными речевыми сигналами по пакетной сети. Передача пакетов RTP ведется поверх протокола UDP, работающего, в свою очередь, поверх IP (рис. 3.2).
увеличить изображение
Рис. 3.1. Взаимодействие Softswitch с остальным оборудованием
Характерные для IP-сетей временные задержки и вариация задержки пакетов (джиттер) могут серьезно исказить информацию, чувствительную к задержке, например речь и видеоинформацию, сделав ее абсолютно непригодной для восприятия. Вариация задержки (джиттер) пакетов гораздо сильнее влияет на субъективную оценку качества передачи, чем абсолютное значение задержки.
Протокол RTP позволяет компенсировать негативное влияние джиттера на качество речевой и видеоинформации, но в то же время он не имеет собственных механизмов, гарантирующих своевременную доставку пакетов или другие параметры качества услуг, – это осуществляют нижележащие протоколы. Он даже не обеспечивает все те функции, которые обычно предоставляют транспортные протоколы, в частности функции исправления ошибок и управления потоком. Обычно протокол RTP базируется на протоколе UDP и использует его функции, но может работать и поверх других транспортных протоколов.
Рис. 3.2. Уровни протоколов RTP/UDP/IP
Протокол TCP плохо подходит для передачи чувствительной к задержкам информации. Во-первых, это алгоритм надежной доставки пакетов. Пока отправитель повторно передаст пропавший пакет, получатель будет ждать, результатом чего может быть недопустимое увеличение задержки. Во-вторых, алгоритм управления при перегрузке в протоколе TCP не оптимален для передачи речи и видеоинформации. При обнаружении потерь пакетов протокол TCP уменьшает размер окна, а затем будет его медленно увеличивать, когда как разумнее было бы изменить метод кодирования или размер видеоизображения.
Протокол RTP предусматривает индикацию типа полезной нагрузки и порядкового номера пакета в потоке, а также применение временных меток.
Отправитель помечает каждый RTP- пакет временной меткой, получатель извлекает ее и вычисляет суммарную задержку. Разница в задержке разных пакетов позволяет определить джиттер и смягчить его влияние – все пакеты будут выдаваться приложению с одинаковой задержкой.
Доставка RTP-пакетов контролируется специальным протоколом RTCP (Real Time Control Protocol).
Основной функцией протокола RTCP является организация обратной связи приемника с отправителем информации для отчета о качестве получаемых данных. Протокол RTCP передает сведения (как от приемника, так и от отправителя) о числе переданных и потерянных пакетов, значении джиттера, задержке и т.д. Эта информация может быть использована отправителем для изменения параметров передачи, например для уменьшения коэффициента сжатия информации с целью улучшения качества ее передачи.
Протокол передачи пользовательских дейтаграмм – User Datagram Protocol (UDP) – обеспечивает негарантированную доставку данных, т.е. не требует подтверждения их получения; кроме того, данный протокол не требует установления соединения между источником и приемником информации.
SCTP для MEGACO
Направленные на достижение высокой пропускной способности и доступности, реализации протокола MEGACO могут особенно эффективно использоваться в сочетании с теми возможностями образования информационных потоков, избыточности сетевой поддержки, исключения перегрузок и обеспечения высоких характеристик информационной безопасности, которые предоставляются протоколом SCTP.
Реализациями MEGACO могут применяться следующие предоставляемые SCTP возможности:
транспортировка, основанная на передаче дейтаграмм;надежность доставки информации: как транспортный протокол повышенной надежности, SCTP обеспечивает механизмы восстановления пакетов информации при ее потере или дублировании. Указанное свойство позволяет упростить разработку уровня приложений;надежность доставки сообщений при обеспечении очередности и без таковой: при необходимости ускоренного обслуживания приложения для каждого сообщения может устанавливаться высший по сравнению с не нуждающимися в обеспечении очередности приоритет транзакций:передача потоков информации: SCTP в состоянии обеспечить до 65536 однонаправленных потоков в каждом направлении связи MGC-MG. SCTP передает сообщения и обрабатывает принимаемые сообщения одного потока независимо от порядка или статуса сообщений других потоков. Приложение имеет возможность эффективно избегать возникновения блокировок линии посредством передачи информации независимых друг от друга транзакций по разным потокам;защита против столкновений сообщений: встроенный в SCTP механизм шифрования обеспечивает защиту на узле MGC или MG; управление сетевыми перегрузками: средствами SCTP для обнаружения и обработки случаев перегрузки сети обеспечены эффективные средства;управление резервным маршрутом: для крупного MG на сетевом уровне может требоваться наличие с MGC связи, имеющей повышенную устойчивость к отказам.
В целях предоставления резервных маршрутов SCTP поддерживает функционирование нескольких находящихся в разных местах (multi-homed) узлов IP.
SCTP обеспечивает проверку доступности, функции ускоренного переключения в аварийных ситуациях (switch-over/fail-over) и (потенциально) балансирование нагрузки между резервными маршрутами.
Транспортировка информации сигнализации(SIGTRAN)
Транспортировка информации сигнализации по технологии SIGTRAN (рис. 3.9) предназначена для передачи сообщений протокола сигнализации сети с коммутацией каналов через сеть с коммутацией пакетов и должна обеспечивать:
передачу сообщений разнообразных протоколов сигнализации, обслуживающих соединения сетей с коммутацией каналов (CSN), например протоколов прикладных и пользовательских подсистем ОКС7 (включая уровень 3 МТР, ISUP, SCCP, TCAP, MAP, INAP и т. д.), а также сообщений уровня 3 протоколов DSS1/PSS1 (т. е. Q.931 и QSIG);средства идентификации конкретного транспортируемого протокола сигнализации сети с коммутацией каналов;общий базовый протокол, определяющий форматы заголовков, расширения в целях информационной безопасности и процедуры для транспортировки сигнальной информации, а также (при необходимости) расширения для введения конкретных индивидуальных протоколов сигнализации сети с коммутацией каналов;функциональные возможности (с участием нижележащего сетевого протокола, например IP), соответствующие нижнему уровню конкретной сети с коммутацией каналов.
Рис. 3.9. Архитектура протоколов SIGTRAN
При транспортировке сигнальной информации через инфраструктуру сети Интернет используемым промежуточным средством считается протокол передачи информации управления потоком (Stream Control Transmission Protocol – SCTP).
