Протокол H.323 обеспечивает основу для передачи данных, видео- и аудиоинформации через IP-сети, включая Internet. H.323 рекомендуется Международным телекоммуникационным союзом (International Telecommunication Union — ITU) в качестве набора стандартов передачи мультимедиа-информации через локальные сети, не поддерживающие гарантированного качества сервиса (QoS). Большинство современных сетей относится именно к такому типу — примерами могут служить сети на базе протоколов TCP/IP и IPX в средах Ethernet, Fast Ethernet и T oken Ring. Следовательно, протоколы H.323 являются важной частью построения ЛВС с поддержкой приложений мультимедиа. Такие приложения будут включать H.225.0-RAS, Q.931-H.245, RTP/RTCP и кодеки (кодер-декодер) аудио/видео/данных (аудио-кодеки G.711, G.723.1, G.728 и т. п., видео-кодеки H.261, H.263 с компрессией и декомпрессией, а также кодеки данных T.120).

Мультимедиа-потоки передаются на базе протоколов RTP/RTCP. RTP обеспечивает передачу собственно потоков мультимедиа, а RTCP поддерживает передачу данных для управления и контроля. Сигнализация (исключая RAS) передается с помощью протокола TCP. С сигнализацией имеют дело перечисленные ниже протоколы:

• RAS управляет регистрацией, доступом и состоянием;
• Q.931 обеспечивает организацию и разрыв соединений;
• H.245 отвечает за согласование возможностей и использование каналов.

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

H.235 обеспечивает средства безопасности и аутентификацию;

• H.450.x — дополнительные услуги.

Расположение протоколов H.323 в модели OSI показано на рисунке.

Положение стека протоколов H.323 в эталонной модели OSI

RTP

RFC 1889

Протокол RTP (Real-time Transport — передача в реальном масштабе времени) обеспечивает транспортные функции для приложений, передающих данные в реальном масштабе времени (таких, как голос или видео) с использованием индивидуальных или групповых адресов. RTP не резервирует ресурсы и не гарантирует качества обслуживания QoS для сервиса в реальном масштабе времени. Протокол управления передачей RTCP позволяет осуществлять мониторинг доставки данных (в том числе и для больших сетей с групповой адресацией) и обеспечивает минимальный набор функций управления и идентификации. Протоколы RTP и RTCP разработаны таким образом, что функционирует независимо от нижележащих транспортных и сетевых протоколов. Протокол RTCP поддерживает использование трансляторов и миксеров уровня RTP.

Формат заголовка RTP с фиксированной структурой показан на рисунке.

Структура RTP

V

Версия протокола RTP.

P

Флаг заполнения. P=1 говорит о том, что в конце пакета содержится один или несколько октетов выравнивания, не являющихся частью полезной информации.

X

Бит расширения. При X=1 после заголовка с фиксированной структурой следует дополнительный заголовок определенного формата.

Счетчик CSRC

Показывает число идентификаторов CSRC, следующих за заголовком.

M

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

Тип содержимого

Идентификатор типа содержимого задает формат информационной части пакета RTP и определяет интерпретацию пакета приложениями. Используемое по умолчанию статическое отображение кодов типа содержимого в форматы данных задается профилем. Дополнительные коды типов данных могут динамически задаваться иными средствами (не относящимися к RTP).

Порядковый номер

Данное поле увеличивается на единицу для каждого следующего посылаемого пакета RTP. Номер может использоваться получателем для обнаружения потери пакетов и восстановления корректной последовательности пакетов.

Временная метка

Отражает момент выборки первого октета в пакете данных RTP. Значение времени выборки должно браться из переменной (часов), которая увеличивается во времени непрерывно и линейно. Это значение используется для синхронизации и обнаружения флуктуаций времени доставки (jitter). Уровень разрешения часов должен быть достаточным для обеспечения желаемой точности синхронизации и соответствующей точности определения флуктуация времени доставки (как правило одного изменения показаний часов на видео-кадр недостаточно).

SSRC

Указывает источник синхронизации (идентификатор выбирается случайным образом с учетом того, что два источника синхронизации в одной сессии RTP не должны иметь одинаковых идентификаторов SSRC).

