Протокол Megaco/H.248

6.4.1. Особенности Megaco/H.248

Этот протокол известен в комитете IETF под названием Megaco (MEdia GAteway COntrol Protocol), а в Международном союзе элек­тросвязи ITU - под названием H.248. Протокол Megaco/K248 во многом архитектурно схож с MGCP. Подобно MGCP, он определяет транспортные шлюзы MG, которые преобразуют информацию из формата, принятого в одной сети, в формат, необходимый в другой сети, и контроллеры транспортных шлюзов MGC или Softswitch, которые управляют установлением соединений и их отменой в пре­делах шлюзов MG. Едва ли стоит удивляться сходству протоколов, учитывая тот факт, что оба они были разработаны с учетом анало­гичного набора требований.

Для переноса сигнальных сообщений Megaco/H.248 может использоваться протокол UDP, протокол TCP, протокол SCTP или транспортная технология АТМ. Поддержка для этих целей протоко­ла UDP - обязательное требование только к контроллеру шлюзов, протокол TCP должен поддерживаться и контроллером, и транспор­тным шлюзом, а поддержка протокола SCTP, как и технологии АТМ, является необязательной.

Еще одной особенностью протокола Megaco/H.248 является то, что сообщения этого протокола могут кодироваться двумя спо­собами. Комитет IETF предложил текстовый способ кодирования сигнальной информации, а для описания сеанса связи предложил использовать протокол SDP. Кодирование текста пишется в соот­ветствии с формами Бэкуса-Наура ABNF (Augmented Backus-Naur Form), описанными одним из авторов в главе 2 книги [4]. В свою очередь, ITU-T предусматривает бинарный способ представления сигнальной информации на языке ASN.1 (Abstract Syntax Notation One), рассмотренным в рекомендации ITU-T X.680 от 1997 года, а для описания сеансов связи рекомендует специальный инстру­мент - схему TLV(тип-длина-значение), подробно обсуждавшуюся авторами в их предыдущей книге [3].

В результате, спецификация 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. Модель обслуживания вызова

Описание алгоритма установления соединения с использовани­ем протокола Megaco опирается на модель процесса обслуживания вызова, отличную от рассмотренной в предыдущем параграфе мо­дели MGCP. В своей модели процесса обслуживания вызова про­токол Megaco оперирует двумя логическими объектами: окончание или порт (termination) и контекст (context). Мы можем рассматри­вать окончание (порт) как логический объект транспортного шлюза или IAD, который может являться источником и приемником муль­тимедийной информации, во многом аналогичным порту (endpoint) протокола MGCP. Контекст - это отображение логической связи между несколькими портами; например, все порты, участвующие в конференции, составляют единый контекст, т.е. находятся внутри одного контекста. Таким образом, контекст является абстрактным представлением более высокого уровня, чем MGCP, и в некотором смысле, включает в себя понятие «сеанс связи». Как мы увидим, в алгоритме установления соединения с помощью протокола Megaco, представленном для шлюза типа Residential Gateway, порт (окончание), соответствующий физическому устройству (напри­мер, телефонному аппарату), входит в тот же контекст, что и логи­ческое RTP-соединение, для того чтобы обеспечить отображение двусторонней мультимедийной связи. Контекст имеет локальное значение, т.е. действителен для одного транспортного шлюза. Существует особый вид контекста - нулевой (null). В него по умол­чанию входят все порты, которые не связаны ни между собой, ни с другими портами.

6.4.3. Окончания

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

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

Виртуальные окончания существуют только в течение разго­ворного сеанса, являются интерфейсами со стороны IP-сети (на­пример, RTP-окончания), через которые ведутся передача и прием пакетов. Виртуальные окончания создаются шлюзом при получении от Softswitch команды Add и ликвидируются при получении команды Subtract, тогда как физические окончания при получении команды Add или Subtract, соответственно, выводятся из нулевого контекста или возвращаются обратно в нулевой контекст.

Окончания имеют различные свойства. Очевидно, например, что подключенное к аналоговой линии окончание имеет не такие характеристики, как окончание, подключенное к цифровому каналу 64 Кбит/с. Свойства окончания определяются набором дескрипто­ров, включаемых в состав команд Megaco, что позволяет изменять свойства оконечных устройств в соответствии с указаниями, пере­даваемыми из Softswitch в MG.

