Основные протоколы, используемые в сетях следующего поколения
Протокол MEGACO/H.248
Рабочая группа MEGACO комитета IETF, продолжая исследования, направленные на усовершенствование протокола управления шлюзами, создала более функциональный (по сравнению с рассмотренным в предыдущей главе протоколом MGCP ) протокол MEGACO. Но разработкой протоколов управления транспортными шлюзами, кроме комитета IETF, занималась еще и исследовательская группа SG 16 Международного союза электросвязи. Спецификации адаптированного протокола приведены в рекомендации ITU-T H.248.
Порты являются источниками и приемниками речевой информации. Определено два вида портов: физические и виртуальные.
Физические порты, существующие постоянно с момента конфигурации шлюза, — это аналоговые телефонные интерфейсы оборудования, поддерживающие одно телефонное соединение, или цифровые каналы, также поддерживающие одно телефонное соединение и сгруппированные по принципу временного разделения каналов в тракт Е1.
Контекст – это отображение связи между несколькими портами, то есть абстрактное представление соединения двух или более портов одного шлюза. В любой момент времени порт может относиться только к одному контексту, который имеет свой уникальный идентификатор. Существует особый вид контекста – нулевой. Все порты, входящие в нулевой контекст, не связаны ни между собой, ни с другими портами. Например, абстрактным представлением свободного (не занятого) канала в модели процесса обслуживания вызова является порт в нулевом контексте.
Порт имеет уникальный идентификатор (TerminationID), который назначается шлюзом при конфигурации порта. Например, идентификатором порта может служить номер тракта Е1 и номер временного канала внутри тракта.
При помощи протокола MEGACO контроллер может изменять свойства портов шлюза. Свойства портов группируются в дескрипторы, которые включаются в команды управления портами.
Сведем основные характеристики протоколов IP-телефонии в одну таблицу (таблица 3.1).
| Характеристики | 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/H.248 и SIP
MEGACO/H.248 и Н.323
Основные протоколы, используемые в сетях следующего поколения
Протокол MEGACO/H.248
Рабочая группа MEGACO комитета IETF, продолжая исследования, направленные на усовершенствование протокола управления шлюзами, создала более функциональный (по сравнению с рассмотренным в предыдущей главе протоколом MGCP ) протокол MEGACO. Но разработкой протоколов управления транспортными шлюзами, кроме комитета IETF, занималась еще и исследовательская группа SG 16 Международного союза электросвязи. Спецификации адаптированного протокола приведены в рекомендации ITU-T H.248.
Порты являются источниками и приемниками речевой информации. Определено два вида портов: физические и виртуальные.
Физические порты, существующие постоянно с момента конфигурации шлюза, — это аналоговые телефонные интерфейсы оборудования, поддерживающие одно телефонное соединение, или цифровые каналы, также поддерживающие одно телефонное соединение и сгруппированные по принципу временного разделения каналов в тракт Е1.
Контекст – это отображение связи между несколькими портами, то есть абстрактное представление соединения двух или более портов одного шлюза. В любой момент времени порт может относиться только к одному контексту, который имеет свой уникальный идентификатор. Существует особый вид контекста – нулевой. Все порты, входящие в нулевой контекст, не связаны ни между собой, ни с другими портами. Например, абстрактным представлением свободного (не занятого) канала в модели процесса обслуживания вызова является порт в нулевом контексте.
Порт имеет уникальный идентификатор (TerminationID), который назначается шлюзом при конфигурации порта. Например, идентификатором порта может служить номер тракта Е1 и номер временного канала внутри тракта.
При помощи протокола MEGACO контроллер может изменять свойства портов шлюза. Свойства портов группируются в дескрипторы, которые включаются в команды управления портами.
Сведем основные характеристики протоколов IP-телефонии в одну таблицу (таблица 3.1).
| Характеристики | 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/H.248 и SIP
MEGACO/H.248 и Н.323
H 248 протокол что это
Глава 9 Протокол MEGACO/H.248
9.1 История создания и особенности протокола MEGACO/H.248
Рис. 9.1 Дерево эволюции протокола MEGACO/H.248
9.2 Модель процесса обслуживания вызова
При описании алгоритма установления соединения с использованием протокола MEGACO комитет IETF опирается на специальную модель процесса обслуживания вызова, отличную от модели MGCP. Протокол MEGACO оперирует с двумя логическими объектами внутри транспортного шлюза: порт (termination) и контекст (context), которыми может управлять контроллер шлюза. Пример модели процесса обслуживания вызова приведен на рис. 9.2.
Порты являются источниками и приемниками речевой информации. Определено два вида портов: физические и виртуальные. Физические порты, существующие постоянно с момента конфигурации шлюза, это аналоговые телефонные интерфейсы оборудования, поддерживающие одно телефонное соединение, или цифровые каналы, также поддерживающие одно телефонное соединение и сгруппированные по принципу временного разделения каналов в тракт Е1. Виртуальные порты, существующие только в течение разговорной сессии, являются портами со стороны IP сети (RTP-порты), через которые ведутся передача и прием пакетов RTP.
Рис. 9.2 Примеры модели процесса обслуживания вызова
Виртуальные порты создаются шлюзом при получении от контроллера команды Add и ликвидируются при получении команды Subtract, тогда как физические порты при получении команды Add или Subtract, соответственно, выводятся из нулевого контекста или возвращаются обратно в нулевой контекст.
Порты обладают рядом свойств (properties), каждое из которых имеет уникальный идентификатор (propertylD). Например, порты могут обладать свойствами генерировать речевые подсказки, акустические и вызывные сигналы, а также детектировать сигналы DTMF.
При создании портов некоторые свойства присваиваются им по умолчанию. При помощи протокола MEGACO контроллер может изменять свойства портов шлюза. Свойства портов группируются в дескрипторы, которые включаются в команды управления портами (таблица 9.1).
Таблица 9.1 Дескрипторы протокола MEGACO
Название дескриптора
Идентифицирует тип и параметры модема
Описывает тип мультиплексирования информации, используемый мультимедийными терминалами, например, Н.221, Н.223, Н.225.0
Специфицирует параметры информационного потока
Включает в себя ряд дескрипторов (Remote, Local, LocalControl, Signals, Events), специфицирующих параметры отдельного двунаправленного информационного потока
Содержит параметры, описывающие информационный поток, передаваемый или принимаемый данным шлюзом. Информация, содержащаяся в этом дескрипторе, переносится от одного шлюза к другому
Содержит параметры, описывающие информационный поток, передаваемый или принимаемый удаленным шлюзом. Информация, содержащаяся в этом дескрипторе, переносится от одного шлюза к другому
Определяет события, которые шлюз должен отслеживать, и реакцию на эти события. Определены следующие реакции: NotifyAction (известить контроллер), Accumulate (сохранить информацию о событии в буфере), AccumulateByDigitMap (накопить цифры номера в соответствии с планом нумерации), KeepActive (известить контроллер, и продолжить передачу сигнала)
Описывает сигналы конечному пользователю, передачу которых порт шлюза должен начать или прекратить
Содержит информацию (в виде ряда дескрипторов), которую контроллер запрашивает у шлюза. Посылается в командах AuditValue и AuditCapabilities
Описывает совокупность свойств порта, передается в команде AuditValue
При помощи этого дескриптора контроллер информирует шлюз об используемом плане нумерации
Содержит информацию, относящуюся к изменению состояния порта шлюза, такую как причина, метод изменения и др.
Содержит информацию о произошедших событиях. Передается в командах Notify и AuditValue
Содержит статистическую информацию, собранную портом за время соединения
Позволяет передавать информацию, не специфицированную в протоколе
В общем случае для присоединения порта к контексту служит команда Add. При этом, если контроллер не специфицирует существующий контекст, к которому должен быть добавлен порт, то шлюз создает новый контекст.
Если шлюз поддерживает конференцию, то контекст определяет топологию связей между портами, участвующими в конференции, то есть возможные направления потоков информации для каждой пары портов. Примеры топологий, поддерживаемых протоколом MEGACO/H.323, приведены на рис. 9.3.
После того, как ITU взял на себя ответственность за обслуживание протокола, IETF реклассифицировал свои публикации как исторические в RFC 5125. ITU опубликовал три версии H.248, самая последняя в сентябре 2005 года. H.248 охватывает не только базовую спецификацию протокола в H.248.1, но многие расширения определены во всей подсерии H.248.
СОДЕРЖАНИЕ
Обзор протокола
H.248 / Megaco из-за своей природы «главный-подчиненный» не описывает установление вызовов между доменами или контроллерами медиашлюза. H.248 / Megaco используется для нисходящей связи с медиашлюзами и не представляет собой полную систему. Архитектура требует других протоколов для связи между несколькими контроллерами MGC.
Устройство, которое выполняет функцию управления вызовом, называется контроллером интеллектуального медиашлюза, а устройство, которое обрабатывает мультимедиа, называется относительно неинтеллектуальным медиашлюзом. H.248 определяет протокол для контроллеров медиашлюзов для управления медиашлюзами для поддержки потоков мультимедиа в IP- сетях и коммутируемой телефонной сети общего пользования (PSTN). Обычно он используется для предоставления услуг передачи голоса по Интернет-протоколу (VoIP), таких как передача голоса и факсов между IP-сетями и PSTN ) или полностью внутри IP-сетей.
Прекращения Эти источники или приемники одного или нескольких медиапотоков или управляющих потоков. Прекращение действия может быть физическим или временным.
Хотя моделирование медиашлюза отличается в H.248 / Megaco по сравнению с MGCP, существует сходство между семантикой команд в двух спецификациях. Между командами MEGACO и MGCP существует почти однозначное соответствие. Например, команда Create connection в MGCP имеет эквивалентную команду завершения ADD в MEGACO, команда Modify connection в MGCP приравнивается к команде завершения MODIFY в MEGACO, а команда Delete connection приравнивается к команде завершения SUBTRACT в MEGACO.
Сообщения и команды
Контроллер медиа-шлюза всегда управляет медиа-каналами, доступными на самом медиа-шлюзе, управляя конкретными контекстами и завершениями. Когда состояние вызова изменяется, MGC отправляет соответствующее сообщение на шлюз и ожидает подтверждения.
Каждое сообщение является транспортным механизмом для передачи команд, а не самой командой, в отличие от большинства других телекоммуникационных протоколов.
Типичный обмен сообщениями MGC и MG
Структура сообщения
По аналогии с моделью OSI иерархия уровней взаимодействия с точки зрения передачи по сети (Ethernet или ATM) следующая.
Сравнение с MGCP
Модель H.248 / Megaco более сложна, чем модель протокола управления медиашлюзом (MGCP), и обеспечивает большую гибкость при определении управления мультимедиа. Например, в MGCP вызов может использовать конференцию в режиме конечной точки для управления микшированием потоков, но он не может достичь точного управления H.248 / Megaco при управлении медиапотоками.
Модель H.248 / Megaco упрощает установку соединения внутри MG и с объектами за пределами MG. Это упрощает механизм, с помощью которого контроллер медиашлюза (MGC) может указывать связанные медиапотоки, а также указывать направление медиапотока. Таким образом, H.248 / Megaco может обеспечить большую поддержку на уровне приложений, чем MGCP. Например, установка многосторонней конференции с H.248 просто включает в себя добавление нескольких завершений в контекст. В случае MGCP, однако, MGC необходимо установить несколько соединений с конечной точкой особого типа, называемой мостом конференц-связи.
Ниже приведены основные различия между Megaco / H.248 и MGCP:
Протокол Megaco/H.248
6.4.1. Особенности Megaco/H.248
В результате, спецификация Megaco/K248 написана таким образом, что обеспечивает как кодирование текста, так и двоичное кодирование протокола, нивелирует различие между IETF, который обычно использует ABNF и ITU, где выбран формат ASN.1. Вопрос о том, является ли текстовый протокол лучшим решением, чем протокол сигнализации в виде машинных кодов (или наоборот), в процессе разработки протокола решен не был. Сегодня H.248/Megaco поддерживает оба варианта и рекомендует, чтобы при реализации Softswitch использовались и тот, и другой вариант протокола, а при реализации транспортных шлюзов или устройств интегрированного доступа IAD может быть выбран любой предпочтительный для разработчика вариант.
В настоящий момент еще нет информации, достаточной для того, чтобы уверенно сказать, какой вариант (двоичный или текстовый) будет преобладать в реализациях систем. Однако поскольку протокол Megaco предназначен заменить реализации на базе протокола MGCP, которые являются текстовыми, ожидается, что это обстоятельство окажет сильное влияние. В этой книге в примерах, иллюстрирующих использование Megaco, для представления сообщений применяется форма синтаксиса ASN.1.
Между протоколами MGCP и Megaco/H.248 много общего и помимо сходства их архитектуры. Оба протокола работают по принципу «ведущий-ведомый», при котором Softswitch управляет транспортным шлюзом и его портами через запросы включения питания, уведомления о событиях, генерации сигналов, передаваемых к порту, а также установлением и разрушением сигнального соединения путем создания и ликвидации логических соединений между портами.
И все же, при всех общих чертах, присущих этим двум протоколам, синтаксис команд и ответов на команды в протоколах MGCP и Megaco абсолютно разный. Кодирование и условные обозначения событий и сигналов, а также модель обслуживания вызовов имеют ряд различий.
6.4.2. Модель обслуживания вызова
Виртуальные окончания существуют только в течение разговорного сеанса, являются интерфейсами со стороны IP-сети (например, RTP-окончания), через которые ведутся передача и прием пакетов. Виртуальные окончания создаются шлюзом при получении от Softswitch команды Add и ликвидируются при получении команды Subtract, тогда как физические окончания при получении команды Add или Subtract, соответственно, выводятся из нулевого контекста или возвращаются обратно в нулевой контекст.
Окончания имеют различные свойства. Очевидно, например, что подключенное к аналоговой линии окончание имеет не такие характеристики, как окончание, подключенное к цифровому каналу 64 Кбит/с. Свойства окончания определяются набором дескрипторов, включаемых в состав команд Megaco, что позволяет изменять свойства оконечных устройств в соответствии с указаниями, передаваемыми из Softswitch в MG.
Контекст (Context) представляет собой отображение связи между несколькими окончаниями, то есть абстрактное представление соединения двух или более портов одного шлюза. Окончания могут быть добавлены к контексту, удалены из контекста или перемещены из одного контекста в другой. В любой момент времени окончание может существовать только в одном контексте, который имеет свой уникальный идентификатор, и окончания могут обмениваться информацией, только находясь в одном и том же контексте.
Атрибутами контекста являются: идентификатор контекста ContextID, топология контекста (кто кому передает и от кого принимает информацию), приоритет (один из 16 уровней), индикатор «аварийного вызова» (высший приоритет в обслуживании). Протокол имеет средства, чтобы управлять параметрами контекста.
Megaco/H.248 определяет восемь команд, которые обеспечивают возможность управлять и манипулировать контекстами и окончаниями. Большинство команд предназначено для того, чтобы передаваться из Softswitch в транспортные шлюзы MG, за исключением команд Notify и ServiceChange. Рассмотрим эти 8 команд подробнее.
Команда Add (добавить). С ее помощью Softswitch дает указание шлюзу добавить окончание к контексту. Если команда Add не указывает контекст, куда добавляется окончание, то создается новый контекст. Если в команде не указан определенный TerminationID, а использован символ группового выбора ($), MG создаст новое виртуальное окончание и добавит его в контекст.
Командой Modify (изменить) Softswitch дает указание шлюзу изменить свойства окончания. Команда Modify изменяет значения свойств окончания, приказывает окончанию отправить один или несколько сигналов или обнаруживать определенные события и докладывать о них.
Команда Subtract (исключить) удаляет окончание из контекста. Ответ на команду может содержать статистические данные, относящиеся к участию окончания в контексте. Эти данные зависят от типа оконечного устройства. Для окончания RTP-статистические данные могут включать в себя сведения о переданных пакетах, о полученных пакетах, о джиттере и т.п. В этом отношении команда Subtract аналогична команде DLCX протокола MGCP.
Команда AuditValue (проверить значение) используется Softswitch для поиска текущих значений свойств, событий и сигналов, ассоциированных с одним или несколькими окончаниями.
Команда AuditCapabilities (проверить возможности) используется Softswitch для поиска возможных значений свойств, событий и сигналов, ассоциированных с одним или несколькими окончаниями. На первый взгляд, эта команда может показаться очень похожей на команду AuditValue. Разница между ними заключается в том, что команда AuditValue используется для определения текущего состояния окончания, в то время как команда AuditCapabilities позволяет определять состояния, которые окончание может принимать. Например, AuditValue будет указывать любые сигналы, подаваемые окончанием в данный момент, а AuditCapabilities может указать все возможные сигналы, которые окончание может подавать в случае необходимости.
Команда Notify (уведомить) передается MG для того, чтобы информировать Softswitch о событиях, которые произошли в транспортном шлюзе. По поводу событий, о которых необходимо сообщать, обычно предварительно приходит запрос в составе команды из Softswitch в MG, например, в команде Modify. События, о которых сообщается, обычно сопровождаются параметром RequestedID, чтобы Softswitch мог увязать эти события с ранее переданными запросами.
Команда ServiceChange (изменение обслуживания) позволяет MG информировать Softswitch о предстоящем выводе из обслуживания или возврате в обслуживание группы окончаний. Команда используется также в ситуации, когда Softswitch передает управление некоторым транспортным шлюзом другому Softswitch. В этом случае команда сначала передается из Softswitch в MG, чтобы инициировать передачу управления, а затем MG передает команду ServiceChange в новый Softswitch для установления новых взаимоотношений.
Общий формат дескриптора выглядит следующим образом:
Дескриптор модема, Modem, специфицирует тип модема и связанные с ним параметры, которые следует использовать в соединениях модема при передаче аудио, видео или данных. Определены следующие типы модемов: V.18 (текстовая телефония), V.22 (1200 б/с), V.22bis (2400 б/с), V.32 (9600 б/с), V.32bis (14400 б/с), V.34 (33600 б/с), V.90 (56 Кб/с), V.91 (64 Кб/с) и синхронная ISDN. По умолчанию окончание не имеет дескриптора модема. Иначе говоря, при начале работы окончания никакие свойства его модема не задаются. Они могут задаваться позже, в результате передачи команды Add или Modify из Softswitch в MG.
Дескриптор модема был включен в первую версию спецификации Megaco RFC 3015, а в синтаксис версии 2 он включен только затем, чтобы обеспечить обратную совместимость. Т.о., в следующих версиях протокола этот дескриптор не используется, и при приеме его необходимо игнорировать.
Дескриптор мультиплексирования, Mux, характеризует тип мультиплексирования в мультимедийном терминале. Протокол поддерживает типы мультиплексирования: H.211, H.223, H.226. V.76 и Nx64K.
Локальный дескриптор управления Локальный дескриптор Удаленный дескриптор
Дескриптор состояния окончания, TerminationState, содержит сведения о двух характеристиках окончания: ServiceStates и EventBufferControl, а также сведения о ряде других характеристик, которые к медиа-потокам отношения не имеют.
Характеристика ServiceStates указывает, доступно ли окончание для использования. Она может иметь три значения: тестирование, вне обслуживания и в обслуживании. Значение в обслуживании не означает, что в данный момент окончание принимает участие в связи, а указывает, что окончание либо активно участвует в ней, либо может быть использовано для ее создания. Значение в обслуживании устанавливается по умолчанию.
Характеристика EventBufferControl указывает, следует ли сведения об обнаруженных окончанием событиях помещать в буфер или их надо немедленно обрабатывать. Вначале окончание докладывает о событиях, извещение о которых заказал Softswitch с помощью команды, содержащей EventsDescriptor. Будет ли окончание фактически докладывать об указанных в EventsDescriptor событиях, зависит от того, установлена ли EventBufferControl в состояние off (выключено) или в состояние lockstep (жесткой конфигурации). Если установлено off, окончание немедленно доложит об обнаруженном событии. Если установлено lockstep, данные о событии будут помещены в буфер с дисциплиной FIFO (первым вошел, первым обслужен). Содержимое буфера проверяется при получении нового EventsDescriptor, указывающего, какие события должно обнаруживать окончание. Включение EventBufferControl в состав Term inationStateDescriptor позволяет Softswitch включать или выключать немедленное уведомление о событиях и не передавать каждый раз EventsDescriptor без необходимости.
Дескриптор состояния окончания является необязательным.
Дескрипторы потока, Stream. Поток определяется дескрипторами LocalControlDescriptor, Local Descriptor RemoteDescriptor и идентифицируется с помощью StreamID. Значения StreamID используются между MG и Softswitch, чтобы указывать, какие медиа- потоки взаимосвязаны. В пределах одного контекста потоки с одним и тем же StreamID соединены. Поток создается определением в контексте нового StreamID в окончании. Поток удаляется с помощью установки пустого локального или удаленного дескриптора и установки значений ReserveGroup и ReserveValue в подчиненном LocalControlDescriptor в логическое значение false.
Дескриптор LocalControlDescriptor содержит сведения об особых характеристиках медиа-потока, в частности, о характеристиках Mode, ReserveGroup и ReserveValue.
Характеристика Mode (режим) может принимать одно из следующих значений: только передача, только прием, передача/прием, неактивный или закольцован. Направления передачи и приема определяются по отношению к внешней стороне контекста. Если установлен режим только передача, окончание может только передавать информацию в объекты за пределами контекста. Окончание не может пропускать информацию в другие логические объекты того же контекста. Если установлен режим только прием, окончание может только принимать информацию извне контекста и пропускать ее в другие окончания контекста, но не может принимать информацию от других окончаний и пропускать ее адресатам за пределами контекста. Когда Softswitch хочет добавить окончание в контекст, он может специфицировать набор вариантов для сеанса (используя локальные и удаленные дескрипторы), которые Softswitch предпочитает для использования в MG, причем специфицирует их в порядке предпочтительности. MG не обязан выбрать первый из предлагаемых Softswitch вариантов, но может быть обязан резервировать ресурсы для сеанса, указанного Softswitch.
ReserveValue и ReserveGroup указывают, какие ресурсы должны быть резервированы для вариантов, специфицированных Softswitch в LocalDescriptor и RemoteDescriptor.
Local Descriptor и RemoteDescriptor могут специфицировать несколько характеристик и/или групп характеристик. Например, описание SDP может указывать две группы характеристик: одну для G.711 A-закона и одну для G.729. Если логическое значение ReserveGroup равно true (истина), то MG должен резервировать ресурсы для одной из этих групп характеристик. ReserveValue используется аналогично, но применяется с целью резервирования ресурсов для одной определенной характеристики, а не для группы характеристик.
Дескрипторы LocalDescriptor и RemoteDescriptor содержат или не содержат несколько описаний сеансов SDP, описывающих сеанс на локальном и удаленном концах соединения, соответственно. Использование SDP согласно Megaco имеет некоторые отклонения от строгого синтаксиса SDP, как он специфицирован в документе RFC 2327. В частности, строки s=, t= и o= являются опциональными, знак группового выбора ($) разрешен, допускается указывать несколько альтернативных значений параметра в тех местах, где обычно должно использоваться одно значение. И LocalDescriptor, и RemoteDescriptor могут содержать несколько описаний сеансов.
Дескриптор проверки, Audit Descriptor, задает перечень информации, которую необходимо передавать из MG в Softswitch. Дескриптор проверки является просто списком других дескрипторов, которые должны переноситься в ответе. В их число могут входить дескрипторы: мультиплексирования, событий, сигналов, ObservedEvents, DigitMap, статистических данных и EventBuffer.
Дескриптор ServiceChangeDescriptor используется только в сочетании с командой ServiceChange и включает в себя такую информацию, как тип изменения обслуживания, которое произошло или должно произойти, причина изменения обслуживания и новый адрес для использования после изменения обслуживания.
Тип изменения обслуживания определяется параметром ServiceChangeMethod, который может принимать одно из следующих значений: Graceful, Forced, Restart, Disconnected, Handoff, Failover (постепенное, принудительное, перезапуск, отключено, передача управления, неисправность). Graceful указывает выведение окончаний из обслуживания после заданной задержки и без прерывания существующих соединений. Forced указывает внезапное, резкое выведение из обслуживания с потерей существующих соединений. Restart указывает, что восстановление обслуживания начнется после заданной задержки. Disconnected применяется ко всему MG и указывает, что соединение с Softswitch разрушено, но будет восстановлено. Softswitch может передавать команду Audit для проверки того, что характеристики оконечного устройства не изменились за время потери контакта. Handoff передается из Softswitch в MG, чтобы указать, что Softswitch выводится из обслуживания и управление принимает новый Softswitch. Значение Handoff передается также из MG в новый Softswitch во время попытки установить контакт после приема handoff от предыдущего Softswitch. Failover передается из MG в Softswitch, если MG обнаружил неисправность и производится переключение на резервный MG.
Параметр ServiceChangeDelay определяет длительность используемой задержки в секундах. Его необходимо передавать, например, в сочетании с изменением обслуживания типа Graceful. Если параметр отсутствует, или имеет значение ноль, задержки не происходит. В случае изменения обслуживания по типу Graceful нулевое значение указывает, что Softswitch должен ждать естественного удаления оконечных устройств из их контекста; т.е. ждать, когда сеансы связи с использованием указанных окончаний завершатся по инициативе их участников. Параметр ServiceChange Reason, как и следует из его названия, указывает причину изменения обслуживания.
Дескриптор DigitMap является описанием плана нумерации. Иначе говоря, DigitMap специфицирует множество разрешенных для набора комбинаций цифр. Оно хранится в MG, так что тот может передавать принятые цифры в Softswitch блоками, а не по одной. План нумерации может быть загружен в MG средствами эксплуатационного управления или из Softswitch по командам Megaco. Если план загружается из Softswitch, то чтобы переправить информацию, используется дескриптор DigitMap.
Дескриптор StatisticsDescriptor содержит информацию, которая относится к использованию окончания в данном контексте.
Особенности статистических данных, которые должны передаваться по запросу, зависят от типа окончания. Строго говоря, этот дескриптор всегда является опциональным и может передаваться при удалении окончания из контекста по команде Subtract или в ответ на команду AuditValue.
Дескриптор Observed Events является обязательным параметром в команде Notify, где он используется для того, чтобы информировать Softswitch о событиях, которые были обнаружены. В большинстве остальных ответов на команды этот дескриптор является необязательным, кроме ServiceChange. При использовании в ответе на команду AuditValue он предназначен для передачи информации о событиях, которые записаны в буфере событий и еще не известны Softswitch. Дескриптор содержит Requestldentifier со значением, которое согласовано с принятым в дескрипторе событий списком таких событий, которые должны быть обнаружены в первую очередь. Этим обеспечивается увязка запрашиваемых данных о событиях и данных о событиях в сообщениях.
Дескриптор опционально допускает включение в него временных меток с указанием момента обнаружения каждого наблюдаемого события. Эта временная метка структурируется в виде yyyymmddThhmmssss, где записываются сотни секунд. Буква T отделяет год, месяц и день от часа, минуты и секунд. Сама временная метка отделяется от описания соответствующего события двоеточием.
Дескриптор Error передается в ответе, когда не может быть выполнена команда. Он может быть также включен в команду Notify, передаваемую из MG в Softswitch. Дескриптор ошибок состоит из кода ошибки и текстового описания ошибки, опционально сопровождающего этот код.
Если в контексте используется более двух окончаний, то требуется более одной тройки. Например, если используется три оконечных устройства (о1, о2 и о3), то в описании топологии нужны три тройки: для связи между о1 и о2, для связи между о1 и о3 и для связи между о2 и о3. Дескриптор топологии может быть полезным инструментом для реализации таких услуг как вызов с предварительным заказом или конференцсвязь с возможностью части ее участников провести отдельные разговоры перед возвращением в общую группу. По умолчанию характеристики всех дескрипторов, за исключением дескриптора состояния окончания и дескриптора локального управления, являются пустыми.
Команды, передаваемые между Softswitch и MG, группируются в структуры, которые устроены так, что за набором команд, относящихся к одному контексту, может следовать набор команд, относящихся к другому контексту. Сгруппированные команды передаются вместе в едином блоке TransactionRequest. Это можно представить так:
После приема TransactionRequest получатель выполняет вложенные команды. Команды выполняются последовательно, в том порядке, в каком они указаны в TransactionRequest. После выполнения всех команд передается ответ TransactionReply. Он имеет структуру, аналогичную структуре TransactionRequest в том смысле, что содержит несколько ответов для нескольких контекстов. TransactionReply можно представить так:
Если получателю TransactionRequest потребуется некоторое время для выполнения запроса, он может передать отправителю этого запроса предварительный ответ, чтобы тот не считал запрос потерянным. Этот предварительный ответ TransactionPending извещает, что TransactionRequest принят и в данный момент обрабатывается. Такой ответ содержит принятый TransactionID без каких-либо параметров:
Параметр normalMGExecutionTime определяет интервал времени, в течение которого контроллер ожидает получение ответа от шлюза. Аналогичный параметр normalSoftswitchExecutionTime определяет время ожидания шлюзом ответа от контроллера.
Для ограничения времени ожидания используется пара параметров MGOriginatedPendingLimit и SoftswitchOriginatedPendingLi- mit; она определяет предельно допустимое количество получаемых извещений TransactionPending. По достижении указанного предела передается либо ответ, либо извещение об ошибке транзакции.
6.4.9. Наборы сигналов и событий
Шлюзы разных типов могут использовать окончания с сильно различающимися характеристиками. Чтобы обеспечить возможность взаимодействия MG и Softswitch, протокол Megaco определяет типовые наборы packages) характеристик, сигналов и событий для Softswitch и шлюзов разных типов. Softswitch может запросить у шлюза сведения, необходимые, чтобы знать, с какими из таких наборов он может работать. Определяемые в наборе характеристики, события, сигналы или статистические данные, а также их параметры снабжаются идентификаторами. Для каждого набора идентификаторы перечисленных объектов имеют уникальные области имен, и в каждой из областей могут использоваться одинаковые идентификаторы, например, два идентификатора propertyID в разных наборах могут быть одинаковыми. Типовой набор характеризуется базовым описанием, свойствами, предусматриваемыми событиями, поддерживаемыми сигналами, предоставляемыми статистическими данными, годными для интерпретации и анализа, любыми процедурами, относящимися к надлежащей поддержке набора. Он содержит следующие разделы.
 Рис. 6.5. Структура сообщений H.248/Megaco |