CSRC

Список идентификаторов источников информации, содержащий указатели на источники включенной в пакет полезной информации.

RTCP

RFC 1889 http://www.cis.ohio-state.edu/htbin/rfc/rfc1889.html

Протокол управления RTP (RTP control protocol) основывается на периодической передаче управляющих пакетов всем участникам сессии с использованием того же механизма, который служит для передачи пакетов данных. Нижележащий протокол уровня должен поддерживать мультиплексирование пакетов данных и управляющих пакетов (например, за счет использования разных номер портов в UDP).

Структура RTCP

Версия

Номер версии RTP, совпадающий для пакетов RTCP и пакетов данных RTP. В настоящее время используется версия 2.

P

Флаг заполнения. P=1 говорит о том, что в конце пакета содержится один или несколько октетов выравнивания, не являющихся частью полезной информации. Последний октет поля заполнения содержит число октетов заполнения, которые следует игнорировать. Заполнение может требоваться при использовании некоторых алгоритмов шифрования с фиксированным размером блоков. В составном пакете RTCP заполнение может потребоваться только для последнего из отдельных пакетов, поскольку составной пакет шифруется как единое целое.

Счетчик принятых отчетов

Количество блоков отчета, содержащихся в пакете. Допустимо нулевое значение поля.

Тип пакета

Поле типа пакета содержит константу 200, указывающую, что данный пакет относится к RTCP SR.

Длина

Поле длины задает размер пакета RTCP в 32-битовых словах минус 1 (с учетом заголовка и заполнения). Уменьшение реального размера пакета делает 0 корректным значением длины и позволяет избежать зацикливания при сканировании составного пакета RTCP, а подсчет в 32-битовых словах позволяет избежать проверки кратности размера (в октетах) числу 4.

RAS

H.225:

Канал RAS (Registration, Admission and Status — регистрация, доступ, состояние) служит для сообщений, используемых в процессах обнаружения шлюзов и регистрации конечных точек. Последний процесс используются для установки соответствия адресов конечных точек и транспортных адресов сигнальных транспортных каналов. Поскольку канал RAS не обеспечивает гарантированной доставки, H.225.0 рекомендует использовать для различных сообщений таймаут и счетчики повторов. Конечная точка или шлюз, которым не удается ответить на запрос в течение заданного времени (таймаут), могут использовать сообщения RIP (Request in Progress — запрос обрабатывается) для индикации того, что запрос до сих пор не обработан. Конечная точка или шлюз, получающие RIP, сбрасывают таймер и счетчик повторов.

Сообщения RAS используют синтаксис ASN.1.

H.225

H.225: http://www.itu.int/itudoc/itu-t/rec/h/h225-0.html

H.225 представляет собой стандарт узкополосных видеотелефонных услуг, определенных в рекомендациях H.200/AV.120. Стандарт имеет дело с ситуациями, когда маршрут передачи включает, по крайней мере, одну сеть передачи пакетов, которая настроена на предоставление негарантируемого качества обслуживания QoS (такие сети также не поддерживают механизмов защиты и восстановления сверх заданных рекомендациями H.320 для терминалов). H.225.0 описывает организацию потоков голоса, видео, данных и управляющей информации в сетях передачи пакетов для обеспечения диалогового сервиса с помощью оборудования H.323.

Структура пакетов H.225 соответствует стандарту Q.931 и показана на рисунке.

Структура H.225

Дискриминатор протокола

Используется для того, чтобы отличать сообщения, управляющие вызовами пользователь-сеть, от других сообщений.

Размер ссылки

Ссылка на вызов

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

Тип сообщения

Поле типа определяет функцию переданного сообщения. Используются следующие типы сообщений:

Информационные элементы (IE)

Протокол определяет две категории информационных элементов — размером в один октет и переменной длины. Форматы информационных элементов показаны на рисунке.

Формат информационного элемента из одного октета (тип 1)

Формат информационного элемента из одного октета (тип 2)

Формат информационного элемента переменной длины

H.245

H.245: http://www.itu.int/itudoc/itu-t/rec/h/h245.html

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

Сообщения H.225 соответствуют синтаксису ASN.1.

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

