Вторым вариантом построения сетей стал протокол 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 обращается к серверу местоположения, чтобы узнать адрес, по которому можно найти пользователя. В ответ тот сообщает либо список возможных адресов, либо информирует о невозможности найти их.
Протокол 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 – коммутационные устройства с интерфейсом для управления от внешнего устройства.
Протокол MEGACO/H.248
Рабочая группа MEGACO комитета IETF, продолжая исследования, направленные на усовершенствование протокола управления шлюзами, создала более функциональный (по сравнению с рассмотренным в предыдущей главе протоколом MGCP ) протокол MEGACO. Но разработкой протоколов управления транспортными шлюзами, кроме комитета IETF, занималась еще и исследовательская группа SG 16 Международного союза электросвязи. Спецификации адаптированного протокола приведены в рекомендации ITU-T H.248.
Рассмотрим кратко основные особенности протокола MEGACO/ H.248. Для переноса сигнальных сообщений MEGACO/ H.248 могут использоваться протоколы 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).
Таблица 3.1. Основные протоколы IP-телефонии
Характеристики
SIP
H.323
MGCP
MEGACO
ISUP
Назначение
Для IP-коммуникаций
Для IP-телефонии
Для управления транспортными шлюзами
Для сетей с BPK
Архитектура
Peer-to-Peer
Peer-to-Peer
Master-Slave
Peer-to-Peer
Интеллект
Рассредоточен по элементам сети
В ядре сети
В ядре сети
В ядре сети
Сложность
Простой
Сложный
Простой
Сложный
Масштабируемость
Высокая
Средняя
-
Средняя
Тип данных
Речь, данные, видео
Речь, данные, видео
Управление передачей речи, данных
Речь и данные
QoS
Поддерживается
Поддержка диффиринцированного обслуживания
Контроль QoS на уровне IP
Не требуется
Адресация
Поддержка IP-адресов и имен доменов, через DNS
Поддержка IP-адресов, мультизонная, многодоменовая поддержка через привратник
Цифровая адресация терминалов пользователей, поддержка IP-адресов и имен доменов для транспортных шлюзов
Статические
Сравнение протоколов (с позиции применения в ССП)
MEGACO/H.248 и MGCP
Прежде всего, MEGACO имеет более общую модель обслуживания вызовов, что позволяет ему лучше работать с такими соединениями какTDM-TDM, TDM-ATM, и TDM-IP, а также более гибко управлять конференциями. Еще одно различие касается транзакций. MEGACO в транзакциях содержит команды раздельно друг от друга, в то время как МGCP позволяет использовать вложенные команды, что усложняет процесс поиска команды. MEGACO может применять в целях обеспечения безопасности заголовки аутентификации, которых нет у MGCP. Что касается мультимедиа, MEGACO позволяет микшировать аудио/видеоданные и таким образом поддерживает мультимедийный трафик, а MGCPориентирован только на поддержку аудиоинформации. Если шлюз обнаруживает аварию на управляющем им Softswitch при помощи команд, протокол MEGACO позволяет назначить новый управляющий Softswitch. В MGCP это делается гораздо более сложным способом.
MEGACO/H.248 и SIP
MEGACO/ H.248 и SIP не соперничают друг с другом, т.к. MEGACO – это протокол, предназначенный для взаимодействия Softswitch и медиашлюзов, а SIP – это протокол взаимодействия одноранговых устройств (Softswitch или SIP -телефон). Взаимодействие транспортных шлюзов ограничено областью одного домена, т.к. они контролируются одним Softswitch. Таким образом, можно сказать, что MEGACO не определяет систему связи в целом, ему нужен протокол для взаимодействия Softswitch, которым может быть SIP.
MEGACO/H.248 и Н.323
Как и SIP, протокол H.323 может дополнять MEGACO/ H.248, поскольку тоже является протоколом, обеспечивающим взаимодействие одноранговых устройств. В таком случае MEGACO/H.248 позволит Н.323 избавиться от присущих ему проблем с масштабируемостью, доступностью и возможностью взаимодействовать с ОКС7. В этих условиях Н.323 будет протоколом терминалов для взаимодействия друг с другом и с сетью, а MEGACO будет использоваться привратниками для управления большими шлюзами, обеспечивающими взаимодействие IP-сети, построенной согласно Н.323 с сетью ТфОП.
Протокол BICC
Для взаимодействия Softswitch между собой теоретически должен применяться протокол BICC (Bearer Independent Call Control), разработанный МСЭ. И хотя на практике более популярным становится второй протокол – SIP (SIP-T), разработанный IETF, протокол BICC успешно используется до сих пор, например в решениях Ericsson.
При разработке данного протокола обязательным требованием являлась поддержка сигнальных сообщений 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), но не все сетевые технологии требуют их наличия.