Принципы установления соединения по протоколу sip. Протокол SIP.

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

Протокол SIP разработан группой MMUSIC комитета IETF , а спецификации протокола представлены в документе RFC 2543. В основу протокола заложены следующие принципы:

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

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

   Для расширения возможностей протокола SIP могут быть также добавлены и новые типы сообщений .

4. Интеграция в стек существующих протоколов Интернета, разработанных IETF . Протокол SIP является частью глобальной архитектуры мультимедиа, разработанной IETF . Эта архитектура включает в себя также и другие протоколы: резервирования ресурсов (Resource Reservation Protocol - RSVP , RFC 2205), транспортный протокол реального времени ( Real-Time Transport Protocol - RTP , RFC 1889), протокол передачи потоковой информации в реальном времени ( Real-Time Streaming Protocol - RTSP, RFC 2326), протокол описания параметров связи ( SDP , RFC 2327). Однако функции самого протокола SIP не зависят ни от одного из этих протоколов.
5. Взаимодействие с другими протоколами сигнализации. Протокол SIP может быть использован совместно с протоколом Н.323.

5.2. Интеграция протокола SIP с IP-сетями

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

Сигнальные сообщения могут переноситься как протоколом транспортного уровня UDP , так и протоколом TCP . Протокол UDP позволяет быстрее, чем TCP , доставлять сигнальную информацию (даже с учетом повторной передачи неподтвержденных сообщений), а также вести параллельный поиск местоположения пользователей и передавать приглашения к участию в сеансе связи в режиме многоадресной рассылки. В свою очередь , протокол TCP упрощает работу с межсетевыми экранами ( firewall ), а также гарантирует надежную доставку данных. При использовании протокола TCP разные сообщения, относящиеся к одному вызову, могут либо передаваться по одному TCP -соединению, либо для каждого запроса и ответа на него может открываться отдельное TCP -соединение. На рисунке 5.1 показано место , занимаемое протоколом SIP в стеке протоколов TCP/IP .

Рис. 5.1.

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

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

Протокол SIP предусматривает организацию конференций трех видов:

• в режиме многоадресной рассылки ( multicasting ), когда информация передается на один multicast -адрес, откуда затем доставляется сетью конечным адресатам;
• при помощи контроллера управления конференции ( MCU ), к которому участники конференции передают информацию в режиме "точка-точка", а контроллер обрабатывает информацию (т. е. смешивает или коммутирует) и рассылает ее участникам конференции;
• путем соединения каждого пользователя с каждым в режиме "точка-точка".

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

5.3. Адресация

Для организации взаимодействия с существующими приложениями IP -сетей и для обеспечения мобильности пользователей протокол SIP использует адрес , подобный адресу электронной почты. В качестве адресов рабочих станций используются специальные универсальные указатели ресурсов - так называемые SIP URL (Universal Resource Locators).

SIP -адреса бывают четырех типов:

• имя@домен;
• имя@хост;
• имя@IР-адрес;
• №телефона@шлюз.

Представляет собой протокол для сигнализации и управления мультимедийными сеансами связи. Наиболее распространённые области применения в интернет-телефонии - для передачи голоса и осуществления видеозвонков, а также обмена мгновенными сообщениями по сетям IP (Internet Protocol).

Он определяет сообщения, которые посылаются между конечными точками и регулируют создание, прекращение и другие существенные элементы вызова. Протокол SIP, описание которого представлено выше, может быть использован для создания, модификации и завершения сеансов, состоящих из одного или нескольких потоков мультимедийных данных. Он представляет собой протокол прикладного уровня. Разработанный для того, чтобы быть независимым от основного транспортного слоя. Другими словами, на основе текста, включающий в себя множество элементов HTTP (Hypertext Transfer) и (SMTP).

SIP-протокол - что это такое?