Соответственно, каждое окончание имеет уникальный иденти­фикатор TerminationID, который назначается шлюзом при конфигу­рации порта. Идентификаторы физических окончаний формируют­ся непосредственно в транспортном шлюзе. Например, идентифи­катором порта может служить номер тракта E1 и номер временного канала внутри тракта. Иногда команды могут относиться ко всему шлюзу, тогда используется общий идентификатор окончаний Root. Используется также и механизм групповых символов wildcard: ALL и CHOOSE. Первый позволяет адресоваться к нескольким оконча­ниям одновременно, а второй - предоставить шлюзу право выбора подходящего окончания. К тому же, окончания обладают рядом изначальных свойств (properties), каждое из которых тоже имеет уникальный идентификатор propertylD. Например, окончания могут обладать способностью генерировать речевые подсказки, акус­тические и вызывные сигналы, а также выявлять сигналы DTMF Некоторые свойства окончаний присваиваются им по умолчанию при создании, а при помощи команд протокола Megaco/H.248 эти свойства можно изменять. Описанию команд посвящен п. 6.4.5 этого параграфа. Сами свойства окончаний определяются вклю­чаемыми в команды Megaco/H.248 дескрипторами, которые опи­сываются в п. 6.4.6. Окончания, как только что упоминалось, могут генерировать и передавать сигналы и быть запрограммированы на обнаружение событий, при возникновении которых транспортный шлюз должен будет передать извещение к Softswitch или выполнить определенные действия. В окончании могут накапливаться статис­тические данные и потом передаваться по запросу и/или при удале­нии окончания из контекста.

6.4.4. Контекст

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

Существует особый вид контекста - нулевой. Все окончания, входящие в нулевой контекст, не связаны ни между собой, ни с дру­гими портами. Для рассматриваемой модели обслуживания вызовов окончание в нулевом контексте является абстрактным представлени­ем свободного (не занятого) канала. В общем случае для присоеди­нения окончания к контексту служит команда Add. Если команда Add не указывает контекст, в который должно быть добавлено окончание, в результате выполнения команды Add создается новый контекст. Это единственный механизм для создания нового контекста. Окончание переводится из одного контекста в другой с помощью команды Move, а удаляется из контекста с помощью команды Subtract. Если в результате выполнения команды Subtract из контекста удаляется последнее окончание, этот контекст стирается.

Атрибутами контекста являются: идентификатор контекста ContextID, топология контекста (кто кому передает и от кого при­нимает информацию), приоритет (один из 16 уровней), индикатор «аварийного вызова» (высший приоритет в обслуживании). Прото­кол имеет средства, чтобы управлять параметрами контекста.

6.4.5. Команды

Megaco/H.248 определяет восемь команд, которые обеспечива­ют возможность управлять и манипулировать контекстами и окон­чаниями. Большинство команд предназначено для того, чтобы передаваться из Softswitch в транспортные шлюзы MG, за исклю­чением команд Notify и ServiceChange. Рассмотрим эти 8 команд подробнее.

Команда Add (добавить). С ее помощью Softswitch дает указание шлюзу добавить окончание к контексту. Если команда Add не ука­зывает контекст, куда добавляется окончание, то создается новый контекст. Если в команде не указан определенный TerminationID, а использован символ группового выбора ($), MG создаст новое виртуальное окончание и добавит его в контекст.

Командой Modify (изменить) Softswitch дает указание шлюзу изменить свойства окончания. Команда Modify изменяет значения свойств окончания, приказывает окончанию отправить один или несколько сигналов или обнаруживать определенные события и до­кладывать о них.

Команда Subtract (исключить) удаляет окончание из контекста. Ответ на команду может содержать статистические данные, относя­щиеся к участию окончания в контексте. Эти данные зависят от типа оконечного устройства. Для окончания RTP-статистические данные могут включать в себя сведения о переданных пакетах, о получен­ных пакетах, о джиттере и т.п. В этом отношении команда Subtract аналогична команде DLCX протокола MGCP.

Команда Move (переместить) перемещает окончание из одного контекста в другой. Она не используется для перемещения окон­чания из нулевого контекста или в него, поскольку эти операции должны выполняться командами Add и Subtract, соответственно. Возможность перемещать окончание из одного контекста в дру­гой - это полезный инструмент для реализации услуги «вызов с ожиданием».

Команда 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 для установления новых взаимо­отношений.

