К какой плоскости архитектуры voip относится протокол mgcp

Обновлено: 04.07.2024

Короткая, но богатая событиями история развития IP-телефонии привела к тому, что сегодня в реальных сетях VoIP сосуществуют и конкурируют между собой три основных семейства протоколов - H.323, SIP и MGCP. Протоколы всех трех перечисленных семейств регламентируют управление мультимедиа-вызовами и передачу медиа-трафика в IP-сетях, но при этом реализуют три различных подхода к построению систем телефонной сигнализации. Попробуем разобраться, почему сложилась такая ситуация, что представляют собой эти протоколы и каковы перспективы развития каждого из них.

Набор рекомендаций Н.323

Исторически первый и самый распространенный в настоящее время - это введенный Международным союзом электросвязи (МСЭ) набор рекомендаций Н.323 (для простоты будем называть его протоколом). Н.323 стал плодом деятельности разработчиков протоколов мультимедийной связи в сетях ISDN (H.320). Соответствующие работы велись еще c начала 90-х годов, когда никакой IP-телефонии и в помине не было. Первая версия этого протокола была принята МСЭ в 1996 г. и по сути была попыткой перенести телефонную сигнализацию ISDN Q.931 на IP-соединения, т. е. как бы "наложить" традиционную телефонию на сети передачи данных. Рекомендации H.323 достаточно подробно описывают способы организации мультимедийных конференций, охватывая сервисы передачи голоса, видео и компьютерных данных в пакетных сетях с негарантированной доставкой. К настоящему времени принята уже четвертая версия этого набора рекомендаций. К основным компонентам набора относятся описанные ниже протоколы.

RAS (Registration, Admission, Status) - отвечает за регистрацию устройств в сети, контроль доступа к ресурсам, контроль полосы пропускания, необходимой для сеанса связи, и контроль состояния устройств в сети. Работает по протоколу UDP.

H.245 - отвечает за обмен информацией, необходимой для согласования параметров логических каналов для передачи медиа-потоков, т. е. собственно голоса или видео. Сюда входит, к примеру, согласование кодеков, номеров UDP-портов и т. д. Обмен происходит по протоколу TCP.

H.450.x (появившийся в четвертой версии H.323) - отвечает за обеспечение таких дополнительных или интеллектуальных функций, как Hold, Transfer и т. д.

Архитектура H.323 (рис. 1) весьма проста и состоит всего из четырех функциональных компонентов, ни один из которых не является обязательным.

Рис. 1. Архитектура Н.323.

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

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

Привратник (H.323 Gatekeeper, GK) - управляющий элемент, "интеллект" H.323 сети, обеспечивающий ее масштабируемость, централизацию управления и настроек, а также трансляцию телефонных префиксов и идентификаторов (H.323 ID) в IP-адреса шлюзов или H.323 терминалов. Кроме того, привратник отвечает за управление доступом (Admission Сontrol) при регистрации шлюзов и терминалов, авторизацию звонков (Call Admission Control), управление полосой пропускания и маршрутизацию вызовов. Привратник управляет подчиненной ему частью сети (зоной) через RAS - протокол общения шлюзов с ним. Предусмотрено объединение привратников в группы, управлять которыми можно с помощью выделенного привратника - Directory Gatekeeper.

Устройство многопользовательских конференций (H.323 Multipoint Conference Unit, MCU) - управляет проведением многопользовательских конференций, согласует параметры соединения всех участников в режиме централизованной, децентрализованной или комбинированной конференции. Возможно переключение или смешивание медиа-потоков.

В наиболее общей форме сценарий соединения по протоколу H.323 выглядит как ряд последовательных шагов (рис. 2). Вначале для установления соединения терминал обнаруживает привратника и регистрируется у него по протоколу RAS. Затем происходит установление сигнального канала по протоколам RAS и H.225. На следующем этапе выполняется согласование параметров оборудования, обмен информацией о его функциональных возможностях и открытие логических каналов по протоколу H.245. Только после этого происходит передача медиа-трафика по протоколам RTP/RTCP, а по ее окончании - завершение соединения.

Рис. 2. Сценарий соединения по протоколу H.323.

Протокол SIP

