Всё, что вы хотели знать о протоколе SIP::Журнал СА 5.2007
www.samag.ru
     
Поиск   
              
 www.samag.ru    Web  0 товаров , сумма 0 руб.
E-mail
Пароль  
 Запомнить меня
Регистрация | Забыли пароль?
О журнале
Журнал «БИТ»
Информация для ВАК
Звезды «СА»
Подписка
Где купить
Авторам
Рекламодателям
Магазин
Архив номеров
Вакансии
Игры
Контакты
   


  Опросы

Какие курсы вы бы выбрали для себя?  

Очные
Онлайновые
Платные
Бесплатные
Я и так все знаю

 Читать далее...

1001 и 1 книга  
27.03.2019г.
Просмотров: 262
Комментарии: 0
Arduino Uno и Raspberry Pi 3: от схемотехники к интернету вещей

 Читать далее...

27.03.2019г.
Просмотров: 206
Комментарии: 0
Автоматизация программируемых сетей

 Читать далее...

27.03.2019г.
Просмотров: 237
Комментарии: 0
Изучаем pandas. Второе издание

 Читать далее...

27.03.2019г.
Просмотров: 185
Комментарии: 0
Компьютерное зрение. Теория и алгоритмы

 Читать далее...

13.03.2019г.
Просмотров: 396
Комментарии: 0
DevOps для ИТ-менеджеров

 Читать далее...

Друзья сайта  

Форум системных администраторов  

sysadmins.ru

 Всё, что вы хотели знать о протоколе SIP

Архив номеров / 2007 / Выпуск №5 (54) / Всё, что вы хотели знать о протоколе SIP

Рубрика: IP-телефония

Андрей Погребенник

Всё, что вы хотели знать о протоколе SIP

Что общего у Microsoft Exchange 2007, Asterisk и Google Talk? А общим здесь является использование протокола SIP, который обещает единое решение задач как реализации мультимедийных функций в веб-приложениях, так и переноса сигнального трафика в сетях операторов связи.

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

Путь будущего развития коммуникаций лежит через разделение логики работы сетей и предоставления услуг. Новые услуги будут предоставляться опорной сетью, т.е. независимо от сети доступа. Таким образом, в любом месте, при использовании любого метода доступа к сети и с любого оконечного устройства пользователь может обращаться к одним и тем же услугам. В опорных сетях уже сейчас происходит переход от сетей с коммутацией каналов и мультиплексированием с разделением по времени (Time-division Multiplexing, TDM), на которых реализована вся традиционная телефония, к пакетным сетям. Дополняет картину Fixed Mobile Convergence – идея интеграции функционала мобильных и фиксированных сетей.

Операторы готовят инфраструктуру к предоставлению услуг следующего поколения путем применения программных коммутаторов, отличающихся большой гибкостью. Программные коммутаторы реализуют функции сопряжения с телефонной сетью общего пользования (ТфОП), обеспечивают централизованный биллинг, управление и интеллектуальную динамическую маршрутизацию звонков. Их применение означает для операторов фиксированной и мобильной связи возможность предоставления услуг транзита голосового трафика через опорную сеть IP/MPLS (Internet Protocol/Multiprotocol Label Switching), подключения корпоративных клиентов, управления вызовами и обслуживания клиентских устройств – и всё это, как правило, с меньшими затратами в сравнении с сетями TDM.

Происходящие в последние годы изменения на мировом рынке услуг телефонной связи сравнимы по своей значимости с переходом телефонии на автоматическую коммутацию. Эти изменения не в последнюю очередь связаны с появлением так называемых услуг SIP-телефонии, активно обсуждаемых в телекоммуникационном сообществе. Протокол SIP был стандартизирован в апреле 1999 года, а актуальная спецификация (версия 2.0 протокола SIP) датирована 2002 годом.

Назначение SIP

Session Initiation Protocol (SIP) – это клиент-серверный протокол прикладного уровня, предназначенный для установления, изменения и окончания сеансов связи с одним или несколькими участниками для обмена интерактивным трафиком: голосом, видео, мгновенными сообщениями. SIP относится к классу протоколов сигнализации; его задачи аналогичны тем, которые выполняет протокол общеканальной сигнализации №7 (ОКС7 или SS7) в обычной телефонии, а протоколы H.323 и MGCP (Media Gateway Control Protocol) – в IP-телефонии. Основными функциями SIP являются:

  • Определение местонахождения адресата.
  • Определение готовности адресата установить контакт.
  • Обмен данными о функциональных возможностях участников сеанса.
  • Изменение параметров медиапотока уже установленного сеанса.
  • Управление сеансом связи.

Непосредственным носителем голосовых или видеоданных является протокол RTP (Real-time Transport Protocol), SIP-сообщение же выполняет роль контейнера для сообщений протокола описания сеансов связи SDP (Session Description Protocol). Сообщение SDP описывает медиаданные в рамках сессии: тип медиаданных, транспортный протокол, формат данных и пр. RTP и SDP будут рассмотрены в следующей статье цикла, сейчас же сделаем акцент на том, что SIP был расширен для поддержки функций обмена мгновенными сообщениями и информацией о присутствии и статусе абонента. Последнее позволяет выполнять более совершенное управление голосовыми вывозами с переадресациями и продвинутой маршрутизацией. SIP поддерживает также приглашение участников к текущим сеансам наподобие многоточечных конференций, добавление к текущему сеансу или удаление из него мультимедийных данных, прозрачное распределение имён и перенаправление услуг, включая персональную мобильность пользователя.

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

