И если H.323 можно сравнить с ванилью, то протокол Session Initialization Protocol (SIP) вполне уместно в таком случае считать клубникой. Он не лучше и не хуже, чем H.323; он просто другой.

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

SIP - это протокол прикладного уровня, предназначенный для установления, изменения и окончания сеансов с одним или несколькими участниками. Эти сеансы могут включать в себя мультимедиа-конференции, дистанционное обучение, телефонные звонки по Internet и распространение мультимедийного информационного наполнения. Для участия в сеансе SIP способен «пригласить» людей или «роботов», таких, например, как службы хранения мультимедиа-информации.

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

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

Абоненты, как инициирующие звонок, так и принимающие его, идентифицируются с помощью адресов SIP. Звонящий сначала определяет местонахождение соответствующего сервера, затем передает запрос SIP. В идеальном случае запрос передается адресату, который возвращает код ответа SIP, равный 200. Как и в случае с другими кодами ответа TCP/IP, двойка в начале свидетельствует об отсутствии ошибки.

Затем инициатор звонка посылает подтверждение получателю, что несколько необычно, потому что станция, которая инициировала звонок, также посылает подтверждение.

SIP позволяет взаимодействовать в рамках многоадресной рассылки, в сети одноадресных связей или посредством сочетания много- и одноадресных связей.

Объекты, к которым обращаются посредством SIP, являются пользователями на хостах, которые идентифицируются с помощью URL-адресов SIP. Пользовательская часть - это имя пользователя или номер телефона. Хостовая часть - это имя домена или IP-адрес.

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

Транзакция SIP состоит из запроса и соответствующего ответа. В парных запросах и ответах имеются несколько полей, содержащих идентичные значения. К таким полям относятся поле с идентификатором звонка, номер командной последовательности, поле получателя, поле отправителя и тег (если присутствует). Поля отправителя и получателя идентичны в обоих направлениях. Это необычно, но отнюдь не ново в отличие от метода, применяемого в High-Level Data Link Control. Это помогает решить возникающие проблемы при использовании анализатора протокола для поиска и устранения аномалий в сети.

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

Если говорить очень упрощенно, IETF создала SIP и связанные с ним протоколы потому, что убеждена в недостаточной масштабируемости H.323. Пока же совершенно очевидно, что H.323 опережает SIP в этой гонке. Но каков будет финиш?

Как работает протокол SIP

терминал;

gatekeeper (контроллер зоны);

устройство управления многоточечной конференцией (MCU).

Рис.4.2. Базовая архитектура стандарта H.323

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

H.245 для установления возможностей терминалов и создания канала обмена аудио информацией;

H.225 для сигнализации вызова и установки параметров связи;

RAS для регистрации терминала пользователя и установки дополнительных параметров управления контроллером зоны,

RTP/RTCP для упорядочивания звуковых и видео пакетов.

H.323-терминал должен также поддерживать звуковой кодер-декодер в соответствии с G.711.

Протокол H.225 RAS используется между H.323-оконечными точками (терминалами и шлюзами) и контроллером зоны для обеспечения для:

Обнаружения контроллера зоны (GRQ);

Регистрации оконечной точки;

Определения расположения оконечной точки;

Управление аутенфикацией;

Задание маркера доступа.

RAS-сообщения передаются через ненадежные RAS-каналы, вследствие этого, при обмене сообщениями возможны потери, задержки и повторные передачи.

Обнаружение контроллера зоны (GRQ)

Процесс обнаружения контроллера зоны используется H.323-оконечными точками, в которых оконечная точка должна зарегистрироваться. Обнаружение контроллера зоны может быть выполнено статически или динамически. В статическом режиме, оконечная точка знает транспортный адрес контроллера априорно. В динамическом режиме обнаружения контроллера, оконечная точка посылает многоадресное сообщение (multicasts GRQ) поиска контроллера на групповой адрес поиска контроллера содержащее вопрос: - "Кто мой контроллер?". Один или большее количество контроллеров могут отвечать GCF-сообщением: "Я могу быть вашим контроллером".

Регистрация оконечной точки

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

Определение положения оконечной точки

Определение положения оконечной точки это процесс привязки ее сетевого адреса (адреса в сети транспортировки) к ее H.323-псевдониму или адресу E.164 (телефонному номеру).

Другие функции управления

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

Стандарты H.225 сигнализация вызова и H.245 сигнализация управления

