Протоколы применяемые в сигнализации IP – телефонии
Сигнализация по стандарту Н.323

Рекомендация Международного союза электросвязи (МСЭ-Т) Н.323 определяет основы процесса передачи аудио, видео и данных по сетям с коммутацией пакетов, например по сетям IP. В ней описаны объекты, необходимые для мультимедийной связи, их функции и способы взаимодействия, в частности алгоритмы формирования пакетов, сжатия аудио- и видеоинформации. Кроме того, рекомендация Н.323 нацелена на решение задач администрирования конечных пользователей, адресации, контроля за использованием полосы пропускания сети и сетевых объектов.
В настоящее время действительна версия 2 Н.323 - это зонтичная рекомендация, в которой описаны компоненты сети и даны рекомендации к применению множества дополнительных рекомендаций. Все вместе эти рекомендации часто называют семейством Н.323.
Сейчас готовится следующая версия стандарта. В ней будут описаны: создание пакетных сетей факсимильной связи и организация связи между Н.323-шлюзами. Речь идет и о таких функциях, распространенных в современной телефонии, включая уведомление о поступлении второго вызова и режим справки. Некоторые компании добиваются включения в Н.323 поддержки мультимедиа-возможностей, ос-нованных на предложенном IETF протоколе Session Initiation Protocol. Помимо «телефонных» функций, новая версия будет дополнена средствами, позволяющими учитывать параметры сеансов для целей тарификации, а также поддержкой каталогов - вместо цифровых IP-адресов можно будет пользоваться именами абонентов.
Для выполнения действий сигнализации между шлюзами и gatekeeper в соответствии с Рекомендацией МСЭ-Т Н.323 должны использоваться следующие протоколы:
- сигнализация RAS (Registration, Admission, Status);
- сигнализация Q.931 (согласно Н.225.0);
- протокол управления Н.245.

Сигнализация RAS