Традиционно H.323 называли более зрелым протоколом, а SIP – более динамичным, расширяемым, масштабируемым и, главное, простым в сравнении с H.323. Впрочем, эти границы постепенно размываются: в своём сегодняшнем виде SIP так же сложен, как и H.323.

Так или иначе, кажется, что отрасль уже сделала свой выбор в пользу SIP (хотя позиции H.323 в операторской среде по-прежнему прочны). Выбор SIP консорциумом 3GPP (3G Partnership Project) в качестве фундамента для строительства сетей мобильной связи следующего поколения в ноябре 2000 года способствовал появлению сервисной архитектуры подсистемы IP-мультимедиа (IP Multimedia Subsystem, IMS). Протоколу SIP, который уже сегодня получил распространение в корпоративных и операторских сетях, уготовано центральное место в унифицированной модульной архитектуре сетей нового поколения (Next Generation Networks, NGN) – фактически то место, которое cистема сигнализации SS7 сегодня занимает в сетях TDM.

SIP предполагает простую (и, следовательно, хорошо масштабируемую) сеть с интеллектом, встроенным в конечные элементы (пользовательские агенты). Другими словами, функции SIP реализованы в конечных устройствах, в отличие от традиционных возможностей SS7, которые поддерживаются самой сетью. Протокол SIP по структуре напоминает протоколы HTTP и SMTP. Из HTTP он взял клиент-серверную архитектуру и использование URL и URI, а из SMTP – способ кодировки текста и стиль заголовков.

SIP ориентирован в первую очередь на взаимосвязи точка-точка, но поддерживает и режим многоадресной рассылки (multicast). Последний может использоваться для организации конференций, когда информация передается на один multicast-адрес, а затем доставляется сетью конечным адресатам. Другие два варианта организации конференций – соединение каждого пользователя с каждым в режиме точка-точка и соединение каждого пользователя с устройством управления конференцией.

Впрочем, «точка-точка» – это слегка идеализированный сценарий, возможный лишь в рамках одного домена. Типичная сеть SIP содержит и другие элементы: сервер регистрации, прокси-серверы, а иногда и сервер переадресации. SIP работает в среде IPv4 и IPv6 с использованием транспорта протоколов UDP, TCP, TLS или SCTP. Таблицы 1, 2 помогут читателю оценить различия архитектур SIP, H.323 и MGCP.

Таблица 1. Компоненты и сервисы протоколов сигнализации

Протокол

H.323

SIP

MGCP

Управляющие компоненты сети

Привратник

Прокси‑сервер, сервер перенаправления, сервер регистрации

Call Agent

Конечные точки

Шлюз, терминал

Пользовательский агент

Шлюз или медиашлюз

Управление звонками и функции учёта

Шлюз, привратник

Шлюз

Call Agent

Статус звонка

Шлюз, привратник

Шлюз

Call Agent

Обработка адресной информации

Привратник

Сервер регистрации

Call Agent

Контроль доступа (admission control)

Привратник

Не поддерживается

Call Agent

Таблица 2. Сравнительные характеристики протоколов сигнализации

Протокол

H.323

SIP

MGCP

Назначение

Для IP-телефонии

Для IP-коммуникаций

Для управления транспортными шлюзами

Комитет стандартов

ITU-T

IETF

IETF

Текущая версия

H.323v4

SIP 2.0 (RFC 3261)

MGCP 1.0 (RCF 3435)

Тип архитектуры

Распределённая

Распределённая

Централизованная

Интеллект

Рассредоточен по элементам сети

В ядре сети

В ядре сети

Используемый транспорт

TCP (H.225, H.245) и UDP (RAS)

UDP, TCP, TLS или SCTP

UDP

Поддержка мультимедиа

Да

Да

Да

Тип кодирования сообщений

ASN.1 BER

Текстовый

Текстовый

Описание сеанса

Протокол SDP

Протокол H.245

Протокол SDP

Дополнительные услуги

Предоставляются конечными или управляющими устройствами

Предоставляются конечными или управляющими устройствами

Предоставляются конечными устройствами

Структура сообщений

Теперь пора перейти к рассмотрению «строительных блоков» протокола SIP: методов, запросов и ответов, заголовков и т. д.

SIP использует набор символов ISO 10646 в кодировке UTF-8. Запросы и ответы SIP имеют одинаковый базовый формат сообщения и различаются наборами символов и синтаксисом. Сообщение состоит из:

  • стартовой строки;
  • одного или нескольких полей заголовков;
  • пустой строки, обозначающей конец полей заголовков;
  • тела сообщения (необязательно).

Возьмём небольшой пример в виде запроса INVITE:

INVITE sip:bob@bigisp.com SIP/2.0

Via: SIP/2.0/UDP pc33.example.com;branch=z9hG4bK776asdhds

Max-Forwards: 70

To: Bob <sip:bob@bigisp.com>

From: Alice <sip:alice@example.com>;tag=1928301774

Call-ID: a84b4c76e66710@pc33.example.com

CSeq: 101 INVITE

Contact: sip:alice@pc33.example.com

