Управляющий канал H.245

В рекомендации ITU-T Н.245 определен ряд независимых проце­дур для управления информационными каналами. Для выполнения этих процедур между оконечными устройствами или между оконеч­ным оборудованием и устройством управления конференциями или привратником организуется управляющий канал Н.245. При этом оконечное оборудование должно создавать один (и только один) управляющий канал для каждого соединения, в котором оно участвует. Перенос управляющей информации Н.245 производится протоколом TCP по нулевому логическому каналу, который должен быть постоянно открытым с момента организации канала Н.245 и вплоть до его ликвидации. Следует отметить, что нормальные процедуры открытия и закрытия логических каналов, описываемые в этой главе, для управления нулевым логическим каналом не при­меняются.

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

Процедура определения ведущего и ведомого оборудования используется для разрешения конфликтов, возникающих между двумя устройствами при организации конференции, когда ведущим в ней может быть любое из этих устройств, или между двумя уст­ройствами, которые одновременно пытаются открыть двунаправ­ленный логический канал. Устройства обмениваются сообщениями masterSlaveDetermination, в поле terminalType которых поме­щается значение, соответствующее типу оборудования, а в поле statusDeterminationNumber - случайное число из интервала [0-(2²⁴-1)]. Ведущим становится оборудование, поместившее боль­шее число в поле terminalType, а при совпадении типов оборудова­ния - большее число в поле statusDeterminationNumber.

В ответ на полученные сообщения masterSlaveDetermination оба устройства передают сообщения masterSlaveDeterminationAck, в которых указывается, какое оборудование является для данного со­единения ведущим, а какое - ведомым.

Как правило, устройства поддерживают несколько алгоритмов кодирования и декодирования информации каждого вида, поэтому

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

В сообщение TerminalCapabilitySet включается поле capabilityTable - таблица функциональных возможностей, где каждому алгоритму кодирования/декодирования присвоен поряд­ковый номер. Например, возможности приема речевой информа­ции, закодированной по алгоритму G.723.1, соответствует номер 1, возможности приема речевой информации, закодированной по алгоритму G.728, - номер 2, возможности приема видеосигналов, закодированных по алгоритму Н.263, - номер 3 и т. д.

Указанные порядковые номера объединяются в список альтерна­тивных режимов alternativeCapabilitySet. Оборудование может ис­пользовать любой (но только один) из режимов, указанных в списке. Например, список альтернативных режимов {G.711, G.723.1, G.728} означает, что оборудование может функционировать в любом из указанных режимов обработки речи, но только в одном.

В свою очередь, альтернативные режимы объединяются в наборы одновременно возможных режимов функционирования simultaneousCapabilities.

Функциональные возможности терминала описываются набором дескрипторов (capabilityDescriptor), каждый из которых состоит из одного набора одновременно возможных режимов функционирования оборудования и номера дескриптора (capabilityDescriptorNumber). Если при обмене данными о функциональных возможностях оборудо­вание указывает более чем один дескриптор, это означает, что обору­дование поддерживает несколько режимов функционирования.

Заметим, что функциональные возможности оборудования, не определенные рекомендацией ITU Н.245, могут быть указаны в поле nonStandartParameter.

Оборудование может в любое время передать сообщение TerminalCapabilitySet с дескриптором, добавляющим новые функциональные возможности, или с дескриптором, исклю­чающим некоторые из ранее указанных возможностей. Любое оборудование стандарта Н.323 должно включать в сообщение TerminalCapabilitySet, по крайней мере, один дескриптор. Исклю­чение составляет сообщение EmptyCapabilitySet (пустой набор функциональных возможностей), которое используется для реали­зации дополнительных возможностей системы.

Оборудование, которое получило от другого оборудования со­общение TerminalCapabilitySet, может подтвердить его получение передачей сообщения TerminalCapabilitySetAck. При получении сообщения с некорректным набором возможностей оборудование отвечает сообщением TerminalCapabilitySetReject.

Теперь рассмотрим процедуры открытия и закрытия логических каналов. Информация, передаваемая источником к одному или более приемникам в сетях, базирующихся на рекомендации Н.323, переносится по логическим каналам, которые идентифицируются уникальным для каждого направления передачи номером канала. Рекомендацией Н.245 предусмотрена возможность открытия логи­ческих каналов двух видов: однонаправленных (uni-directional) при помощи процедуры Uni-directional Logical Signalling, т.е. открываю­щихся в направлении от источника к приемнику информации, и дву­направленных (bi-directional) при помощи процедуры Bi-directional Logical Signalling, открывающихся сразу в двух направлениях - от источника к приемнику информации и в обратном направлении.