SIP работает совместно с несколькими другими протоколами прикладного уровня, которые идентифицируют и передают мультимедийные сессии. Выявление и согласование медийных данных достигается совместно с Session Description Protocol (SDP). Для передачи мультимедийных потоков - голоса, видео - он обычно использует транспортный протокол реального времени (RTP) или режим Secure (SRTP). Для безопасной передачи сообщений SIP может быть зашифрован с помощью Transport Layer Security (TLS).

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

SIP-протокол был первоначально разработан группой специалистов в 1996 году. Он был стандартизован в RFC 2543 в 1999 году (SIP 1.0). В ноябре 2000 года он был принят в качестве сигнального протокола 3 GPP и постоянного элемента IP-архитектуры Multimedia Subsystem (IMS) для потоковых мультимедийных услуг на базе IP в системах сотовой связи. Последняя версия (SIP 2.0) в спецификации RFC 3261 была выпущена в июне 2002 года. С определёнными расширениями и уточнениями она используется и в наше время.

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

Протокол SIP - описание и операции

Session Initiation Protocol не зависит от основного транспортного протокола. Он работает на основе пользовательского Datagram Protocol (UDP) или протокола управления передачей потока (SCTP). Он может быть использован как для передачи данных между двумя сторонами (одноадресной рассылки), так и для многоадресной сессии.

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

Каждый ресурс сети Session Initiation Protocol - агент пользователя или ящик голосовой почты - распознаётся с помощью идентификатора распределения ресурса (URI), функционирующего на основе общего стандартного синтаксиса, который также используется в веб-сервисах и электронной почте. Схема URI, которая используется для SIP, имеет вид логической цепочки: имя пользователя: пароль @ хост: порт.

Политика безопасности

Если требуется безопасная схема предписывает, что каждый из элементов сети, по которому перенаправляется запрос до целевого домена, должен быть обеспечен Transport Layer Security (TLS). Последний шаг от прокси-сервера к целевому домену при этом обязан функционировать в соответствии с местными настройками по безопасности. TLS защищает от злоумышленников, которые пытаются перехватить данные в момент их отправки. Но она не обеспечивает реальную безопасность до конца и не может предотвратить слежение и кражу информации. Как же SIP-протокол, порты которого должны быть надёжно соединены, работает с другими службами сети?

Он работает совместно с несколькими другими протоколами и участвует только в части сигнализации сеанса связи. SIP-клиенты, как правило, используют TCP или UDP с номерами портов 5060 или 5061 для подключения к SIP-серверам и другим конечным точкам SIP. Порт 5060 обычно используется для незашифрованного сигнального трафика, тогда как порт 5061 тесно «дружит» с Transport Layer Security (TLS).

Для чего используется?

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

Набор из SIP-правил, связанных с Internet Engineering Task Force (IETF), определяет инструкцию для таких применений. Голосовые и видеопотоковые сообщения в приложениях переносятся на другой протокол прикладной программы в режиме реального времени Transport Protocol (RTP). Параметры - номера портов, протоколы, кодеки - для этих медиа потоков определены и согласованы с использованием протокола описания сеанса (SDP), которое перемещается в теле пакета Session Initiation Protocol (например, протокол SIP T).

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

Значение в телефонной связи

Телефонные сети с поддержкой SIP могут также осуществлять многие из более продвинутых функций обработки вызовов, присутствующих в Signaling System 7 (SS7). Хотя оба этих протокола весьма различны. SS7 представляет собой централизованный протокол. Он характеризуется сложной центральной и «тупыми» конечными точками (традиционные телефонные аппараты). SIP является протоколом типа «клиент-сервер». Однако большинство устройств с поддержкой Session Initiation Protocol могут выполнять как роль клиента, так и сервера. В общем, инициатором сеанса выступает клиент, а получатель вызова выполняет функцию сервера. Таким образом, функции SIP реализованы в сообщающихся конечных точках, вопреки традиционным возможностям SS7, которые реализуются в сети.

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

Сетевые элементы

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

Агент пользователя