Content-Type: application/sdp

Content-Length: 142

 

v=0

o=alice 2890844526 2890844526 IN IP4 example.com

c=IN IP4 10.1.3.33

t=0 0

m=audio 49172 RTP/AVP 0

a=rtpmap:0 PCMU/8000

Теперь детально рассмотрим каждую строку запроса.

Первая, или стартовая, строка запроса имеет следующий формат:

<Имя метода> <Request-URI (адресат)> <Номер версии SIP>

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

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

Заголовок Max-Forwards указывает максимальное количество серверов SIP, разрешённое на сигнальном пути. Он обязателен во всех запросах SIP, кроме INFO.

Поля заголовков From и To идентифицируют отправителя и получателя сообщения; они обязательны во всех без исключения запросах. Параметр tag заголовков From и To содержит псевдослучайное значение, применяемое (наряду с заголовком Call-ID) для идентификации диалога на уровне сгенерировавшего сообщение пользовательского агента.

Call-ID – это идентификатор вызова, глобально уникальный в рамках домена.

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

Contact содержит прямой путь к отправителю сообщения – FQDN или IP-адрес. Заголовков Contact может быть несколько.

Наконец, поле заголовка Content-Type содержит описание тела сообщения, а Content-Length – длину содержимого тела сообщения в октетах.

После пробела следует тело сообщения. Тело сообщения несёт описание сеанса либо текстовые или двоичные данные, относящиеся определённым образом к нему. Тело сообщения может присутствовать как в запросе, так и в отклике. Обычно телом сообщения выступает SDP- или MIME-часть. Выше показано тело сообщения SDP. Пока мы пропустим его разбор; SDP будет рассмотрен в следующей части статьи.

В таблице 3 сведены основные методы SIP вместе с их описаниями. По своему типу заголовки SIP можно разделить на несколько категорий, см. таблицу 4.

Таблица 3. Методы SIP

Метод

Описание

Спецификация

INVITE

Абонент или услуга приглашаются для установления связи

RFC 3261

ACK

Подтверждение получения финального ответа на INVITE

RFC 3261

OPTIONS

Запрос информации о функциональных возможностях терминала адресата

RFC 3261

BYE

Запрос завершения сеанса

RFC 3261

CANCEL

Отмена вызова в стадии установления

RFC 3261

REGISTER

Запрос регистрации пользовательского агента на сервере регистрации

RFC 3261

INFO

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

RFC 2976

MESSAGE

Переносит мгновенное сообщение в теле запроса

RFC 3428

NOTIFY

Передаёт информацию о изменении состоянии ресурса, на уведомления о котором была открыта подписка

RFC 3428

PRACK

Промежуточный ответ, сообщающий о статусе обработки запроса

RFC 3262

REFER

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

RFC 3515

SUBSCRIBE

Запрашивает текущее состояние и информацию об обновлениях состояния удалённого ресурса

RFC 3265

UPDATE

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

RFC 3311

Таблица 4. Заголовки SIP

Тип заголовка SIP

Примеры

Общие заголовки

Accept

Accept-Encoding

Accept-Language

Alert-Info

Call-ID

Call-Info

CSeq

Contact

Date

Expires

From

To

Record-Route

Route

Timestamp

Via

Заголовки с информацией отеле сообщения

Content-Disposition

Content-Encoding

Content-Language

Content-Length

Content-Type

Заголовки запросов

Authorization

Max-Forwards

Organization  Priority

Proxy-Authorization

Proxy-Require

Route  Require

Subject

User-Agent

Заголовки ответов

Allow

Error-Info

Proxy-Authenticate

Retry-After

Unsupported

Server

Warning

WWW-Authenticate

На каждый запрос отправителю направляется ответ, содержащий код результата выполнения запроса. Например, положительный ответ на приведённый выше INVITE может быть таким:

SIP/2.0 200 OK

Via: SIP/2.0/TCP pc33.example.com;branch=z9hG4bKnashds8;

received=10.1.3.33

To: Bob <sip:bob@bigisp.com>;tag=a6c85cf

From: Alice <sip:alice@example.com>;tag=1928301774

Call-ID: a84b4c76e66710@pc33.example.com

CSeq: 102 INVITE

Contact: <sip:bob@192.168.10.20>

Content-Length: 255

Content-Type: application/sdp

SDP-часть не показана для экономии пространства. Все заголовки кроме стартовой строки вам уже знакомы, а стартовая строка ответа имеет следующий формат:

<Номер версии SIP> <Код статуса> <Текст причины>

Код статуса – это 3-значное число, первая цифра которого указывает на класс ответа, а остальные две – идентифицируют конкретный ответ в каждом классе. Устройство может не знать, что означает код ответа, но должно обязательно знать класс ответа. Всего существует 6 классов ответов (таблица 5). Информационные ответы сообщают о стадии выполнения запроса, они не являются завершением транзакции. Остальные же классы ответов завершают транзакцию.

Таблица 5. Ответы SIP

 

Описание

Примеры

1xx

Информационные – запрос получен, продолжаю его обрабатывать

100 Trying

180 Ringing

183 Session Progressing

2xx

Успех – действие было успешно получено, понято и выполнено

200 OK

202 Accepted

3xx

Перевод вызова – для завершения выполнения запроса необходимо обратиться к другому элементу SIP