• Master Slave Determination (определение ведущего и ведомого).
• Terminal Capability (возможности терминала).
• Logical Channel Signaling (сигнализация логического канала).
• Multiplex Table signaling (сигнализация таблицы мультиплексирования).
• Request Multiplex Table signaling (запрос сигнализации таблицы мультиплексирования).
• Request Mode (режим запроса).
• Round Trip Delay (задержка прохождения сигнала в обоих направлениях).
• Maintenance Loop (цикл обслуживания).
• Communication Mode (коммуникационный режим).
• Conference Request and Response (запрос и отклик для конференции).
• Terminal ID (идентификатор терминала).

Commands and Indications (команды и индикаторы).

H.261

H.261: http://www.cis.ohio-state.edu/htbin/rfc/rfc2032.html

Протокол H.261 описывает видео-потоки для передачи с помощью транспортного протокола в реальном масштабе времени (RTP). На более низком уровне могут использоваться любые протоколы, способные поддерживать трафик RTP.

Формат заголовка показан на рисунке.

Структура заголовка H.261

SBIT

Стартовый бит. Количество старших битов, которые должны игнорироваться в первом октете данных.

EBIT

Завершающий бит. Количество младших битов, которые должны быть проигнорированы в последнем октете данных.

I

Флаг кодирования данных INTRA-кадра. Если данный бит имеет значение 1, поток содержит только блоки, кодированные как INTRA-кадры. Нулевое значение флага говорит, что данный поток может содержать или не содержать блоки, кодированные как INTRA-кадр. Значение этого бита не может изменяться в течение всей RTP-сессии.

V

Флаг вектора перемещения (Motion Vector). Нулевое значение устанавливается в том случае, когда векторы перемещения не используются в данном потоке. Единичное значение флага говорит о возможности присутствия векторов перемещения. Значение этого бита не может изменяться в течение всей RTP-сессии.

GOBN

Номер GOB, задающий начало пакета. Значение этого поля равно 0, если пакет начинается с заголовка GOB.

MBAP

Поле MBAP (Macroblock Address Predictor – предсказание адреса макроблока) кодирует предсказание адреса макроблока (т. е. последнее значение MBA, содержащееся в предыдущем пакете). Значение поля находится в диапазоне 0-32 (для предсказания допустимых значений MBA — 1-33), но, поскольку битовый поток не может быть фрагментирован между заголовком GOB и MB 1, предсказатель в начале пакета не может быть равен 0. Таким образом, остается диапазон 1-32, который смещается на –1 для того, чтобы было достаточно 5-битового поля. Если пакет начинается с заголовка GOB, поле MBAP=0.

QUANT

Поле QUANT показывает значение MQUANT или GQUANT до начала пакета. Если пакет начинается с заголовка GOB, для поля QUANT устанавливается нулевое значение.

HMVD

Поле HMVD (Horizontal Motion Vector Data — вектор горизонтального перемещения) представляет собой ссылку на горизонтальный вектор перемещения данных (Motion Vector Data – MVD). HMVD=0, если флаг V равен 0, пакет начинается с заголовка GOB или для последнего MB, помещенного в предыдущий пакет, значение MTYPE не равно MC. Значение HMVD должно находиться в диапазоне от –15 до +15.

VMVD

Поле VMVD (Vertical Motion Vector Data — вектор вертикального перемещения) представляет собой ссылку на вертикальный вектор перемещения данных MVD. Значение VMVD=0, если флаг V равен 0, пакет начинается с заголовка GOB или для последнего MB, помещенного в предыдущий пакет, значение MTYPE не равно MC. Значение VMVD должно находиться в диапазоне от –15 до +15.

H.263

RFC 2190 (RTP): http://www.cis.ohio-state.edu/htbin/rfc/rfc2032.html

H.263: http://www.itu.int/itudoc/itu-t/rec/h/h263.html

Протокол H.263 определяет формат инкапсуляции битового потока H.263 в пакеты протокола RTP (Real-time Transport Protocol – протокол транспортировки в реальном масштабе времени). Для заголовка потока (payload) H.263 определены три режима. Пакет RTP может использовать один из трех режимов видео-потока H.263 в зависимости от желаемого размера сетевого пакета и опций кодирования H.263. Самый короткий заголовок H.263 (режим A) поддерживает фрагментацию GOB (Group of Block — группа блока). Длинные заголовки H.263 (режимы B и C) поддерживают разбиение потока на макроблоки (MB).

