Технология H.323 IP-телефонии

О программе
Лабораторная работа на тему:
«Технология H.323 IP-телефонии»
Выполнила: Забавникова Анна
группа АС-21

1.Общие сведения
2. Транспортные протоколы
Выбрать раздел:

1. Общие сведения
1.1 Протокол Н.323
1.2 Семейство протоколов Н.323
1.3 Сигнализация Н.323
1.4 Основные сценарии IP-телефонии
Назад
Содержание

Назад
Содержание
1.1. Протокол Н.323
H.323 - протокол передачи данных, а также передачи в реальном времени аудио- и видеоинформации по сетям, поддерживающим пакетную коммутацию. В число таких сетей входят сети, работающие по протоколу IP (интернет), местные сети, поддерживающие обмен интернет-пакетами, производственные, городские и региональные сети. H.323 может применяться в многополюсных мультимедиа-коммуникациях. Предоставляет массу услуг для использования в коммерческих, бизнес - и развлекательных приложениях. Значительно влияет на совместимость мобильных мультимедиа-приложений и услуг третьего поколения беспроводных технологий. H.323 — основополагающий стандарт, где описывается, каким образом чувствительный к задержке трафик, в частности голос и видео, получает приоритет в локальных и глобальных сетях. Он состоит из ряда рекомендаций по смежным техническим вопросам, таким, как качество речи, контроль вызовов и спецификации привратников.

Преимущества:
– Возможность существенного снижения затрат на междугородние и международные телефонные переговоры.
– Возможность передачи голосового трафика от головных офисов в филиалы в единой информационной IP магистрали.
Смысл введения стандарта H.323 прост - он предлагает протокол, с помощью которого коммуникационные программные продукты, созданные различными производителями, могут работать совместно (то есть взаимодействовать). Компания Intel внесла большой вклад в создание, развитие и распространение технологии H.323.
Совместимые с H.323 приложения и поддерживающая их инфраструктура Internet являются основой нового направления развития коммуникационных возможностей, связанных с использованием ПК. Программное обеспечение, разработанное Intel и другими компаниями на основе стандарта H.323, впервые позволит нам без проблем, с помощью простого нажатия кнопки, осуществлять обмен аудио- и видео- данными.
Назад
Конец раздела
Построение сети по рекомендации Н.323

Демонстрация по щелчку мыши!
Рисунок 1. Семейство протоколов Н.323
Гарантированная доставка
информации по протоколу
TCP
Негарантированная доставка
информации по протоколу
UDP
Н.245
Н.225
Управление
соединением (Q.931)
RAS
Потоки речи и
видеоинформации
RTCP
RTP
TCP
UDP
IP
Канальный уровень
Физический уровень
2.2.Семейство протоколов Н.323
Q.931
Протокол управления
логическими каналами. По протоколу
Н.245 происходит обмен между
участниками соединения информацией,
которая необходима для создания
логических каналов. По этим каналам
передается речевая информация,
упакованная в пакеты RTP/UDP/IP
Н.225 -
Протокол управления
соединениями
Протокол Н.225.0 (Q.931) поддерживает
процедуры установления, поддержания
и разрушения соединения.
В качестве транспортного протокола
используется протокол с установлением
соединения и гарантированной доставкой
информации TCP.
Протокол RAS (Registration, Admission, Status) обеспечивает
взаимодействие оконечных и других устройств с привратником.
Основными функциями протокола являются: регистрация устройства
в системе, контроль его доступа к сетевым ресурсам, изменение
полосы пропускания в процессе связи, опрос и индикация текущего
состояния устройства.В качестве транспортного протокола используется
протокол с негарантированной доставкой информации UDP
Для переноса речевой и
видеоинформации используется
протокол передачи
информации в реальном
времени - RTP.
Для переноса сигнальных сообщений Н.225 и управляющих сообщений Н.245 используется протокол с установлением соединения и с гарантированной доставкой информации - TCP
Сигнальные сообщения RAS
переносятся протоколом с
негарантированной доставкой
информации - UDP.
Контроль переноса пользовательской информации производится протоколом RTCP
RAS
H.245

Основными процедурами, выполняемыми оконечным оборудованием и привратником с помощью протокола RAS, являются:
1. Обнаружение привратника.
2. Регистрация оконечного оборудования у привратника.
3. Контроль доступа оконечного оборудования к сетевым ресурсам.
4. Определение местоположения оконечного оборудования в сети.
5. Изменение полосы пропускания в процессе обслуживания вызова.
6. Опрос и индикация текущего состояния оконечного оборудования.
7. Оповещение привратника об освобождении полосы пропускания, ранее занимавшейся оборудованием.
Выполнение первых трех процедур, предусмотренных протоколом RAS, является начальной фазой установления соединения с использованием сигнализации Н.323. Далее следуют фаза сигнализации Н.225.0 (Q.931) и обмен управляющими сообщениями Н.245. Разъединение происходит в обратной последовательности: в первую очередь закрывается управляющий канал Н.245 и сигнальный канал Н.225.0, после чего по каналу RAS привратник оповещается об освобождении ранее занимавшейся оконечным оборудованием полосы пропускания.
Для переноса сообщений протокола RAS используется протокол негарантированной доставки информации UDP. Важно отметить, что в сети без привратника сигнальный канал RAS вообще не используется.
ссылка
Таблица 1
Таблица 2
Таблица 3

Рассмотрим формат сообщения протокола Q.931:
8
Биты
7
6
5
2
1
4
3
Дискриминатор протокола (Protocol discriminator)
0
0
0
0
Длина значения указателя вызова Length CRV (в байтах)
1
2
Значение указателя вызова (Call reference value – CRV)
3
4
0
Байты
Тип сообщения (Message type – MT)
Другие информационные элементы (IE)
5
Дискриминатор протокола –
предназначен для идентификации
протокола 3-го уровня
Указатель вызова (CRV) предназначен
для идентификации вызова
среди других вызовов или
регистрации услуги в интерфейсе
“пользователь−сеть”
Тип сообщения (MT) –
- кодирует конкретное
сообщение согласно его
назначению
Информационные элементы (IE) –
общее название параметров,
детализирующих конкретное сообщение.
К таким параметрам, например,
относятся – атрибуты запрошенной
услуги – скорость, вид передаваемой
информации, номер абонента и т.п.
Рисунок 1а − Формат сообщений протокола Q.931
Используйте левую кнопку мыши!!!

Пример трассировки сообщений
08 01 01 05 04 04 88 90 21 8F 6C 07 00 80 32 33 39 37 34
Используйте левую кнопку мыши!!!
Setup (установить)
08-Дискриминатор Протокола = Q.931. (Protocol discriminator = Q.931)
01 - .... 0001 Длина
Рекомендации
Запроса = 1. ( 01 ....0001 Call Reference Length = 1)
01 - 0 ....... флаг = СОЗДАТЕЛЬ .0000001 Ценностей Рекомендации Запроса = 1. (01 0....... Flag = ORIGINATOR
.0000001 Call Reference Value = 1)
05 - 0 ....... E
.0000101 Сообщений напечатают = УСТАНОВКА. (05 0....... E
.0000101 Message type = SETUP )
04 - Элемент Информации = СПОСОБНОСТЬ ПРЕДЪЯВИТЕЛЯ. (04 Info Element = BEARER CAPABILITY (BC) )
04 - Длина = 4 октета. (04 Length = 4 octets )
88 - 1 ....... РАСШИРЕНИЕ
.00..... Кодирование стандарта = CCITT
... 01000 Информации передают способность = Неограниченная цифровая информация. (88 1....... EXT
.00..... Coding standard = CCITT
...01000 Info transfer capability = Unrestricted digital info )
90 - 1 ....... РАСШИРЕНИЕ
.00..... Способ передачи= способ Кругооборота
... 10000 Информации передают норму = 64 kbit/s. (90 1....... EXT
.00..... Transfer mode = Circuit mode
...10000 Info transfer rate = 64 kbit/s )
21 - 0 ....... РАСШИРЕНИЙ
.01..... Уровень 1 ID ... 00001 Пользовательский разряд информации 1 протокол = CCITT V.110 и X.30. (21 0....... EXT
.01..... Layer 1 ID
...00001 User info layer 1 protocol = CCITT V.110 & X.30 )
8F - 1 ....... РАСШИРЕНИЕ .0 ...... синхронный/Асинхронный = Синхронные данные
.. 0..... Переговоры = В-полосе переговоры, не возможные
... 01111 Пользовательских разрядов = 56 kbit/s V.6. (8F 1....... EXT
.0...... Synchronous/Asynchronous = Synchronous data
..0..... Negotiation = In-band negotiation not possible
...01111 User rate = 56 kbit/s V.6 )
6С - Элемент Информации = ЗВОНЯЩИЙ НОМЕР СТОРОНЫ (CgPN). (Info Element = CALLING PARTY NUMBER (CgPN) )
07 - Длина = 7 октетов. (07 Length = 7 octets )
00 - 0 ....... РАСШИРЕНИЙ
.000.... Тип числа(номера) = Неизвестный
.... 0000 Насчитывающих планирует = Неизвестный. (00 0....... EXT
.000.... Type of number = Unknown ....0000 Numbering plan = Unknown )
80 - 1 ....... РАСШИРЕНИЕ
.00..... Индикатор представления = позволенное Представление
... 000.. Запасной бит (ы) ...... 00 индикаторов Screening = Пользователь, если, не показанный на экране. (80 1....... EXT .00..... Presentation indicator = Presentation allowed
...000.. Spare bit(s)
......00 Screening indicator = User provided, not screened )
цифры Номера = 23974. (32 33 39 37
Number digits = 23974 )