300 Multiple Choices

301 Moved Permanently

302 Moved Temporarily

4xx

Ошибка клиента – запрос содержит ошибки или не может быть обслужен на этом сервере

400 Bad Request

401 Unauthorized

403 Forbidden

404 Not Found

407 Proxy Authentication Required

408 Request Timeout

480 Temporary Unavailable

481 Call or Transaction Does Not Exist

486 Busy Here

487 Request Terminated

5xx

Ошибка сервера – сервер не смог обслужить правильно построенный запрос

502 Bad Gateway

503 Service Unavailable

6xx

Глобальная ошибка – запрос не может быть обслужен ни на одном сервере

600 Busy Everywhere

603 Decline

Адресация в SIP

Для идентификации абонентов и ресурсов в протоколе SIP используются SIP URI-идентификаторы, описанные в RCF 2396. SIP URI состоит из двух частей: первая часть – это имя пользователя, зарегистрировавшегося в домене или на рабочей станции. Во второй части указывается имя домена, рабочей станции или шлюза. Если вторая часть адреса идентифицирует какой-либо шлюз, то в первой указывается телефонный номер абонента. В начале адреса ставится слово «sip:», указывающее, что это именно SIP URI (бывают и другие, например «sips:» для SIPS URI или «tel:» для номеров в формате E.164).

Таким образом, возможны SIP URI следующего вида:

  • имя@домен (где домен – полностью квалифицированное доменное имя, FQDN) – bob@example.com;
  • имя@хост – bob@proxy10.bigisp.com;
  • имя@IP_адрес – bob@10.1.1.1;
  • №_телефона@шлюз – sip:18665551234@gateway.com; user=phone (user=phone означает, что это шлюз; gateway.com – FQDN терминирующего шлюза).

Если во второй части указывается доменное имя, для определения IP-адреса устройства необходимо обратиться к службе DNS. RFC 3263 описывает процедуры DNS, с помощью которых можно транслировать SIP URI в IP-адрес, порт и транспортный протокол, необходимые для связи с абонентом. RFC также специфицирует использование для этой цели ресурсных записей DNS SRV и NAPTR.

Уровни протокола SIP. Понятия транзакции и диалога

SIP представляет собой многоуровневый протокол, но не каждый элемент, работающий по протоколу SIP, содержит все уровни, а сами элементы, работающие в сети SIP, являются скорее логическими, нежели физическими. На рис. 1 показаны уровни протокола SIP; он также послужит нам иллюстрацией того, из каких логических компонентов состоит каждый элемент сети SIP. Самый нижний уровень отвечает за синтаксис и кодирование сообщений. Вторым уровнем протокола является транспортный уровень – он определяет, как клиент передаёт запросы и получает ответы от сервера и как сервер получает запросы и передаёт ответы клиенту; эти функции свойственны всем элементам сети, следовательно, все они содержат транспортный уровень.

Рисунок 1. Многоуровневая структура протокола SIP

Рисунок 1. Многоуровневая структура протокола SIP

Следующий уровень – это уровень транзакций. О SIP говорят как о транзакционном протоколе. Транзакцией называют совокупность соообщений, состоящую из запроса, отправленного клиентом серверу, и всех ответов сервера на этот запрос (см. рис. 2). Уровень транзакций содержит клиентскую часть, называемую клиентской транзакцией, и серверную часть, называемую серверной транзакцией. Уровень транзакций предпринимает повторную передачу сообщений, определяет соответствие ответов запросу и уведомляет верхний уровень протокола о срабатывании таймеров. И на самом верху находится уровень пользователя транзакций (Transaction User, TU), который управляет созданием транзакций. Все элементы сети SIP, за исключением прокси-сервера без хранения состояния, обязательно содержат уровни транзакций и пользователя транзакций.

Рисунок 2. Понятия транзакции и диалога

Рисунок 2. Понятия транзакции и диалога

Правила проверки соответствия запроса серверной транзакции таковы: сервер анализирует верхний заголовок Via на предмет наличия параметра branch. Если он присутствует и в начале его значения стоит набор символов «z9hG4bK», как в рассмотренном выше примере:

Via: SIP/2.0/UDP pc33.example.com;

branch=z9hG4bK776asdhds,

следовательно запрос был сгенерирован клиентом, поддерживающим RFC 3261 в полной мере, и параметр branch уникален в каждой транзакции данного клиента. Запрос принадлежит транзакции в том случае, если значение параметра branch запроса совпадает с таковым из запроса, образовавшего транзакцию, а имя метода из поля заголовка CSeq совпадает с таковым из запроса, образовавшего транзакцию.

Если же параметр branch отсутствует, как показано ниже:

Via: SIP/2.0/UDP pc33.example.com,

сервер руководствуется следующими правилами. Запрос принадлежит транзакции в том случае, если Request-URI (часть стартовой строки, указывающая на адресата данного запроса), теги заголовков From и To, заголовки Call-ID и Cseq (включая название метода) и верхний заголовок Via совпадают с соответствующими полями запроса, образовавшего транзакцию. В случае проверки соответствия запроса ACK серверной транзакции, Request-URI, теги заголовков From и To, заголовки Call-ID, Cseq и Via запроса ACK сравниваются с таковыми в изначальном INVITE, а To-тег – с тегом первого ответа серверной транзакции на INVITE. Аналогично выполняется проверка соответствия ответа клиентской транзакции.