H. 225 сигнализация вызова

H.225-сигнализация вызова используется, для установления соединения между H.323- оконечными точками (терминалами и шлюзами), через которые будут транспортироваться данные в реальном масштабе времени. Сигнализация вызова включает обмен H.225- сообщениями протокола через надежный канал, используемый для этой цели (канал сигнализации вызовов).

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

Метод с маршрутизацией вызовов в контроллере зоны

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

H.245 сигнализация управления

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

Сообщения обмена параметрами

Обмен параметрами позволяет терминалам выбрать такие режимы обмена данными и форматы кодирования, которые они могут использовать при совместной работе друг с другом. Уточняются возможности терминалов: как на прием, так и на передачу.

Сообщения управления процессами логическими каналами между конечными точками.

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

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

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

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

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

Рис. 4.4. Схемы централизованной и децентрализованной организаций конференции в H.323.

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

Рис. 4.5. Схемы децентрализованной и смешанной организаций конференции в H.323.

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

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

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

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

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

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

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

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

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

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

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

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

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

Управление вызовами

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

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

Управление вызовом

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

Игорь Масленников ,
директор по развитию бизнеса компании CompTek
[email protected]

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

Исторически первый и самый распространенный в настоящее время - это введенный Международным союзом электросвязи (МСЭ) набор рекомендаций Н.323 (для простоты будем называть его протоколом). Н.323 стал плодом деятельности разработчиков протоколов мультимедийной связи в сетях ISDN (H.320). Соответствующие работы велись еще c начала 90-х годов, когда никакой IP-телефонии и в помине не было. Первая версия этого протокола была принята МСЭ в 1996 г. и по сути была попыткой перенести телефонную сигнализацию ISDN Q.931 на IP-соединения, т. е. как бы "наложить" традиционную телефонию на сети передачи данных. Рекомендации H.323 достаточно подробно описывают способы организации мультимедийных конференций, охватывая сервисы передачи голоса, видео и компьютерных данных в пакетных сетях с негарантированной доставкой. К настоящему времени принята уже четвертая версия этого набора рекомендаций. К основным компонентам набора относятся описанные ниже протоколы.

H.225 - полный аналог протокола Q.931 в сетях ISDN; описывает процесс установления, поддержки и завершения соединения. Обмен сообщениями происходит по протоколу TCP.

RAS (Registration, Admission, Status) - отвечает за регистрацию устройств в сети, контроль доступа к ресурсам, контроль полосы пропускания, необходимой для сеанса связи, и контроль состояния устройств в сети. Работает по протоколу UDP.

H.245 - отвечает за обмен информацией, необходимой для согласования параметров логических каналов для передачи медиа-потоков, т. е. собственно голоса или видео. Сюда входит, к примеру, согласование кодеков, номеров UDP-портов и т. д. Обмен происходит по протоколу TCP.

H.450.x (появившийся в четвертой версии H.323) - отвечает за обеспечение таких дополнительных или интеллектуальных функций, как Hold, Transfer и т. д.

Архитектура H.323 (рис. 1) весьма проста и состоит всего из четырех функциональных компонентов, ни один из которых не является обязательным.

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

Шлюз (H.323 Gateway) - центральное понятие сегодняшней IP-телефонии. Данное устройство обеспечивает взаимное сопряжение телефонной сети с IP-сетью. При этом предоставляется поддержка разных протоколов и интерфейсов сетей обоих типов. Если выход в телефонную сеть не требуется, то данный компонент не нужен, а терминалы могут связываться друг с другом напрямую.

Привратник (H.323 Gatekeeper, GK) - управляющий элемент, "интеллект" H.323 сети, обеспечивающий ее масштабируемость, централизацию управления и настроек, а также трансляцию телефонных префиксов и идентификаторов (H.323 ID) в IP-адреса шлюзов или H.323 терминалов. Кроме того, привратник отвечает за управление доступом (Admission Сontrol) при регистрации шлюзов и терминалов, авторизацию звонков (Call Admission Control), управление полосой пропускания и маршрутизацию вызовов. Привратник управляет подчиненной ему частью сети (зоной) через RAS - протокол общения шлюзов с ним. Предусмотрено объединение привратников в группы, управлять которыми можно с помощью выделенного привратника - Directory Gatekeeper.

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