Агент пользователя SIP (UA) представляет собой логическую сеть конечных точек. Они используются для создания или получения сообщений и тем самым управляют SIP-сеансом. SIP-UA может выполнять роль клиента агента пользователя (UAC), который посылает запросы SIP, а также его сервера (UAS), что принимает запросы и возвращает ответ SIP. Такой контроль учётных записей и UAS осуществляется только в течение транзакции SIP.

Телефония

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

SIP-телефоны могут быть реализованы в виде аппаратного устройства либо в качестве софтфона. Поскольку производители всё чаще используют этот протокол в качестве стандартной платформы телефонии (в последние годы - посредством 4G), различие между аппаратной и программной основах SIP-телефонов остаются размытыми. Кроме того, элементы Session Initiation Protocol сегодня реализованы в основных функциях встроенного программного обеспечения многих IP-совместимых устройств. Примерами могут служить многие устройства от Nokia и BlackBerry, а SIP-протокол на Android в настоящее время является незаменимым сервисом.

В SIP, как в HTTP, агент пользователя может идентифицировать себя с помощью сообщения поля заголовка User-Agent, содержащего текстовое описание программного обеспечения/аппаратных средств/наименований продукции. Поле агента пользователя передаётся в сообщениях запроса. Это означает, что принимающий сервер SIP может видеть эту информацию. Сетевые элементы Session Initiation Protocol иногда могут хранить эту информацию. И это может быть полезным при диагностике проблем совместимости.

Протокол Session Initiation Protocol (SIP), обычно применяемый в VoIP-телефонах (как аппаратных, так и программных), отвечает за установку и разъединение соединения, а также за любые изменения, происходящие во время соединения, такие как переадресации. Назначение SIP – помочь двум конечным точкам поговорить друг с другом (по возможности напрямую). Протокол SIP – это просто протокол обмена сигналами, то есть его задачей является лишь обеспечить возможность двум конечным точкам говорить друг с другом, но не работа с носителем вызова (голосом) . Передача голоса осуществляется с помощью другого протокола – Real-Time Transport Protocol (транспортный протокол реального времени – RTP ; RFC 3550) – для передачи медиа-данных непосредственно между двумя конечными точками.

RFC SIP

SIP- запросы

Запросы : В первоначальной версии протокола SIP (RFC 3261) было определено шесть типов запросов. С помощью запросов клиент сообщает о текущем местоположении, приглашает пользователей принять участие в сеансах связи, модифицирует уже установленные сеансы, завершает их и т. д. Тип запроса указывается в стартовой строке.

INVITE - Приглашает пользователя к сеансу связи. Обычно содержит SDP -описание сеанса. Запрос INVITE, который отправлен для уже установленного сеанса связи, называется методом re-INVITE. re-INVITE позволяет менять адреса или порты сеансов, может добавлять поток медиаданных, удалять поток медиаданных, и т.д.

АСК - Подтверждает приём ответа на запрос INVITE.

BYE - Завершает сеанс связи. Может быть передан любой из сторон, участвующих в сеансе.

CANCEL - Отменяет обработку ранее переданных запросов, но не влияет на запросы, которые уже закончили обрабатываться.

REGISTER - Переносит адресную информацию для регистрации пользователя на сервере определения местоположения.

OPTIONS - Запрашивает информацию о функциональных возможностях терминала. Передача информации о возможностях вызывающего и вызываемого SIP телефонов.

Но в процессе развития, в протокол было добавлено еще несколько типов запросов, которые дополнили его функциональность:

PRACK - временное подтверждение (RFC 3262)

SUBSCRIBE - подписка на получение уведомлений о событии (RFC 3265)

NOTIFY - уведомление подписчика о событии (RFC 3265)

PUBLISH - публикация события на сервере (RFC 3903)

INFO - передача информации, которая не изменяет состояние сессии (RFC 2976)

REFER - запрос получателя о передаче запроса SIP (RFC 3515)

MESSAGE - передача мгновенных сообщений средствами SIP (RFC 3428)

UPDATE - модификация состояния сессии без изменения состояния диалога (RFC 3311)

