Stinger – семейство DSL-решений от Lucent

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

H.323

Одним из самых распространенных протоколов сигнализации является H.323. В сущности, H.323 - это набор технических стандартов, описывающих решение задачи передачи аудио и видео информации по сетям IP. Условно говоря - это язык, на котором договариваются между собой участники соединения. Он включает в себя следующие протоколы:
- RAS (H.225) signaling;
- Call control/call setup (H.225);
- Media control and transport (H.245) signaling.
H.323 определяет четыре основных компонента для коммуникаций (рис. 1):
- Gateway (шлюз);
- Gatekeeper (контроллер);
- Terminal (терминал);
- MCU (multipoint control unit) - устройство для конференций.

Рис. 1.

Терминал - конечное клиентское устройство. Представляет собой аппаратно-программный комплекс, например компьютер со звуковой картой, подключенный к сети. Шлюз - согласующее устройство между H.323 и терминалами других типов. Осуществляет преобразование между форматами передачи данных. Например, это может быть оборудование, соединяющее IP-сеть (VoIP) с телефонной станцией.
Любое из устройств - gateway, terminal, MCU - называют конечным узлом - Endpoint. Для обеспечения двухточечных соединений достаточно использования только Endpointов.

Алгоритм взаимодействия следующий: сначала вызывающий узел (Endpoint) находит вызываемого и договаривается с ним о параметрах связи, используя средства сигнализации H.323, а затем происходит передача кодированной речи (рис. 2).

Рис. 2.

Однако для гибкой маршрутизации соединений, авторизации, биллинга и прочего необходимо использовать Gatekeeper (в переводе с английского - привратник). Он выполняет только функции сигнализации, так называемые RAS - Registration, Admission and Status. Непосредственно данные (речь) передаются между шлюзами и терминалами. Фактически Gatekeeper выполняет функции маршрутизатора звонков.
Совокупность Endpoint’ов, которые регистрируются на конкретном Gatekeeper’e, образуют так называемую зону. Gatekeeper в этом случае является контроллером зоны, он знает о всех Endpoint’ах, которые на нем зарегистрировались. В зоне может быть только один Gatekeeper (рис. 3).

рис. 3.

Gatekeeper - предоставляет следующие обязательные сервисы:
- трансляция адресов (address translation) - преобразование H.323-идентификаторов (вида voice1) и E.164-номеров (стандартные телефонные номера) в IP-адреса данных Endpoints, зарегистрированных на данном Gatekeeper’e;
- управление доступом (admission control) - контролирование прохождения звонков от и к Endpoint;
- регулирование полосы пропускания (bandwidth control) - согласование требуемых Endpoint’ом параметров связи;
- администрирование зоны (zone management) - например, контроль за регистрацией Endpoint’ов в данной зоне.
И необязательные сервисы (может и не предоставлять):
- авторизация вызовов (call authorization) - разрешение звонков в соответствии с определенными правилами;
- маршрутизация H.323 соединений - проброс управляющих сообщений между участниками (очень редкая функция).
Рассмотрим алгоритм взаимодействия Endpoint и Gatekeeper.

поиск Gatekeeper’a

Endpoint при активации (включении) должен найти Gatekeeper. Данное действие выполняется путем посылки специального запроса - gatekeeper request (GRQ). В случае успешного поиска Gatekeeper возвращает gatekeeper confirm (GRQ), а в случае неудачи - gatekeeper reject (GRJ).
Данный пункт алгоритма обычно выполняется даже если gatekeeper вписывается в конфигурацию endpoint статически (для того, чтобы убедиться в наличии и работоспособности Gatekeeper’a). Если же Endpoint вообще ничего не знает о Gatekeepere, то используется multicast-запрос GRQ (рис. 4).

Рис. 4.

регистрация на Gatekeeper’e