Протокол сигнализации RAS (регистрации, подтверждения и состояния) применяется для передачи служебных сообщений между терминалами и контроллером зоны Н.323. RAS-сообщения служат для регистрации терминалов, допуска их к сеансу связи, изменения используемой полосы пропускания, информирования о состоянии сеанса и его прекращении. В отсутствии контроллера зоны (gatekeeper) протокол RAS не задействуется.
Функции сигнализации RAS используют сообщения протокола Н.225.0. Канал сигнализации RAS не зависит от канала управления вызовом и канала управления Н.245.
С помощью сигнализации RAS должно осуществляться:
1.) нахождение gatekeeper, на котором возможна регистрация оконечного оборудования;
2.) регистрация оконечного устройства;
3.) определение географического положения оконечного устройства;
4.) указание необходимой полосы пропускания;
5.) изменение полосы пропускания.
Передача сообщений RAS осуществляется в дейтаграммах UDP. Для адресации RAS должна использоваться адресная информации, в которую входят:
1.) сетевой адрес оборудования;
2.) идентификатор TSAP (Transport Layer Service Access Point);
3.) мнемонический адрес (Alias Address).
Сетевой адрес является адресом в формате, используемом в сети с коммутацией пакетов, например, адрес в форматах IPv4, IPv6, IPX, NetBIOS.
Идентификатор TSAP используется для идентификации информационных потоков, отправленных с одного сетевого адреса. Для gatekeeper выделены постоянные значения идентификатора TSAP: 1718 (для поиска gatekeeper) и 1719 (для передачи сообщений сигнализации RAS).
Мнемонический адрес служит для адресации оконечного оборудования в удобной пользователю форме. Адресом может быть телефонный номер в формате Е.164, телефонный номер в корпоративной сети, адрес электронной почты и так далее. Gatekeeper не имеет мнемонического адреса.
Нахождение gatekeeper должно осуществляться с помощью широковещательного запроса GRQ (Gatekeeper Request), передаваемого оконечным оборудованием с идентификатором TSAP, равным 1718. Если gatekeeper найден, и он готов обслужить запрос от оконечного оборудования, в ответ оно должно получить сообщение GCF (Gatekeeper Confirm). Если оконечное оборудование получило ответ от нескольких gatekeeper, выбор одного из них должен осуществляться оконечным оборудованием произвольным образом. Если gatekeeper не может обслужить запрос от оконечного оборудования, то в ответ он должен передать сообщение GRJ (Gatekeeper Reject), в котором должна сообщаться причина отказа, и может содержаться адрес альтернативного gatekeeper. При нахождении gatekeeper между ним и оконечным оборудованием осуществляется установление логического канала сигнализации, по которому будут передаваться остальные сообщения RAS.
После нахождения gatekeeper оконечное оборудование в сообщении RRQ (Registration Request) должно сообщить gatekeeper свой сетевой и мнемонический адрес. В ответ gatekeeper должен передать сообщение RCF (Registration Confirm) для подтверждения регистрации оконечного оборудования, либо RRJ (Registration Reject) в случае отказа от регистрации. Сообщение RRQ может передаваться при включении оконечного оборудования. Если при повторной регистрации мнемонический и сетевой адреса, переданные gatekeeper оконечным оборудованием, совпадают с ранее переданными, то gatekeeper должен передать сообщение RCF. Если при повторной регистрации мнемонический адрес равен ранее указанному, а сетевые отличаются, должно быть передано сообщение RRJ с причиной отказа «duplicate registration». Для отмены регистрации используются сообщения URQ (Unregistered Request), передаваемое оконечным оборудованием, и UCF (Unregistered confirm), URJ (Unregistered reject), передаваемые gatekeeper оконечному оборудованию.
Регистрация оконечного оборудования на gatekeeper может осуществляться один раз и не повторяться при включении оконечного оборудования. В этом случае gatekeeper должен определять состояние оконечного оборудования. Для этого gatekeeper должен периодически передавать сообщение IRQ (Information Request). Интервал определяется производителем оборудования и должен быть не менее 10 секунд.
После регистрации оконечного оборудования на gatekeeper оно может установить соединение с вызываемым оконечным оборудованием. Для этого оконечное оборудование-инициатор должно передать сообщение ARQ (Admissions Request) и установить логический канал для передачи сообщений Q.931. В сообщении ARQ указываются скорость передачи, кратная 100 бит/с, и количество каналов, необходимых для передачи речевой информации. Например, при использовании интерфейсов ISDN для выделения полосы 192 кбит/с необходимо указать значения соответственно 640 и 3. Скорость указывается без учета размеров заголовков пакетов и блоков данных транспортных протоколов. Если сеть может обеспечить требуемые параметры, то gatekeeper должен передать подтверждение ACF (Admissions Confirm), в противном случае передается сообщение ARJ (Admissions Reject) с указанием причины отказа.
После получения подтверждения оконечное оборудование устанавливает соединение с вызываемым оконечным оборудованием с использованием сигнализации Q.931 (в соответствии с Н.225.0). Сообщения сигнализации Q.931 могут передаваться по логическому каналу через gatekeeper или непосредственно между двумя оконечными устройствами. Выбор способа осуществляет gatekeeper и сообщает об этом оконечному оборудованию в сообщении ACF.
Если сообщения передаются через gatekeeper, то он может либо закрыть логический канал после установления соединения для передачи речевой информации, либо оставить его до конца сеанса связи, если поддерживаются дополнительные услуги. Для установления соединения используются сообщения Setup и Connect, после передачи, которых устанавливается канал управления Н.245. Канал для передачи информации управления Н.245 может быть установлен двумя способами: через gatekeeper или непосредственно между оконечными устройствами. В случае, если логический канал сигнализации Q.931 устанавливается через gatekeeper, то канал для передачи информации управления Н.245 также должен устанавливаться через gatekeeper. Способ установления канала для передачи информации управления Н.245 между оконечным оборудованием в настоящее время не специфицирован.
Если канал сигнализации RAS установлен, то он может использоваться для установления нескольких соединений. Идентификация сообщений сигнализации, принадлежащих одному и тому же соединению, осуществляется с помощью идентификатора Call ID.