В требовании открыть логический канал openLogicalChannel оборудование указывает вид информации, который будет пере­даваться по этому каналу, и алгоритм кодирования информации. Если логический канал предназначается для переноса речи или видеоинформации с помощью протокола RTP (Real Time Protocol), то в сообщение openLogicalChannel должен включаться параметр mediaControlChannel с указанием транспортного адреса канала протокола RTCP (Real Time Control Protocol), при помощи которого ведется контроль передачи RTP пакетов.

Оборудование, получившее запрос открыть логический канал для приема данных, вид которых не поддерживается или не рас­познан, должно ответить сообщением openLogicalChannelReject, а получение корректного сообщения openLogicalChannel оборудо­вание должно подтвердить сообщением openLogicalChannelAck. В случае открытия двустороннего канала добавляется сообщение openLogicalChannelConfirm, которое передается в ответ на сооб­щение openLogicalChannelAck и подтверждает, что двунаправлен­ный логический канал открыт. Закрытие логических каналов может производиться с помощью процедуры CloseLogicalChannel, но она используется, в основном, для поддержки предоставления до­полнительных услуг, в первую очередь, постановки на удержание. Для нормального разрушения соединения стороны обмениваются сообщениями endSessionCommand. После обмена этими сооб­щениями закрываются не только логические каналы, но и управля­ющий канал Н.245.

Еще одним важным аспектом является мультиплексирование потоков в H.245. Такая ситуация возникает, когда через один ло­гический канал по протоколу RTP передается поток, который со­держит в себе несколько медиапотоков, мультиплексированных с использованием протоколов Н.222.0 или Н.223. Благодаря приме­нению протоколов мультиплексирования, оконечное оборудования Н.323 может использовать выделенную полосу пропускания более эффективно, упростить процедуру синхронизации, а также снизить возникающие при передаче мультимедиа потока задержки.

Существует два подхода к вопросу контроля конфигурации муль­типлексированного потока.

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

Второй вариант заключается в контроле логических каналов мультиплексированного потока тем же самым путем, что и конт­роль не мультиплексированных логических каналов, т.е. сообщения Н.245 для мультиплексированного потока передаются тем же спо­собом, что и обычные сообщения Н.245. В таком случае оконечное оборудование открывает одно/двунаправленный логический канал для передачи мультиплексированного потока, используя процеду­ры открытия и закрытия логических каналов Н.245, как для обычных RTP медиа-потоков. Когда логические каналы мультиплексирован­ного потока открыты, используя указанные процедуры с параметра­ми конфигурации протокола мультиплексирования и параметрами числа логических каналов мультиплексированного потока, создает­ся новый логический канал.

Обмен данными о функциональных возможностях относительно мультиплексированного потока представляет собой следующее. Терминалы Н.323, поддерживающие одиночные потоки, отоб­ражают эту возможность, включая заголовок MiltiplexedStream- Capability, как часть возможностей терминала Н.323. Параметр controlOnMuxStream в заголовке MultiplexedStreamCapability отображает, поддерживается ли контроль мультиплексированного потока с использованием сообщения Н.245, или контроль ведется посредством пакетов RTP. Если параметр controlOnMuxStream равен логической единице, возможности терминала относи­тельно работы с кодеками могут быть выражены в парамет­ре capabilityOnMuxStream. В случае отсутствия параметра capabilityOnMuxStream, терминал должен производить обмен данными о функциональных возможностях, передавая сообщения Н.245 в RTP пакетах через мультиплексированный поток в открытом логическом канале. В случае, когда controlOnMuxStream равен логическому нулю, возможности работы оборудования с кодеками должны быть определены в параметре capabilityOnMuxStream.

Сигнализация логических каналов для транспортировки муль­типлексированного потока происходит следующим образом. Ло­гический канал для мультиплексированного потока открывается путем передачи сообщения openLogicalChannel с параметром dataType заголовка MultiplexedStreamCapability и парамет­рами miltiplexParameters заголовка h2250LogicalChannelPa- rameters. Если в заголовке MultiplexedStreamCapability параметр controlOnMuxStream=1, открываемый логический канал должен быть двусторонним, т.е. должны быть установлены параметры reverseLogicalChanelParameters. Иначе логический канал будет односторонним. Необходимо отметить, что если логический канал открыт как односторонний, некоторые функции протокола мульти­плексирования не смогут действовать (например, AL3 в протоколе Н.223). Терминал не должен открывать более одного логического канала с параметрами multiplexFormat заголовка h223Capability и controlOnMuxStream, равными логическому нулю.