Адресация SIP

Адресация SIP логическая, того же типа, что URL в HTTP . Для организации взаимодействия с существующими приложениями IP-сетей и для обеспечения мобильности пользователей протокол SIP использует адрес, подобный адресу электронной почты. В качестве адресов рабочих станций используются специальные универсальные указатели ресурсов - так называемые SIP URL (Universal Resource Locators).

SIP- адреса бывают четырех типов:

имя@домен;

имя@хост;

имя@IР-адрес;

№телефона@шлюз

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

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

В начале SIP- адреса ставится слово "sip:", указывающее, что это именно SIP- адрес. Примеры SIP- адресов:

Sip: [email protected] sip: [email protected] sip: [email protected]

В SIP поддерживает функции messaging и presence. Первая обеспечивает обмен в реальном времени короткими сообщениями (как ICQ на ПК или SMS в сетях GSM), вторая позволяет определять состояние абонента, т. е. на месте ли он, не занят ли и т. д. (в ICQ тоже есть такая возможность). Благодаря этим двум функциям SIP позволяет реагировать на события, а также рассылать сообщения "по событию".

IP-интеграция

SIP поддерживает специальный довольно мощный язык CPL (Call Processing Language -язык обработки звонков) на основе XML , предназначенный для написания телефонных скриптов, позволяющий указать, кто кому когда и зачем звонит, что делать, если трубку не берут или берут не там, и т. д. В силу всего этого в рамках SIP легко строить самые разнообразные сервисы.

Подобные сервисы могут создавать три группы людей: производители SIP- оборудования, сервис-провайдеры и сами конечные пользователи. Язык CPL несложен, так что, видимо, многие будут способны реализовать вполне изощренную схему работы автоответчика: скажем, если позвонивший набирает цифру 1, он переключается на домашний телефон абонента, если 2 – на сотовый, если 3 – на телефон его родителей и т. д. А почему бы не написать скрипт, который, когда раздастся звонок, показывал бы вам лицо (фотографию) звонящего? Телефон ресторана мог бы, скажем, сразу выдавать на дисплей сегодняшнее меню, – короче говоря, возможности здесь ограничены только фантазией пользователя.

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

Сценарий установления соединения

между пользователями

Первый пользователь снимает трубку и набирает номер, SIP-клиент генерирует сигнал INVITE (приглашение), у второго пользователя звонит телефон, его SIP-клиент выдает сообщение 180 (Ringing, звонок), затем пользователь берет трубку, SIP-клиент выдает сообщение 200 (OK), первый SIP-клиент посылает второму сигнал ACK (подтверждение) – и далее начинается передача голосового потока по протоколу RTP (Real-time Transport Protocol). Когда разговор окончен и один из пользователей вешает трубку, SIP-клиент посылает сигнал BYE. Вот и все.

в сети предприятия

Но такая схема абсолютно неэффективна, когда клиентов в сети не два, а два миллиарда. SIP-сетям с большим числом пользователей необходима инфраструктура, и ее создают различные серверы SIP. Сервер регистрации (registrar) занимается учетом и авторизацией пользователей, сервер локализации (allocation) ищет их и определяет их местонахождение, сервер переадресации (redirect) переводит звонки абонентам туда, где они фактически находятся в данный момент, – если меня, например, нет в Москве, потому что я уехал в Америку, сервер переведет звонок на мой американский номер. Наиболее сложные функции ложатся на прокси-сервер (SIP Proxy), обеспечивающий взаимодействие внутренней (например, учрежденческой) IP-телефонной сети с внешним миром, – именно он определяет все политики, правила общения и т. д. Существуют и другие серверы SIP (например, сервер конференций), но они менее важны. На рисунке показано, как может работать SIP в сети предприятия.