1.4. Основные сценарии IP-телефонии
Наиболее часто используются 3 сценария IP-телефонии:
1. “компьютер-компьютер”;
2. “компьютер-телефон”;
3. “телефон-телефон”.
Если оба абонента подключены с помощью терминала Если оба абонента подключены с помощью терминала Н.323, то не требуется подключения шлюзов.Нет перехода с одной технологии на другую, т.к. протокол Н.323 поддерживают сами терминалы.
При технологии “телефон-компьютер” рассматриваются две модификации:
- от компьютера (пользователя IP-сети) к телефону (абоненту ТфОП) (рисунок 5)
- от абонента ТфОП к пользователю IP-сети с идентификацией вызываемой стороны на основе нумерации по Е.164 или IP-адресации (рисунок 6).

Функции передачи
Функции приема
Функции передачи
Функции приема
Абонент А
Абонент Б
Рисунок 2. Сценарий IP-телефонии "компьютер-компьютер"
Демонстрация по левому щелчку мыши!!!
АЦП
ЦАП
АЦП
ЦАП
Сжатие
речевой
информации
Развертывание
речевой
информации
Сжатие
речевой
информации
Развертывание
речевой
информации
пакетизация
Управление и
сигнализация
депакетизация
пакетизация
Управление и
сигнализация
депакетизация
IP-сеть
Сжатые речевые данные поступают в
устройство, развертывающее их в
первоначальную форму, т.е речевые
данные снова преобразуются в
аналоговую форму с помощью
цифро-аналогового преобразователя
(ЦАП) и попадают в телефон
абонента Б
Под IP-сетью, подразумевается
либо глобальная сеть
Интернет, либо корпоративная
сеть предприятия Intranet.
В этом сценарии аналоговые речевые
сигналы от микрофона абонента А
преобразуются в цифровую форму с
помощью аналого-цифрового
преобразователя (АЦП), обычно
при 8000 отсчетов/с, 8 битов/отсчет,
в итоге - 64 Кбит/с.
Отсчеты речевых данных
в цифровой форме затем
сжимаются кодирующим устройством
для сокращения нужной для их
передачи полосы в отношении
4:1, 8:1 или 10:1.
Выходные данные после сжатия
формируются в пакеты, к которым
добавляются заголовки протоколов,
после чего пакеты передаются
через IP-сеть в систему IP-телефонии,
обслуживающую абонента Б.
Когда пакеты принимаются
системой абонента Б, заголовки
протокола удаляются.

Назад
Содержание
Н.323-терминал
Н.323-терминал
Рисунок 3. Упрощенный сценарий IP-телефонии "компьютер-компьютер"
(аналог рисунка 2)
Для поддержки сценария "компьютер - компьютер» поставщику
услуг Интернет желательно иметь отдельный сервер (привратник),
преобразующий имена пользователей в динамические адреса IP.
Сам сценарий ориентирован на пользователя, которому сеть
нужна, в основном, для передачи данных, а программное
обеспечение IP-телефонии требуется лишь иногда для
разговоров с коллегами.
IP-сеть

Н.323-терминал
Н.323-терминал
шлюз
шлюз
Рисунок 4. Упрощенный сценарий IP-телефонии "компьютер-компьютер". Соединение пользователей IP-сетей через транзитную СКК
Назад
Содержание
IP-сеть
IP-сеть
ТФОП / ISDN

Н.323-терминал
шлюз
Вызов инициирован пользователем IP-сети
Рисунок 5. Вызов абонента ТфОП пользователем IP-сети по сценарию "компьютер - телефон"
Назад
Содержание
Используйте левую кнопку мыши!!!
IP-сеть
ТФОП / ISDN
Шлюз (GW) для взаимодействия сетей
ТфОП и IP может быть реализован
в отдельном устройстве или интегрирован
в существующее оборудование ТфОП
или IP-сети. Показанная на рисунке сеть
СКК может быть корпоративной
сетью или сетью общего
пользования.

Н.323-терминал
шлюз
Вызов инициирован абонентом ТфОП
Рисунок 6. Пользователя IP-сети вызывает абонент ТФОП по сценарию "компьютер - телефон"
Назад
Содержание
Демонстрация левым щелчком мыши!
ТФОП / ISDN
IP-сеть
При попытке вызвать справочно
-информационную службу,
используя услуги пакетной телефонии
и обычный телефон, на
начальной фазе абонент А
вызывает близлежащий
шлюз IP-телефонии
От шлюза к абоненту А поступает запрос
ввести номер, к которому должен быть
направлен вызов (например, номер службы),
и личный идентификационный номер (PIN)
для аутентификации и последующего
начисления платы, если это служба, вызов
которой оплачивается вызывающим абонентом.
Основываясь на вызываемом номере,
шлюз определяет наиболее доступный
путь к данной службе. Кроме того,
шлюз активизирует свои функции кодирования
и пакетизации речи, устанавливает
контакт со службой, ведет мониторинг процесса
обслуживания вызова и принимает информацию
о состояниях этого процесса (например,
занятость, посылка вызова, разъединение и т.п.)
от исходящей стороны через протокол управления
и сигнализации.
Разъединение с любой стороны
передается противоположной
стороне по протоколу сигнализации
и вызывает завершение установленных
соединений и освобождение
ресурсов шлюза для обслуживания
следующего вызова

шлюз
шлюз
Рисунок 7. Соединение абонентов ТфОП через транзитную IP-сеть по сценарию "телефон-телефон"
Назад
Демонстрация левым щелчком мыши!
Конец раздела
IP-сеть
ТФОП/ISDN
ТФОП/ISDN
Поставщики услуг IP-телефонии
предоставляют услуги "телефон-телефон»
путём установки шлюзов IP-телефонии
на входе и выходе IP-сетей. Абоненты
подключаются к шлюзу поставщика через ТфОП,
набирая специальный номер доступа.
Абонент получает доступ к шлюзу,
используя персональный идентификационный
номер (PIN) или услугу идентификации номера
вызывающего абонента
(Calling Line Identification)
После этого шлюз просит ввести
телефонный номер вызываемого абонента,
анализирует этот номер и определяет,
какой шлюз имеет лучший доступ к нужному
телефону. Как только между входным
и выходным шлюзами устанавливается
контакт, дальнейшее установление
соединения к вызываемому абоненту
выполняется выходным шлюзом через
его местную телефонную сеть

Назад
Содержание
1.3.Сигнализация Н.323
1.3.1 Алгоритмы установления, поддержания
и разрушения соединения
1.3.2 Базовое соединение с участием привратника
1.3.3 Базовое соединение без участия привратника
1.3.4 Установление соединения с участием шлюза

3.1 Алгоритмы установления, поддержания и разрушения соединения
Рассмотрим наиболее часто применяемые на практике примеры базового соединения в сети, базирующейся на рекомендации Н.323. В качестве примеров взяты случаи:
- вызываемый и вызывающий пользователи зарегистрированы в одном и том же привратнике, который маршрутизирует сигнальную и управляющую информацию;
- вызываемый и вызывающий пользователи соединяются непосредственно друг с другом, привратник в сети отсутствует.
Прежде чем рассматривать эти два сценария, отметим, что в общем случае алгоритмы установления, поддержания и разрушения соединений по Н.323 включают в себя следующие фазы:
Фаза А. Установление соединения;
Фаза В. Определение ведущего/ведомого оборудования и обмен данными о функциональных возможностях;
Фаза С. Установление аудиовизуальной связи между вызывающим и вызываемым оборудованием;
Фаза D. Изменение полосы пропускания, запрос текущего состояния оборудования, создание конференций и обращение к дополнительным услугам;
Фаза Е. Завершение соединения.

Обнаружение привратника
Для взаимодействия оконечного оборудования с привратником нужно, чтобы устройству стал известен сетевой адрес подходящего привратника. Процесс определения этого адреса называется обнаружением привратника.
Определены два способа обнаружения - ручной и автоматический.
Ручной способ заключается в том, что привратник, обслуживающий данное устройство, определяется заранее при конфигурации этого устройства. Первая фаза установления соединения начинается сразу с запроса регистрации устройства, который передается на уже известный сетевой адрес привратника и на UDP-порт 1719, а в случае взаимодействия с привратником, поддерживающим первую версию протокола Н.323, - на порт 1718.
Оконечное
оборудование
Привратник
GRQ
GCF / GRJ
Рассмотрим автоматический способ обнаружения привратника:
Устройство передает запрос
GRQ в режиме многоадресной рассылки,
используя IP-адрес
224.0.1.41- Gatekeeper UDP Discovery Multicast Address
- и UDP порт 1718 - Gatekeeper UDP Discovery Port.
Ответить оконечному оборудованию
могут один или несколько привратников,
передав на адрес, указанный в поле
rasAddress запроса GRQ, сообщение
GCF с предложением своих услуг
и с указанием транспортного адреса
канала RAS
Демонстрация по левому щелчку мыши!
Если привратник не имеет
возможности зарегистрировать
оконечное оборудование, он
отвечает на запрос сообщением GRJ
Рисунок 8. Автоматическое обнаружение привратника
Если на GRQ отвечает несколько привратников,
оконечное оборудование может выбрать
по своему усмотрению любой из них, после
чего инициировать процесс регистрации.
Если в течение 5 секунд ни один привратник не ответит
на GRQ, оконечное оборудование может
повторить запрос. Если ответ опять не будет получен,
необходимо прибегнуть к ручному способу
обнаружения привратника. При возникновении
ошибки в процессе регистрации у своего привратника,
т.е. при получении отказа в регистрации или при
отсутствии ответа на запрос регистрации, оконечное
оборудование должно провести процедуру
обнаружения привратника снова.