Сигнализация Н.225.0 (Q.931) и протокол управления Н.245

Стандарт Н.225 описывает протоколы сигнализации и формирования пакетов в системах пакетной передачи мультимедийного трафика. Канал управления вызовами Н.225.0 используется для установления и разрыва соединений между двумя терминалами Н.323, а также между терминалом и шлюзом. Служебные сообщения этого протокола передаются поверх TCP или UDP. Соответствующий механизм Н.225.0 основан на протоколе Q.931, который был разработан для сетей ISDN. Он обеспечивает предоставление целого ряда дополнительных видов обслуживания и возможность взаимодействия с сетями, базирующимися на коммутации каналов. Канал управления вызовом не зависит от канала RAS и канала управления Н.245.
Рекомендация Н.245 определяет синтаксис и семантику терминальных сигнальных сообщений, а также процедур, которые используются для передачи их в полосе разговора в начале или в течение сеанса связи. Определены процедуры подтверждения сигнальной информации для обеспечения гарантии надежной передачи аудио-визуальной информации и данных.
Рекомендация охватывает широкий диапазон приложений, включая хранение/повторную передачу, передачу сообщений и распределение услуг, а также обеспечение диалога. Это применимо к системам передачи всех видов информации, которые используют методы мультиплексирования, определенные в Рекомендациях Н.222.0, Н.223 и Н.225.0.
Протокол управления мультимедийной передачей Н.245 обеспечивает:

- согласование возможностей компонентов;
- установление и разрыв логических каналов;
- передачу запросов на установление приоритета;
- управление потоком (загрузкой канала);
- передачу общих команд и индикаторов.
  Сообщения протокола Н.245 передаются по специальному каналу управления. Это логический канал «0», который, в отличие от каналов обмена мультимедиа-потоками, постоянно открыт. Обмен параметрами между терминалами позволяет согласовывать режимы работы и форматы кодирования информации, что обеспечивает взаимодействие терминалов от разных производителей. В процессе обмена сообщениями о параметрах уточняются возможности терминалов принимать и передавать различные виды трафика.
  С помощью сигнализации Q.931 согласно рекомендации МСЭ-Т Н.225.0 и протоколу управления Н.245 должно осуществляться:
- передача запроса на установление соединения;
- инициализация соединения и обмен информацией о возможностях;
- установление соединения для передачи речевой информации;
- разъединение соединения.
  Для установления соединения инициатор вызова (оконечное оборудование 1) должно передать сообщение Setup оконечному оборудованию 2 по логическому каналу сигнализации с идентификатором TSAP, равным 1719.
  В ответ получатель (оконечное оборудование 2) должен передать сообщение Connect, сообщающее инициатору о готовности установить соединение. Инициатор сообщения должен получить сообщения Call proceeding, Connect, Alerting в течении 4 секунд.
  После получения сообщения Connect должен быть установлен логический канал управления Н.245, по которому передается информация о возможностях оконечного оборудования в сообщении terminal Capability Set.
  Для определения инициатора установления канала RTP используется идентификатор status Determination Number в сообщении Master Slave Determination.
  После инициализации соединения создается логический канал для передачи речевой информации. Установление канала для передачи речевой информации осуществляется оконечным оборудованием после получения сообщения open Logical Channel по каналу управления Н.245. Передача речевой информации по логическому каналу должна осуществляться в пакетах RTP. Передача управляющей информации должна осуществляться в пакетах RTCP.
  При необходимости изменить требуемую полосу пропускания используется сообщение BRQ (Bandwidth Change Request) сигнализации RAS, которое может передаваться как gatekeeper, так и оконечным оборудованием. Если изменение полосы пропускания невозможно, то посылается сообщение BRJ (Bandwidth Reject). Если изменение возможно, то передается сообщение BCF (Bandwidth Confirm).
  Уменьшение полосы пропускания возможно всегда, а для увеличения полосы пропускания свыше значения, указанного в последнем сообщении ARQ, оконечное оборудование должно закрыть все логические каналы и открыть их заново. Логический канал должен быть закрыт сообщением close Logical Channel протокола управления Н.245, а открыт с новыми параметрами сообщением open Logical Channel.
  Соединение разъединяется следующим образом:
- инициатор разъединения должен закрыть канал сообщением close Logical Channel, передаваемым по каналу управления Н.245;
- инициатор разъединения должен передать сообщение end Session Command, передаваемым по каналу управления Н.245;
- удаленное оборудование дожидается сообщения end Session Command, передаваемое по каналу управления Н.245;
- если логический канал сигнализации Q.931 открыт, он закрывается сообщением Release Complete.
  Если в системе присутствует Gatekeeper, то он должен освободить ранее выделенную полосу пропускания. Освобождение полосы пропускания осуществляется сообщением DRQ (Disengage Request) сигнализации RAS, передаваемым оконечным оборудованием. В ответ должно быть получено сообщение подтверждения DCF (Disengage Confirm) или сообщение отказа DRJ (Disengage Reject).

  Сигнализация Н.450

  Дополнительные услуги в сетях IP-телефонии определяет семейство рекомендаций Н.450. Так, 450.1 описывает протокол сигнализации между двумя компонентами сети, позволяющий предоставлять дополнительные услуги, а 450.2 - механизмы услуги трансформации вызова (Call Transfer), благодаря которой соединение между терминалами А и Б преобразуется в соединение между Б и В. Дополнительная услуга Call Diversion, которую определяет Н.450.3, предоставляет возможность переадресовать вызов в тех случаях, когда вызываемый абонент занят, не отвечает или когда предварительно установлен соответствующий параметр.

  Сигнализация на основе протокола SIP.

  Протокол SIP (описанный в RFC 2543) является довольно молодым решением, призванный избавиться от сложности и других недостатков основоположника сетей IP-телефонии – H.323. SIP представляет собой текст ориентированный протокол, который является частью глобальной архитектуры мультимедиа, разработанной комитетом IETF. Эта архитектура так же включает в себя протокол резервирования ресурсов (RSVP – Resource Reservation Protocol, RFC 2205), транспортный протокол реального времени (RTP – Real-Time Transport Protocol, RFC 1889), протокол передачи потоков в реальном времени (RTSP – Real-Time Streaming Protocol, RFC 2326), протокол описания параметров связи (SDP – Session Description Protocol, RFC 2327), протокол уведомления о связи (SAP – Session Announcement Protocol). Однако функции протокола SIP не зависят от любого из этих протоколов. Следует отметить, что хотя на сегодня наиболее широкое распространение получил протокол H.323, всё большее количество производителей старается предусмотреть в своих новых продуктах поддержку протокола SIP. Пока это единичные явления и серьёзной конкуренции протоколу H.323 они составить не могут. Однако учитывая темпы роста популярности протокола SIP, весьма вероятно, что в ближайшем будущем решения на его базе займут значительную нишу рынка IP-телефонии. Подход SIP к построению сетей IP-телефонии намного проще в реализации, чем H.323, но меньше подходит для организации взаимодействия с телефонными сетями. В основном это связанно с тем, что протокол сигнализации SIP, базирующийся на протоколе HTTP, плохо согласуется с системами сигнализации, используемыми в ТФОП. Поэтому протокол SIP более подходит поставщикам услуг Internet для предоставления услуг IP-телефонии, причем эта услуга будет являться всего лишь частью пакета услуг.
  Сеть SIP содержит основные составляющие трех типов: агенты пользователя (SIP-клиенты), прокси-серверы и серверы переадресации. В основном имеет место применение первых двух типов.
  Протокол SIP в качестве транспортной среды может применять как протокол TCP, так и протокол UDP. В спецификации SIPa предусмотрено шесть основных запросов и ответов на них.
  INVITE – запрос привлекает пользователя или услугу к участию в сеансе связи и содержит описание параметров этой связи. С помощью этого запроса пользователь может определить функциональные возможности терминала своего партнера по связи и начать сеанс связи, используя ограниченное число сообщений и подтверждений их приёма.
  ACK-запрос подтверждает прием от вызываемой стороны ответа на команду INVITE и завершает транзакцию.
  OPTIONS – запрос позволяет получить информацию о функциональных возможностях пользовательских агентов и сетевых серверов. Однако этот запрос не используется для организации сеанса связи.
  BYE – запрос используется вызывающей и вызываемой сторонами для разрушения соединения. Перед тем, как разрушить соединение, пользовательские агенты отправляют этот запрос к серверу, сообщая о намерении прекратить сеанс связи.
  CANCEL – запрос позволяет пользовательским агентам и сетевым серверам отменить любой ранее переданный запрос, если ответ на неё ещё не был получен.
  REGISTER – запрос применяется клиентами для регистрации информации о местоположении с использованием серверов SIP.

  Особенности сигнализации по концепции TIPHON

  Базируясь на стандарте Н.323 для IP-сети, спецификация TIPHON дополняет его некоторыми обязательными процедурами, а также механизмами взаимодействия с сетями коммутации каналов. Функциональная модель TIPHON состоит из тех же компонентов - gatekeeper, шлюза и терминала, - что и модель Н.323, однако в ней предусмотрено разделение шлюза на три функциональных объекта. Это шлюз сигнализации (SG - Signalling Gateway), транспортный шлюз (MG – Media Gateway) и контроллер транспортного шлюза (MGC – Media Gateway Controller) (рисунок А.1)

  Функциональная модель сети по проекту TIPHON

  Шлюз сигнализации служит промежуточным звеном сигнализации между сетями с пакетной и канальной коммутацией. В задачи транспортного шлюза входит преобразование и/или перекодирование передаваемой информации; он обеспечивает терминирование ИКМ-трафика телефонных сетей и пакетного трафика, транслирует адреса, подавляет эхо, воспроизводит различные сообщения для абонентов, принимает и передает цифры кодом DTMF и г.д. Контроллер сигнализации MGC выполняет процедуры сигнализации Н.323, которые определены в рекомендациях Н.323, Н.225 (RAS и Q.931) и Н.245, и преобразует сообщения сигнализации телефонных сетей в сообщения сигнализации Н.323. Основная его задача - управлять работой транспортного шлюза, то есть осуществлять контроль за соединениями, использованием ресурсов, трансляцией протоколов и тому подобное. Следует отметить, что MGC не обеспечивает управление вызовами. Это задачи gatekeeper, который выполняет их в соответствии с рекомендациями Н.323.
  При использовании сигнализации ОКС №7 в контроллер MGC по IP-сети будут передаваться сообщения ISUP (подсистемы обслуживания вызовов сети ISDN). Если же применяется сигнализация по выделенному каналу (CAS), сигнальные сообщения сначала вместе с информацией абонента поступят в транспортный шлюз, а затем уже будут выделены в контроллер MGC. При этом предполагается использовать протокол MDTP (Multi-Network Datagram Transmission Protocol), который служит для инкапсуляции телефонных протоколов сигнализации (ISUP, CAS, PRI) и передачи переносимой ими информации в контроллер транспортного шлюза.
  MGC анализирует информацию сигнализации и передает управляющую информацию в транспортный шлюз посредством специального протокола управления, в задачи которого входит обеспечение управления различными ресурсами (системой интерактивного речевого отклика, мостами конференцсвязи и т.д.), приемом и формированием сигналов DTMF, формированием тональных сигналов (готовности к набору номера, контроля посылки вызова, «занято» и прочее), эхо-подавлением, использованием кодеков (G.711, G.723.1, G.729, GSM и так далее), сбором статистики, тестированием конечных точек (например, испытания по шлейфу), резервированием, разъединением и блокировкой конечных точек, шифрованием.
  Протокол управления транспортными шлюзами MGCP представляет собой достаточно простой протокол клиент-сервер. Логика управления вызовами выполняется агентом (Call Agent), находящимся вне транспортного шлюза. Сам же транспортный шлюз представляется в виде объекта, состоящего из конечных точек - точек входа/выхода информационных потоков и соединений - двух или более соединенных конечных точек. Модель определяет физические конечные точки (например, окончания соединительных линий) и виртуальные конечные точки (например, аудиоисточники). Сам протокол MGCP использует принцип «ведущий/ведомый», согласно которому агент управления вызовами передает транспортному шлюзу команды для управления конечными точками и соединениями, а также инициации определенных действий.
  MGCP является достаточно универсальным протоколом, способным обеспечить распределенное управление различными типами транспортных шлюзов, в частности телефонными шлюзами и серверами доступа. Он может использоваться для установления соединения и выполнения разных функций обслуживания, например тестирования шлейфа.
  Дальнейшим развитием протокола MGCP является протокол управления вызовами Megaco (Media Gateway Control), известный также как стандарт ITU Н.248, который определяет взаимодействие, с одной стороны, шлюза между разными средами передачи данных (Media Gateway, MG) и. с другой, - контроллера шлюзов между средами передачи данных (Media Gateway Controller, MGC). Иными словами, Megaco разработан для внутридоменного удаленного управления устройствами, отвечающими за установление соединения или проведение сеанса связи, включая шлюзы VoIP, серверы удаленного доступа, мультиплексоры цифровых абонентских линий (Digital Subscriber Line Access Multiplexer, DSLAM), маршрутизаторы с поддержкой многопротокольной коммутации с использованием меток (Multiprotocol Label Switching, MPLS), оптические кросс-коннекторы, модули агрегирования сеансов РРР и unvrue.
  MGCP и Megaco - это сравнительно низкоуровневые протоколы управления устройствами, которые сообщают шлюзу, каким образом связать потоки, поступающие в сеть с коммутацией пакетов или ячеек, с потоками пакетов или ячеек, переносимыми, например, транспортным протоколом реального времени (Real-Time Transport Protocol, RTP). По существу, Megaco повторяет MGCP в отношении архитектуры и взаимодействия контроллера со шлюзом, но при этом Megaco поддерживает более широкий диапазон сетевых технологий, в том числе ATM.
  Типичным примером работы протокола MGCP является проверка состояния конечной точки на предмет снятия трубки (которую поднимает абонент, чтобы сделать звонок). После фиксации события «снятие трубки» шлюз сообщает об этом контроллеру, после чего последний может послать шлюзу команду подать в линию непрерывный гудок и ждать тональных сигналов DTMF набираемого номера абонента. После получения номера контроллер решает, по какому маршруту следует направить вызов, и, используя протокол сигнализации между контроллерами, в том числе Н.323, SIP или Q.BICC, взаимодействует с оконечным контроллером. Оконечный контроллер дает соответствующему шлюзу указание подать звонок на вызываемую линию. Когда этот шлюз определяет, что вызываемый абонент снял трубку, оба контроллера дают соответствующим шлюзам команды на установление двухсторонней голосовой связи по сети передачи данных. Таким способом данные протоколы распознают состояния конечных точек, уведомляют об этих состояниях контроллер, генерируют в линии сигналы (например, непрерывный гудок), а также формируют потоки данных между подключенными к шлюзу конечными точками и сетью передачи данных, например потоки RTP.
  Протоколы MGCP и Megaco очень похожи друг на друга, и для многих приложений не имеет значения, какой из них будет использоваться. Однако Megaco лучше интегрирован с приложениями с поддержкой нескольких сред передачи, чем MGCP, потому что в базовый протокол включены семантические элементы для конференций. Благодаря этому MGCP может быть лучшей основой для приложений, не привязанных к какой-либо среде, например для управления сеансами на базе MPLS.
  Следует отметить, что вопрос о принятии Megaco в качестве международного стандарта для приложений с различными средами передачи данных является пока открытым, хотя некоторые производители приступили к внедрению данного протокола в свои продукты. Подтверждением этого является то, что в конце августа 2000 г. в лаборатории функциональной совместимости университета Нью-Гемпшира проводилось тестирование уже более десяти независимых разработок, использующих протокол Megaco.