Наконец, диалог – это равноправное взаимодействие двух элементов сети SIP в виде последовательности SIP-сообщений между ними. Диалог всегда инициируется пользовательским агентом, но другие элементы сети также в нём участвуют. Сообщения в рамках одного диалога отличаются одинаковыми Call-ID и тегами заголовков From и To, а порядковый номер в поле CSeq монотонно возрастает. Фактически CSeq идентифицирует транзакцию в рамках диалога, а диалог является последовательностью транзакций, из которых только одна может быть активна в каждый момент времени. Однако, кроме диалогообразующих запросов, существуют и запросы, не образующие диалогов.

Здесь также уместно разъяснить значение заголовка Call-ID и From- и To-тегов:

  • Call-ID – это некая уникальная строка, идентифицирующая вызов. Call-ID, как правило, не меняется на протяжении всех диалогов, составляющих один вызов.
  • Тег заголовка From генерируется пользовательским агентом вызывающего абонента и недвусмысленно идентифицирует диалог на уровне данного пользовательского агента.
  • Тег заголовка From генерируется пользовательским агентом вызываемого абонента и также идентифицирует диалог на уровне данного пользовательского агента.

Компоненты SIP. Пользовательские агенты (User Agent – UA)

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

Поскольку SIP – это одновременно и протокол типа «точка-точка», и клиент-серверный протокол, конечная точка SIP должна быть способна отвечать на запросы сессии SIP и инициировать их. Следовательно, конечная точка должна содержать два SIP-стека одновременно:

  • User Agent Client (UAC) – инициатор запросов.
  • User Agent Server (UAS) – инициатор ответов на запросы. UAS может взаимодействовать с пользователем, поэтому вместе с запросом SIP пользователь иногда в той или иной форме получает уведомление от UAS.

Для UA существует также другое название – SIP-клиент.

Сообщение SIP – это или запрос от UAC к UAS, или ответ UAS компоненту UAC. В оригинальной спецификации SIP описано шесть возможных типов запросов (или методов), которые может выдать UAC: INVITE, ACK, OPTIONS, BYE, CANCEL и REGISTER. Расширения SIP, описанные в RFC, определяют дополнительные методы – такие, как MESSAGE, INFO и NOTIFY.

Когда UAC инициирует SIP-сессию, он определяет протокол, порт и IP-адрес UAS, которому посылается запрос. При отсутствии любой информации о локально настроенном прокси-сервере, UAC использует данные в URI запроса для определения маршрута SIP-запроса. Данный URI запроса всегда определяет хост, но не всегда – порт и протокол. Если хост через адрес IP указан явным образом, UAC пытается связаться с UAS по этому адресу. Если URI запроса специфицирует полностью определенное доменное имя Fully Qualified Domain Name (FQDN), UAC опрашивает службы DNS для разрешения имен, используя для этого ADDRESS, CNAME или другие данные в ресурсной записи. Если URI запроса содержит номер порта, UAC пытается установить соединение с UAS, используя данный номер; если же URI запроса не указывает номер порта, UAC по умолчанию использует в качестве порта назначения 5060. Если URI запроса указывает транспортный протокол (TCP или UDP), UAC использует его. В противном случае UAC предпринимает попытку связи по UDP, а в случае ошибки UAC пытается задействовать TCP.

Каждый UA должен хранить состояние диалога, а именно: помнить теги From и To, локальный и удалённый номера CSeq, Call-ID, маршрутные заголовки и характеристики медиапотоков.

Шлюзы, выполняющие преобразование H.323 в SIP, ISDN в SIP или SS7 в SIP, с точки зрения SIP функционально ничем не отличаются от пользовательских агентов (ведь другие элементы сети SIP не «знают», действует ли UA, руководствуясь командами пользователя или сообщениями/событиями других протоколов).

Серверы регистрации

Архитектура SIP поддерживает персональную мобильность пользователей. Пользователи могут перемещаться без ограничений в пределах сети, поэтому услуги связи должны предоставляться им в любом месте этой сети. Пользователю присваивается уникальный идентификатор, а сеть предоставляет ему услуги связи вне зависимости от того, где он находится. Пользователь косвенно информирует прокси-сервер или сервер переадресации, по какому адресу следует обращаться для установления сеанса связи. Обработкой этой информации и занимается сервер регистрации: получая от пользовательского агента запрос REGISTER, он создаёт временную связку из присвоенного пользователю SIP URI (называемого также Address of Record – AOR) и URI заголовка Contact, который указывает на адрес, куда следует направлять запросы (см. рис. 3). База данных с информацией о местоположении пользователей доступна для всех серверов в рамках данного административного домена (для прокси-серверов и серверов перенаправления), что делает возможной маршрутизацию входящих вызовов. Сам запрос REGISTER может использоваться для получения списка текущих привязок, удаления всех привязок или добавления новой. Отклик 200 OK на запрос REGISTER содержит заголовок Expires, указывающий, через сколько секунд нужно обновлять регистрацию, а также один или несколько заголовков Contact со всеми текущими привязками.

Рисунок 3. Работа сервера регистрации

Рисунок 3. Работа сервера регистрации

Сервер переадресации

