|
Главная страница / Литература / Учебник по IP-телефонии
Глава №4. СИГНАЛИЗАЦИЯ В СЕТЯХ IP-ТЕЛЕФОНИИ
4.1. Общие принципы сигнализации в сетях IP-телефонии
Для обеспечения
широкомасштабного внедрения IP-телефонии одним из самых важных факторов является
обеспечение совместимости систем разных фирм. Достижение совместимости возможно
только на базе стандартных протоколов сигнализации. Протоколы сигнализации обеспечивают
установление, администрирование и завершение сеанса связи между конечными точками
(пользователями), однозначно идентифицируемыми заданной схемой адресации. Понятие
«сигнализация» относится ко всей информации, связанной с вызовами
и необходимой для их установления, маршрутизации, мониторинга и завершения как
на физическом, так и на логическом уровне.
В традиционной
телефонии вызывающий пользователь набирает номер нужного ему абонента, а телефонная
сеть использует его для маршрутизации вызова. Процедура управления вызовами
делится на три фазы: установление соединения, передача речи или данных и разъединение.
Сообщения системы сигнализации инициируют и завершают эти фазы, а стандартные
контрольные сигналы и (или) записанные голосовые сообщения информируют абонента
о характере прохождения его вызова.
Во всех современных
сетях с коммутацией каналов система сигнализации основана на семействе ОКС №7.
Они обеспечивают обмен сообщениями, которые необходимы для маршрутизации вызовов,
резервирования ресурсов, трансляции адресов, установления соединений, управления
ими, выставления счетов. Кроме того, на Взаимоувязанной сети связи Российской
Федерации используется еще много других систем сигнализации (аналоговых и цифровых).
По сравнению
с сигнализацией в обычных телефонных сетях сигнализация IP-телефонии должна
обладать более широкими возможностями в силу специфики конечных узлов. Они могут
иметь самые разные характеристики в части требуемой полосы пропускания, кодирования/декодирования
аудиосигналов, передачи данных и т.д., и для установления сеанса связи между
ними необходимо убедиться в совместимости этих характеристик.
В системах
IP-телефонии процедуры управления вызовами выполняются протоколами сигнализации,
а непосредственная маршрутизация трафика через IP-сеть обеспечивается протоколами:
OSPF или ВGР (резервирование сетевых ресурсов возможно, например, при помощи
протокола RSVP). Таким образом, архитектура сети IP-телефонии предусматривает
разделение плоскостей управления и передачи пользовательской информации, что
является наиболее благоприятным условием для внедрения новых услуг (рис. 4.1).
В настоящее
время еще окончательно не решен вопрос выбора оптимальной архитектуры управления
вызовами особенно для Интернет-телефонии: должна ли она быть интегрирована
с существующими службами Интернет или развернута отдельно для обеспечения управления
в режиме реального времени. Первый подход привлекает Интернет-провайдеров, которые
рассматривают услуги Интернет-телефонии лишь как небольшую часть своего сервисного
пакета. Они планируют предлагать эти услуги по фиксированным тарифам, используя
максимально упрощенную схему управления услугами. За второй подход ратуют операторы,
для которых Интернет-телефония является основной или даже единственной предлагаемой
услугой. Им необходимы системы, способные обеспечить высокий уровень контроля
за использованием сетевых ресурсов и мощные средства биллинга.
Рис. 4.1. Управление вызовами в сети IP-телефонии
Еще один
важный вопрос, связанный с сигнализацией в IP-телефонии — контроль за доступом
к сети. В обычной телефонной сети общего пользования (ТфОП) абонент подключается
к АТС через фиксированный местный шлейф, поэтому идентифицировать его телефонный
аппарат очень просто. В сети IP-телефонии все гораздо сложнее, поскольку существует
множество разных способов доступа к ней: с обычного телефона через ТфОП, по
модемному соединению через сервер удаленного доступа, через ЛВС и территориально
распределенную сеть и т.д. Кроме этого, пользователи могут перемещаться между
различными сетями, таким образом, абонента нельзя идентифицировать по используемой
им линии доступа.
Для эффективного
контроля за доступом оператор должен аутентифицировать каждого пользователя,
запрашивающего услугу. С увеличением числа операторов IP-телефонии требуются
также средства контроля за трафиком на границе между их сетями. Такие средства
должны осуществлять контроль за доступом и использованием сетевых ресурсов и
выполнением соглашений
по качеству обслуживания. При их отсутствии оператору может оказаться проблематичным
гарантировать пользователю определенный класс обслуживания, если его — трафик
частично проходит через сеть другого оператора.
На рис. 4.2
показано место механизмов сигнализации IP-телефонии в протокольном стеке: над
ними находятся приложения, под ними — транспортные службы IP. Приложение может
представлять собой телефонный шлюз.
Рис. 4.2. Механизмы сигнализации IP-телефонии в протокольном стеке
В общем случае
для установления соединения между вызываемым и вызывающим абонентом шлюзы IP-телефонии
должны:
- найти gatekeeper, на котором возможна регистрация оконечного устройства;
- зарегистрировать свой мнемонический адрес на gatekeeper;
- указать требуемую полосу пропускания;
- передать запрос на установление соединения;
- установить соединение;
- в процессе вызова управлять параметрами соединения;
- разъединить соединение.
Для выполнения
этих операций в настоящее время могут использоваться различные протоколы сигнализации,
рассмотренные ниже.
4.2. Сигнализация по стандарту H.323
Рекомендация
Международного союза электросвязи (МСЭ-Т) H.323 определяет основы процесса передачи
аудио, видео и данных по сетям с коммутацией пакетов, например по сетям IP.
В ней описаны объекты, необходимые для мультимедийной связи, их функции и способы
взаимодействия, в частности алгоритмы формирования пакетов, сжатия аудио- и
видеоинформации. Кроме того, рекомендация H.323 нацелена на решение задач администрирования
конечных пользователей, адресации, контроля за использованием полосы пропускания
сети и сетевых объектов.
В настоящее
время действительна версия 2 H.323 — это зонтичная рекомендация, в которой описаны
компоненты сети и даны рекомендации к применению множества дополнительных рекомендаций.
Все вместе эти рекомендации часто называют семейством H.323 (рис. 4.3).
Сейчас готовится
следующая версия стандарта. В ней будут описаны: создание пакетных сетей факсимильной
связи и организация связи между H.323-шлюзами. Речь идет и о таких функциях,
распространенных в современной телефонии, включая уведомление о поступлении
второго вызова и режим справки. Некоторые компании добиваются включения в H.323
поддержки мультимедиа-возможностей, основанных на предложенном IETF протоколе
Session Initiation Protocol. Помимо «телефонных» функций, новая
версия будет дополнена средствами, позволяющими учитывать параметры сеансов
для целей тарификации, а также поддержкой каталогов — вместо цифровых IP-адресов
можно будет пользоваться именами абонентов.
Для выполнения
действий сигнализации между шлюзами и gatekeeper в соответствии с Рекомендацией
МСЭ-Т H.323 должны использоваться следующие протоколы:
- сигнализация RAS (Registration, Admission, Status);
- сигнализация Q.931 (согласно H.225.0);
- протокол управления Н.245.
Сигнализация
RAS
Протокол
сигнализации RAS (регистрации, подтверждения и состояния) применяется для передачи
служебных сообщений между терминалами и контроллером зоны H.323. RAS-сообщения
служат для регистрации терминалов, допуска их к сеансу связи, изменения используемой
полосы пропускания, информирования о состоянии сеанса и его прекращении. В отсутствии
контроллера зоны (gatekeeper) протокол RAS не задействуется.
Функции сигнализации
RAS используют сообщения протокола H.225.0. Канал сигнализации RAS не зависит
от канала управления вызовом и канала управления Н.245.
С помощью сигнализации RAS должно осуществляться:
- нахождение gatekeeper, на котором возможна регистрация оконечного оборудования;
- регистрация оконечного устройства;
- определение географического положения оконечного устройства;
- указание необходимой полосы пропускания;
- изменение полосы пропускания.
Передача
сообщений RAS осуществляется в дейтаграммах UDP. Для адресации RAS должна использоваться
адресная информации, в которую входят:
- сетевой адрес оборудования;
- идентификатор TSAP (Transport Layer Service Access Point);
- мнемонический адрес (Alias Address).
Сетевой адрес
является адресом в формате, используемом в сети с коммутацией пакетов, например,
адрес в форматах IPv4, IPv6, IPX, NetBIOS.
Идентификатор
TSAP используется для идентификации информационных потоков, отправленных с одного
сетевого адреса. Для gatekeeper выделены постоянные значения идеyтификатора
TSAP: 1718 (для поиска gatekeeper) и 1719 (для передачи сообщений сигнализации
RAS).
Мнемонический адрес служит для адресации оконечного оборудования в удобной пользователю форме.
Адресом может быть телефонный номер в формате ЕЛ 64, телефонный
номер в корпоративной сети, адрес электронной почты и т.д. Gatekeeper не имеет мнемонического адреса.
Рис. 4.3. Совокупность рекомендаций H.323
Нахождение
gatekeeper должно осуществляться с помощью широковещательного запроса GRQ (Gatekeeper
Request), передаваемого оконечным оборудованием с идентификатором TSAP, равным
1718. Если gatekeeper найден, и он готов обслужить запрос от оконечного оборудования,
в ответ оно должно получить сообщение GCF (Gatekeeper Confirm). Если оконечное
оборудование получило ответ от нескольких gatekeeper, выбор одного из них должен
осуществляться оконечным оборудованием произвольным образом. Если gatekeeper
не может обслужить запрос от оконечного оборудования, то в ответ он должен передать
сообщение GRJ (Gatekeeper Reject), в котором должна сообщаться причина отказа,
и может содержаться адрес альтернативного gatekeeper. При нахождении gatekeeper
между ним и оконечным оборудованием осуществляется установление логического
канала сигнализации, по которому будут передаваться остальные сообщения RAS
(рис. 4.4).
После нахождения
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 (в соответствии с H.225.0).
Сообщения сигнализации Q.931 могут передаваться по логическому каналу через
gatekeeper или непосредственно между двумя оконечными устройствами. Выбор способа
осуществляет gatekeeper и сообщает об этом оконечному оборудованию в сообщении
ACF.
Если сообщения
передаются через gatekeeper, то он может либо закрыть логический канал после
установления соединения для передачи речевой информации, либо оставить его до
конца сеанса связи, если поддерживаются дополнительные услуги.
Рис. 4.4. Этапы прохождения вызова в среде H.323
Для установления
соединения используются сообщения Setup и Connect, после передачи которых устанавливается
канал управления Н.245. Канал для передачи информации управления Н.245 может
быть установлен двумя способами: через gatekeeper или непосредственно между
оконечными устройствами. В случае, если логический канал сигнализации Q.931
устанавливается через gatekeeper, то канал для передачи информации управления
Н.245 также должен устанавливаться через gatekeeper. Способ установления канала
для передачи информации управления Н.245 между оконечным оборудованием в настоящее
время не специфицирован.
Если канал
сигнализации RAS установлен, то он может использоваться для установления нескольких
соединений. Идентификация сообщений сигнализации, принадлежащих одному и тому
же соединению, осуществляется с помощью идентификатора Call ID.
Сигнализация H.225.0 (Q.931) и протокол управления Н.245
Стандарт
H.225 описывает протоколы сигнализации и формирования пакетов в системах пакетной
передачи мультимедийного трафика. Канал управления вызовами H.225.0 используется
для установления и разрыва соединений между двумя терминалами H.323, а также
между терминалом и шлюзом. Служебные сообщения этого протокола передаются поверх
TCP или UDP (рис. 4.5). Соответствующий механизм H.225.0 основан на протоколе
Q.931, который был разработан для сетей ISDN. Он обеспечивает предоставление
целого ряда дополнительных видов обслуживания и возможность взаимодействия с
сетями, базирующимися на коммутации каналов. Канал управления вызовом не зависит
от канала RAS и канала управления Н.245.
Рис. 4.5. Положение H.225.0 в стеке протоколов H.323
Рекомендация
Н.245 определяет синтаксис и семантику терминальных сигнальных сообщений, а
также процедур, которые используются для передачи их в полосе разговора в начале
или в течение сеанса связи. Определены процедуры подтверждения сигнальной информации
для обеспечения гарантии надежной передачи аудиовизуальной информации и данных.
Рекомендация
охватывает широкий диапазон приложений, включая хранение/повторную передачу,
передачу сообщений и распределение услуг, а также обеспечение диалога. Это применимо
к системам передачи всех видов информации, которые используют методы мультиплексирования,
определенные в Рекомендациях Н.222.0, Н.223 и H.225.0.
Протокол управления мультимедийной передачей Н.245 обеспечивает:
- согласование возможностей компонентов;
- установление и разрыв логических каналов;
- передачу запросов на установление приоритета;
- управление потоком (загрузкой канала);
- передачу общих команд и индикаторов.
Сообщения
протокола Н.245 передаются по специальному каналу управления. Это логический
канал «О», который, в отличие от каналов обмена мультимедиа-потоками,
постоянно открыт. Обмен параметрами между терминалами позволяет согласовывать
режимы работы и форматы кодирования информации, что обеспечивает взаимодействие
терминалов от разных производителей. В процессе обмена сообщениями о параметрах
уточняются возможности терминалов принимать и передавать различные виды трафика.
С помощью
сигнализации Q.931 согласно рекомендации МСЭ-Т H.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, предоставляет возможность переадресовать вызов в тех случаях, когда
вызываемый абонент занят, не отвечает или когда предварительно установлен соответствующий
параметр.
4.3. Сигнализация на основе протокола SIP
Протокол
SIP (Session Initiation Protocol) является протоколом прикладного уровня, разработанным
рабочей группой по управлению многоточечными сеансами мультимедиа-связи (MMUSIC)
организации IETF (Рекомендация RFC 2543). Он позволяет организовать и провести
такой сеанс, обеспечивая его установление, модификацию и завершение.
При организации
мультимедийного сеанса используется два основных метода для нахождения и информирования
заинтересованных участников:
- уведомление о сеансе
с использованием разных средств — электронной почты, новостных групп, Web-страниц
или специального протокола SAP (Session Announcement Protocol);
- приглашение к участию в сеансе с помощью протокола SIP.
Для установления
сеансов одноадресного вещания, которое характерно при IP-телефонии, основным
протоколом установления соединений является протокол SIP. SIP работает по схеме
клиент-сервер (рис. 4.6): клиент запрашивает определенный тип сервиса, а сервер
обрабатывает его запрос и обеспечивает предоставление сервиса. Согласно протоколу
SIP, пользовательская
система может не только формировать, но и принимать запросы. Это означает, что
она должна быть оснащена и клиентской (клиент агента пользователя — UAC) и серверной
(сервер агента пользователя — UAS) частями.
Рис. 4.6. Схема сигнализации по протоколу SIP
Обработка
вызовов осуществляется сервером SIP, который может работать в режиме непосредственного
установления связи или в режиме переадресации. В обоих режимах сервер принимает
запросы на определение местоположения нужного пользователя, но если в первом
режиме он сам доводит вызов до адресата, то во втором — возвращает адрес конечного
пункта запрашиваемому клиенту.
В протоколе
SIP определены два вида сигнальных сообщений — запрос и ответ. Они имеют текстовый
формат (кодировка символов согласно RFC 2279) и базируются на протоколе HTTP
(синтаксис и семантика определены в RFC 2068). В запросе указываются процедуры,
вызываемые для выполнения требуемых операций, а в ответе — результаты их выполнения.
Определены шесть процедур:
- INVITE — приглашает
пользователя принять участие в сеансе связи (служит для установления нового
соединения; может содержать параметры для согласования);
- BYE — завершает соединение между двумя пользователями;
- OPTIONS — используется
для передачи информации о поддерживаемых характеристиках (эта передача может
осуществляться напрямую между двумя агентами пользователей или через сервер SIP);
- АСК — используется для подтверждения получения сообщения или для положительного ответа на команду INVITE;
- CANCEL — прекращает поиск пользователя;
- REGISTER — передает информацию о местоположении пользователя на сервер SIP, который может транслировать
ее на сервер адресов (Location Server).
Оба протокола
SAP и SIP используют механизм SDP (Session Description Protocol) для описания
характеристик сеанса: время проведения, требуемые ресурсы и т.д. (Рекомендация
RFC 2327). SDP используется исключительно для текстового описания сеанса и не
имеет ни транспортных механизмов, ни средств согласования требуемых для сеанса
параметров. Эти функции должны выполнять протоколы, применяемые для передачи
информации SDP.
Сообщения-ответы
могут содержать шесть типов возможных результатов: запрос в процессе выполнения
(1хх), успешный запрос (2хх), переадресация (Зхх), неправильный запрос (4хх),
отказ сервера (5хх) и глобальный отказ (6хх).
Используемая
в SIP адресация основана на унифицированном указателе ресурсов SIP URL, в котором
может быть записано имя домена (user@domain) или IP-адрес (user@IPadress) пользователя.
Цель использования подобного формата — интеграция SIP-услуг с существующими
службами Интернет. Сервер имен доменов (DNS) преобразует доменные имена в IP-адреса
конечной точки (рис. 4.7). Вся маршрутизация и передача мультимедийных потоков
выполняется нижележащей IP-сетью. Таким образом, услуги SIP хорошо интегрируются
в традиционную модель Web-коммуникаций с сервером DNS, обеспечивающим преобразование
доменного имени в сетевой адрес.
Предназначенный
для инициации сеансов протокол SIP обеспечивает определение адреса пользователя
и установление соединения с ним. Кроме этого, он служит основой для применения
других протоколов, реализующих функции защиты, аутентификации, описания канала
мультимедийной связи и т.д. Для биллинга, например, может использоваться протокол
Radius.
В работах
над протоколом SIP участвуют ведущие производители сетевого и телекоммуникационного
оборудования (Cisco Systems, Lucent Technologies, 3Com) и крупнейшие операторы
(AT&T, MCI, Level 3). О своих планах по его поддержке заявили и многие компании,
в частности, CableLabs, Telcordia, General Instrument, Com21.
Примером
реализации протокола SIP может служить программная платформа еСоп-vergence Server
Solutions фирмы Dynamicsoft, включающая следующие продукты:
- SIP Proxy Server —
маршрутизатор между конечными точками, каждая из которых определена как UAC
или UAS; в дополнение к функциям обеспечения взаимодействия между различными
серверами платформы он предоставляет услуги перенаправления и регистрации/определения
местоположения пользователей;
- SIP Location Server
— обеспечивает безопасную сигнализацию вызовов, хранит информацию о пользователях,
необходимую сервис-провайдерам для гибкого управления доступом пользователей
и маршрутизации вызовов с целью предоставления наилучшего качества услуги;
- SIP User Agent — управляет
соединениями между исходящей и входящей сторонами, обеспечивая поддержку необходимого
качества услуг;
- SIP CallAccounting
Server — выполняет функции сбора и обработки информации в виде детальных отчетов
о транзакциях TDR, получаемых от SIP Proxy Server, которая в дальнейшем может
быть использована в системах биллинга и менеджмента пользователей.
Рис. 4.7. Возможный сценарий установления и завершения сеанса связи по протоколу SIP
4.4. Сравнение протоколов H.323 и SIP
Протоколы
H.323 и SIP представляют существенно различные подходы к решению одних и тех
же задач: если H.323 близок к традиционным системам сигнализации (с коммутацией
каналов на основе протокола Q.931 или более ранних рекомендаций серии Н), то
SIP реализует более простой, интернетовский подход на основе HTTP.
Следует отметить,
что стандарт H.323 не решает проблемы, связанные с защитой вызова от несанкционированного
доступа, взаимодействием между шлюзами и gatekeeper разных сетей, между телефонами
и персональными компьютерами, роумингом и интеграцией с телефонной сигнализацией
ОКС №7. Протокол H.323 может лишь гарантировать взаимодействие типа шлюз-шлюз
и телефон-телефон, поскольку ориентирован на транспортные сервисы в середине
сети и не способен что-либо улучшить на уровне конечных узлов. Он не предусматривает
каких-либо средств, облегчающих разработку новых приложений. Алгоритмы H.323
не оптимизированы для реальных сетей, они сложны в реализации и требуют больших
ресурсов на клиентской стороне. Тем не менее, рекомендация неплохо подходит
для популярных сегодня магистральных приложений IP-телефонии в виде Интернет-телефонии,
обеспечивающих существенное снижение расходов на междугородную и международную
связь.
По сравнению
с H.323 протокол SIP базируется на текстовом формате, более прост для реализации
и добавления новых функций. Простота SIP не означает скудность его функциональных
возможностей. Протокол обеспечивает реализацию важных для систем Интернет-телефонии
функций, включая шифрование и аутентификация. То, что SIP базируется на архитектуре
клиент-сервер, позволяет обеспечить управление вызовами на уровне сервера (подобное
невозможно в одноранговых схемах обслуживания вызовов, используемых большинством
конечных точек H.323). В настоящее время предложены спецификации, которые расширяют
протокол SIP средствами управления безопасностью вызова, запроса качества обслуживания,
сигнализации изменения состояния сети.
Систему объектов
H.323 можно рассматривать как прикладную сеть, наложенную на сеть передачи данных
(IP-сеть), в то время как службы SIP ориентированы на интеграцию со службами
Интернет. Какой из вариантов более предпочтителен, зависит от требуемых функциональных
возможностей и целей бизнеса.
Технология
H.323 предоставляет больше возможностей по управлению конкретной услугой в части
аутентификации и учета и контроля за использованием сетевых ресурсов. Возможности
протокола SIP здесь значительно меньшие. Выбор этого протокола компанией-поставщиком
услуг фактически означает, что технологическая интеграция услуг для нее важнее
возможностей гибкой тарификации и контроля за использованием сетевых ресурсов.
В целом можно
сделать вывод, что протокол SIP ориентирован на Интернет-провайдеров, которые
рассматривают услугу Интернет-телефонии лишь как небольшую часть своего сервисного
пакета. Будучи самодостаточной, технология H.323 больше подходит для корпоративных
сетей (интранет) и поставщиков услуг IP-телефонии, для которых данные услуги
не являются доминирующими. В целом H.323 и SIP не следует рассматривать как
конкурирующие технологии, они являются различными подходами, предназначенными
для разных сегментов рынка. Они могут работать параллельно и даже взаимодействовать
через специальный пограничный шлюз.
4.5. Особенности сигнализации по концепции TIPHON
Базируясь
на стандарте H.323 для IP-сети, спецификация TIPHON дополняет его некоторыми
обязательными процедурами, а также механизмами взаимодействия с сетями коммутации
каналов. Функциональная модель TIPHON состоит из тех же компонентов -gatekeeper,
шлюза и терминала, — что и модель H.323, однако в ней предусмотрено разделение
шлюза на три функциональных объекта. Это шлюз сигнализации (SG — Signalling
Gate— way), транспортный шлюз (MG — Media Gateway) и контроллер транспортного
шлюза (MGC — Media Gateway Controller) (рис. 4.8).
Рис. 4.8. Функциональная модель сети по проекту TIPHON
Шлюз сигнализации
.служит промежуточным звеном сигнализации между сетями с пакетной и канальной
коммутацией. В задачи транспортного шлюза входит преобразование и/или перекодирование
передаваемой информации; он обеспечивает терминирование ИКМ-трафика телефонных
сетей и пакетного трафика, транслирует адреса, подавляет эхо, воспроизводит
различные сообщения для абонентов, принимает и передает цифры кодом DTMF и т.д.
Контроллер сигнализации MGC выполняет процедуры сигнализации H.323, которые
определены в рекомендациях H.323, H.225 (RAS и Q.931) и Н.245, и преобразует
сообщения сигнализации телефонных сетей в сообщения сигнализации H.323. Основная
его задача -управлять работой транспортного шлюза, т.е. осуществлять контроль
за соединениями, использованием ресурсов, трансляцией протоколов и т.п. Следует
отметить, что MGC не обеспечивает управление вызовами. Это задачи gatekeeper,
который выполняет их в соответствии с рекомендациями H.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 H.248, который определяет
взаимодействие, с одной стороны, шлюза между разными средами передачи данных
(Media Gateway, MG) и, с другой, — контроллера шлюзов между средами передачи
данных (Media Gateway Controller, MGC) (рис. 4.9). Иными словами, Megaco разработан
для внутри-доменного удаленного управления устройствами, отвечающими за установление
соединения или проведение сеанса связи, включая шлюзы VoIP, серверы удаленного
доступа, мультиплексоры цифровых абонентских линий (Digital Subscriber Line
Access Multiplexer, DSLAM), маршрутизаторы с поддержкой многопротокольной коммутации
с использованием меток (Multiprotocol Label Switching, MPLS), оптические кросс-коннекторы,
модули агрегирования сеансов РРР и другие.
Рис. 4.9. Использование протокола Megaco в сети IP-телефонии
MGCP и Megaco — эти сравнительно низкоуровневые протоколы управления устройствами, которые
сообщают шлюзу, каким образом связать потоки, поступающие в сеть с коммутацией
пакетов или ячеек, с потоками пакетов или ячеек, переносимыми, например, транспортным
протоколом реального времени (Real-Time Transport Protocol, RTF). По существу,
Megaco повторяет MGCP в отношении архитектуры и взаимодействия контроллера со
шлюзом, но при этом Megaco поддерживает более широкий диапазон сетевых технологий,
в том числе ATM.
Типичным
примером работы протокола MGCP является проверка состояния конечной точки на
предмет снятия трубки (которую поднимает абонент, чтобы сделать звонок). После
фиксации события «снятие трубки» шлюз сообщает об этом контроллеру,
после чего последний может послать шлюзу команду подать в линию непрерывный
гудок и ждать тональных сигналов DTMF набираемого номера абонента. После получения
номера контроллер решает, по какому маршруту следует направить вызов, и, используя
протокол сигнализации между контроллерами, в том числе H.323, SIP или Q.BICC,
взаимодействует с оконечным контроллером. Оконечный контроллер дает соответствующему
шлюзу указание подать звонок на вызываемую линию. Когда этот шлюз определяет,
что вызываемый абонент снял трубку, оба контроллера дают соответствующим шлюзам
команды на установление двухсторонней голосовой связи по сети передачи данных.
Таким способом данные протоколы распознают состояния конечных точек, уведомляют
об этих состояниях контроллер,— генерируют в линии сигналы (например, непрерывный
гудок), а также формируют потоки данных между подключенными к шлюзу конечными
точками и сетью передачи данных, например потоки RTP.
Протоколы
MGCP и Megaco очень похожи друг на друга, и для многих приложений не имеет значения,
какой из них будет использоваться. Однако Megaco лучше интегрирован с приложениями
с поддержкой нескольких сред передачи, чем MGCP, потому что в базовый протокол
включены семантические элементы для конференций. Благодаря этому MGCP может
быть лучшей основой для приложений, не привязанных к какой-либо среде, например
для управления сеансами на базе MPLS.
Следует отметить,
что вопрос о принятии Megaco в качестве международного стандарта для приложений
с различными средами передачи данных является пока открытым, хотя некоторые
производители приступили к внедрению данного протокола в свои продукты. Подтверждением
этого является то, что в конце августа 2000 г. в лаборатории функциональной
совместимости университета Нью-Гемпшира проводилось тестирование уже более десяти
независимых разработок, использующих протокол Megaco.
4.6. Межсетевое взаимодействие
При внедрении
систем IP-телефонии часто необходимо решать задачу обеспечения эффективного
взаимодействия сетей различных операторов. Здесь существует масса проблем, связанных
с преобразованием адресов между административными доменами, взаиморасчетами
между операторами, контролем доступа к ресурсам сети, защитой внутренней топологии
и т.д. Успешное решение данных задач должна обеспечивать соответствующая система
сигнализации IP-телефонии.
В третьей
версии рекомендаций H.323 появилось приложение G к H.225. В нем описан метод
взаимодействия административных доменов с помощью объекта, называемого «пограничным
элементом» (Border Element). Этот функциональный элемент поддерживает
открытый доступ к административному домену для доведения вызова до входящего
в этот домен узла или предоставления других услуг, требующих установления мультимедиасвязи
с его узлами.
Взаимодействие
между пограничными элементами осуществляется посредством протокола, который
определен в приложении G. Он может быть использован с целью обмена планами нумерации
и тарификационной информацией, сведениями для авторизации и маршрутизации вызовов,
отчетами об использовании сетевых ресурсов.
Подобные
функции межсетевого взаимодействия реализованы и в проекте TIPHON. На рис. 4.10
показан пример передачи сигнальной информации между терминалом и шлюзом, расположенными
в различных административных доменах.
Рис. 4.10. Пример взаимодействия двух доменов
В сценарии,
показанном на рис. 4.11, ресурсы зоны H.323 (терминал, шлюз и сервер авторизации),
требуемые для реализации вызова IP-телефонии, разделены между тремя административными
доменами. В рассматриваемом случае два домена (первый и второй) не имеют установленных
сигнальных отношений, но каждый должен иметь сигнальные отношения с третьим
доменом, в котором расположен центр авторизации. На рис. 4.11 показаны следующие
потоки информации:
Рис. 4.11. Пример взаимодействия трех доменов
S1: Обмен информацией разрешения запроса между терминалом и gatekeeper 1.
S2: Обмен информацией разрешения запроса между gatekeeper 1 и сервером авторизации.
S3: Обмен информацией разрешения запроса между gatekeeper 1 и шлюзом.
S4: Обмен информацией разрешения запроса между шлюзом и его gatekeeper.
S5: Обмен информацией разрешения запроса между gatekeeper 2 и сервер от третьего лица.
S6: Обмен информацией разрешения запроса между gatekeeper 1 и gatekeeper 2.
Следует особо
отметить, что реализация передачи сигнальной информации между различными административными
доменами в сети IP-телефонии требует обеспечения соответствующей степени защиты
информации.
| 