Для каждого пакета RTP после заголовка RTP фиксированной длины следует заголовок содержимого H.263, а за ним — сжатый битовый поток стандарта H.263. Размер заголовка содержимого H.263 зависит от используемого режима. Схема видео-пакета RTP H.263 показана на рисунке.

Видео-пакет RTP H.263

В режиме A заголовок H.263 содержит 4 байта. Данный режим поддерживает фрагментацию RTP. В режиме B используется 8-байтовый заголовок H.263 и каждый пакет начинается на границе MB без опции PB. 12-байтовый заголовок H.263 определяет режим C, поддерживающий фрагментацию на границах MB для кадров с опцией PB.

Режим каждого заголовка потока H.263 указывается значениями полей F и P. Пакеты различных режимов могут перемешиваться. Формат заголовка для режима A показан на следующем рисунке.

Структура заголовка H.263 для режима A.

F

Флаг, показывающий режим заголовка потока H.263.

P

Флаг необязательного режима PB, определенного в стандарте H.263.

1. Обычный кадр типа I или P.

1 Кадр PB.

Если F=1, поле P показывает режим:

Обычный кадр типа I или P.

0 Режим B.

1 Режим C.

SBIT

Стартовый бит. Количество старших битов, которые должны игнорироваться в первом байте данных.

EBIT

Завершающий бит. Количество младших битов, которые должны быть проигнорированы в последнем байте данных.

SRC

Исходный формат (биты 6, 7 и 8 поля TYPE, определяемые H.263), задающий разрешение текущего изображения.

I

Тип кодирования изображения (бит 9 в PTYPE, определяемый H.263):

0 Intra-кодирование (внутреннее).

1 Inter -кодирование.

U

Поле U имеет значение 1, если в текущем заголовке изображения была установлена (1) опция неограниченного вектора перемещения (Unrestricted Motion Vector), задаваемая битом 10 в поле PTYPE в соответствии с определением H.263.

S

Поле S имеет значение 1, если для текущего заголовка изображения была установлена (1) опция синтаксического арифметического кодирования (Syntax-based Arithmetic Coding), задаваемая битом 11 в поле PTYPE в соответствии с определением H.263.

A

Поле A имеет значение 1, если для текущего заголовка изображения была установлена (1) опция расширенного предсказания (Advanced Prediction), задаваемая битом 12 в поле PTYPE в соответствии с определением H.263.

R

DBQ

Параметр дифференциального квантования, используемый для расчета параметров квантования для B-кадра на основе параметра квантования для P-кадра при использовании опции PB-кадров. Значение этого поля должно быть равно DBQUANT (определено в H.263). Нулевое значение поля устанавливается в тех случаях, когда опция PB-кадров не используется.

TRB

TR

Формат заголовка для режима B показан на следующем рисунке.

Структура заголовка H.263 для режима B.

Поля F, P, SBIT, EBIT, SRC, I, U, S и A определяются так же, как для режима A.

QUANT

Значение квантования для первого MB, кодированного в начале пакета. Если пакет начинается с заголовка GOB, поле QUANT=0.

GOBN

Номер GOB в начале пакета. Номер GOB задается по разному для различного разрешения.

MBA

Адрес внутри GOB первого MB в пакете (считается от нуля в порядке сканирования). Например, третий макроблок в любом GOB будет иметь MBA=2.

R

Поле зарезервировано и должно иметь нулевое значение.

HMV1, VMV1

Предсказание вертикального и горизонтального вектора перемещения для первого макроблока в данном пакете. Когда для текущего макроблока используются четыре вектора перемещения с опцией расширенного предсказания (advcanced prediction), эти векторы являются предсказателями вектора перемещения для блока номер 1 в макроблоке. Каждое 7-битовое поле кодирует предсказатель вектора перемещения в половинах разрешающей способности, используя дополнение до 2.

HMV2, VMV2