Сервер переадресации возвращает пользовательскому агенту новый адрес для прямой маршрутизации вызова по этому адресу, иными словами – производит перенаправление вызывающей стороны к другому серверу (см. рис. 4). Сервер переадресации отвечает на запрос, но никогда не пересылает запрос дальше и не хранит состояние. Впрочем, нельзя сказать, что он применяется часто: каждый оператор предпочитает полностью контролировать сеанс связи.

Рисунок 4. Переадресация вызова

Рисунок 4. Переадресация вызова

Прокси-серверы

Наличие прокси-сервера является обязательным атрибутом каждой корпоративной или операторской сети. Прокси-сервер действует как посредник, который обслуживает запросы пользовательских агентов и пересылает их дальше, выполняя маршрутизацию сообщений. Прокси-серверы играют ключевую роль в сетях SIP, поскольку связывают вместе пользовательские агенты и другие элементы SIP-сети в одном или множественных доменах, реализуя логику маршрутизации. Прокси-сервер не генерирует запросы самостоятельно (за исключением CANCEL), а лишь отвечает или пересылает запросы, полученные от UAC. Также он выполняет интерпретацию, удаление, добавление или модификацию заголовков, касающихся прямых функций прокси-сервера (таких, как Record-Route или Via), но ничего не «знает» о SDP-части. А основные функции прокси-сервера следующие:

  • Маршрутизация – определение получателя вызова, поиск маршрута для отправки сообщения и собственно отправка.
  • Безопасность – с помощью функций контроля доступа прокси-сервер авторизирует доступ к той или иной услуге или ресурсу со стороны конечных абонентов или других прокси-серверов.
  • Дополнительные услуги – прокси-серверы могут предоставлять набор дополнительных услуг, такик как: перенаправление вызова, уведомление о пропущенных вызовах, обеспечение приватности и т. д.

Алгоритм маршрутизации не поддаётся формализации, поскольку определяется архитектурой и политикой конкретной сети, но мы рассмотрим некий усреднённый пример. Итак,

  • Запросы к абонентам, принадлежащим к тому же административному домену, что и прокси-сервер, маршрутизируются на основе:
    • базы данных сервера регистрации;
    • статистически заданных маршрутов (например, для вызовов по номеру 911).
  • Запросы к абонентам, принадлежащим к другому домену, маршрутизируются исходя из результатов DNS-запроса ресурсной записи SRV (указывающей на расположение службы).
  • Запросы, адресованные по некоторым предопределённым номерам, маршрутизируются к специализированным серверам приложений (например, *98 для доступа к серверу голосовой почты).
  • Запросы, адресованные на номер в формате E.164, маршрутизируются, основываясь на:
    • Заранее заданных таблицах маршрутизации;
    • Динамически получаемых (например, от биллинговой системы) маршрутов;
    • ENUM (см. врезку «ENUM» на стр. 84).

Запись типа SRV предоставляет механизм для получения списка хостов, предоставляющих некоторую службу посредством разных транспортных протоколов, с упорядочиванием по предпочтению. Для примера, пусть клиент пытается разрешить URI sip:user@example.com. Клиент производит DNS-запрос и выбирает ресурсные записи типа NAPTR для данного домена:

;;;; Записи NAPTR для различных услуг SIP сети

   ;          order pref flags service      regexp  replacement

      IN NAPTR 50   50   "s"   "SIPS+D2T"     ""   _sips._tcp.example.com.

      IN NAPTR 90   50   "s"   "SIP+D2T"      ""   _sip._tcp.example.com.

      IN NAPTR 100  50   "s"   "SIP+D2U"      ""   _sip._udp.example.com.

В примере видно, что сервер поддерживает TCP, UDP и TCP через ТLS. Затем, обрабатывая записи SRV, клиент определяет сервер назначения (или список серверов) для предпочитаемого им типа транспортного протокола:

;;;; Записи SRV для каждой SIP услуги

  ;; Служба.протокол.имя         Приоритет Вес    Порт Цель

  _sips._tcp.example.com SRV    10        1      5061 proxy1.example.com.

                         SRV    20        1      5061 proxy2.example.com.

  _sip._tcp. example.com SRV    10        1      5060 proxy1.example.com.

                         SRV    20        1      5060 proxy2.example.com.

  _sip._udp.example.com  SRV    10        1      5060 proxy1.example.com.

                         SRV    20        1      5060 proxy2.example.com.

Дальнейшее разрешение имён производится с помощью привычных ресурсных записей адреса узла (A).

Когда proxy-сервер пересылает SIP-запрос, он добавляет своё имя (имя сервера) в начало списка в поле Via в заголовке SIP-сообщения. Это поле позволяет возвращать ответы по тому же маршруту, по которому проходил запрос. На «обратном» пути каждый proxy-сервер удаляет своё имя из поля Via после обработки SIP-ответа (см. рис. 5).

Рисунок 5. Маршрутизация вызова между доменами при посредничестве прокси-серверов

Рисунок 5. Маршрутизация вызова между доменами при посредничестве прокси-серверов

Обобщённый же алгоритм работы прокси-сервера можно представить следующим образом:

1) Проверка корректности составления входящего запроса.

2) Приведение номера вызываемой стороны к формату E.164.

3) Аутентификация отправителя запроса.