Пользователь Алиса приходит на свое рабочее место в компании Example, включает в корпоративную сеть ноутбук и активизирует имеющийся на нем программный телефон, который автоматически регистрируется на сервере регистрации. Тот, в свою очередь, запрашивает информацию о пользователе в корпоративной базе данных и сообщает о том, как с ним контактировать, серверу локализации. (Оба сервера могут интегрироваться с различными базами данных, службами каталогов типа LDAP или MS Active Directory и т. д.) Теперь, когда кто-нибудь позвонит Алисе, прокси-сервер, запросив сервер локализации, установит связь с ее рабочим местом.

Аутентификация и авторизация SIP 2.0

Гольдштейн Б.С., Зарубин А.А., Саморезов В.В. Протокол SIP. Глава 2.6. Процедуры функционирования HTTP аутентификации

До выхода SIP 2.0, который поддерживается любым современным оборудованием и ПО, разрешалась передача паролей чуть ли не открытым текстом (HTTP Basic Authentication), что в настоящее время вообще немыслимо. Однако, применяемая в SIP 2.0 авторизация на основе дайджеста от случайной строки и пароля (HTTP Хеш-сумма Authentication), также относительно уязвима. Ведь если злоумышленник перехватывает случайную строку и полученный дайджест (MD5 или SHA -1), он имеет возможность автономно подобрать пароль (по словарю или перебором), и ему не понадобится даже подключаться к SIP-серверу. Это главная причина, по которой настоятельно рекомендуется использовать сложные пароли длиной не менее 10 символов.

Прохождение авторизации в SIP протоколе зависит от "Что такое "realm"? ", различного для каждого защищаемого домена.

md5 алгоритм на входе принимает любую длину символов и на выходе выдать 128-битный отпечаток (finger-print) или профиль сообщения (message digest), которое было подано на вход алгоритма. Гипотетически считается, что два сообщения, которые имеют один и тот же профиль сообщения или выработаны любым сообщением, имеют определенный профиль сообщения.

Message digest - коротка цифровая строка фиксированной длины, формируется из более длинного сообщения с использованием специального алгоритма. Алгоритм md5 назначен для цифровой подписи (digital signature) приложений, где большие файлы должны быть «сжаты» в безопасный способ, до того как они будут закриптованы с помощью публичного или скрытого ключа с помощью криптосистемы с открытым ключом, например RSA. Digital signature - цифровая подпись, которая является уникальным электронным идентификатором, обеспечивающим проверку сообщения с установлением подлинности отправителя и гарантии то, что документ не был изменен с момента подписания.

Последовательность действий для авторизации клиентского оборудования на сервере.

Вариант №1 . Абонент: высылает серверу сообщение с заголовком REGISTER. Если в настройках абонента не указан secret, то этого достаточно, сервер присылает ответ SIP/2.0 200 OK и процесс регистрации заканчивается.

Вариант №2 . Если secret указан. Сервер на запрос REGISTER присылает ответ SIP/2.0 401 Unauthorized (нормальный ответ сервера о том, что пользователь еще не авторизировался; обычно после этого абонентское оборудование отправляет на сервер новый запрос, содержащий логин и пароль).

Вариант №3 . Если используется внешний сервер для аутентификации (процедура проверки подлинности) по протоколу RADIUS . Сервер на запрос REGISTER присылает ответ SIP/2.0 407 Proxy Authentication Required - необходима аутентификация на прокси-сервере).

SIP URI

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

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

Всё, что вы хотели знать о протоколе 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:[email protected] SIP/2.0 Via: SIP/2.0/UDP pc33.example.com;branch=z9hG4bK776asdhds Max-Forwards: 70 To: Bob From: Alice ;tag=1928301774 CSeq: 101 INVITE Contact: sip:[email protected] 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

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

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

<Имя метода> <Номер версии 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 ;tag=a6c85cf From: Alice ;tag=1928301774 Call-ID: [email protected] CSeq: 102 INVITE Contact: 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) – [email protected];
• имя@хост – [email protected];
• имя@IP_адрес – [email protected];
• №_телефона@шлюз – sip:[email protected]; 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. Самый нижний уровень отвечает за синтаксис и кодирование сообщений. Вторым уровнем протокола является транспортный уровень – он определяет, как клиент передаёт запросы и получает ответы от сервера и как сервер получает запросы и передаёт ответы клиенту; эти функции свойственны всем элементам сети, следовательно, все они содержат транспортный уровень.

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

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