Предсказания вертикального и горизонтального векторов перемещения для блока номер 3 в первом макроблоке этого пакета, когда четыре вектора перемещения используются для с опцией расширенного предсказания (advcanced prediction). Это необходимо, поскольку для блока номер 3 в макроблоке требуются отличные от других макроблоков предсказания векторов перемещения. Описываемые поля не используются в тех случаях, когда MB имеет только один вектор перемещения. Каждое 7-битовое поле кодирует предсказатель вектора перемещения в половинах разрешающей способности, используя дополнение до 2.

Формат заголовка для режима С показан на рисунке.

Структура заголовка H.263 для режима С.

Поля F, P, SBIT, EBIT, SRC, I, U, S, A, DBQ, TRB и TR определяются так же, как для режима A; поля QUANT, GOBN, MBA, HMV1, VMV1, HMV2, VMV2 — как для режима B.

RR

Поле зарезервировано и должно иметь нулевое значение.

H.235

H.235: http://www.itu.int/itudoc/itu-t/rec/h/h235.html

Протокол H.235 обеспечивает расширение рекомендаций серии H.3xx в части добавления услуг обеспечения безопасности, такие как аутентификация и конфиденциальность (Authentication and Privacy) (шифрование данных). H.235 должен работать с другими протоколами серии H, которые используют H.245 в качестве протокола управления.

Все сообщения H.235 шифруются так же, как в ASN.1.

Характеристика стека протоколов H.323

Стек протоколов стандарта Н.323 разработан международным телекоммуникационным союзом ITU для передачи мультисервисного трафика через пакетные сети. Широко используется при передаче голоса через IP-сети (VoIP).

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

· терминал,

· шлюз GW (Gateway),

· устройство управления доступом GK (Gatekeeper),

· блок управления многоточечными конференциями MCU (Multipoint Conference Unit) (рис. 7.1).

Рисунок 7.1

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

Устройство управления доступом GK (Gatekeeper) обеспечивает трансляцию имен терминалов в ІР-адреса. Совокупность всех терминалов, шлюзов и блока управления многоточечными конференциями, управляемых с помощью одного GK, называется зоной. Зона независима от топологии сети и может быть составлена из множества сегментов, соединенных с помощью маршрутизаторов. Шлюз обеспечивает функции преобразования информации между ІР-сетями и телефонными станциями общего пользования ТфОП (PSTN). Блок управления многоточечными конференциями MCU обеспечивает возможность общения трех и более терминалов и шлюзов.

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

Сигналы управления включают: сигнализацию установления соединения, сигнализацию возможностей обмена данными, сигнализацию вызова команд и индикацию их выполнения, сигнализацию открытия и описания логического канала. Стек Н323 включает следующие виды протоколов (рис. 7.2):

Рисунок 7.2

В стеке H323 используется система трех стандартов H225, H235, H245. Стандарт H225 формирует поток данных сетевого уровня и отвечает за упаковку и сортировку данных. Стандарт H235 обеспечивает аутентификацию данных. Стандарт H245 управляет соединениями, по которым будут передаваться аудио и видео данные.

Протоколы (Т122-Т127) входят в семейство Т120. Семейство Т120 представляет собой набор телекоммуникационных и прикладных протоколов для организации и проведения многоточечных конференций в реальном времени. Главная особенность Т120 заключается в организации и поддержании конференций на любой платформе, управлении множеством участников и программ, безошибочном и безопасном обмене данными при всем многообразии возможных сетевых сценариев.

Архитектура Т120 – это двухуровневая архитектура. Протоколы Т122 - Т125 описывают независимый от приложений механизм для организации многоточечной связи, а протоколы верхнего уровня Т126 и Т127 являются прикладными.

Стек Н323 использует как «надежные» (с подтверждением) TCP, так и «ненадежные» UDP. По протоколу ТСР передается управляющая информация (сигналы управления Н245 и сигнализации Q931), по UDP – аудио и видеоданные.

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