Обмен сообщениями между компонентами сети H.323 происходит в двоичном формате (ASN.1), для анализа которого нужен транслятор из двоичного формата в текстовый (ASN parser). Что же касается способов адресации, то в рекомендациях H.323 на этот счет определено несколько вариантов:

• телефонные номера в формате E.164, т. е. только символы из набора "0123456789#*,";
• H.323-идентификатор (H323-ID) - произвольный набор символов Unicode;
• универсальный идентификатор ресурса в формате URL (URL-ID);
• IP-адрес с номером порта, например, 10.2.3.4:1720;
• адрес электронной почты (Email-ID).

В наиболее общей форме сценарий соединения по протоколу H.323 выглядит как ряд последовательных шагов (рис. 2). Вначале для установления соединения терминал обнаруживает привратника и регистрируется у него по протоколу RAS. Затем происходит установление сигнального канала по протоколам RAS и H.225. На следующем этапе выполняется согласование параметров оборудования, обмен информацией о его функциональных возможностях и открытие логических каналов по протоколу H.245. Только после этого происходит передача медиа-трафика по протоколам RTP/RTCP, а по ее окончании - завершение соединения.

Протокол SIP

Следующий по распространенности протокол IP-телефонии называется SIP (Session Initiation Protocol); он описан в рекомендациях RFC 2543. SIP регламентирует установление и завершение мультимедийных сессий - сеансов связи, в ходе которых пользователи могут говорить друг с другом, обмениваться видеоматериалами и текстом, совместно работать над приложениями и т. д. SIP и сопутствующие ему протоколы родились и развиваются в рамках IETF - главного органа стандартизации Интернета. Первая версия протокола SIP была принята в марте 1999 г., на три года позже, чем H.323, но благодаря интенсивному развитию этого направления сегодня набор рекомендаций RFC (базовых официальных документов IETF), имеющих отношение к SIP-архитектуре, насчитывает десятки, если не сотни документов.

SIP очень похож на протокол HTTP, поскольку разрабатывался по образу и подобию широко известных спецификаций HTTP и SMTP. По сути это клиент-серверный протокол, работа которого состоит из череды запросов и ответов, причем все SIP-заголовки передаются в формате ASCII-текста, а потому легко читаются. Наверняка коды возврата 200 (OK), а особенно 404 (Not found) хорошо знакомы всем пользователям Интернета. SIP позволяет использовать логическую адресацию (URL) на базе протокола TCP или UDP. Проще всего в качестве адреса в сети SIP задавать адреса электронной почты, к примеру, sip:[email protected] - это самый естественный URL, адекватно понимаемый SIP. При этом допускается применение разнообразных параметров, определяющих функциональность SIP-адреса или тип протокола связи. Например, можно указать, что соединение осуществляется с обычным телефонным номером сети общего пользования - sip:tel:+70957852525, и дополнить его добавочным номером postd=pp521, или определить параметры модемной связи - modem:+70957852526;type=v32b?7e1;type=v110.

SIP имеет несколько комплементарных протоколов, которые служат для реализации дополнительных возможностей. Наиболее важный из них - SDP (Session Description Protocol, RFC 2327), протокол согласования таких параметров сеанса связи, как виды кодеков, номера UDP-портов и т. д. SDP обеспечивает изменение параметров сеанса связи "на ходу", во время сеанса. Перенос сообщений SDP основан на протоколе Session Announcement Protocol (SAP, RFC 2974).

Другой пример комплементарного протокола - SIMPLE (SIP for Instant Messaging and Presence Levering Extension). Фактически это расширение SIP, служащее для предоставления информации о событиях (presence) и для рассылки "мгновенных" сообщений (instant messaging).

Следует также упомянуть SIP-T (Trunk) - протокол переноса сообщений SS7 в виде MIME-объектов между контроллерами сигнализации, а также SIGTRAN (Signaling Transport) - протокол переноса сообщений сигнализации SS7 через IP-сеть.

Архитектура SIP (рис. 3) также очень проста и состоит из нескольких необязательных компонентов.

Рис. 3. Архитектура SIP.

Клиент SIP (SIP user agent) - может быть представлен как устройством (IP-телефон, шлюз или другой пользовательский терминал), так и программным приложением для ПК, PDA и т. д. Обычно SIP-клиент содержит и клиентскую, и серверную часть (User Agent Client, или UAC, и User Agent Server, или UAS). Основные функции данного компонента - инициирование и завершение вызовов.