4) Выполнение запрошенных вызывающей стороной процедур, таких как удаление из запроса или изменение идентифицирующих вызывающую сторону заголовков.

5) Авторизация вызова.

6) Обращение к серверу регистрации для поиска подходящего получателя запроса.

7) Если получатель найден – направить запрос ему (и при необходимости – выполнить такие действия, как перенаправление вызова).

8) Если получатель не найден – отправить звонок в ТфОП.

Различные типы прокси-серверов

Прокси-сервер без хранения состояния (Transaction Stateless) – прокси-сервер, который не хранит состояние сеанса и руководствуется лишь внутренней логикой маршрутизации сообщения, применяя её к каждому отдельно взятому запросу. Такой прокси-сервер не выполняет повторную передачу сообщений (а следовательно, неприменим в рамках модели SIP/TCP). Целесообразным применение такого прокси-сервера является при очень высокой нагрузке или в балансировщиках нагрузки прикладного уровня.

Прокси-сервер с хранением состояния транзакции (Transaction Stateful) – прокси-сервер, который запоминает входящие и исходящие сообщения в рамках данной транзакции до получения (или отправки) финального ответа. Прокси-сервер с хранением состояния транзакции ничего не «знает» о запросах UPDATE, REFER и BYE, но уже способен эффективно выполнять отправку учётной информации, разветвление, перенаправление вызова и некоторые другие расширенные функции.

Прокси-сервер с хранением состояния диалога (Dialog Stateful) – прокси-сервер, который вставляет заголовок Record-Route в самый первый запрос SIP для того, чтобы все последующие сообщения в рамках данного диалога проходили через этот же сервер; это относится к каждому прокси-серверу на пути между пользовательскими агентами. Такой прокси-сервер способен предоставить полный набор функций программного коммутатора классов 4 и 5.

Back-to-Back UA (B2BUA)

«Back-to-back user agent» – это компонент, состоящий из двух SIP UA, которые общаются между собой строго на прикладном уровне (с помощью SIP-сообщений). B2BUA образует своего рода периметр безопасности между SIP UA, находящимися по обе стороны от B2BUA: он скрывает детали реализации SIP на каждом из конечных устройств. В типичном случае B2BUA используется для форсирования обрыва звонков в сетях операторов связи по истечении предоплаченного объема услуг и вообще какого-либа контроля диалога третьей стороной, а также скрытия топологии сети и обеспечения определённых функций безопасности (кстати говоря, шлюз уровня приложений, ALG, с поддержкой SIP, архитектурно представляет собой не что иное, как B2BUA). Также B2BUA делает возможным реализацию перекодирования медиапотока, его перехвата и т. д.

Пользуясь лишь критерием хранения состояния, B2BUA можно было бы отнести к классу прокси-серверов с хранением состояния диалога. На самом деле это не прокси-сервер в привычном смысле этого слова: он выполняет несвойственные для прокси-сервера операции по удалению и модификации заголовков (а иногда и модификацию SDP-части). Есть и другая характерная черта: B2BUA фактически никогда не бывает реальным адресатом запроса, а лишь пересылает его другой стороне. Такая функциональность выходит за рамки RFC 3261: RFC специфицирует лишь то, что SIP-прокси маршрутизирует один диалог, т.е. сообщения с одинаковыми Call-ID и тегами заголовков From и To, между конечными устройствами, не изменяя их (кроме заголовков, используемых для маршрутизации, включая неизвестные заголовки), а B2BUA же создаёт новый диалог и может модифицировать любую содержающуюся в запросе информацию перед отправкой сообщения адресату. Разработчики могли бы для реализации каждого подмножества набора расширенных услуг предлагать некий «расширенный» прокси-сервер, нарушающий отдельные аспекты RFC 3261, но такой подход вряд ли можно счесть практичным и расширяемым. Объединение же стеков UAC и UAS в одном устройстве позволяет в точности придерживаться требований спецификаций, а тщательный подход к реализации самих стеков – сделать B2BUA максимально прозрачным для конечных абонентов.

В следующий раз мы  рассмотрим реальный пример вызовов в сети SIP, поговорим о предоставлении спектра расширенных услуг на базе протокола, протокол описания сеанса SDP и транспортный протокол реального времени RTP.

Приложение

История разработки SIP

Проект, который со временем стал стандартом SIP, был начат в 1996 году Хенингом Шулзри (Колумбийский университет) и Марком Хэндли (UCL), участниками рабочей группы MMUSIC (Multi-Party Multimedia Session Control) ассоциации IETF. Черновик IETF, описывающий SIP версии 1.0, увидел свет в 1997 году. В следующем году был издан уже черновик версии 2.0. Статус предложенного стандарта SIP получил в марте 1999 года, а в апреле того же года был опубликован RFC первой предложенной версии стандарта – RFC 2543. В сентябре 1999 года была образована SIP Working Group, работающая с тех пор над самим протоколом и его расширениями. В июле 2000 года был опубликован RFC 2543 «bis», содержащий множественные поправки и улучшения к оригинальной спецификации. Этот документ лёг в основу RFC 3261 (2002 года), являющегося и на сегодняшний день основным SIP RFC. Заметьте, что номер версии всё ещё равен 2.0.