6.4.6. Дескрипторы

Megaco/H.248 определяет ряд дескрипторов, предназначенных для использования вместе с командами и ответами. Эти дескрип­торы образуют параметры команды и/или ответа и содержат до­полнительную информацию об их свойствах. В зависимости от ко­манды или ответа тот или иной дескриптор бывает обязательным, запрещенным или опциональным. В большинстве случаев, если де­скриптор не является обязательным, он - опциональный. Случаев, когда дескриптор является запрещенным, относительно мало.

Общий формат дескриптора выглядит следующим образом:

Descriptorname=<someID>{parm=value, parm=value,... }

Дескриптор модема, 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.

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

Дескриптор среды

Дескриптор потока

Локальный дескриптор управления Локальный дескриптор Удаленный дескриптор

Дескриптор состояния окончания, 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 могут содержать несколько описаний сеансов.

Дескриптор событий, Events, содержит Requestldentifier и спи­сок событий, которые MG должен обнаруживать и про которые со­общать (переход в состояние трубка поднята, тональный сигнал факса и пр.). Назначение Requestldentifier - увязывать запросы и последующие сообщения. Обычно сообщения об обнаруженных событиях немедленно передаются в Softswitch. Однако, в зависи­мости от значения EventControlBuffer (которое является специфи­цируемым в TerminationStateDescriptor), сведения о событиях могут и записываться в буфер. Когда события записываются в буфер, и затем о них должно сообщаться в Softswitch, то связанная с этими событиями информация хранится в EventBufferDescriptor.

Дескриптор сигналов, Signals, содержит список сигналов, ко­торые должно подавать окончание. Сигналы могут подаваться толь­ко одному потоку или всем потокам в окончании. В состав типичных сигналов могут входить, например, такие подаваемые в абонент­скую линию акустические сигналы, как ответ станции или контроль посылки вызова. Существуют сигналы трех типов: On/off - сигнал остается включенным (on) до тех пор, пока явно не будет выключен (off), Timeout - сигнал сохраняется до тех пор, пока не истечет оп­ределенный период времени или пока не будет выключен еще до истечения заданного времени, Краткий - сигнал должен подаваться только на очень короткое время, как в случае многочастотных сиг­налов в соединительных линиях с сигнализацией R1.5. Дескриптор сигналов может включать в свой состав логическую последова­тельность сигналов, которые необходимо воспроизводить друг за другом.

Дескриптор проверки, 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.

С точки зрения синтаксиса DigitMap является строкой или спис­ком строк, причем каждая строка состоит из ряда символов, пред­ставляющих собой цифры от 0 до 9 и буквы от A до K. Букву X можно использовать как групповой символ, обозначающий любую цифру от 0 до 9, а символ «точка» (.) используется для указания нуля или нескольких повторений непосредственно предшествовавшей циф­ры или строки цифр. Этот символ можно использовать для указа­ния номера с длиной, не определенной в плане нумерации. Кроме того, строка может содержать три символа, определяющих запуск таймера (T), короткого таймера (S) и длинного таймера (L). Чтобы понять назначение этих таймеров, рассмотрим, что происходит, когда абонент поднимает трубку обычного телефонного аппарата, чтобы вызвать станцию. АТС обнаруживает вызов, подает сигнал «Ответ станции» и готовится к приему первой цифры номера, вклю­чая таймер ожидания этой цифры (порядка 30 секунд). Если цифра не поступит в течение этого времени, АТС определит срабатывание таймера и передаст абоненту зуммер «Занято». Это - таймер T. Когда абонент начал набирать номер, запускается межцифровой таймер. Этот таймер бывает или коротким таймером S, или длин­ным таймером L, в зависимости от плана нумерации. Если абонент набрал некоторое количество цифр, а АТС нужно больше цифр для маршрутизации вызова, при ожидании следующей цифры обычно применяется короткий таймер. Кроме того, в АТС запускается тай­мер ограничения длительности непроизводител ьного занятия до момента получения сигнала «Ответ» от вызываемого абонента [т1], для чего применяется длинный таймер L.

Дескриптор StatisticsDescriptor содержит информацию, ко­торая относится к использованию окончания в данном контексте.

Особенности статистических данных, которые должны переда­ваться по запросу, зависят от типа окончания. Строго говоря, этот дескриптор всегда является опциональным и может передаваться при удалении окончания из контекста по команде Subtract или в от­вет на команду AuditValue.