Прокси-сервер SIP - управляет маршрутизацией вызовов и работой приложения. Прокси-сервер не может инициировать или терминировать вызовы.

Redirect-сервер SIP - перенаправляет звонки согласно заданным условиям.

Сервер регистрации SIP (registrar/location) - осуществляет регистрацию пользователей и ведет базу соответствия имен пользователей их адресам, телефонным номерам и т. д.

Еще один важный компонент реальных SIP-сетей, хотя и не входящий формально в архитектуру SIP, - Back-to-Back User Agent (B2BUA). Это своеобразный сервер, представляющий собой два соединенных друг с другом SIP-клиента и поэтому способный инициировать и завершать вызовы.

Из этих компонентов, как из функциональных "кирпичиков", можно строить сети VoIP любой топологии, сложности и масштаба, вплоть до сетей, полностью замещающих функции современных АТС. Можно также создавать совершенно новые сервисы - интеграцию Интернет- и бизнес-приложений, программируемые службы, многоадресный поиск абонента, мультимедийные сервисы, уведомления о событиях и т. д.

В наиболее общей форме сценарий соединения по протоколу SIP с участием прокси-сервера показан на рис. 4. Абонент посылает на прокси-сервер запрос на соединение, отправляя сообщение Invite. Прокси-сервер возвращает сообщение Trying и передает сообщение Invite вызываемому абоненту. Вызываемая сторона отвечает сообщением Ringing, которое прокси-сервер пересылает вызывающей стороне. После того как вызываемый абонент снимет трубку, вызывающей стороне отправляется сообщение ОК, которое транслируется прокси-сервером. Вызываемому абоненту возвращается подтверждающее сообщение Ack.

C этого момента соединение считается установленным и начинается обмен медиа-трафиком по протоколам RTP/RTCP. Сторона, желающая завершить соединение, посылает сообщение Bye, и после получения подтверждающего ОК соединение разрывается.

Этот сценарий очень прост, в нем не участвуют никакие другие серверы (Redirection, Registrar, Location), но он дает представление о схеме взаимодействия функциональных элементов SIP-сети.

Протокол MGCP

Последний из рассматриваемых протоколов IP-телефонии - MGCP (Media Gateway Control Protocol). Точнее, речь здесь идет не об одном протоколе, а о целой группе - SGCP, IPDC, MGCP, MEGACO, H.248. Эти спецификации не только очень схожи концептуально, но и являются "близкими родственниками".

История формирования MGCP началась с создания двух протоколов - SGCP (Simple Gateway Control Protocol, разработка Bellcore и Cisco Systems) и IPDC (Internet Protocol for Device Control, разрабатывался компанией Level 3 при участии многих производителей). Затем SGCP и IPDC были объединены в один протокол, получивший название MGCP. В дальнейшем эволюция MGCP привела к появлению протоколов MEGACO (в рамках IETF) и H.248 (в рамках МСЭ).

Первая версия протокола MGCP (RFC 2705) датирована октябрем 1999 г. Интересно отметить, что MGCP - единственный из трех описываемых здесь протоколов, в работе над которым IETF и МСЭ сотрудничают; именно в результате этого взаимодействия и были созданы протоколы MEGACO и H.248. В то же время существуют и другие реализации MGCP-подобных протоколов, например, фирменный протокол Cisco Systems SSCP (Skinny Station Control Protocol), с помощью которого УАТС Cisco Call Manager управляет IP-телефонами.

Основная идея MGCP очень проста. Она состоит в том, что управление сигнализацией (Call Control) сосредоточено на центральном управляющем устройстве, называемом контроллером сигнализаций (Call Agent, CA), и полностью отделено от медиа-потоков (bearer). Эти потоки обрабатываются "тупыми" шлюзами или абонентскими терминалами, которые способны исполнять лишь ограниченный набор команд, исходящих от управляющего устройства. Архитектура протокола MGCP-сети также очень проста (рис. 5), в ней выделяются всего два функциональных компонента. Первый может быть представлен шлюзом (Media Gateway, MG) или IP-телефоном, а второй - устройством управления вызовами, которое может называться контроллером сигнализаций (CA), контроллером шлюза (Media Gateway Controller, MGC) или программным контроллером (Softswitch, SS). Иногда контроллер сигнализаций представляют в виде двух компонентов - собственно контроллера (Call Agent), выполняющего функции управления шлюзами, и шлюза сигнализации (Signaling Gateway), обеспечивающего обмен сигнальной информацией и согласование между традиционной телефонной сетью и сетью IP.