Следующий по распространенности протокол IP-телефонии называется SIP (Session Initiation Protocol); он описан в рекомендациях RFC 2543. SIP регламентирует установление и завершение мультимедийных сессий - сеансов связи, в ходе которых пользователи могут говорить друг с другом, обмениваться видеоматериалами и текстом, совместно работать над приложениями и т. д. SIP и сопутствующие ему протоколы родились и развиваются в рамках IETF - главного органа стандартизации Интернета. Первая версия протокола SIP была принята в марте 1999 г., на три года позже, чем H.323, но благодаря интенсивному развитию этого направления сегодня набор рекомендаций RFC (базовых официальных документов IETF), имеющих отношение к SIP-архитектуре, насчитывает десятки, если не сотни документов.

Архитектура SIP (рис. 3) также очень проста и состоит из нескольких необязательных компонентов.

Рис. 3. Архитектура SIP.

Клиент SIP (SIP user agent) - может быть представлен как устройством (IP-телефон, шлюз или другой пользовательский терминал), так и программным приложением для ПК, PDA и т. д. Обычно SIP-клиент содержит и клиентскую, и серверную часть (User Agent Client, или UAC, и User Agent Server, или UAS). Основные функции данного компонента - инициирование и завершение вызовов.

Прокси-сервер SIP - управляет маршрутизацией вызовов и работой приложения. Прокси-сервер не может инициировать или терминировать вызовы.

Redirect-сервер SIP - перенаправляет звонки согласно заданным условиям.

Сервер регистрации SIP (registrar/location) - осуществляет регистрацию пользователей и ведет базу соответствия имен пользователей их адресам, телефонным номерам и т. д.

Еще один важный компонент реальных SIP-сетей, хотя и не входящий формально в архитектуру SIP, - Back-to-Back User Agent (B2BUA). Это своеобразный сервер, представляющий собой два соединенных друг с другом SIP-клиента и поэтому способный инициировать и завершать вызовы.

Из этих компонентов, как из функциональных "кирпичиков", можно строить сети VoIP любой топологии, сложности и масштаба, вплоть до сетей, полностью замещающих функции современных АТС. Можно также создавать совершенно новые сервисы - интеграцию Интернет- и бизнес-приложений, программируемые службы, многоадресный поиск абонента, мультимедийные сервисы, уведомления о событиях и т. д.

Рис. 4. Сценарий соединения по протоколу SIP.

Этот сценарий очень прост, в нем не участвуют никакие другие серверы (Redirection, Registrar, Location), но он дает представление о схеме взаимодействия функциональных элементов SIP-сети.

Протокол MGCP

Последний из рассматриваемых протоколов IP-телефонии - MGCP (Media Gateway Control Protocol). Точнее, речь здесь идет не об одном протоколе, а о целой группе - SGCP, IPDC, MGCP, MEGACO, H.248. Эти спецификации не только очень схожи концептуально, но и являются "близкими родственниками".

История формирования MGCP началась с создания двух протоколов - SGCP (Simple Gateway Control Protocol, разработка Bellcore и Cisco Systems) и IPDC (Internet Protocol for Device Control, разрабатывался компанией Level 3 при участии многих производителей). Затем SGCP и IPDC были объединены в один протокол, получивший название MGCP. В дальнейшем эволюция MGCP привела к появлению протоколов MEGACO (в рамках IETF) и H.248 (в рамках МСЭ).

Первая версия протокола MGCP (RFC 2705) датирована октябрем 1999 г. Интересно отметить, что MGCP - единственный из трех описываемых здесь протоколов, в работе над которым IETF и МСЭ сотрудничают; именно в результате этого взаимодействия и были созданы протоколы MEGACO и H.248. В то же время существуют и другие реализации MGCP-подобных протоколов, например, фирменный протокол Cisco Systems SSCP (Skinny Station Control Protocol), с помощью которого УАТС Cisco Call Manager управляет IP-телефонами.

Основная идея MGCP очень проста. Она состоит в том, что управление сигнализацией (Call Control) сосредоточено на центральном управляющем устройстве, называемом контроллером сигнализаций (Call Agent, CA), и полностью отделено от медиа-потоков (bearer). Эти потоки обрабатываются "тупыми" шлюзами или абонентскими терминалами, которые способны исполнять лишь ограниченный набор команд, исходящих от управляющего устройства. Архитектура протокола MGCP-сети также очень проста (рис. 5), в ней выделяются всего два функциональных компонента. Первый может быть представлен шлюзом (Media Gateway, MG) или IP-телефоном, а второй - устройством управления вызовами, которое может называться контроллером сигнализаций (CA), контроллером шлюза (Media Gateway Controller, MGC) или программным контроллером (Softswitch, SS). Иногда контроллер сигнализаций представляют в виде двух компонентов - собственно контроллера (Call Agent), выполняющего функции управления шлюзами, и шлюза сигнализации (Signaling Gateway), обеспечивающего обмен сигнальной информацией и согласование между традиционной телефонной сетью и сетью IP.