Постепенно были образованы и другие рабочие группы IETF, работа которых так или иначе касается SIP. Так, рабочая группа SIPPING (SIP Investigation) была сформирована для исследования новых областей применения SIP, выработки требований к расширениям SIP и документов рекомендательного характера касательно применения SIP в приложениях. Рабочая группа SIMPLE (SIP for Instant Messaging and Presence Leveraging Extensions) была сформирована для стандартизации расширений SIP для обмена мгновенными сообщениями и информацией о статусе состояния абонента.

Другие рабочие группы по SIP – ENUM (работающая над интеграцией SIP-адресации и принятых в ТфОП номерных планов), SIGTRAN (Signaling Transport, перенос сигнализации SS7 поверх IP) и AVT (Audio/Video Transport (RTP), отвечающая за поддержку и расширение протокола RTP). MMUSIC же ответственна за SDP (Session Description Protocol), SAP (Session Announcement Protocol), RTSP (Real Time Streaming Protocol) и исследование возможностей применения SIP для мультимедиа-конференций.

ENUM

Как быть, когда при развёртывании SIP-сети необходимо предусмотреть возможность приёма входящих вызовов от абонентов ТфОП, но использование DID-номеров (Direct Inward Dial) по тем или иным причинам невозможно? Адреса E.164 могут храниться в особой зоне, e164.arpa, службы DNS с помощью протокола ENUM (TElephone NUmber Mapping). Любой телефонный номер, например +878102233350332, может быть преобразован в доменное имя записью цифр в обратном порядке, разделением их точками и добавлением суффикса e164.arpa, для нашего примера: +878102233350332 -> 2.3.3.0.5.3.3.3.2.2.0.1.8.7.8.e164.arpa.

Это преобразование выполняется на так называемом ENUM-шлюзе (физически им может являться шлюз, UA или даже веб-браузер). Полученное доменное имя можно использовать в запросе к DNS-серверу для получения ресурсной записи типа NAPTR (Naming Authority Pointer DNS Resource Records, RFC 3403), которая содержит предпочтения пользователя касательно того, как и куда следует терминировать вызов. Сама запись типа NAPTR поддерживает регулярные выражения, а алгоритм DDDS (Dynamic Delegation Discovery System, RFC 3401 – RFC 3405) используется для преобразования доменного имени в адрес того или иного сервиса с использованием данных регулярных выражений.

Например, возьмём NAPTR-запись такого вида:

$ORIGIN 2.3.3.0.5.3.3.3.2.2.0.1.8.7.8.e164.arpa.

 IN NAPTR 100 10 "u" "E2U+sip"  "!^.*$!sip:andrew.pogrebennyk@sip2sip.info!i" .  

 IN NAPTR 101 10 "u" "E2U+h323"  "!^.*$!h323:andrew.pogrebennyk@sip2sip.info!i" .

 IN NAPTR 102 10 "u" "E2U+msg"  "!^.*$!mailto:andrew.pogrebennyk@sip2sip.info!i" .

Числа 100, 101, 102 указывают порядок, в котором записи должны быть обработаны для образования упорядоченного списка правил, поэтому мы сначала выбираем первую запись. Число 10 (Preference) для нас не имеет значения, поскольку других записей с порядковым номером 100 нет. Если бы записей с порядковым номером 100 было несколько, более приоритетной стала бы запись с меньшим значением Preference. Затем «u» – это флаг, который контролирует интерпретацию последующих полей; «u» предписывает выполнить преобразование и не анализировать последующие правила записи. Соответственно, если мы поддерживаем сервис, на который указывает поле «E2U+sip», правила с более высокими порядковыми номерами анализироваться не будут. Если приложение не поддерживает SIP, протокол mailto: поддерживается наверняка (как видите, ENUM не является протоколом, специфичным исключительно для VoIP). Заметим, что набор сервисов не ограничен только этими тремя. Наконец, последнее поле задаёт регулярное выражение (синтаксиса регулярных выражений Perl, только вместо прямого слэша используется знак восклицания), которое нужно применить к указанному в запросе доменному имени, чтобы получить результат запроса. Как только результат получен, дальнейшая маршрутизация выполняется обычными для данного протокола методами, а всё, о чём мы говорили до сих пор, абсолютно прозрачно для конечного пользователя. К тому же подписчик ENUM имеет возможность задать под одним E.164-номером множество протоколов и адресов, запрограммировать перенаправление вызовов и т. д.

За работу зоны e164.arpa отвечает RIPE NCC: http://www.ripe.net/enum, но ответственность за отдельные страны поручена локальным NIC (nic.at, nic.cz, …) или компаниям, работающим с ENUM (Neustar, Verisign). Владелец ENUM-номера обычно имеет возможность изменять связанный с номером SIP URI через веб-интерфейс.

Кроме уже упомянутых RFC, данной теме посвящён RFC 3761.

  1. http://www.cs.columbia.edu/sip – сайт Хенинга Шулзри, Колумбийский университет.
  2. http://www.sipcenter.org – SIP Center, портал на тему SIP.
  3. http://www.tech-invite.com – Tech Invite – портал, посвящённый SIP и IMS.

Комментарии отсутствуют

Добавить комментарий

Комментарии могут оставлять только зарегистрированные пользователи

               Copyright © Системный администратор

Яндекс.Метрика
Tel.: (499) 277-12-41
Fax: (499) 277-12-45
E-mail: sa@samag.ru