Таблица 1. Сообщения RAS
О (options) - необязательное, М (mandatory) - обязательное.
1
2
3
4
5
6

Продолжение таблицы 1. Сообщения RAS
1
2
3
4
5
6

Продолжение таблицы 1. Сообщения RAS
1
2
3
4
5
6

Продолжение таблицы 1. Сообщения RAS
1
2
3
4
5
6

Таблица 2. Параметры сообщения RAS

Продолжение таблицы 2. Параметры сообщения RAS

Продолжение таблицы 2. Параметры сообщения RAS

Продолжение таблицы 2. Параметры сообщения RAS

Продолжение таблицы 2. Параметры сообщения RAS

Продолжение таблицы 2. Параметры сообщения RAS

Продолжение таблицы 2. Параметры сообщения RAS

Продолжение таблицы 2. Параметры сообщения RAS

Продолжение таблицы 2. Параметры сообщения RAS

Продолжение таблицы 2. Параметры сообщения RAS

Продолжение таблицы 2. Параметры сообщения RAS

Продолжение таблицы 2. Параметры сообщения RAS

Продолжение таблицы 2. Параметры сообщения RAS

Продолжение таблицы 2. Параметры сообщения RAS

Продолжение таблицы 2. Параметры сообщения RAS

Таблица 3. Связь процедур и параметров

Продолжение таблицы 3. Связь процедур и параметров

Продолжение таблицы 3. Связь процедур и параметров

Продолжение таблицы 3. Связь процедур и параметров

Продолжение таблицы 3. Связь процедур и параметров

Продолжение таблицы 3. Связь процедур и параметров

Продолжение таблицы 3. Связь процедур и параметров

Регистрация оконечного оборудования
Оконечное
оборудование
Привратник
Оконечное
оборудование
Оконечное
оборудование
Привратник
Привратник
Регистрация оконечного оборудования у привратника
Инициирование процесса отмены регистрации оконечным оборудованием
Инициирование процесса отмены регистрации привратником
RRQ
RСF or RRJ
URQ
UСF/URJ
URQ
UСF
Рисунок 9. Процесс регистрации и отмены регистрации
Оконечное оборудование
может отменить регистрацию
у привратника, передав
сообщение Unregister Request (URQ)
Привратник должен ответить подтверждением
UCF. Такая процедура
позволяет оборудованию изменить свой
alias-адрес или транспортный адрес. Если
оборудование не было зарегистрировано у
привратника, последний должен
ответить на требование URQ отказом URJ
При получении сообщения URQ
оконечное оборудование
должно ответить подтверждением
UCF
Оконечное оборудование передает
запрос регистрации RRQ
на сетевой адрес привратника, либо
Полученный при выполнении процедуры
его автоматического обнаружения, либо
известный априори. Стоит отметить, что
запрос направляется на общеизвестный
номер UDP-порта 1719.
Этот порт имеет соответствующее
название - Gatekeeper UDP
Registration and Status Port.
Привратник отвечает на запрос
подтверждением RCF
или отказом в регистрации
RRJ. Если оконечное
оборудование не указывает свой
alias-адрес в запросе RRQ, привратник
может сам назначить такой адрес и
вернуть его в сообщении RCF
Привратник может отменить
регистрацию оборудования,
передав сообщение
URQ

Доступ к сетевым ресурсам
Оконечное
оборудование
Привратник
ARQ
ACF / ARJ
Демонстрация по левому щелчку мыши! В сообщении ARQ обязательно содержится идентификатор оборудования, пославшего сообщение ARQ, и контактная информация того оборудования, с которым желает связаться оборудование, пославшее сообщение ARQ. Контактная информация оборудования включает в себя alias-адрес и/или транспортный адрес сигнального канала, но, как правило, в запрос ARQ помещается только alias-адрес вызываемого оборудования. В сообщении ARQ указывается также верхний предел суммарной скорости передачи и приема пользовательской информации по всем речевым и видеоканалам без учета заголовков RTP/UDP/IP и другой служебной информации. Во время связи средняя за секунду суммарная скорость передачи и приема информации оконечным оборудованием не должна превышать этот верхний предел. Отметим, что суммарная скорость не включает в себя скорость передачи и приема информации по каналу передачи данных, по управляющему и сигнальному каналам.
Рисунок 10. Доступ к сетевым ресурсам
Привратник может выделить требуемую полосу
пропускания или снизить предел суммарной
скорости, передав сообщение ACF.
В этом же сообщении, кроме суммарной скорости,
указывается транспортный адрес сигнального
канала встречного оборудования, если сигнальный
канал будет организован непосредственно между
тем и другим оборудованием, или адрес привратника,
если он будет маршрутизировать сигнальные сообщения.
Если требуемая полоса
недоступна, привратник
передает сообщение
Admission Reject (ARJ)
В начальной фазе установления соединения,
а также после получения запроса соединения
(сообщения Setup), оборудование обращается
к привратнику при помощи запроса ARQ
с просьбой разрешить соединение с другим оборудованием,
что является началом процедуры доступа к сетевым ресурсам.
Важно отметить, что процедура доступа выполняется
всеми участниками соединения