Транспортный протокол реального времени RTP (Real-Time Transport Protocol) гарантирует доставку данных одному или более адресатам с задержкой в заданных пределах. В типичной среде реального времени отправитель генерирует пакеты с постоянной скоростью. Они отправляются им через сеть и принимаются получателем. Однако ввиду вариации задержки при передаче по сети пакеты прибывают через нерегулярные интервалы. Для компенсации этого явления пакеты буферизируются, а затем с постоянной скоростью выдаются получателю.

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

Протокол RTP используется только для передачи пользовательских данных – всем участникам сеанса. Отдельный протокол управления реального времени RTCP (Real-Time Transport Control Protocol) работает с несколькими адресатами для обеспечения обратной связи с отправителем данных. RTCP использует транспортный протокол UDP, но с другим номером порта. Этот протокол является также многоадресным.

Частота передачи этих пакетов зависит от числа участников и снижается с увеличением количества участников. Цель такого решения состоит в том, чтобы трафик RTCP не превышает 5% общего времени трафика сеанса.

Работу набора протоколов Н323 обеспечивает также протокол резервирования ресурсов RSVP (Resource Reservation Protocol). Этот протокол должен поддерживать все компоненты Н323 (терминалы, шлюзы, MCU), а также коммутаторы и маршрутизаторы.

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

Контроллер управления многоточечными конференциями (Multipoint Control Unit - MCU) предназначен для организации конференций с участием трех и более участников. В этом устройстве должен присутствовать контроллер Multipoint Controller (MC) и, возможно, процессоры Multipoint Processors ( MP ). Контроллер MC поддерживает протокол Н.245 и предназначен для согласования параметров обработки аудио- и видеопотоков между терминалами. Процессоры занимаются коммутированием, микшированием и обработкой этих потоков.

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

Централизованная многоточечная конференция требует наличия устройства MCU . Каждый терминал обменивается с MCU потоками аудио, видео, данными и командами управления по схеме "точка-точка". Контроллер MCU , используя протокол H.245, определяет возможности каждого терминала. Процессор MP формирует необходимые для каждого терминала мультимедийные потоки и рассылает их. Кроме того, процессор может обеспечивать преобразования потоков от различных кодеков с различными скоростями данных.

Децентрализованная многоточечная конференция использует технологию групповой адресации. Участвующие в конференции H.323-терминалы осуществляют многоадресную передачу мультимедиа потока остальным участникам без посылки на MCU . Передача контрольной и управляющей информации осуществляется по схеме "точка-точка" между терминалами и MCU . В этом случае контроль многоточечной рассылки осуществляется контроллером MCU .

Гибридная схема организации конференц-связи является комбинацией двух предыдущих. Участвующие в конференции H.323-терминалы осуществляют многоадресную передачу только аудио- или только видеопотока остальным участникам без посылки на MCU . Передача остальных потоков осуществляется по схеме "точка-точка" между терминалами и MCU . В этом случае задействуются как контроллер, так и процессор MCU .

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

Контроллер зоны (или Gatekeeper) - рекомендуемое, но не обязательное устройство, обеспечивающее сетевое управление и исполняющее роль виртуальной телефонной станции.

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

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

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

Обязательные функции контроллера зоны

• Трансляция адреса

  Вызов, порожденный внутри H.323-сети, может использоваться для адресования нужного терминала с помощью его псевдонима (краткого названия). Вызов, порожденный вне H.323-сети и полученный через шлюз для адресования терминалу получателя, может использовать номер телефона в соответствии с рекомендацией E.164 (например, 310-442-9222 ). Данная рекомендация используется для адресования абонентов сети ISDN. Контроллер зоны преобразует полученный E.164-номер телефона или псевдоним в сетевой адрес (например, 204.252.32.156 для IP-сети) терминала адресата. Оконечная точка адресата может быть достигнута с использованием этого сетевого адреса.

• Управление регистрацией

  Контроллер зоны может управлять регистрацией оконечных точек в H.323-сети. При этом используются RAS -сообщения: запрос регистрации ( ARQ ), подтверждение ( ACF ) и отклонение ( ARJ ). Управление регистрацией может быть фиктивной функцией, которая допускает все оконечные точки к H.323-сети.