Далее Endpoint должен зарегистрироваться на Gatekeeper’e. При этом Endpoint сообщает свои параметры (H.323 ID - идентификатор, E164 - телефонный номер), а Gatekeeper ассоциирует эту информацию с сетевыми параметрами (например, IP-адресом).
Регистрация (имени, номера) происходит путем посылки запроса registration request - RRQ (рис. 5).

Рис. 5.

В случае успеха Gatekeeper посылает registration confirm (RCF) и запоминает параметры зарегистрированного Endpoint’a, а при неудаче - registration reject (RRJ).
После данного этапа Gatekeeper в состоянии выступать в качестве справочной телефонной (адресной) книги при маршрутизации звонков - ведь он знает всех своих зарегистрированных Endpoint’ов.
контроль прохождения вызовов

Контроль разрешения вызовов (admission control) происходит в момент инициализации звонка или получения вызова (рис. 6).

Рис. 6.

Диалог при этом примерно следующий:
- Endpoint посылает ARQ (admission request): «Я, Endpoint такой-то (H.323 ID или номер) хочу позвонить на Endpoint такой-то (H.323 ID или номер)».
- Gatekeeper отвечает ACF (admission confirm): «Да, вы можете позвонить, IP-адрес Endpoint назначения звонка такой-то.
Или:
- Gatekeeper отвечает ARJ (admission reject): «Нет, вы не можете позвонить. Причина такая-то (например, нет такого назначения или у вас недостаточно средств на счете).

согласование параметров связи

Endpoint может согласовать параметры необходимой полосы пропускания, посылая запрос BRQ (bandwidth request), а Gatekeeper отвечает удовлетворительно (BCF, bandwidth confirm), если требуемая полоса может быть выделена, или отрицательно (BRJ, bandwidth reject) если требования невыполнимы (например вся полоса уже исчерпана) (рис. 7).

Рис. 7.

поиск абонента

В случае, если звонок направлен в другую зону (то есть предназначен для Endpoint’а, который не регистрируется на данном Gatekeeper’е и, следовательно, ему не известен), то Gatekeeper может послать другим Gatekeeper’ам специальный запрос для выяснения, где регистрируется нужный Endpoint.
При этом Gatekeeper посылает location request (LRQ), а ему отвечает другой Gatekeeper: location confirm (LCF), если знает о запрашиваемом абоненте, или location reject (LRJ), если ничего не знает.
По сути это поиск абонента в другой зоне (рис. 8).

Рис. 8.

отключение

И, наконец, при прекращении работы Endpoint должен отключиться от Gatekeeper’a, посылая unregistration request (URQ). В ответ Gatekeeper обычно отвечает согласием unregistration confirm (URF) и удаляет данные о Endpoint’e из своей базы. И крайне редко unregistration reject (URJ) (рис. 9).

Рис. 9.

В итоге, упрощенная схема взаимодействия между Endpoint’ами в одной зоне выглядит, как показано на рис. 10.

Рис. 10.

Endpoint’ы регистрируются и координируют направления звонков через Gatekeeper, а голосовой трафик проходит непосредственно между ними. Некоторые Gatekeeper’ы (особенно программные) могут дополнительно проксировать и голосовой поток, в этом случае Endpoint’ы не взаимодействуют между собой вообще. Это может потребоваться, например, в случае подключения к сети IP (Интернет) клиентской подсети с приватными адресами через шлюз, выполняющий функции трансляции адресов. Gatekeeper будет выступать в качестве голосового прокси-сервера.

SIP

Одним из наиболее перспективных протоколов сигнализации в современных приложениях IP-телефонии является SIP. Расшифровывается как Session Initiation Protocol, то есть протокол управления (инициализации, модификации и прерывания) коммуникационными сессиями с одним или несколькими участниками. Определение сессии включает в себя: интернет-мультимедиа-конференции, интернет-телефонные звонки и прочее.
По мнению многих специалистов SIP более приближен к IP-сетевому взаимодействию, чем все остальные протоколы (H.323, MGCP и другие). SIP использует обычные текстовые сообщения и очень напоминает HTTP (практически базируется на нем). Архитектура сети SIP базируется на клиент-серверном взаимодействии.
Компоненты SIP делятся на два класса: клиенты и серверы.
User agent (UA) - клиентское приложение, которое посылает и принимает SIP-запросы. UA, в свою очередь, состоит из UAC (User Agent Client - клиент) и UAS (User Agent Server - сервер). UAC представляет собой инициатора SIP-запросов к UAS (рис. 11).