сервер руководствуется следующими правилами. Запрос принадлежит транзакции в том случае, если 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 со всеми текущими привязками.

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

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

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

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

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

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

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

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

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

Когда proxy-сервер пересылает SIP-запрос, он добавляет своё имя (имя сервера) в начало списка в поле Via в заголовке SIP-сообщения. Это поле позволяет возвращать ответы по тому же маршруту, по которому проходил запрос. На «обратном» пути каждый proxy-сервер удаляет своё имя из поля Via после обработки SIP-ответа (см. рис. 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:[email protected]!i" . IN NAPTR 101 10 "u" "E2U+h323" "!^.*$!h323:[email protected]!i" . IN NAPTR 102 10 "u" "E2U+msg" "!^.*$!mailto:[email protected]!i" .

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

Месяц назад я начал свое знакомство с IP-телефонией, а именно с Lync и Asterisk. И заметил следующую картину: в сети очень много интересных статей по практической стороне вопроса (как и что делать) и очень мало внимания уделено теории (в конце статьи приведены ссылки). Если Вы хотите разобраться с SIP, то извольте либо читать RFC 3261, либо одну из «этих толстых книг». Это, естественно, полезно, но многим хочется в начале изучить некую выжимку, а уж потом бросаться в омут с головой. Эта статья как раз для таких людей.

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

Простое взаимодействие клиентов

Взаимодействие клиентов в рамках SIP чаще всего осуществляется в виде диалога.

Диалог – это равноправное взаимодействие двух User Agent (UA) в виде последовательности SIP-сообщений между ними. При этом, существуют запросы, не образующие диалогов. Однако обо всем по-порядку.

Ниже приведен пример простого взаимодействия между двумя устройствами с поддержкой SIP:

Петр хочет начать обмен сообщениями с Иваном, для этого он посылает INVITE-сообщение с данными о типе сессии (простая, мультимедиа и т.д.). Сообщения имеют следующий формат: стартовая строка, одно или несколько полей заголовка, пустая строка, обозначающая конец полей заголовка и необязательное тело сообщения.

Стартовая строка содержит метод, Request-URI и версию SIP (актуальная – 2.0). Request-URI – это SIP-адрес ресурса, которому посылается запрос.

Поля заголовков имеют следующий формат: <Заголовок>: <Значение> <Перевод строки>

Первая строка начинается с заголовка Via. Каждое SIP-устройство, создающее или пересылающее сообщение, добавляет свой адрес в поле Via (как это происходит, я планирую показать в следующей части статьи). Обычно адрес представляет собой имя хоста, которое может быть разрешено с помощью DNS-запроса. Поле Via содержит версию SIP, знак “/”, пробел, транспортный протокол (UDP, TCP, TLS, SCTP), двоеточие, номер порта и branch – идентификатор транзакции. Ответы на этот запрос будут содержать такой же номер транзакции.

Чаще всего, значение branch начинается с “z9hG4bK”. Это значит, что запрос был сгенерирован клиентом, поддерживающим RFC 3261 и параметр уникален для каждой транзакции этого клиента.

Следующее поле, Max-Forwards, содержит относительно большое целое число. Каждый сервер SIP, который пересылает сообщение, уменьшает это число на единицу. Данное поле обеспечивает простой механизм обнаружение петель (loop).

Следом идут поля From и To, которые описывают отправителя и получателя запроса. Важно, что SIP-запросы маршрутизируются исходя из Request-URI, указанного в стартовой строке (см. выше). Это объясняется тем, что поля From и To могут быть изменены при пересылке. Если используется отображаемое имя (например, Ivan Ivanov), то SIP URI помещается внутрь пары угловых скобок. Параметр tag в поле From генерирует отправляющая сторона. В свою очередь принимающая сторона поместит свой tag в поле To.

Поле Call-ID – идентификатор вызова. Совокупность tag’ов из полей From и To и Call-ID однозначно идентифицируют данный диалог. Это необходимо, так как между клиентами может идти сразу несколько диалогов.

Следующее поле, Cseq, содержит порядковый номер запроса и название метода. В данном случае – INVTITE. Номер увеличивается с каждым новым запросом.

Поля Via, Max-Forwards, To, From, Call-ID и CSeq составляют минимальный необходимый набор полей заголовков SIP-сообщения.

Для сообщения INVITE также необходимо поле заголовка Contact, в котором содержится SIP URI, относящийся к коммуникационному устройству отправляющей стороны. Это поле используется, чтобы из всех устройств, которыми одновременно может пользоваться Петр, ответ был отправлен именно на данное устройство. Обратите внимание на значения полей From и Contact. Первый раз я не заметил разницу:

В сообщении присутствует опциональное поле Subject, то есть тема сообщения. Некоторые SIP-клиенты могут выводить значение этого поля на экран. Для маршрутизации и идентификации диалога поле не используется и может быть произвольным.

Поля Content-Type и Content-Length отвечают за описание тела сообщения. В данном случае будет использоваться Session Description Protocol (SDP). Размер сообщения вычисляется с учетом символов перевода строки:

Детальное описание работы протокола SDP заслуживает отдельной статьи, поэтому ниже приведена только краткая расшифровка:

В ответ на INVITE SIP-клиент Ивана отправляет два сообщения: 180 Ringing и 200 OK. Первое сообщает, что на стороне Ивана SIP-клиент подает звуковой сигнал звонка, второе – подтверждает установку диалога. Разберемся с каждым из них.

Так будет выглядеть сообщение 180 Ringing:

Бледным выделен текст, который не изменился по сравнению с сообщением INVITE.

Обратите внимание на поля заголовков To и From. Несмотря на то, что данное сообщение идет со стороны Ивана, значения полей остаются такими же, как были в первоначальном запросе (от Петра к Ивану). Это объясняется тем, что данные поля определяют направление запроса, а не сообщения.

Строка Via также перекочевала из исходного запроса, в конце строки добавлен параметр received этот параметр содержит IP-адрес, с которого пришел запрос. Обычно это адрес, который может быть получен путем разрешения URI, содержащегося в Via.

Наконец, в поле Contact содержится актуальный адрес Ивана.

Так выглядит сообщение 200 ОК, которое отправил SIP-клиент Ивана:

Думаю, смысл всех полей, относящихся к протоколу SIP теперь ясен.

В ответ на 200 ОК клиент Петра отправляет подтверждение:

Данное сообщение подтверждает, что клиента Петра успешно получил ответ от клиента Ивана. Оба клиента договорились о параметрах меди-сессии, которая будет осуществляться по протоколу RTP.

Обратите внимание, что номер последовательности CSeq все еще равен единице, но в качестве метода уже стоит ACK. Параметр Branch в поле Via содержит новый идентификатор транзакции, так как ACK, отправляемый в ответ на 200 OK считает новой транзакцией.

Теперь давайте рассмотрим, как происходит завершение медиа-сессии. Клиент Петра посылает BYE-запрос для завершение сессии:

Получив запрос на завершение сессии, клиент Ивана посылает подтверждение:

Сессия завершена.

Мы рассмотрели простой вариант работы протокола SIP. Обратите внимание, что в разные моменты времени клиенты Ивана и Петра выступали то в роли сервера, то в роли клиента, поэтому во всех SIP-клиентах должна функционировать как серверная (User Agent Server или UAS), так и клиентская часть (User Agent Client или UAC).

В следующей статье я планирую рассмотреть взаимодействие клиентов SIP с использованием Proxy-сервера и регистрацию клиентов на Proxy-сервере.