Определение местоположения оборудования в сети
Оконечное
оборудование
Привратник
LRQ
LCF / LRJ
Демонстрация по левому щелчку мыши!
Оконечное оборудование или привратник,
которые имеют alias-адрес некоторого
оборудования и желают узнать его
контактную информацию (адреса сигнального
канала и канала RAS), могут послать запрос
LRQ по адресу канала RAS
отдельно взятого привратника или
по общему адресу всех привратников
(режим Gatekeeper's Discovery Multicast)
Привратник, у которого зарегистрировано
указанное оборудование, должен ответить
сообщением LCF,
содержащим требуемую контактную
информацию
Привратник, получивший на транспортный адрес
своего канала RAS запрос LRQ, должен ответить
отказом LRJ, если искомое оборудование
у него не зарегистрировано. Те же привратники, у которых
искомое оборудование не зарегистрировано, а сообщение
LRQ было получено в режиме многоадресной рассылки
Gatekeeper's Discovery Multicast, вообще не должны
отвечать на запрос
Рисунок 11 Определение местоположения оборудования в сети

Изменение полосы пропускания
Оконечное
оборудование
Привратник
BRQ
BCF / BRJ
Демонстрация по левому щелчку мыши!
В процессе обслуживания вызова оконечное оборудование или привратник могут предпринять попытку изменить в ту или иную сторону суммарную скорость передачи информации. Данная процедура называется изменением полосы пропускания.
Оконечное оборудование может изменять суммарную скорость, не обращаясь за разрешением к привратнику, если после этого изменения средняя суммарная скорость не превысит предела, определенного при получении доступа к сетевым ресурсам.
Рисунок 12. Изменение полосы пропускания в процессе обслуживания вызова
Оконечное оборудование, которому нужно
превысить указанный предел, должно передать
привратнику запрос BRQ,
но до получения ответа средняя
суммарная скорость должна быть не
выше этого предела.
Если привратник может выделить требуемую
полосу пропускания, он отвечает сообщением
BCF. Далее речевые
и видеоканалы закрываются, а затем при помощи
управляющих сообщений Н.245 открываются каналы
с новой скоростью передачи и приема информации.
Если же привратник по каким-либо причинам не может
удовлетворить требование оборудования, он отклоняет
это требование и передает сообщение BRJ

Опрос текущего состояния оборудования
Оконечное
оборудование
Привратник
IRQ
IRR
Демонстрация по левому щелчку мыши!
Привратник в любой момент времени может определить текущее состояние оборудования, т.е. установить, доступно ли ему это оборудование. Данный процесс называется опросом текущего состояния оборудования. Очевидно, что если питание оборудования выключено, или если в его работе возникла какая-либо неисправность, то оборудование становится недоступным.
Рисунок 13. Опрос текущего состояния оборудования
Получив запрос IRQ, оконечное
оборудование должно передать
запрашиваемую информацию в
сообщении IRR
Запрос информации о текущем
состоянии (статусе) оборудования
производится привратником при
помощи сообщения IRQ.
Интервал между посылками IRQ
оставлен на усмотрение производителя,
но должен быть не меньше 10с

Освобождение полосы пропускания
Оконечное
оборудование
Привратник
DRQ
DCF
Демонстрация по левому щелчку мыши!
Следует отметить, что после того, как полоса пропускания освобождена, оконечное оборудование не должно передавать незапрашиваемые сообщения IRR. Привратник может сам инициировать освобождение сетевых ресурсов, т.е. разрушение существующего соединения, передав сообщение DRQ. Получив сообщение DRQ, оконечное оборудование должно закрыть логические каналы, управляющий и сигнальный каналы, а затем ответить подтверждением DCF.
В случае, если привратник инициирует завершение конференции, сообщение DRQ должно передаваться каждому ее участнику.
Рисунок 14. Освобождение полосы пропускания
В конечной фазе завершения
соединения оборудование извещает
привратник об освобождении раннее
занимавшейся полосы пропускания.
Оконечное оборудование передает
своему привратнику сообщение
DRQ
Привратник отвечает
подтверждением
DCF

Демонстрация по левому щелчку мыши!
Привратник
Оконечное оборудование 2
ARQ
ACF / ARJ
Setup
Setup
Call Proceeding
Call Proceeding
ARQ
ACF
Alerting
Alerting
Connect
Connect
TerminalCapabilitySet
TerminalCapabilitySetAck
MSD
MSDAck
OpenLogicalChannel
EndSessionCommand
РАЗГОВОРНАЯ ФАЗА
OpenLogicalChannelAck
Release Complete
DRQ
DCF
TerminalCapabilitySet
TerminalCapabilitySetAck
MSD
MSDAck
OpenLogicalChannel
OpenLogicalChannelAck
EndSessionCommand
Release Complete
DRQ
DCF
3.2 Базовое соединение с участием привратника
Рисунок 15. Пример соединения с участием привратника
Вызывающее оборудование
передает сообщение ARQ
с alias-адресом вызываемого
абонента
В ответ привратник передает сообщение
ACF с уведомлением, что именно он
будет маршрутизировать сигнальные
сообщения (Gatekeeper routed call signaling),
и с указанием транспортного адреса
своего сигнального канала
Далее вызывающее
оборудование передает на
этот транспортный адрес
запрос соединения Setup
Привратник пересылает
сообщение Setup
вызываемому
оборудованию
Также привратник передает
вызывающему оборудованию
сообщение Call Proceeding,
означающее, что полученной
информации достаточно для
обслуживания поступившего
вызова
Вызываемое оборудование
также отвечает на Setup
сообщением Call Proceeding
Если оборудование имеет возможность
принять вызов, оно передает запрос
допуска к ресурсам сети ARQ, на который
привратник может ответить подтверждением
ACF или отказом в допуске к ресурсам
сети ARJ
После того как вызываемый пользователь
примет входящий вызов, привратнику
передается сообщение Connect с
транспортным адресом
управляющего канала Н.245
вызываемого оборудования
Привратник заменяет этот адрес
транспортным адресом своего
управляющего канала Н.245 и
пересылает Connect вызывающему
оборудованию, после чего
открывается управляющий
канал Н.245
После открытия управляющего канала
Н.245 начинается обмен данными о функциональных
возможностях оборудования. В рассматриваемом нами
случае все управляющие сообщения, передаваемые
от одного оконечного оборудования к другому,
маршрутизируются привратником. Терминалы
обмениваются сообщениями TermlnalCapabilttySet,
в которых указываются возможные алгоритмы
декодирования принимаемой информации.
Следует отметить, что сообщение
TermjnalCapabllHySet должно быть первым
сообщением, передаваемым по
управляющему каналу.
Оборудование, принявшее сообщение
TermlnalCapabllitySet от другого оборудования,
подтверждает его получение передачей
сообщения TermlnalCapabllttySetAck
В ответ на полученные сообщения
masterSlaveDetermination оба устройства
передают сообщения masterSlaveDeterminationAck,
в которых указывается, какое из этих устройств
является для данного соединения ведущим, а какое - ведомым.
Напомним, что возможен сценарий процедуры
Master-Slave Determination, предусматривающий
сокращение количества передаваемых
сообщений
После обмена данными о функциональных
возможностях и определения ведущего и
ведомого оборудования может выполняться
процедура открытия однонаправленных
логических каналов. В требовании открыть
логический канал (в нашем случае - прямой
логический канал) openLogicalChannel оборудование
указывает вид информации, который будет
передаваться по этому каналу, и алгоритм
кодирования. В нашем случае логический канал
предназначается для переноса речи, поэтому
в сообщение openLogicalChannel включается
параметр mediaControlChannel с указанием
транспортного адреса канала RTCP, при помощи
которого производится контроль передачи
RTP пакетов
В ответ на сообщение openLogicalChannel
оборудование должно передать
подтверждение openLogicalChannelAck,
в котором указывается транспортный адрес,
на который передающей стороне
следует посылать RTP пакеты,
а также транспортный адрес канала RTCP
Далее открывается разговорная сессия.
Оборудование вызывающего пользователя
передает речевую информацию, упакованную
в пакеты RTP/UDP/IP, на транспортный адрес
RTP-канала оборудования вызванного пользователя,
а вызванный пользователь передает пакетированную
речевую информацию на транспортный адрес
RTP-канала оборудования вызывающего пользователя.
При помощи канала RTCP ведется контроль
передачи информации по RTP каналам
После окончания разговорной фазы
начинается фаза разрушения соединения.
Оборудование пользователя, инициирующего
разъединение, должно прекратить передачу речевой
информации, закрыть логические каналы и передать
по управляющему каналу сообщение Н.245
endSessionCommand, означающее, что
пользователь хочет завершить соединение
Далее от встречного оборудования
ожидается сообщение endSessionCommand,
после приема которого управляющий
канал Н.245 закрывается
Следующим шагом, если сигнальный канал
еще открыт, передается сообщение Release Complete.
Пользователь, получивший команду
endSessionCommand от пользователя, инициировавшего
разрушение соединения, должен прекратить передачу
речевой информации, закрыть логические
каналы и передать сообщение endSessionCommand.
Далее, если сигнальный канал остался открытым,
передается сообщение Release Complete,
и сигнальный канал закрывается
После вышеописанных действий оконечное
оборудование извещает привратник об
освобождении зарезервированной полосы пропускания.
С этой целью каждый из участников соединения
передает по каналу RAS запрос выхода из
соединения DRQ
На запрос DRQ привратник должен
ответить подтверждением DCF,
после чего обслуживание вызова
считается завершенным
Оконечное оборудование 1
Затем инициируется процедура определения
ведущего/ведомого оборудования, необходимая
для разрешения конфликтов, возникающих между
двумя устройствами при организации конференции,
когда оба они могут быть активными контроллерами
конференций, или между двумя устройствами, пытающимися
одновременно открыть двунаправленные логические
каналы. В ходе процедуры устройства
обмениваются сообщениями masterSlaveDetermlnation
В первом случае вызываемое оборудование
передает сообщение Alerting, и привратник
маршрутизирует его к вызывающему
оборудованию.Вызываемому пользователю
подается визуальный или акустический сигнал
о входящем вызове, а вызывающему
дается индикация того, что вызываемый
пользователь не занят и ему подается
вызывной сигнал. При отказе в допуске
к ресурсам сети вызываемое оборудование
закрывает сигнальный канал путем передачи
привратнику сообщения Release
Complete.
В Начало

Обозначения и пояснения к рисунку:
«Пример соединения с участием привратника»
Сообщения Н.245
Сообщения RAS
Сигнальные сообщения
Чтобы ускорить открытие разговорной сессии, управляющий канал может быть открыт вызываемым оборудованием после получения сообщения Setup с транспортным адресом управляющего канала Н.245 вызывающего оборудования или привратника, или вызывающим пользователем после получения сообщения Call Proceeding или Alerting, содержащего транспортный адрес управляющего канала Н.245 вызываемого пользователя или привратника.

Демонстрация по щелчку мыши!
3.3 Базовое соединение без участия привратника
Рисунок 16. Пример соединения без участием привратника
Оконечное оборудование 1
Оконечное оборудование 2
РАЗГОВОРНАЯ ФАЗА
Setup
Call proceeding
Alerting
Connect
TCS
TCS
TCSAck
TCSAck
MSD
MSD
MSDAck
MSDAck
OLC
OLC
OLCAck
OLCAck
EndSessionCommand
EndSessionCommand
Release Complete
Вызывающее оборудование
посылает запрос соединения
Setup на известный
Транспортный адрес
сигнального канала
вызываемого оборудования
Вызываемое
оборудование отвечает
на Setup сообщением
Call Proceeding
Затем сообщение Alerting.
Вызываемому пользователю
дается визуальный или
акустический сигнал о
входящем вызове, а вызывающему
- индикация того, что
вызываемый пользователь
не занят и получает вызывной
сигнал
Как только вызываемый
пользователь примет входящий
вызов, передается сообщение
Connect с указанием
транспортного адреса
Управляющего канала Н.245
вызываемого оборудования,
после чего открывается
управляющий канал Н.245
Далее открывается разговорная сессия.
Оборудование вызывающего пользователя
передает речевую информацию,
упакованную в пакеты RTP/UDP/IP, на
транспортный адрес RTP-канала оборудования
вызываемого пользователя, а оно, в свою очередь,
передает пакетированную речевую информацию
на транспортный адрес RTP-канала оборудования
вызывающего пользователя
После окончания разговорной фазы
начинается фаза разрушения соединения.
Оборудование пользователя, инициирующего
разъединение, прекращает передачу речевой
информации, закрывает логические
каналы и передает по управляющему каналу
сообщение Н.245 endSessionCommand,
означающее, что пользователь хочет
завершить соединение
Следующим шагом передается сообщение
Release Complete, и сигнальный канал
закрывается. Пользователь, получивший команду
endSessionCommand от пользователя,
инициировавшего разъединение, должен
прекратить передачу речевой информации,
закрыть логические каналы и передать
сообщение endSessionCommand. Далее, если
сигнальный канал остался открытым, передается
сообщение Release Complete, сигнальный
канал закрывается, и обслуживание
вызова считается завершенным
Ожидается сообщение
endSessionCommand от встречного
оборудования, после чего
управляющий канал Н.245
закрывается
После открытия управляющего канала
выполняются все процедуры,
описанные в первом случае: обмен
данными о функциональных возможностях,
определение ведущего/ведомого
оборудования, открытие однонаправленных
логических каналов
Важно!
В Начало

Обозначения и пояснения к рисунку:
«Пример соединения без участия привратника»
Сообщения Н.245
Сигнальные сообщения
Случай, когда вызываемое и вызывающее оборудование взаимодействуют непосредственно друг с другом, привратник в сети отсутствует.
И здесь, чтобы ускорить открытие разговорной сессии, управляющий канал тоже может быть открыт вызываемым оборудованием после получения сообщения Setup с транспортным адресом управляющего канала Н.245 вызывающего оборудования, или вызывающим пользователем после получения сообщения Call Proceeding или Alerting, в котором содержится транспортный адрес управляющего канала Н.245 вызываемого оборудования.

Рассмотрим наиболее часто используемые сигнальные сообщения:
Сообщение Setup передается вызывающим оборудованием с целью установить соединение. Это сообщение передается на общеизвестный TCP порт 1720 вызываемого оборудования.
Сообщение Call Proceeding передается вызывающему оборудованию, чтобы известить его о том, что вызов принят к обслуживанию.
Сообщение Alerting передается вызывающему оборудованию и информирует его о том, что вызываемое оборудование не занято, и что пользователю подается сигнал о входящем вызове.
Сообщение Connect передается вызывающему оборудованию и информирует его о том, что вызываемый пользователь принял входящий вызов. Сообщение Connect может содержать транспортный адрес управляющего канала Н.245.
Сообщение Release Complete передается вызывающим или вызываемым оборудованием с целью завершить соединение. Это сообщение передается только в том случае, когда открыт сигнальный канал.

Рассмотрим варианты, предполагающие участие шлюза - элемента сети Н.323. Первый вариант - это случай, когда абонент ТфОП вызывает пользователя IP-сети, второй - когда пользователь IP-сети вызывает абонента ТфОП, а в третьем варианте абонент ТфОП вызывает абонента ТфОП, но соединение проходит через IP-сеть. В первом варианте с точки зрения протоколов Н.323 соединение устанавливается так же, как соединение участников, включенных в сеть с маршрутизацией пакетов IP. Рассмотрим ситуацию с точки зрения ТфОП. Существует два способа набора номера вызываемого абонента: одноступенчатый и двухступенчатый.
3.4 Установление соединения с участием шлюза
Вызывающий
абонент
Вызываемый
абонент
Рисунок 17. Одноступенчатый способ набора номера вызываемого абонента
Демонстрация по левому щелчку мыши!
ПроцедураSetup.Вызывающий
абонент сразу набирает
номер вызываемого абонента
Setup.И шлюз
устанавливает с
ним соединение
Пока устанавливается
соединение в IP-сети, шлюз
может передать
вызывающему абоненту ТфОП
сообщение Call Proceeding,
чтобы перезапустить таймеры

В сетях связи общего пользования применяется двухступенчатый способ.
Следует отметить, что необходимость в наборе персонального кода возникает не всегда, так как номер вызывающего абонента может содержаться в сигнальных сообщениях систем сигнализации DSS1 и ОКС7, а при использовании систем сигнализации 2ВСК или аналоговых систем сигнализации - определяться при помощи АОН.Существует несколько способов идентификации абонентов. В первом случае alias-адрес абонента (PIN-код или телефонный номер) шлюз передает привратнику в сообщении ARQ. Во втором случае идентификационный номер вызывающего абонента, набранный с помощью DTMF, передается специальному серверу.
Вызывающий
абонент
Вызываемый
абонент
Демонстрация по левому щелчку мыши!
Рисунок 18. Двухступенчатый способ набора номера вызываемого абонента
Затем абонент вводит свой
персональный код для идентификации
и номер вызываемого абонента;
эта информация передается
по проключенному разговорному
тракту сигналами DTMF
Процедура Setup.Вызывающий абонент
сначала набирает телефонный номер
шлюза и устанавливает с ним
соединение

Во втором сценарии, когда пользователь IP-сети вызывает абонента ТфОП при помощи шлюза, с точки зрения протоколов Н.323 соединение устанавливается так же, как описанное соединение участников, включенных в сеть с маршрутизацией пакетов IP.Сценарий вызова абонента ТфОП абонентом ТфОП является комбинацией двух предыдущих сценариев и с технической точки зрения не содержит никаких новых процедур.
Вызывающий
абонент
Вызываемый
абонент
Демонстрация по левому щелчку мыши!
Рисунок 19. Пользователь IP-сети вызывает абонента ТфОП при помощи шлюза.
Вызываемое оборудование
организует сигнальный канал
Н.225.0 со шлюзом
(при участии или без
участия привратника)
Далее передается требование
на установление соединения
Setup, которое содержит
телефонный номер вызываемого
абонента в формате Е. 164
Пока устанавливается соединение в
ТфОП, шлюз может передать вызывающему
абоненту IP-сети сообщение Call Proceeding,
чтобы перезапустить таймеры, если в
течение 4 секунд после приема сообщения
Setup он не передал сообщения Alerting,
Connect или Release Complete.
Чтобы указать, что вызов выходит за
пределы IP-сети, в сообщения Alerting,
Call Proceeding, Progress и Connect должен
включаться информационный элемент
Progress Indicator

2.1. Протокол TCP
2.2. Протокол UDP
2.3. Протокол RTP и
RTCP
2.4. Протокол IP
2.Транспортные протоколы
Содержание

2.1. Протокол TCP
Протокол управления передачей информации - Transmission Control Protocol (TCP) - был разработан для поддержки интерактивной связи между компьютерами. Протокол TCP обеспечивает надежность и достоверность обмена данными между процессами на компьютерах, входящих в общую сеть.
Протокол TCP не приспособлен для передачи мультимедийной информации. Основная причина - обеспечение требуемой достоверности путем повторной передачи потерянных пакетов. Пока передатчик получит информацию о том, что приемник не принял очередной пакет, и передаст его снова, проходит слишком много времени. Приемник вынужден либо ждать прихода повторно переданного пакета, разрушая структуру потоковых данных, либо игнорировать этот пакет, игнорируя одновременно принятый в TCP механизм обеспечения достоверности. Кроме того, TCP предусматривает механизмы управления скоростью передачи с целью избежать перегрузок сети.
Аудиоданные и видеоданные требуют, однако, строго определенных скоростей передачи, которые нельзя изменять произвольным образом.

Рисунок 20. Структура сетевого программного обеспечения стека
протоколов TCP/IP
Назад
Содержание
Ethernet
Ethernet
Приложения TCP
UDP
IP
ARP
Прямоугольники обозначают
модули, обрабатывающие
данные
линии, соединяющие
прямоугольники, - пути
передачи данных
Демонстрация по щелчку мыши
С одной стороны протокол TCP
взаимодействует с прикладным протоколом
пользовательского приложения, а с другой
стороны -с протоколом, обеспечивающим “низкоуровневые”
функции маршрутизации и адресации пакетов,
которые, как правило, выполняет IP.
Горизонтальная линия
обозначает сеть Ethernet,
которая используется в качестве
примера физической среды
В модели межсетевого соединения взаимодействие
TCP и протоколов нижнего уровня, вообще говоря,
не специфицировано, за исключением того, что должен
существовать механизм, который обеспечивал бы
асинхронную передачу информации от одного
уровня к другому. Результатом работы этого механизма
является инкапсуляция протокола более высокого
уровня в тело протокола более низкого уровня.
Каждый TCP-пакет вкладывается в “пакет”
протокола нижележащего уровня, например, IP.
Получившаяся таким образом дейтаграмма содержит
в себе TCP-пакет так же, как TCP-пакет
содержит пользовательские данные.

Состав и назначение полей заголовка
Пакеты протокола TCP переносятся в поле “Данные” IP-дейтаграммы.Заголовок пакета TCP следует за заголовком дейтаграммы. Структура заголовка пакета TCP
представлена на рисунке 21.
Демонстрация по щелчку мыши!
Порт отправителя
Порт получателя
Порядковый номер
Номер при подтверждении
Смещение
данных
Резерв
PSH
URG
ACK
RST
SYN
FIN
Окно
Указатель
срочности
Контрольная сумма
Опции
Заполнение
Данные
Рисунок 21. Заголовок пакета TCP
Порт отправителя (Source Port, 6 битов). Порт получателя (Destination Port, 16 битов)
Порядковый номер (Sequence Number,
32 бита). Если в пакете отсутствует флаг SYN,
то это - номер первого октета данных в этом пакете.
Если флаг SYN в пакете присутствует, то номер
данного пакета становится номером начала
последовательности (ISN), и номером первого
октета данных становится номер ISN+1.
Номер при подтверждении (Acknowledgment
Number, 32 бита) -если пакет содержит
установленный флаг АСК, то это поле содержит
номер следующего ожидаемого получателем
октета данных. При установленном соединении
пакет подтверждения отправляется всегда.
Поле величины смещения
данных (Data Offset,4 бита)
указывает количество 32-битовых
слов заголовка TCP-пакета.
Резерв (Reserved,
6 битов) - зарезервированное
поле.
URG - флаг срочности
АСК - флаг пакета,
содержащего подтверждение
получения
PSH - флаг
форсированной
отправки
RST - сброс соединения
SYN - синхронизация
порядковых номеров
FIN - флаг окончания
передачи со стороны
отправителя
Окно (Window, 16 битов) - поле
содержит количество байтов
данных, которое отправитель данного
сегмента может принять,
считая от байта с номером,
указанным в поле Номер
при подтверждении
Поле контрольной
суммы (Checksum,
16 битов)
Поле указателя срочности данных
(Urgent Pointer, 16 битов). Это поле содержит
номер пакета, начиная с которого следуют
пакеты повышенной срочности. Указатель
принимается во внимание только
в сегментах с установленным
флагом URG
Опции (Options) - поле
дополнительных параметров,
может быть переменной
длины
Заполнение (Padding) - поле,
заполняемое нулями для
выравнивания заголовка
до размера, кратного
32-битам

2.2. Протокол UDP
Протокол передачи пользовательских дейтаграмм - User Datagram Protocol (UDP) предназначается для обмена дейтаграммами между процессами компьютеров, расположенных в объединенной системе компьютерных сетей.
Протокол UDP базируется на протоколе IP и предоставляет прикладным процессам транспортные услуги, немногим отличающиеся от услуг протокола IP. Протокол UDP обеспечивает негарантированную доставку данных, т.е. не требует подтверждения их получения. Кроме того, данный протокол не требует установления соединения между источником и приемником информации, т. е. между модулями UDP.
К заголовку IP-пакета протокол UDP добавляет служебную информацию в виде заголовка UDP-пакета (рисунок 20). Модуль IP, реализованный в принимающей рабочей станции, передает поступающий из сети IP-пакет модулю UDP, если в заголовке этого пакета указано, что протоколом верхнего уровня является протокол UDP. При получении пакета от модуля IP модуль UDP проверяет контрольную сумму, содержащуюся в его заголовке. Если контрольная сумма равна нулю, значит, отправитель ее не подсчитал.
Назад
Содержание

Рисунок 22. Формат UDP-пакета
Порт отправителя
Данные
Длина
Порт получателя
Контрольная сумма
...
Демонстрация по щелчку мыши!
Порт отправителя (Source Port) - поле
указывает порт рабочей станции, передавшей
дейтаграмму. На этот порт следует
адресовать ответную дейтаграмму.
Если данное поле не используется,
оно заполняется нулями.
Порт получателя (Destination Port)
- поле идентифицирует порт
рабочей станции, на которую
будет доставлен пакет
Длина (Length) - это поле информирует
о длине UDP-пакета в октетах,
включая как заголовок, так и
данные. Минимальное значение
длины равно восьми
Контрольная сумма (Checksum) - поле проверки правильности
передачи данных заголовка пакета, псевдозаголовка
и поля полезной нагрузки пакета. Если данное поле не используется,
оно заполняется нулями. Протоколы UDP и TCP имеют
один и тот же алгоритм вычисления контрольной
суммы (RFC-1071), но механизм ее вычисления для
UDP-пакета имеет некоторые особенности.
В частности, UDP-дейтаграмма может содержать
нечетное число байтов, и в этом случае к ней,
для унификации алгоритма, добавляется
нулевой байт, который никуда не пересылается.

2.3. Протокол RTP и RTCP
Комитетом IETF был разработан протокол транспортировки информации в реальном времени - Realtime Transport Protocol (RTP), который стал базисом практически для всех приложений, связанных с интерактивной передачей речевой и видеоинформации по сети с маршрутизацией пакетов.
Уже длительное время ведется работа по созданию методов уменьшения джиттера и задержек. Для этого могут применяться механизмы, обеспечивающие пользователю заданный уровень качества обслуживания. Они, конечно, улучшают качество услуг, предоставляемых сетью, но не могут совсем устранить образование очередей в сетевых устройствах и совсем убрать джиттер.
Именно протокол RTP позволяет компенсировать негативное влияние джиттера на качество речевой и видеоинформации. В то же время, он не имеет собственных механизмов, гарантирующих своевременную доставку пакетов или другие параметры качества услуг, -это осуществляют нижележащие протоколы.
Обычно протокол RTP базируется на протоколе UDP и использует его функции, но может работать и поверх других транспортных протоколов.
Назад
Содержание

Протокол RTP предусматривает индикацию типа полезной нагрузки и порядкового номера пакета в потоке, а также применение временных меток. Отправитель помечает каждый RTP-пакет временной меткой, получатель извлекает ее и вычисляет суммарную задержку. Разница в задержке разных пакетов позволяет определить джиттер и смягчить его влияние - все пакеты будут выдаваться приложению с одинаковой задержкой.
Итак, главная особенность RTP - это вычисление средней задержки некоторого набора принятых пакетов и выдача их пользовательскому приложению с постоянной задержкой, равной этому среднему значению.
Однако следует иметь в виду, что временная метка RTP соответствует моменту кодирования первого дискретного сигнала пакета. Поэтому, если RTP-пакет, например, с видеоинформацией, разбивается на блоки данных нижележащего уровня, то временная метка уже не будет соответствовать истинному времени их передачи, поскольку они перед передачей могут быть установлены в очередь.
На рисунке 21 представлен основной заголовок RTP-пакета, содержащий ряд полей, которые идентифицируют такие элементы, как формат пакета, порядковый номер, источник информации, границы и тип полезной нагрузки.
Назад
Содержание

Назад
Демонстрация по нажатию левой кнопки мыши
Рисунок 23. Основной заголовок RTP-пакета
V=2
P
X
CC
M
PT
Порядковый номер
Временной штамп
Идентификатор SSRC
...
Идентификатор CSRC
0
2
3
4
8
9
16
31
V (2 бита) - поле версии
протокола. Текущая версия
протокола -вторая
Р (1 бит) - поле заполнения.
Сигнализирует о наличии заполнения
в конце поля полезной нагрузки.
Заполнение применяется, когда приложение
требует, чтобы размер полезной нагрузки был
кратен, например, 32 битам
Х (1 бит) - поле расширения заголовка.
Служит для индикации того, что за основным
заголовком следует дополнительный заголовок,
используемый в экспериментальных
расширениях протокола RTP
СС (4 бита) - поле отправителей.
Содержит идентификаторы отправителей, чьи
данные находятся в пакете, причем сами
идентификаторы следуют за основным
заголовком
М (1 бит) - поле маркера.
Обычно используется для указания
границ потока данных. Смысл бита маркера
зависит от типа полезной нагрузки. В случае
передачи видеоинформации он определяет конец
кадра. При передаче речевой информации
маркер указывает начало периода
активности после периода молчания
РТ (7 битов) - поле типа полезной
нагрузки.Идентифицирует тип полезной
нагрузки и формат данных, включая сжатие и
шифрование.В стационарном состоянии отправитель
использует только один тип полезной нагрузки в
течение сеанса, но он может его изменить
в ответ на изменение условий, если об этом
сигнализирует протокол управления транспортировкой
информации в реальном времени
(Real-Time Transport Control Protocol)
Порядковый номер пакета
(Sequence Number, 16 битов).
Каждый источник начинает нумеровать
пакеты с произвольного номера,
увеличиваемого затем на единицу
с каждым переданным пакетом RTP
Это позволяет обнаруживать потери пакетов и
определять порядок пакетов с одинаковым временным
штампом. Несколько последовательных пакетов
могут иметь один и тот же штамп, если логически
они порождены в один и тот же момент, как,
например, пакеты, принадлежащие одному и
тому же видеокадру
Временной штамп
(Timestamp, 32 бита).
Момент времени, в который был
создан первый октет данных
полезной нагрузки. Единицы,
в которых время указывается в этом поле,
зависят от типа полезной нагрузки. Значение
определяется по локальным часам
отправителя
Идентификатор SSRC (Synchronization
SourceIdentifier, 32 бита) -поле идентификатора
источника синхронизации. Псевдослучайное
число, которое уникальным образом идентифицирует
источник в течение сеанса и не зависит
от сетевого адреса. Это число играет важную
роль при обработке порции данных,
поступившей от одного источника
Идентификатор CSRC (Contributing Source
Identifier, 32 бита) - список полей идентификаторов
источников,участвующих в создании RTP-пакета. Устройство
смешивания информации (миксер) вставляет
целый список SSRC идентификаторов источников,
которые участвовали в построении данного RTP-пакета.
Количество элементов в списке: от 0 до 15.
Если число участников более 15, выбираются первые 15.
Примером может служить речевая конференция,
в которой передаются RTP-пакеты с речью всех
участников - каждый со своим идентификатором SSRC.
Они-то и образуют список идентификаторов CSRC.
Вся конференция имеет общий
идентификатор SSRC
Доставка RTP-пакетов контролируется специальным
протоколом RTCP (Real Time Control Protocol).
Основной функцией протокола RTCP является организация
обратной связи приемника с отправителем информации
для отчета о качестве получаемых данных. Протокол RTCP
передает сведения (как от приемника, так и от отправителя)
о числе переданных и потерянных пакетов, значении джиттера,
задержке и т.д. Эта информация может быть использована
отправителем для изменения параметров передачи, например
для уменьшения коэффициента сжатия информации с целью
улучшения качества ее передачи.

2.4. Протокол IP
Протокол IP версии 4
В качестве основного протокола сетевого уровня в стеке протоколов TCP/IP используется протокол IP, который изначально проектировался как протокол передачи пакетов в сетях, состоящих из большого количества локальных сетей. Поэтому протокол IP хорошо работает в сетях со сложной топологией, рационально используя наличие в них подсистем и экономно расходуя пропускную способность низкоскоростных линий связи. Протокол IP организует пакетную передачу информации от узла к узлу IP-сети, не используя процедур установления соединения между источником и приемником информации. Кроме того, Internet Protocol является дейтаграммным протоколом: при передаче информации по протоколу IP каждый пакет передается от узла к узлу и обрабатывается в узлах независимо от других пакетов.
Протокол IP не обеспечивает надежность доставки информации, так как он не имеет механизмов повторной передачи.
Он не имеет также и механизмов управления потоком данных (flow-control). Дейтаграммы могут быть потеряны, размножены, или получены не в том порядке, в каком были переданы.
Назад
Содержание

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

Назад
Содержание
Рисунок 24. IP-дейтаграмма
Демонстрация по щелчку мыши!
Версия (Version)
Длина заголовка
Тип обслуживания
Общая длина
Идентификатор фрагмента
Флаги
Смещение фрагмента
Время жизни
Протокол
Контрольная сумма заголовка
Адрес отправителя
Адрес получателя
Опционные поля и заполнение
Данные
Протокол IP использует 3 поля заголовка
для управления фрагментацией/сборкой
дейтаграмм. Как уже упоминалось,
фрагментация необходима потому, что
разные сети, по которым передаются дейтаграммы,
имеют разные максимальные размеры кадра
Поле версия (version) идентифицирует
используемую версию протокола IP,
в рассматриваемом случае указывается версия 4.
Необходимость этого поля объясняется тем,
что в переходный период в сети могут
использоваться протоколы разных версий
Поле длина заголовка (header length),
состоящее из 4 битов, определяет длину
заголовка, причем длина указывается
как количество блоков размером 32 бита.
В типичном случае значение
этого поля равно 5
Поле тип обслуживания (Type of Service) содержит
информацию, которая бывает нужна при
поддержке сетью разных классов обслуживания.
Использование этого поля в Интернет будет
возрастать по мере роста в IP-сетях возможностей
передачи мультимедийного трафика с задаваемыми
параметрами качества обслуживания
Поле общая длина (Total Length)
определяет общую длину дейтаграммы
в октетах (байтах), включая заголовок и
полезную нагрузку.Максимальная длина
дейтаграммы составляет 65535 октетов, однако,
на практике,все рабочие станции и маршрутизаторы
работают с длинами, не превышающими
576 байтов. Это объясняется тем, что при
превышении указанной длины,
снижается эффективность работы сети
Идентификатор фрагмента (Identifier)
обозначает все фрагменты одной дейтаграммы,
что необходимо для ее успешной
сборки на приемной стороне
Поле флагов (Flags) обеспечивает
возможность фрагментации дейтаграмм
и, при использовании фрагментации,
позволяет идентифицировать
последний фрагмент дейтаграммы
Поле смещение фрагмента
(Fragment Offset) определяет
положение фрагмента относительно
исходной дейтаграммы в единицах,
равных 8 октетам
Поле время жизни (TTL - Time To Live)
используется для ограничения времени, в
течение которого дейтаграмма находится в сети.
Каждый маршрутизатор сети должен уменьшать
значение этого поля на единицу, и отбрасывать
дейтаграмму, если поле TTL приняло нулевое значение.
Наличие поля TTL ограничивает возможность
бесконечной циркуляции дейтаграммы по сети,
например, в случае, если по какой-либо причине
маршрут, по которому она следует,
оказался “закольцованным”
Поле протокол (Protocol)
идентифицирует протокол
верхнего уровня (TCP,
UDP и т.д.)
Поле контрольная сумма заголовка
(Header Checksum) обеспечивает возможность
контроля ошибок в заголовке. Алгоритм подсчета
контрольной суммы весьма прост,
поскольку обычно протоколы нижнего
уровня имеют более развитые
средства контроля ошибок
IP-дейтаграммы содержат в заголовке
два адреса - отправителя (Source) и
получателя (Destination), которые
не меняются на протяжении
всей жизни дейтаграммы

Протокол IP версии 6
Облегчить работу маршрутизаторов можно, в частности, путем модернизации протокола IP.
Комитет IETF намеревается решить существующие проблемы с помощью межсетевого протокола нового поколения - IPng, известного также как IPv6.
Наряду с вводом новых функций непосредственно в протокол IP, целесообразно обеспечить более тесное взаимодействие его с новыми протоколами, путем введения в заголовок пакета новых полей. Например, работу механизмов обеспечения гарантированного качества обслуживания облегчает внесение в заголовок метки потока, а работу IPSec - внесение в заголовок поля аутентификации.
В результате было решено подвергнуть протокол IP модернизации, преследуя следующие основные цели:
- создание новой расширенной схемы адресации;
- улучшение масштабируемости сетей за счет сокращения функций магистральных маршрутизаторов;
- обеспечение защиты данных.
Работы по модернизации протокола IP начались в 1992 году, когда было предложено несколько альтернативных вариантов спецификаций. С тех пор в рамках IETF была проделана огромная работа, в результате которой в августе 1998 года были приняты окончательные версии стандартов, определяющих как общую архитектуру IPv6 (RFC 2460 “Internet Protocol, Version 6 (IPv6) Specification”), так и отдельные компоненты данной технологии (RFC 2373 “IP Version 6 Addressing Architecture”).

Переход к протоколу IP версии 6.
Так как IPv6 представляет собой естественное развитие предыдущей версии, он с самого начала спроектирован с учетом возможности поэтапного мягкого перехода к его использованию, что требует обеспечения взаимодействия узлов с разными версиями протоколов. Способы, которые используются для организации совместной работы протоколов IPv6 и IPv4, вполне традиционны:
Установка на некоторых сетевых узлах сразу двух стеков протоколов, так что при взаимодействии с рабочими станциями, поддерживающими разные версии протокола, используется соответствующий стек протоколов TCP/IP. Маршрутизаторы могут в данном случае обрабатывать оба протокола независимо друг от друга.
Конвертирование протоколов при помощи специальных шлюзов, которые преобразуют пакеты IPv4 в пакеты IPv6 и обратно. Важнейшая часть этого процесса - преобразование адресов.
Для упрощения данной процедуры применяются так называемые “IРv4-совместимые адреса IPv6”, которые содержат в четырех младших байтах адрес, используемый в протоколе IPv4.

До свидания!
ВЫХОД

ТЕСТ

0
IP
Eth
0
Конвертор
протоколов
G.729
RTP
0
G.711
Шлюз
Router
IP
IP
PPP
Eth
U
U
IP
PPP
RTP
UDP
Codec
G.729
Демонстрация по левому щелчку мыши!
Рисунок 25. Пример обмена пользовательской информации в сети между пользователем Н.323 и аналоговым пользователем телефонной сети.
Передаваемая информация кодируется кодеком G.729
Как указано в протоколе RTP добавляется заголовок UDP
С помощью IP формируется дейтаграмма
Контроль. Для проверки искажен или нет кадр или пакет.
Маршрутизация в нужном направлении
Преобразование и кодирование в конкретный time-слот
Передача на маршрутизатор
АЦП-ЦАП

Управляющий канал Н.245
В рекомендации ITU-Т Н.245 определен ряд независимых процедур, которые должны выполняться для управления информационными каналами. К ним относятся процедуры:
• определения ведущего и ведомого устройств (Master/slave determination);
• обмена данными о функциональных возможностях (Capability Exchange);
• открытия и закрытия однонаправленных логических каналов (Logical Channel Signalling);
• открытия и закрытия двунаправленных логических каналов (Bidirectional Logical Channel Signalling);
• закрытия логических каналов (Close Logical Channel Signalling);
• определения задержки, возникающей при передаче информации от источника к приемнику и в обратном направлении (Round Trip Delay Determination);
• выбора режима обработки информации (Mode Request);
• сигнализации по петле, создаваемой для целей технического обслуживания оборудования (Maintenance Loop Signalling).
Для выполнения вышеуказанных процедур между оконечными устройствами или между оконечным оборудованием и устройством управления конференциями или привратником организуется управляющий канал Н.245. При этом оконечное оборудование должно открывать один (и только один) управляющий канал для каждого соединения, в котором оно участвует.
процедуры

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

Оконечное
Оборудование 1
Оконечное
Оборудование 2
MSD
MSD
MSDAck (ведущее)
MSDAck (ведомое)
Рисунок 26. Процедура определения ведущего и ведомого оборудования.
Существует вариант процедуры Master-Slave Determination, предусматривающий сокращение числа передаваемых сообщений.
Оконечное
Оборудование 1
Оконечное
Оборудование 2
MSD
MSDAck (ведущее)
MSDAck (ведомое)
В ответ на полученные сообщения masterSlaveDetermination оба устройства передают сообщения masterSlaveDetermlnatlonAck, в которых указывается, какое оборудование является для данного соединения ведущим, а какое - ведомым. При этом любое оборудование стандарта Н.323 должно быть способно работать и в качестве ведущего, и в качестве ведомого.
Устройства обмениваются сообщениями master-SlaveDetermination, в поле terminalType которых помещается значение, соответствующее типу данного оборудования, а в поле statusDeterminationNumber - случайное число из интервала [0 - 224].
Ведущим становится оборудование, поместившее большее число в поле terminalType, а при совпадении типов оборудования - большее число в поле statusDeterminationNumber.
Оборудование передает сообщение master-SlaveDetermination
И получает в ответ сообщение masterSlave-DeterminationAck
Передает сообщение masterSlaveDetermina-tlonAck
Рисунок 27. Процедура Master-Slave Determination предусматривающая сокращение числа передаваемых сообщений.

2. Обмен данными о функциональных возможностях
Оборудование стандарта Н.323, в общем случае, способно принимать и передавать речь, видеоинформацию и данные. Это означает, что оборудование обычно содержит приемник и передатчик информации. Как правило, устройства поддерживают несколько алгоритмов кодирования и декодирования информации каждого вида. Для согласования режимов работы передающей и принимающей сторон используется процедура, называемая обменом данными о функциональных возможностях оборудования.
Оконечное
Оборудование 1
Оконечное
Оборудование 2
TerminalCapabilitySet
TerminalCapabilltySetAck
Рисунок 28. Обмен данными о функциональных возможностях оборудования.
Терминалы обмениваются сообщениями TerminalCapabilitySet, в которых каждый из них указывает алгоритмы, используемые для декодирования принимаемой и кодирования передаваемой информации, то есть режимы, в которых оборудование может функционировать. В сообщение TerminalCapabilitySet включается поле capability Table - таблица функциональных возможностей, где каждому алгоритму кодирования/декодирования присвоен порядковый номер. Указанные порядковые номера объединяются в список альтернативных режимов alternativeCapabilitySet. Оборудование может использовать любой (но только один) из режимов, указанных в списке.
Оборудование, которое получило от другого оборудования сообщение TerminalCapabllHySet, может подтвердить его получение передачей сообщения TerminalCapabilltySetAck.
При получении сообщения с некорректным набором возможностей оборудование отвечает сообщением TerminalCapabilitySetRe-ject. При срабатывании таймера, запущенного после отправки сообщения TerminalCapabilitySet, оборудование, его пославшее, передает сообщение TerminalCapabilitySetRelease

В свою очередь, альтернативные режимы объединяются в наборы одновременно возможных режимов функционирования simulta-neousCapabilltles. Функциональные возможности терминала описываются набором дескрипторов (capability Descriptor), каждый из которых состоит из одного набора одновременно возможных режимов функционирования оборудования и номера дескриптора (capabilityDescrlptorNum-ber). Если при обмене данными о функциональных возможностях оборудование указывает более чем один дескриптор, то это означает, что оборудование поддерживает несколько режимов функционирования.
Заметим, что функциональные возможности оборудования, не определенные рекомендацией ITU H.245, могут быть указаны в поле nonStandardParameter.
Оборудование может в любое время передать сообщение TerminalCapabilitySet с дескриптором, добавляющим новые функциональные возможности, или с дескриптором, обеспечивающим исключение некоторых из ранее указанных возможностей. Любое оборудование стандарта Н.323 должно включать в сообщение TerminalCapabilitySet, no крайней мере, один дескриптор. Исключение составляет сообщение EmptyCapabilitySet (пустой набор функциональных возможностей), которое используется для реализации дополнительных возможностей системы.

3. Открытие и закрытие логических каналов
Информация, передаваемая источником к одному или более приемникам в сетях, базирующихся на рекомендации Н.323, переносится по логическим каналам, которые идентифицируются уникальным для каждого направления передачи номером канала.
Рекомендацией Н.245 предусмотрена возможность открытия логических каналов двух видов: однонаправленных (uni-directional), т.е. открывающихся в направлении от источника к приемнику информации, и двунаправленных (bi-directional), открывающихся сразу в двух направлениях - от источника к приемнику информации и в обратном направлении.
Однонаправленные логические каналы открываются при помощи процедуры Uni-directional Logical Signalling.
Оконечное
Оборудование 1
Оконечное
Оборудование 2
ОpenLogicalChannel
ОpenLogicalChannelAck
Рисунок 29. Процедура открытия однонаправленных логических каналов
В требовании открыть логический канал openLogicalChannel оборудование указывает вид информации, который будет передаваться по этому каналу, и алгоритм кодирования информации. Если логический канал предназначается для переноса речи или видеоинформации, упакованной в пакеты рассмотренного в главе 4 протокола RTP (Real Time Protocol), то в сообщение openLogicalChannel должен включаться параметр mediaControlChannel с указанием транспортного адреса канала протокола RTCP (Real Time Control Protocol), при помощи которого ведется контроль передачи RTP пакетов.
Оборудование, получившее запрос открыть логический канал для приема данных, вид которых не поддерживается или не распознан, должно ответить сообщением openLogicalChannelReject. Получение корректного сообщения opentogicalChannel оборудование должно подтвердить сообщением openLogicalChannelAck
Закрытие логических каналов может производиться
с помощью процедуры CloseLogicalChannel, но она
используется, в основном, для поддержки
предоставления дополнительных услуг, в первую
очередь, - перевода в режим удержания. Для
нормального разрушения соединения стороны
обмениваются сообщениями endSessionCommand.
После обмена этими сообщениями закрываются не
только логические каналы, но и управляющий
канал Н.245

В некоторых случаях, например, для обмена данными по протоколу Т. 120, оборудование, инициирующее такой обмен, должно открывать сразу и прямой, и обратный каналы. Делается это с помощью процедуры Bi-directional Logical Signalling, которая практически идентична вышеописанной процедуре Uni-directional Logical Signalling и также предусматривает обмен сообщениями openLogicalChannel и openLogicalChannelAck. Добавляется сообщение - openLogicalChannelConfirm, - которое передается в ответ на сообщение OpenLogicalChannelAck и подтверждает, что двунаправленный логический канал открыт.
4. Выбор режима обработки информации
Оконечное
Оборудование 1
Оконечное
Оборудование 2
RequestMode
RequestMode Ack
Оконечное оборудование в ходе процедуры Capabilitiesexchange может объявить поддерживаемые им режимы передачи информации. Встречное оборудование, получив список возможных режимов передачи информации, может, передав сообщение requestMode, запросить передачу в одном из этих режимов.
Устройство, получившее сообщение requestMode, должно, если это возможно, выполнить содержащееся в нем требование. Оборудование, не желающее находиться под контролем другого оборудования в части выбора режима передачи информации, может просто не указывать каким способом оно будет ее передавать.
Рисунок 30. Выбор режима обработки информации
Терминальное оборудование, участвующее в конференции
и получившее от контроллера конференций сообщение
multipointModeCommand, должно выполнять требования,
содержащиеся в сообщениях requestMode, если эти
требования не выходят за пределы возможностей оборудования.
Примечательно, что в централизованных и децентрализованных
конференциях, все сообщения requestMode, передаваемые
терминалами, поступают на контроллер конференций, и он
принимает решение, удовлетворить полученные требования
или нет. Приняв нераспознаваемое сообщение, оборудование
Н.323 должно передать в ответ сообщение
functlonNotSupported

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

Основной функцией шлюза является преобразование речевой (мультимедийной) информации, поступающей со стороны ТФОП с постоянной скоростью, в вид, пригодный для передачи по IP-сетям, т.е. кодирование информации, подавление пауз в разговоре, упаковка информации в пакеты RTP/UDP/IP, а также обратное преобразование.
Кроме того, шлюз должен уметь поддерживать обмен сигнальными сообщениями как с коммутационным или терминальным оборудованием ТфОП, так и с привратником или оконечным устройством сети Н.323. Таким образом, шлюз должен преобразовывать аналоговую абонентскую сигнализацию, сигнализацию по 2ВСК, сигнальные сообщения систем сигнализации DSS1 и ОКС7 в сигнальные сообщения Н.323
В привратнике сосредоточен весь интеллект сетей IP-телефонии, базирующихся на рекомендации ITU Н.323. Сеть Н.323 имеет зонную архитектуру.
Привратник выполняет функции управления зоной сети IP-телефонии, в которую входят терминалы, шлюзы и устройства управления конференциями, зарегистрированные у этого привратника. Разные участки зоны сети Н.323 могут быть территориально разнесены и соединяться друг с другом через маршрутизаторы. Следует обратить внимание на то, что коммутаторы кадров Ethernet и маршрутизаторы пакетов IP не являются сетевыми элементами Н.323, так как они работают на звеньевом или сетевом уровнях соответственно, в то время как оборудование Н.323 работает на прикладном уровне стека протоколов TCP/IP.

В число наиболее важных функций, выполняемых привратником, входят:
• преобразование так называемого alias (имени абонента, телефонного номера, адреса электронной почты и др.) в транспортный адрес сети с маршрутизацией пакетов IP (IP адрес и номер порта TCP);
• контроль доступа пользователей системы к услугам IP-телефонии при помощи сигнализации RAS (используются сообщения ARQ/ACF/ARJ);
• контроль, управление и резервирование пропускной способности сети;
• маршрутизация сигнальных сообщений между терминалами, расположенными в одной зоне.
Устройство управления конференциями.
Рекомендация Н.323 предусматривает три вида конференций.
Первый вид - централизованная конференция, в которой оконечные устройства соединяются в режиме точка-точка с устройством управления конференциями (MCU), контролирующим процесс создания и завершения конференции, а также обрабатывающим потоки пользовательской информации.
Второй вид - децентрализованная конференция, в которой каждый ее участник соединяется с остальными участниками в режиме точка - группа точек, и оконечные устройства сами обрабатывают (переключают или смешивают) потоки информации, поступающие от других участников конференции.
Третий вид - смешанная конференция, т.е. комбинация двух предыдущих видов.

Преимущество централизованной конференции - сравнительно простые требования к терминальному оборудованию, недостаток - большая стоимость устройства управления конференциями.
Для децентрализованной конференции требуется более сложное терминальное оборудование, кроме того, желательно, чтобы в сети
Терминал D
Терминал E
Терминал F
Терминал A
Терминал B
Терминал C
Устройство управления конференциями
Централизованная конференция
Децентрализованная конференция
Рисунок 32. Виды конференции в сетях Н.323