Рис. 11.

Только UA непосредственно взаимодействует с клиентом. Все остальные компоненты SIP-сети этого не могут, они взаимодействуют только с UA или между собой.
Proxy server принимает SIP запросы от UAC (UA) и инициирует новые запросы в сторону запрашиваемого абонента UAS (UA). Это может быть поиск и вызов абонента, маршрутизация запроса и т.п. Практически это SIP-роутер (маршрутизатор), который перенаправляет запросы сигнализации (call signalling) в реальном времени (рис. 12).

Рис. 12.

Registrar - сервер определения местоположения объектов. Регистрирует клиентов (адреса, по которым они достижимы) (рис. 13).

Рис. 13.

Часто Registrar комбинируется с proxy, но это отдельный логический процесс.
Redirect server - сервер переадресации. Предназначен для определения текущего адреса вызываемого абонента. Алгоритм простой: вызывающий абонент обращается к redirect серверу с известным ему адресом вызываемого пользователя, а redirect переадресует вызов на текущий адрес. В процессе данной деятельности redirect server взаимодействует с сервером registrar. Redirect только сообщает адрес вызываемого абонента или прокси-сервера (рис. 14).

Рис. 14.

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

Рис. 15.

поиск серверов

Как клиентское приложение получает информацию о доступных в сети серверах? Для этого используются следующие алгоритмы:
- IP-адреса серверов могут быть внесены в конфигурацию клиентского приложения. Это менее гибкий, но более надежный способ для статичных топологий.
- Для поиска сервера регистрации (Registrar) может использоваться мультикастовый запрос.
- Для поиска прокси сервера (Proxy) и сервера переадресации (Redirect) может использоваться специальный запрос к серверу имен (DNS). User agent посылает SRV-запрос DNS-серверу, а тот в случае наличия в своей базе нужной информации возвращает имя (Hostname) запрашиваемого сервера и порт (Port) для взаимодействия. По данному имени User agent может выяснить требуемый IP-адрес.

адресация

Для взаимодействия между собой приложения используют SIP-адрес, очень напоминающий адрес электронной почты (SIP URL) . Адреса SIP имеют только UA. Все остальные компоненты (Proxy, Redirect, Registrar) идентифицируются только IP-адресами и номерами портов (например, по умолчанию SIP сервер использует 5060 порт).
Синтаксис SIP адреса следующий:

sip: userid@hostname

где userid - username или e.164 адрес (телефонный номер), hostname - домен, хост или IP-адрес.
Кроме того, в SIP-адрес могут входить дополнительные параметры (пароли, номера портов и тому подобное).
Приведем примеры SIP-адресов:

Sip: vasya@home.ru
Sip: petya@192.168.0.1
Sip: 12345@gate.ru

структура SIP-сообщения

Все SIP-сообщения делятся на два вида: запросы и ответы на них.
Структура любого сообщения выглядит так:

Start line
Headers
Body

В свою очередь Start line запроса включает в себя Method, Request-URI, SIP version.
В спецификации определено несколько видов запросов, включающих следующие методы:
- REGISTER - регистрация на Registrar сервере;
- INVITE - приглашение к началу сеанса связи;
- ACK - подтверждение приема;
- BYE - завершение сеанса связи;
- INFO - информация;
- OPTIONS - дополнительные опции;
и другие.
Для примера приведем начало стандартного SIP-запроса:

INVITE sip: vasya@etel.ru SIP/2.0