Рис. 5. Архитектура MGCP.

Контроллеры обмениваются со шлюзами (или IP-телефонами) данными в простом текстовом формате (в случае H.248 возможен и бинарный обмен), а функциональное назначение каждого шлюза определяется набором команд, которые он "понимает". Манипулируя наборами команд, можно получать специализированные шлюзы: транковые (Trunking gateways, TGW), абонентские (Residential gateways, RGW), шлюзы доступа (Access gateways, AGW) и т. д.

Контроллер сигнализаций CA воспринимает сеть как набор двух логических элементов - устройств (end-points) и соединений (connections) между ними. Устройства могут быть физическими (например, IP-телефоны или линии на шлюзах) или виртуальными (например, линии к серверам голосовых сообщений). Соединения могут быть ориентированы на передачу голоса, факс-сообщений или данных. Управление этими элементами, т. е. организация соединений между устройствами, происходит путем посылки команд в виде текстовых (ASCII) сообщений по протоколу UDP - при этом может использоваться уже знакомый нам протокол SDP. Как правило, управляющие воздействия контроллера СА инициируются какими-то событиями (events).

Простейший сценарий соединения в концепции MGCP (рис. 6) будет выглядеть следующим образом. Пользователь телефона, подключенного к MGCP-шлюзу, снимает трубку, после чего шлюз сообщает контроллеру об этом событии, а СА дает команду шлюзу включить в телефонную линию сигнал готовности (dial-ton). Теперь пользователь слышит в трубке непрерывный гудок. Набор телефонного номера - тоже последовательность событий для контроллера. Анализируя эти события, СА может установить соединение с другим абонентом в IP-сети или в телефонной сети. Кстати, централизованная обработка сигнализации дает возможность контроллеру прозрачно транслировать сигнализацию SS7 или ISDN из телефонной сети в IP-сеть и, наоборот, получать соответствующие сигнальные сообщения, упакованные в IP-пакеты, а затем анализировать их и манипулировать голосовыми каналами на шлюзах.

Резюме

Сравнивая "биографические данные" и функциональные особенности трех видов протоколов (см. таблицу), мы видим, что их различия обусловлены историческими причинами, в частности, изменениями представлений о пути развития телекоммуникаций в разное время. При этом H.323 - это технологически устоявшийся, широко распространенный протокол IP-телефонии для операторских сетей и межоператорского обмена, можно сказать, "транзитный" протокол. В свою очередь, SIP - протокол предоставления расширенных голосовых услуг в IP-сетях, который продолжает быстро развиваться, иначе говоря, "абонентский" протокол. Что касается MGCP, то он ориентирован прежде всего на организацию больших операторских узлов сопряжения IP-сетей с ТфОП и сетями SS7.

Сравнение протоколов VoIP-сети

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

Поэтому весьма вероятно, что протокол SIP, гораздо более понятный и удобный для инженеров-сетевиков и программистов, через некоторое время превратится в протокол некоей новой службы, функции которой далеко выходят за пределы передачи голоса по пакетным сетям. Термин "IP-коммуникации" сейчас можно услышать все чаще. Отличие IP-коммуникаций от телефонии (в том числе от сегодняшней IP-телефонии) как раз и будет состоять в обилии сервисов, о возможности которых мы пока просто не догадываемся.

Как сложится судьба представителей семейства MGCP, пока сказать трудно. Эти протоколы, очевидно, будут востребованы на протяжении переходного периода - от сетей с коммутацией каналов и TDM-сетей к сетям пакетной коммутации (точнее, к IP-сетям). В первую очередь такая востребованность обусловлена возможностью прозрачной интеграции телефонных сетей (особенно SS7) с сетями IP-телефонии. Но дальнейшая перспектива развития протоколов семейства MGCP будет зависеть от того, по какому пути пойдет процесс конвергенции телекоммуникаций - по "интернетному", подразумевающему равноправие сетевых узлов, наличие "умных клиентов" и инновационных сервисов, или по "телефонному", с жесткой иерархией, при которой новые сервисы вводятся только централизованно, и неписаным правилом: чем "тупее" клиент, тем проще жить оператору.

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

Протокол 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.

В сегодняшней статье мы поговорим об одном из первых протоколов, получивших широкое применения в сетях 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.

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

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

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