Рис. 5. Архитектура MGCP.

Контроллеры обмениваются со шлюзами (или IP-телефонами) данными в простом текстовом формате (в случае H.248 возможен и бинарный обмен), а функциональное назначение каждого шлюза определяется набором команд, которые он "понимает". Манипулируя наборами команд, можно получать специализированные шлюзы: транковые (Trunking gateways, TGW), абонентские (Residential gateways, RGW), шлюзы доступа (Access gateways, AGW) и т. д.

Рис. 6. Сценарий соединения по протоколу МGCP.

Резюме

Сравнивая "биографические данные" и функциональные особенности трех видов протоколов (см. таблицу), мы видим, что их различия обусловлены историческими причинами, в частности, изменениями представлений о пути развития телекоммуникаций в разное время. При этом H.323 - это технологически устоявшийся, широко распространенный протокол IP-телефонии для операторских сетей и межоператорского обмена, можно сказать, "транзитный" протокол. В свою очередь, SIP - протокол предоставления расширенных голосовых услуг в IP-сетях, который продолжает быстро развиваться, иначе говоря, "абонентский" протокол. Что касается MGCP, то он ориентирован прежде всего на организацию больших операторских узлов сопряжения IP-сетей с ТфОП и сетями SS7.

Сравнение протоколов VoIP-сети

Эволюция H.323 позволяет предположить, что будущее развитие IP-телефонии связано не столько с замещением традиционной телефонии, сколько с появлением новых сервисов, которые невозможны в рамках обычной телефонной сети. Однако создавать такие сервисы, используя лишь семейство протоколов H.323, достаточно сложно по сравнению, например, с Интернет-сервисами. Сам процесс разработки на базе H.323, доступный только "телефонным гуру", подчиняется традиционным канонам мира обычной телефонии.

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

Как сложится судьба представителей семейства MGCP, пока сказать трудно. Эти протоколы, очевидно, будут востребованы на протяжении переходного периода - от сетей с коммутацией каналов и TDM-сетей к сетям пакетной коммутации (точнее, к IP-сетям). В первую очередь такая востребованность обусловлена возможностью прозрачной интеграции телефонных сетей (особенно SS7) с сетями IP-телефонии. Но дальнейшая перспектива развития протоколов семейства MGCP будет зависеть от того, по какому пути пойдет процесс конвергенции телекоммуникаций - по "интернетному", подразумевающему равноправие сетевых узлов, наличие "умных клиентов" и инновационных сервисов, или по "телефонному", с жесткой иерархией, при которой новые сервисы вводятся только централизованно, и неписаным правилом: чем "тупее" клиент, тем проще жить оператору.

Но в любом случае нас ожидает довольно долгий переходный период, в течение которого и Н.323, и SIP, и MGCP, и какие-то новые, еще не родившиеся протоколы будут сосуществовать в реальных операторских и корпоративных сетях. Практика их использования может меняться со временем, и мы обязательно увидим много интересного и неожиданного на телекоммуникационной сцене в ближайшие годы.

Другие статьи из раздела

С 26 по 29 октября 2010 года состоялась 21-ая ежегодная выставка информационных и коммуникационных технологий Softool

ООО «ИТ-экспо»
С 26 по 29 октября 2010 года состоялась 21-ая ежегодная выставка информационных и коммуникационных технологий Softool
Выставка прошла при поддержке Российской академии наук, Министерство связи и массовых коммуникаций Российской Федерации, Правительства Москвы …

День открытых дверей в дата-центре DataLine

DataLine
День открытых дверей в дата-центре DataLine
27 октября 2010 г. компания DataLine совместно с агентством Cnews провели День Открытых дверей в центре обработки данных на улице Боровой дом 7 …

OKI Data Corporation объявляет о начале работы ООО «ОКИ Системс Рус»