Дескриптор Observed Events является обязательным пара­метром в команде Notify, где он используется для того, чтобы ин­формировать Softswitch о событиях, которые были обнаружены. В большинстве остальных ответов на команды этот дескриптор яв­ляется необязательным, кроме ServiceChange. При использовании в ответе на команду AuditValue он предназначен для передачи ин­формации о событиях, которые записаны в буфере событий и еще не известны Softswitch. Дескриптор содержит Requestldentifier со значением, которое согласовано с принятым в дескрипторе со­бытий списком таких событий, которые должны быть обнаружены в первую очередь. Этим обеспечивается увязка запрашиваемых данных о событиях и данных о событиях в сообщениях.

Дескриптор опционально допускает включение в него времен­ных меток с указанием момента обнаружения каждого наблю­даемого события. Эта временная метка структурируется в виде yyyymmddThhmmssss, где записываются сотни секунд. Буква T отде­ляет год, месяц и день от часа, минуты и секунд. Сама временная мет­ка отделяется от описания соответствующего события двоеточием.

Дескриптор Error передается в ответе, когда не может быть выполнена команда. Он может быть также включен в команду Notify, передаваемую из MG в Softswitch. Дескриптор ошибок состоит из кода ошибки и текстового описания ошибки, опционально сопро­вождающего этот код.

Дескриптор топологии Topology отличается от других де­скрипторов в том смысле, что он соответствует только контексту, а не определенному окончанию в контексте. Назначение дескрип­тора - указать, как должны протекать в контексте медиа-потоки, т.е. кто и кого должен слышать или видеть. По умолчанию все оконча­ния в контексте могут передавать и принимать информацию друг от друга. Если желательна другая ситуация, то используется дескрип­тор топологии.

Дескриптор состоит из последовательности троек объектов вида окончание1 - окончание2 - соединение. Такая тройка указывает, существует или нет поток между двумя окончаниями (isolate), дол­жен ли этот поток быть односторонним (oneway) или двусторонним (bothway). Порядок, в котором оконечные устройства появляются в тройке, имеет значение: например, тройка о1-о2-oneway озна­чает, что окончание1 может передавать информацию в окончание2, но окончание2 не может передавать информацию в окончание1.

Если в контексте используется более двух окончаний, то требуется более одной тройки. Например, если используется три оконечных устройства (о1, о2 и о3), то в описании топологии нужны три тройки: для связи между о1 и о2, для связи между о1 и о3 и для связи между о2 и о3. Дескриптор топологии может быть полезным инструментом для реализации таких услуг как вызов с предварительным заказом или конференцсвязь с возможностью части ее участников провес­ти отдельные разговоры перед возвращением в общую группу. По умолчанию характеристики всех дескрипторов, за исключением дескриптора состояния окончания и дескриптора локального уп­равления, являются пустыми.

6.4.7. Транзакции

Команды, передаваемые между Softswitch и MG, группируются в структуры, которые устроены так, что за набором команд, относя­щихся к одному контексту, может следовать набор команд, относя­щихся к другому контексту. Сгруппированные команды передаются вместе в едином блоке TransactionRequest. Это можно представить так:

TransactionRequest (TransactionID {

ContextID1 {Command, Command,... Command}, ContextID2 {Command, Command,... Command}, ContextID3 {Command, Command,... Command} })

После приема TransactionRequest получатель выполняет вложен­ные команды. Команды выполняются последовательно, в том по­рядке, в каком они указаны в TransactionRequest. После выполнения всех команд передается ответ TransactionReply. Он имеет структуру, аналогичную структуре TransactionRequest в том смысле, что содер­жит несколько ответов для нескольких контекстов. TransactionReply можно представить так:

TransactionReply (TransactionID {

ContextID1 {Response, Response,... Response }, ContextID2 { Response, Response,... Response }, ContextID3 { Response, Response,... Response } })

Если получателю TransactionRequest потребуется некоторое вре­мя для выполнения запроса, он может передать отправителю этого запроса предварительный ответ, чтобы тот не считал запрос поте­рянным. Этот предварительный ответ TransactionPending извещает, что TransactionRequest принят и в данный момент обрабатывается. Такой ответ содержит принятый TransactionID без каких-либо пара­метров:

TransactionPending (TransactionID {.})