Типовой набор характеризуется базовым описанием, свойствами, предусматриваемыми событиями, поддерживаемыми сигналами, предоставляемыми статистическими данными, годными для интерпретации и анализа, любыми процедурами, относящимися к надлежащей поддержке набора. Он содержит следующие разделы.
Раздел Package содержит общее описание набора, определяющее его имя, идентификатор (PackagelD), текстовое описание, версию, и опциональные поля, определяющие, что набор предусматривает наличие расширения и/или что он сам является расширением уже существующего.
Раздел Properties определяет свойства (характеристики) набора и содержит имя каждого свойства, его идентификатор (propertylD), текстовое описание, тип (логическая переменная, символьная, целочисленная и т.д.), возможные значения, специфицирующие свойство и характеристики (только чтение или только запись, чтение/запись).
Раздел Events определяет события и содержит имя события, его идентификатор (eventID), текстовое описание, параметры дескриптора Events и параметры дескриптора ObservedEvents.
Раздел Signals определяет сигналы, имя и идентификатор каждого из них (signalID), его текстовое описание, тип (on/off, timeout, brief), продолжительность в сотых долях секунды и дополнительные параметры, которые мы опишем ниже.
Раздел Statistics определяет статистические данные, содержит имя и идентификатор данных каждого вида (statisticID), их текстовое описание, единицы измерения (т.е. миллисекунды, количество пакетов и т.д.).
Процедуры Procedures определяют дополнительные аспекты использования набора. Параметры событий и сигналов определяются именем параметра и его идентификатором (parameterID), типом (например, логическая, символьная или целочисленная переменная и т.д.), возможными значениями переменных, текстовыми описаниями. В базовой спецификации протокола Megaco/H.248 определены 13 типовых наборов, содержание которых сведено в табл. 6.4.