OKI Data Corporation
OKI Data Corporation объявляет о начале работы ООО «ОКИ Системс Рус»
Компания OKI Data Corporation, один из лидеров в разработке технологических решений для печати, объявила об официальном начале работы российской …

RAID-контроллеры Adaptec Series 5Z с безбатарейной защитой кэша

Adaptec by PMC
RAID-контроллеры Adaptec Series 5Z с безбатарейной защитой кэша
Опытные сетевые администраторы знают, что задействование в работе кэш-памяти RAID-контроллера дает серьезные преимущества в производительности …

Трехфазный ИБП Chloride от 200 до 1200 кВт: Trinergy

Chloride
Трехфазный ИБП Chloride от 200 до 1200 кВт: Trinergy
Trinergy — новое решение на рынке ИБП, впервые с динамическим режимом работы, масштабируемостью до 9.6 МВт и КПД до 99%. Уникальное сочетание …

30 ноября 2021 г. | Он-лайн формат
Dell Technologies Forum 2021

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

Понятие медиашлюза

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

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

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

структура медиашлюза

структура медиашлюза

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

Описание протокола MGCP

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

Протокол MGCP обеспечивает связь между двумя типами агентов, которые именуются конечными точками и агентами вызовов.

взаимодействие агентов в структуре MGCP

взаимодействие агентов в структуре MGCP

Конечные точки. Конечными точками являются любые голосовые порты на назначенном шлюзе. Это могут быть как аналоговые (FXO/FXS), так и цифровые (T1/E1) порты. В зависимости от числа портов, один шлю может содержать несколько конечных точек. Каждая конечная точка имеет свой собственный идентификатор в формате ‘локальное имя конечной точки’@’имя шлюза’ (localID@domian), по которому к ней обращается агент вызовов. Для управления конечной точкой агент вызова должен распознать характеристики конечной точки. Чтобы упростить этот процесс, конечные точки подразделяются на несколько типов. Цель состоит в том, чтобы сконфигурировать агент вызова для управления типом конечной точки, а не для управления каждой конечной точкой индивидуально.

RFC 2705 определяет восемь типов конечных точек следующим образом:

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

Команды MGCP


взаимодействие конечной точки и агента вызова

взаимодействие конечной точки и агента вызова

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

Инициализация вызова в протоколе MGCP

Вызовы устанавливаются путем соединения двух или более конечных точек, как показано на рисунке 5. Чтобы установить вызов, агент вызова инструктирует шлюз, связанный с каждой конечной точкой, установить соединение с определенной конечной точкой или конечной точкой определенного типа. Шлюз возвращает параметры сеанса своего соединения агенту вызова, который, в свою очередь, отправляет эти параметры сеанса другому шлюзу. С помощью этого метода каждый шлюз получает необходимые параметры сеанса для установления RTP-сессий между конечными точками. Все соединения, связанные с одним и тем же вызовом, имеют общий идентификатор вызова и используют один и тот же медиапоток. По завершении вызова агент вызова отправляет запрос на удаление соединения каждому

реализация звонка в СЗ

реализация звонка в СЗ

взаимодействие агентов

взаимодействие агентов

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

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

Годом рождения Internet-телефонии считают 1995-й, когда компания Vocaltec опубликовала программное обеспечение Internet Phone для системы телефонной передачи с использованием протокола IP. Для сетевой реализации Internet Phone до середины 1990-х были доступны только телефонные модемы, поэтому передача речи посредством Internet Phone значительно уступала по качеству традиционной телефонной связи. Однако первый камень в основание здания VoIP был тем не менее заложен.

Между тем события стали развиваться столь стремительно, что сейчас реальные возможности технологии VoIP значительно шире ее формального названия. По существу эта технология представляет собой средство для передачи не только речи, но и произвольной информации с использованием протокола IP, а обобщающим термином стало определение «мультимедийная». Соответствующая структура данных может включать речь, изображение и данные в любых комбинациях. Эту триаду обычно называют Triple Play.

Архитектура сети VoIP может быть представлена в виде двух плоскостей. Нижняя отображает транспортный механизм негарантированной доставки мультимедийного трафика в виде иерархии протоколов RTP/UDP/IP, а верхняя - механизм управления обслуживанием вызовов. Ее ключевыми протоколами являются H.323 ITU-T, SIP, MGCP и MEGACO, представляющие собой различные реализации обслуживания вызовов в сетях IP-телефонии.