Параметр normalMGExecutionTime определяет интервал вре­мени, в течение которого контроллер ожидает получение ответа от шлюза. Аналогичный параметр normalSoftswitchExecutionTime определяет время ожидания шлюзом ответа от контроллера.

Для ограничения времени ожидания используется пара пара­метров MGOriginatedPendingLimit и SoftswitchOriginatedPendingLi- mit; она определяет предельно допустимое количество получаемых извещений TransactionPending. По достижении указанного предела передается либо ответ, либо извещение об ошибке транзакции.

6.4.8. Сообщения

Несколько транзакций протокола могут помещаться в сообще­ние. Сообщение снабжается заголовком, идентифицирующим от­правителя. Идентификатором сообщения MID (Message Identifier) служит назначенное имя (например, доменовый адрес/доменовое имя/имя устройства) объекта, передающего сообщение. По умол­чанию предлагается использовать доменовое имя. Объекты прото­кола Megaco/H.248 (как MG, так и Softswitch) должны использовать один и тот же MID во всех создаваемых ими сообщениях в течение всего времени взаимодействия между ними. Каждое сообщение содержит номер версии протокола, создавшего сообщение. Для версии отводится два разряда. Текущая версия протокола - 2. Транзакции в пределах сообщения обрабатываются независимо. Порядок транзакций в сообщении не влияет на порядок, в котором их должен обрабатывать получатель сообщения. Заметим, что этот порядок отличается от порядка обработки команд в пределах тран­закции, где очередность команд имеет значение.

Сообщение Megaco/H.248 - это, по сути, только транспортный механизм, в отличие от сообщений многих других сетевых протоко­лов. Общая структура сообщения представлена на рис. 6.5.

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), продолжительность в сотых долях секунды и дополнительные параметры, которые мы опишем ниже.

10. Б.С. Гольдштейн

Раздел Statistics определяет статистические данные, содержит имя и идентификатор данных каждого вида (statisticID), их тексто­вое описание, единицы измерения (т.е. миллисекунды, количество пакетов и т.д.).

Процедуры Procedures определяют дополнительные аспекты использования набора. Параметры событий и сигналов опреде­ляются именем параметра и его идентификатором (parameterID), типом (например, логическая, символьная или целочисленная пе­ременная и т.д.), возможными значениями переменных, текстовы­ми описаниями. В базовой спецификации протокола Megaco/H.248 определены 13 типовых наборов, содержание которых сведено в табл. 6.4.

Таблица 6.4. Типовые наборы Название набора Описание Общий (Generic) Идентификатор: g Пример синтаксиса: g/ События причина (cause) 1. NR - нормальное разъединение 2. UR - недоступны ресурсы 3. FT - временный отказ 4. FP - систематический (устойчивый) отказ 5. IW - ошибка взаимодействия 6. UN - не поддерживается Окончание сигнала (sc) 1. TO - истекла заданная выдержка времени 2. EV - прерван обнаруженным событием 3. SD - остановлен новым дескриптором сигнала 4. NC - не окончен по другой причине Общий набор не задает никаких характеристик, сигналов или видов статистических данных Основной (Base Root) Идентификатор: root Пример синтаксиса: root/ Характеристики 1. MaxNrOfContexts (Максимальное число контекстов) 2. MaxTerminationsPerContext (Максимальное число пор­тов на контекст) 3. NormalMGExecutionTime (Нормальное время работы MG на типовом этапе) 4. NormalSoftswitchExecutionTime (Нормальное время работы Softswitch на типовом этапе) 5. ProvisionalResponseTimerValue (Предварительное зна­чение таймера ответа) В основном наборе отсутствуют процедуры, статистические данные, сигналы или события. Все значения времени работы Softswitch на типовых этапах относятся к ответам на команды и к стандартному времени, требуемому контроллеру для ответа на команду. В не мас­штабируемых платформах, которые не могут гарантировать независимость времени реакции системы от нагрузки, эти величины следует устанавливать очень тщательно