Сигнализация логических каналов для транспортировки ме­диа-потоков через мультиплексированный поток происходит очень похоже. Логический канал через мультиплексированный поток открывается с помощью сообщения openLogicalChannel с соответствующим значением dataType для транспортировки медиа информации и со значением multiplexParameters, соот­ветствующим используемому протоколу мультиплексирования (например, h223logicalChannelPara meters). Если параметр controlOnMuxStream соответствует логической единице, сообще­ния Н.245 доставляются через управляющий канал Н.245, как обыч­но. В случае протокола Н.222.0, параметры resourceID заголовка h2220LogicalChannelParameters назначаются в соответствии с числом логических каналов для мультиплексированного потока, через который открывается новый логический канал. Необходимо отметить, что в случае протокола Н.223 сигнализации такого рода не требуется благодаря тому, что более одного логического канала существовать не может. Образованные через мультиплексирован­ный поток логические каналы закрываются с помощью передачи сообщения closeLogicalChannel, которое пересылается тем же самым путем, что и сообщение openLogicalChannel.

Логический канал для мультиплексированного потока, который был открыт со значением параметра controlOnMuxStream, равным логической единице, может быть закрыт в любое время с помощью сообщения closeLogicalChannel. Если при создании логического канала параметр controlOnMuxStream имел значение «логичес­кий ноль», этот канал необходимо закрывать только после того, как будут закрыты все логические каналы мультиплексированного потока.

В последних версиях протокола Н.323 было сделано немало шагов в сторону повышения стабильности и устойчивости работы. Были также введены механизмы переноса часто передающихся по сети ТфОП сигналов модема и факса, а также обеспечено тунне- лирование через Н.323 сигнализации QSIG, ISUP и DSS1. Можно сказать, что введение новых версий рекомендации и дополнений функций есть не что иное, как попытка превратить Н.323 в полно­ценный протокол NGN. Рассмотрим некоторые из этих дополнений и начнем с передачи пакетов T.38 протоколом H.323.

Связь между двумя факсимильными аппаратами группы 3 рас­сматривается в Н.323 как поток данных, когда пользователь пере­дает факс в режиме реального времени, для чего факсимильные сигналы должны переноситься аналогично речевым сигналам. Случай передачи факсимильных сообщений по технологии Store & Forward не рассматривается. Таким образом, задача сети Н.323 при передаче факсимильных сообщений заключается в передаче пакетов T.38 через сеть IP в режиме реального времени. Любое обо­рудование Н.323, поддерживающее факсимильные возможности, должно поддерживать протокол T.38.

Для передачи пакетов T.38 используется процедура Fast connect. При этом открываются два логических канала (от отправителя к по­лучателю и обратный) или один двунаправленый канал, как показа­но на рис. 5.8.

Поддержка оборудованием второго варианта является необяза­тельной. Пакеты Т.38 могут пересылаться с использованием прото­кола TCP или UDP. В общем случае, протокол TCP является более эффективным, когда пропускная способность факсимильного со­единения ограничена. В ином случае более эффективен протокол UDP. Следует отметить, что помимо факсимильных каналов, допол­нительно может быть открыто до двух аудио-каналов, если оконеч­ное оборудование поддерживает такую функцию.

Аналогичным образом обстоит дело с передачей через H.323 модемных сигналов. В рекомендации Н.323 описано, как исполь­зовать протокол V. 150.1 для передачи модемных сигналов в среде Н.323. Это определило новую концепцию в протоколе Н.245, на­званную MPS (Multiple Payload Streams).

Факсимильное оборудование

Факсимильное оборудование

Логический канал для передачи речи

^Логический канал для приема речи

Факсимильное оборудование

Факсимильное оборудование

Поток передачи

Поток приема

Рис. 5.8. Организация двух логических каналов или одного двунаправленного канала

В последней версии протокола Н.245 оконечному оборудованию позволено создавать RTP-сеансы, которые могут переносить как речевые, так и модемные сигналы (а также и любые другие, напри­мер, DTMF факс и т.п.).