Транспортный протокол реального времени (Real-time Transport Protocol, RTP) предоставляет транспортные услуги мультимедийным приложениям. Он не гарантирует доставку и правильный порядок пакетов, но позволяет приложениям обнаружить потерю или нарушение порядка следования пакетов за счет присвоения каждому из них номера. Протокол предназначен для работы в режимах передачи «точка–точка» или «точка–множество точек» и не зависит от транспортного механизма. Однако в качестве такового обычно используется протокол UDP.

RTP работает совместно с протоколом управления реального времени (Real Time Control Protocol, RTСP), обеспечивающим управление потоком данных и контроль перегрузки канала. Участники сеанса RTP периодически обмениваются пакетами RTCP со статистическими данными (количество отправленных пакетов, число потерянных и т. д.), которые могут быть использованы отправителем мультимедиа, например, для динамической коррекции скорости передачи и даже изменения типа нагрузки.

Среди мультимедийных стандартов наиболее освоен стандарт H.323 ITU-T, к тому же он постоянно совершенствуется и имеет пять версий. Рекомендация H.323, исторически первый способ осуществления вызовов в сети IP, предусматривает следующие виды информационного обмена:

  • «цифровизованное» аудио;
  • «цифровизованное» видео;
  • данные (обмен файлами или изображениями);
  • управление соединением (обмен информацией о поддерживаемых функциях, управление логическими каналами и т. д.);
  • управление установлением и разъединением соединений и сеансов связи.

Основными элементами сети стандарта H.323 являются терминалы (terminal), шлюзы (gateway), привратники (gatekeeper) и устройства управления конференциями (Multipoint Control Units, MCU).

Терминал обеспечивает двухстороннюю связь в реальном времени с другим терминалом H.323, шлюзом или MCU.

Шлюзы устанавливают соединение между терминалами сети H.323 и терминалами, находящимися в сетях, где используются другие протоколы. Главная задача шлюзов заключается во взаимном преобразовании информации между сетями разных протоколов (например, IP и ТфОП).

Привратники участвуют в управлении соединением, отвечая за взаимное преобразование телефонных номеров и IP-адресов.

Еще один элемент сети H.323, называемый proxy-сервером (т. е. посредником), работает на прикладном уровне, он определяет тип приложения и выполняет нужное соединение.

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

Второй способ обслуживания вызовов в сети VoIP предполагает использование протокола инициирования сеансов (Session Initiation Protocol, SIP), его спецификации представлены в документе RFC 2543 комитета IETF. Как протокол прикладного уровня, он предназначен для организации мультимедийных конференций, распределения мультимедийной информации и телефонных соединений. SIP менее приспособлен для взаимодействия с ТфОП, но проще в реализации. Он лучше подходит провайдерам Internet для организации услуги IP-телефонии в рамках предлагаемого ими пакета услуг.

Ключевыми особенностями протокола SIP являются поддержка персональной мобильности пользователя, обеспечение масштабируемости сети, возможность дополнения новыми функциями, интеграция в стек существующих протоколов Internet, взаимодействие с другими протоколами сигнализации (например, H.323), организация доступа пользователей сетей VoIP к услугам интеллектуальных сетей, независимость от транспортных технологий.

Следует отметить, что поддержка мобильности пользователя уже не является прерогативой исключительно SIP. Теперь это характерно и для Н.323 (см. H.510 ITU-T «Mobility for H.323 Multimedia Systems and Services»).

Сеть SIP содержит агенты пользователя (User Agents или SIP Сlients), proxy-серверы и серверы переадресации.

Агенты пользователя - это приложения терминального оборудования, они включают собственно клиент (User Agent Сlient, UAC) и сервер (User Agent Server, UAS). UAC инициирует запрос услуги, а UAS выступает в качестве вызывающей стороны.

Proxy-сервер (Proxy Server) объединяет в себе функции UAC и UAS. Он интерпретирует и, если надо, перезаписывает заголовки запросов перед отправкой их другим серверам.

Сервер переадресации (Redirect Server) определяет положение вызываемого абонента и сообщает его вызывающему пользователю.