Продолжение табл. 6.4 Название набора Описание Набор для генератора то­нальных сигналов(Tone Generator Package) Идентификатор: tonegen Пример синтаксиса: tonegen/ Сигналы 1. pt (tl, ind) определяет воспроизводимый тональный сигнал (характеристика сигнала, длительность пау­зы между сигналами). Не определено никаких характеристик, статистических данных, процедур или событий Набор для детектора то­нальных сигналов(Tone Detection Package) Идентификатор: tonedet Пример синтаксиса: tonedet/ События 1. std (tl,tid) - событие обнаружения начала сигнала Start Tone Detected (идентификатор сигнала) 2. etd (tl,tid,dur) - событие обнаружения конца сигнала End Tone Detected (идентификатор сигнала, дли­тельность) 3. ltd (tl,tid,dur) - событие обнаружения длинного сиг­нала Long Tone Detected (идентификатор сигнала, длительность). Не определено никаких характеристик, сигналов, статисти­ческих данных или процедур. Набор полезен для обнаружения сигналов DTMF, а также сигналов, генерируемых факсимильными аппаратами и мо­демами Базовый набор для гене­ратора сигналов DTMF (Basic DTMF Generator Package) Идентификатор: dg Пример синтаксиса: dg/ Поддерживаемые сигналы Цифры DTMF 0-9, *, #, A-D. Кодирование, соответственно: d0-d9, ds, do, da-dd Набор для детектора сигналов DTMF (DTMF Detection Package) Идентификатор: dd Пример синтаксиса: dd/ Цифры 0-9, A-F Кодирование, соответственно: d0-d9, da-df События Завершение плана нумерации (ce) Последовательность цифр (ds) Метод прекращения (Meth) UM - непротиворечивое соответствие PM - частичное соответствие FM - полное соответствие Отсутствуют характеристики, сигналы, статистика и про­цедуры Набор для генератора акустических сигналов (Call Progress Tones Generator Package) Идентификатор: cg Пример синтаксиса: cg/ Сигналы 1. Ответ станции (dt) 2. КПВ (rt) 3. Зуммер «Занято» (bt) 4. Зуммер «Занято при перегрузке» (ct) 5. Указательный сигнал (sit) 6. Предупреждающий сигнал (wt) 7. Сигнал распознавания таксофона (pt) 8. Сигнал уведомления (cw) 9. Сигнал ожидания для вызывающего абонента (cr) Набор не определяет никаких характеристик, событий или статистических данных. Процедуры определены в E.180/Q.35

Окончание табл. 6.4 Название набора Описание Набор для контроля состоя­ния аналоговых абонентских линий (Analog Line Supervision Package) Идентификатор: al Пример синтаксиса: al/ События 1. Трубка положена (on) 2. Трубка снята (of) 3. Калиброванный разрыв шлейфа (fl) Сигналы 1. Посылка вызова (ri) Не определено никаких свойств или статистики Базовый набор для контроля целостности (Basic Continuity Package) Идентификатор: ct Пример синтаксиса: ct/ События 1. Завершение (cmp) 2. Результат (res) Сигналы 1. Сигнал контроля целостности (ct) 2. Ответный сигнал (rsp) Не определено никаких характеристик и статистических данных. Процедуры управляют взаимодействием конт­роллера (Softswitch) и транспортного шлюза для выбора метода контроля целостности соединения Сетевой набор (Network Package) Идентификатор: nt Пример синтаксиса: nt/ Характеристики Максимальный размер джиттер-буфера (jit) События 1. Сетевой отказ (netfail) 2. Причина (cs) 3. Предупреждение об ухудшении качества (qualert) Статистические данные 1. Длительность соединения (dur) 2. Число переданных байтов (oc) 3. Число принятых байтов (or) Не определено никаких процедур или сигналов Набор RTP (RTP Package) Идентификатор: rtp Пример синтаксиса: rtp События 1. Передача полезной нагрузки (pltrans) Статистические данные 1. Число переданных пакетов 2. Число принятых пакетов 3. Коэффициент потерь пакетов 4. Джиттер 5. Задержка Не определено никаких процедур, сигналов и характе­ристик Набор для каналов систем с временным уплотнением ли­ний (TDM Circuit Package) Идентификатор: tdmc Пример синтаксиса: tdmc/ Свойства 1. Эхокомпенсация (ec) 2. Регулировка усиления (gain) Не определено никаких событий, сигналов, статистичес­ких данных или процедур

Наборы опций являются одним из способов расширения фун­кциональных возможностей протокола. Все новые наборы, опре­деляемые комитетом IETF, издаются в виде отдельных документов RFC, а наборы, определяемые ITU-T, - в виде соответствующих рекомендаций H.248.x.