Ответы делятся на две группы: информационные и финальные.
Информационные ответы содержат в себе ознакомительные данные. Например: Trying, ringing.
Финальные обозначают завершение каких-либо транзакций. Например: Ok.
Начало любого SIP-ответа (start line) состоит из SIP version, Status Code и Reason Phrase, например:

SIP 2.0 Trying

сценарии SIP-взаимодействий

UA-UA.Взаимодействие непосредственно между клиентскими приложениями (UA) без участия серверов. Для этого вызывающий UA должен знать текущий адрес вызываемого абонента (рис. 16).

Рис. 16.

Во время вызова происходит следующий диалог:
- вызывающий UA: "приглашаю к разговору (INVITE)";
- вызываемый UA: "выдаю звонок (RINGING), трубка поднята, можно начинать разговор (OK)";
- вызывающий UA: "подтверждаю начало разговора (ACK)".
Далее идет разговор (RTP/RTCP между клиентскими приложениями).
Если один из участников решает прекратить связь, то:
- вызывающий UA: завершаем звонок (BYE);
- вызываемый UA - хорошо, завершаем (OK).
UA-Proxy-UA.Звонки c участием Proxy сервера (или нескольких серверов).
Вызывающий UA должен знать постоянный адрес абонента, а прокси осуществит поиск и приглашение к сеансу связи. Текущий адрес знать не обязательно. Кроме того, UA должен предварительно выяснить IP-адрес прокси сервера (например, заданный в конфигурации).
Фаза вызова (звонка) показана на рис. 17.

Рис. 17.

Сначала вызывающий абонент (UA) обращается к Proxy с вызовом на постоянный адрес требуемого абонента - INVITE. Далее Proxy выясняет у REGISTRAR сервера текущий адрес вызываемого и от своего имени посылает к нему запрос на установление связи (INVITE). Ответы (RINGING, OK) и подтверждение (ACK) так же проходят через Proxy.
Фаза разговора показана на рис. 18.

Рис. 18.

Разговорная фаза (RTP, RTCP) проходит только между клиентскими приложениями (UA) и не задействует прокси.
Фаза завершения связи (разрыва соединения) - на рис. 19.

Рис. 19.

Завершение связи, так же как и инициализация, проходит через Proxy-сервер, который практически ретранслирует SIP-сообщения.
Как видим, участники соединения не взаимодействуют между собой во время установления и разрыва соединений, то есть вся сигнализационная информация в рамках данной схемы проходит через прокси сервер. Данная конфигурация удобна тем, что клиентским приложениям достаточно знать (получить) информацию только о своем ближайшем SIP прокси-сервере, который будет принимать все звонки и заниматься дальнейшим поиском и маршрутизацией.
Обычно сервер регистрации и прокси-сервер объединяют в одно приложение и в результате получают комбинированный SIP-сервер доступа к VoIP сети.
UA-Redirect-UA.Взаимодействие с участием Redirect-сервера.
В данном случае UA в итоге самостоятельно установит соединение, а сервер переадресации только преобразует постоянный адрес в текущий. Текущий адрес знать не обязательно, это задача сервера переадресации.
Фаза вызова (звонка) показана на рис. 20.

Рис. 20.

Сначала вызывающий абонент (UA) обращается к Redirect с вызовом на постоянный адрес требуемого абонента - INVITE. Далее Redirect выясняет у Registrar-сервера текущий адрес вызываемого и возвращает его вызывающему.
Далее вызывающий абонент взаимодействует с вызываемым непосредственно и без участия Redirect-сервера.
Фаза разговора - рис. 21.

Рис. 21.

Фаза завершения связи (разрыва соединения) - на рис. 22.

Рис. 22.

Практически участие Redirect сервера сводится к сообщению текущего адреса вызываемого абонента (UA), а все дальнейшее взаимодействие происходит по схеме UA-UA.

заключение

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

Эдуард Афонцев.