Третий способ построения сети IP-телефонии опирается на протокол Media Gateway Control Protocol (MGCP), предложенный рабочей группой MEGACO комитета IETF. Архитектура этого протокола, пожалуй, наиболее проста с точки зрения функциональности. Сеть MGCP содержит шлюз (Media Gateway, MG), выполняющий преобразование речевой информации между сетями ТфОП и IP-телефонии, шлюз сигнализации (Signaling Gateway, SG), обеспечивающий обработку сигнальной информации, а также схожий с привратником сети H.323 контроллер шлюзов (Call Agent), осуществляющий функции управления шлюзами.

Четвертый способ построения сети IP, представляющий собой усовершенствование MGCP, разработан группой MEGACO комитета IETF вместе с 16 SG ITU-T, поэтому его называют протоколом MEGACO/H.248. От своего старшего брата он отличается прежде всего иной схемой организации связи. Благодаря ей контроллер MEGACO/H.248 способен изменять топологию связи портов, что позволяет гибко управлять конференциями. Протокол MEGACO поддерживает два способа бинарного кодирования.

Содержание

Обзор протокола MGCP

  • IP-адрес. Для обмена пакетами RTP может использоваться отдаленный шлюз, локальный шлюз или многоадресатная звуковая конференция.
  • Порт UDP. Указывает транспортный порт, используемый для получения пакетов RTP от отдаленного шлюза.
  • Звуковая мультимедийная среда. Определение звуковой мультимедийной среды, включая кодек.

Архитектура сети


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

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


Управление терминалами в сети, базирующейся на протоколе MGCP

Одно из основных требований, предъявляемых к протоколу MGCP, состоит в том, что устройства, реализующие этот протокол, должны работать в режиме без сохранения информации о последовательности транзакций между устройством управления и транспортным шлюзом, т.е. в устройствах не требуется реализации конечного автомата для описания этой последовательности. Однако не следует распространять подобный подход на последовательность состояний соединений, сведения о которых хранятся в устройстве управления.Отметим, что протокол MGCP является внутренним протоколом, поддерживающим обмен информацией между функциональными блоками распределенного шлюза. Протокол MGCP использует принцип master/slave (ведущий/ведомый), причем устройство управления шлюзами является ведущим, а транспортный шлюз - ведомым устройством, выполняющим команды, поступающие от устройства управления.
Такое решение обеспечивает масштабируемость сети и простоту эксплуатационного управления ею через устройство управления шлюзами. К тому же, не интеллектуальные шлюзы требуют меньшей производительности процессоров и, как следствие, оказываются менее дорогими. Кроме того, обеспечивается возможность быстро добавлять новые протоколы сигнализации и новые дополнительные услуги, так как нужные для этого изменения затрагивают только устройство управления шлюзами, а не сами шлюзы.
Основной недостаток этого подхода - незаконченность стандартов. Функциональные блоки распределенных шлюзов, разработанные разными фирмами-производителями телекоммуникационного оборудования, практически несовместимы. Функции устройства управления шлюзами точно не определены. Не стандартизированы механизмы переноса сигнальной информации от шлюза сигнализации (Signalling Gateway) к устройству управления и в обратном направлении. К недостаткам можно отнести также отсутствие стандартизированного протокола взаимодействия между устройствами управления. Кроме того, протокол MGCP, являясь протоколом управления шлюзами, не предназначен для управления соединениями с участием терминального оборудования пользователей (IP-телефонами). Это означает, что в сети, построенной на базе протокола MGCP, для управления терминалами должен присутствовать привратник или сервер SIP.

Классификация шлюзов

Представлена следующая классификация транспортных шлюзов:

  • 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 - коммутационные устройства с интерфейсом для управления от внешнего устройства.

Модель организации данных


Для описания процесса обслуживания вызова с использованием протокола MGCP разработана модель организации соединения - Connection model. Базой модели являются компоненты двух основных видов: порты (Endpoints) и подключения (Connections).
Endpoints - это порты оборудования, являющиеся источниками и приемниками информации. Существуют порты двух видов: физические и виртуальные. Физические порты имеют аналоговые интерфейсы, поддерживающие каждый одно телефонное соединение, или цифровые каналы, также поддерживающие одно телефонное соединение и мультиплексированные по принципу временного разделения каналов в тракт Е1. Примером виртуального порта является источник речевой информации в интерактивном речевом сервере, т.е. некое программное средство.
Connection означает подключение порта к одному из двух концов соединения, которое создается между ним и другим портом. Такое соединение будет установлено после подключения другого порта к его второму концу. Соединение может связывать порты разных шлюзов через сеть с маршрутизацией пакетов IP или порты внутри одного шлюза.
На рисунке изображены примеры использования этих двух компонентов,причем порты некоторых видов могут участвовать в нескольких соединениях одновременно.
Подключения к N соединениям
а) цифровой порт
Подключения к М соединениям
б) аналоговый порт
Подключение к одному соединению
в) порт, передающий речевые извещения
г) интерактивная речевая система
д) порт записи/воспроизведения телефонных разговоров
Подключения к L соединениям
е) порт, поддерживающий конференцсвязь
Подключения к 2 соединениям
ж) межсетевой экран или транскодер - порт ретрансляции пакетов
Подключения к К соединениям
з) АТМ-интерфейс