• Управление полосой пропускания

  Контроллер обеспечивает управление полосой пропускания, используя RAS -сообщения: запрос ширины полосы пропускания (BRQ ), подтверждение (BCF ) и отклонение (BRJ ). Например, если сетевой диспетчер определил порог для числа одновременных соединений для H.323-сети, контроллер зоны может отказываться устанавливать новые соединения, если только этот порог достигнут. В результате имеется возможность ограничивать общее значение распределенной полосы пропускания некоторой частью общей полосы сети передачи данных, оставляя остающуюся ширину полосы пропускания для приложений передачи данных. Управление полосой пропускания может также быть фиктивной функцией, которая просто получает запросы без их обработки.

• Факультативные функции контроллера зоны
  • Управление вызовами

    Контроллер зоны может маршрутизировать вызовы между H.323-оконечными точками. В двухточечной конференции контроллер зоны может обрабатывать H.225 сообщения сигналов вызовов. В качестве альтернативы контроллер зоны может разрешать оконечным точкам самостоятельный обмен H.225-сообщениями сигналов вызовов непосредственно друг с другом.

    

В сегодняшней статье мы поговорим об одном из первых протоколов, получивших широкое применения в сетях VoIP – H.323.

Первая реализация H.323 была представлена ITU-T (International Telecommunication Union - Telecommunications) еще в 1996 и предназначалась для использования в видеоконференциях, ограниченных LAN (Local Area Network). Однако, протокол был быстро адаптирован для передачи голосовых данных в других типах IP сетей, таких как WAN (Wide Are Network) и Интернет.

H.323 чаще всего называют “протоколом”, хотя на самом деле, это целый стек протоколов, которые объединены одной задачей – поддержание передачи аудио- и видео-данных через сеть с коммутацией пакетов.

Как видно из данного рисунка передача аудио и видео осуществляется по стекам G.xxx/RTP/UDP/IP и H.xx/RTP/UDP/IP, за статистическую информацию о сессии отвечает RTCP.

Протокол H.255 RAS (Registration, Admission, Status) отвечает за взаимодействие оконечных устройств с привратником или контроллером зоны.

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

Процесс установления и завершения звонков через IP сеть осуществляется по средствам протокола H.255.0, сигнальные сообщения которого, позаимствованы у Q.931, использующегося в ISDN.

Архитектура H.323 имеет клиент-серверную модель и включает в себя следующие элементы:

- Терминал

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

- Шлюз (Gateway)

Данный элемент присутствует только тогда, когда необходимо обеспечить сопряжение сети H.323 с сетью другого типа, например ISDN (Integrated Services Digital Network) или PSTN (Public Switched Telephone Network). Стоит отметить, что с помощью шлюзов можно обеспечить взаимодействие H.323 и с сетями мобильной связи третьего поколения (3G), которые используют протокол H.324.

- Привратник (Gatekeeper)

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

Привратник работает в двух режимах: direct routed и gatekeeper routed

Наиболее эффективным и широко распространенным является режим direct routed, поскольку в этом режиме оконечные устройства (терминалы), по средствам протокола RAS узнают IP адрес удаленного устройства и соединение происходит напрямую.

В режиме же gatekeeper routed соединение всегда происходит через привратник, что конечно же требует от него дополнительных вычислительных мощностей.

Совокупность устройств, подключенных к одному привратнику называется зоной (zone), поэтому привратник часто называют контроллером зоны.

- Устройство управления конференциями (Multipoint Control Unit)

Данное устройство является сервером, в функции которого входит поддержание аудио- и видео- конференций между тремя или более H.323 терминалами. Сервер управляет ресурсами конференции, определяет аудио- и видео-потоки, проводит согласование терминалов по возможности обработки аудио- и видео-данных.

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

В следующей статье мы более подробно рассмотрим работу некоторых протоколов из стека H.323 , а также изучим возможные варианты сценариев установления соединения. Кроме того, мы научимся разбираться в сигнальных сообщениях протокола Q.931, что поможет нам в понимании не только H.323, но и ISDN.

Полезна ли Вам эта статья?

Пожалуйста, расскажите почему?

Нам жаль, что статья не была полезна для вас:(Пожалуйста, если не затруднит, укажите по какой причине? Мы будем очень благодарны за подробный ответ. Спасибо, что помогаете нам стать лучше!