Протокол MGCP реализует интерфейс управления шлюз-носителя как набор транзакций. Транзакции состоят из команды и обязательного ответа. Все команды MGCP состоят из командной строки, сопровождаемой набором строк параметров и, необязательно, описанием сеанса. Командная строка имеет следующий формат: <имя команды> <идентификатор транзакции> <идентификатор конечной точки> <версия MGCP>. Каждая строка параметра, в свою очередь, состоит из кода параметра, сопровождаемого значением параметра. Все ответы состоят из заголовка ответа, сопровождаемого, необязательно,соответствующим описанием сеанса.
Команды MGCP можно разделить на три категории.

    Простые команды управления вызовом. Они используются при практически каждом случае вызова. Сюда относятся следующие команды:

Команда CreateConnection (CRCX)

Как и следует из ее названия (CreateConnection — СоздатьСоединение), эта команда создает соединение между двумя конечными точками. Параметры команды CreateConnection предоставляют информацию, необходимую шлюзу для создания соединения.

  • Идентификатор вызова (Call ID). Глобально уникальный параметр, назначаемый МСС. Все участвующие в вызове соединения совместно используют этот идентификатор.
  • Уведомляемый объект (Notified Entity — N). Этот необязательный параметр определяет, куда посылать уведомления.
  • Параметры локального соединения (Local Connection Options — L). Этот параметр описывает характеристики передачи данных, используемые при выполнении команды CreateConnection. Поля в этом параметре включают метод кодировки символов, период пакетирования, пропускную способность, тип обслуживания (Type of Service — ToS) и применение подавления эха. По умолчанию подавление эха выполняется всегда.
  • Режим (Mode — M). Этот параметр задает режим работы соединения, а именно дуплекс, только получение, только передача, неактивно и обратная связь.
  • Дескриптор отдаленного соединения (Remote Connection Descriptor — RC). Этот параметр указывает дескриптор для отдаленной стороны соединения, обычно для другой стороны сети IP. Этот параметр может иметь пустое значение, если информация об отдаленной стороне еще не известна.

Команда ModifyConnection (MDCX)

Команда ModifyConnection изменяет характеристики представления шлюза соединения или вызова. Для команды ModifyConnection допустимы те же самые параметры и поля, что и для команды CreateConnection, плюс параметр идентификатор соединения (Connection ID). Этот параметр уникально идентифицирует соединение в конечной точке. Используя команду ModifyConnection, можно изменять следующие параметры соединения: схема кодирования, период пакетирования, подавление эхо, а также активизировать и деактивизировать соединение.

Команда DeleteConnection (DLCX)

Данные Описание
Послано пакетов Количество пакетов, посланных по соединению
Послано октетов Количество октетов, посланных по соединению
Получено пакетов Количество пакетов, полученных по соединению
Получено октетов Количество октетов, полученных по соединению
Потеряно пакетов Количество потерянных пакетов, выясненное по порядковым номерам
Дребезг Средняя задержка между пакетами в миллисекундах
Запаздывание Среднее запаздывание, в мс

Команда NotificationRequest (RQNT)

Контроллер MGC использует команду NotificationRequest для того, чтобы попросить шлюз послать уведомление об определенных событиях, происходящих на конечной точке. Двумя важнейшими параметрами этой команды являются требуемые события (Requested Events), код параметра R, и требуемые сигналы (Signal Requests), код параметра S. Прежде чем переходить к других параметрам, следует подробно рассмотреть параметры R и S. Параметр "требуемые события (R)" содержит список событий, о которых шлюз просит сообщить агента вызова. В списке могут быть указаны такие события, как тон факса и модема, продолжительность тона и выяснение того, лежит ли трубка и была ли она снята, сброс, зависимые от канала сигналы (Channel-Associated Signaling— CAS), мигание и DTMF (или импульсные цифры). Кроме того, каждое событие может квалифицировать запрошенное действие. Действия, когда они определены, кодируются как заключенный в круглые скобки список ключевых слов, разделяемый запятыми. Список кодов для различных действий приведен в таблице:

Действие Код
Уведомлять немедленно (Notify immediately) N
Накапливать (Accumulate) A
Обрабатывать согласно цифровой карте (Treat according to digit map) D
Перестановка (Swap) S
Игнорировать (Ignore) I
Хранить сигнал активным (Keep signal active) K
Встроенный запрос уведомления (Embedded notification request) E

Команда Notification (NTFY)

Шлюз посылает команду Notification на основании запрошенных событий и местонахождения отслеживаемых событий. Команда Notification содержит следующие параметры:

  • Уведомляемый объект (Notified Entity — N). Если присутствует, определяет, куда посылать уведомление. Если отсутствует, значит уведомление должно быть послано отправителю
  • Идентификатор запроса (Request Identifier — X). Аналогичен параметру идентификатор запроса команды NotificationRequest. Соотносит запрос с уведомлением.
  • Наблюдаемые события (Observed Events — О). Этот параметр содержит список событий, которые шлюз обнаруживает на основании запрашиваемого параметра события в более ранней команде Notif icationRequest, полученной от контроллера MGC.

Команда AuditConnection (AUCX)

Агенты вызова используют команду AuditConnection для получения информации о соединении. Эта команда содержит идентификатор конечной точки и идентификатор соединения, указывающие контролируемое расположение и соединение. К запрошенной информации относится следующая.

  • Идентификатор вызова (Call ID). Уникальный идентификатор вызова, к которому принадлежит контролируемое соединение.
  • Уведомляемый объект (Notified Entity — N). Текущий уведомляемый объект соединения.
  • Параметры локшьного соединения (Local Connection Options — L). Параметры, примененные к соединению в настоящий момент.
  • Режим (Mode — м). Текущий режим соединения.
  • Дескриптор отдаленного соединения (Remote Connection Descriptor— RC).Параметры SDP отдаленного объекта, используемые для соединения.
  • Дескриптор локального соединения (Local Connection Descriptor— LC). Шлюз, используемый для соединения.
  • Параметры соединения (Connection Parameters— Р). Текущее значение параметра контролируемого соединения.

Команда AuditEndpoint (AUEP)

Агент вызова может использовать команду AuditEndpoint для определения состояния конечной точки. Обычно это происходит при инициализации агента вызова при поиске состояния всех конечных точек, которыми он управляет. Этот запрос содержит параметр идентификатор конечной точки (Endpoint ID), который идентифицирует контролируемую конечную точку, и параметр запрошенная информация (Requested Information), содержащий следующие внутренние параметры:

  • Список конечных точек (endpoint list). Идентифицирует контролируемую конечную точку. Чтобы указать все конечные точки, соответствующие определенной схеме, можно использовать шаблон.
  • Уведомляемый объект (Notified Entity— N). Объект, уведомляемый об активных запросах.
  • Запрошенные события (Requested Events — R). Список событий, запрошенных в настоящий момент.
  • Цифровая карта (digit map). Текущая цифровая карта конечной точки.
  • Требуемые сигналы (Signal Requests — S). Список сигналов, которые в настоящее время применяются на конечной точке.
  • Идентификатор запроса (Request Identifier— X). Идентификатор последней команды Notif icationRequest, полученной конечной точкой.
  • Идентификаторы соединения (Connection Identifiers — I). Список текущих соединений, поддерживаемых определенной конечной точки.
  • События поиска (Detect Events — Т). Список событий, которые в настоящее время обнаруживаются в режиме карантина.
  • Параметры локального соединения (Local Connection Options — L). Список всех текущих значений, например период пакетирования и кодек. Этот параметр можно использовать для запроса пакета текущих событий, которые поддерживаются определенной конечной точкой.

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

Все команды MGCP следует подтверждать. Подтверждение несет код возврата, который указывает состояние команды. Код возврата (return code) — это целое число, для которого определены четыре диапазона значений:

Читайте также: