Знакомимся с Session Initiation Protocol

Протокол SIP как основа функционирования нового сервера Microsoft RTC Server.

Популярность систем мгновенного обмена сообщениями Instant Messaging (IM) и видеоконференций очень быстро растет. Происходит это как в сфере коммерции, когда организация поддерживает деловые отношения со своими партнерами, в том числе с использованием названных технологий, так и на бытовом уровне. В результате Microsoft начала в равной степени продвигать обе технологии, придерживаясь новых и развивающихся стандартов. Одним из таких стандартов является Session Initiation Protocol, разработанный Internet Engineering Task Force (IETF). В описании и создании этого стандарта специалисты Microsoft принимали самое активное участие. Разработчики компании планируют выпустить сервер Real Time Communications (RTC), в котором используется SIP, для поддержки IM и видеоконференций. Дополнительная информация о том, как предполагается это сделать, содержится во врезке «Компоновка сервера RTC». Microsoft будет поставлять RTC Server примерно в то же время, когда начнутся продажи Windows .NET Server (Win.NET Server) 2003. В настоящее время RTC Server (условно названный Greenwich) проходит бета-тестирование.

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

Основы SIP

SIP — это сквозной (end-to-end) клиент-серверный протокол, который обеспечивает создание, изменение и завершение коммуникационных сессий с участием одного или большего числа пользователей. Коммуникационные сессии могут включать самые разные формы взаимодействия — в основном это точка-точка или групповая передача, — в том числе мультимедийные видеоконференции и телефонные разговоры. Участниками коммуникационных сессий могут быть люди (которые пользуются SIP-телефонами, а также клиенты видеоконференций) или автоматические компоненты (сервер-автоответчик, сервер ведения медиа-архивов).

Хотя телефонная индустрия дала толчок развитию SIP, протокол разрабатывался с целью совершенствования Internet-коммуникаций. Дополнительная информация о развитии протокола SIP приведена на врезке «Краткая история SIP».

Любая коммуникационная сессия, основанная на использовании SIP, подразумевает как минимум три действия и работу трех протоколов.

• SIP обеспечивает базовый обмен пакетами между участниками в момент установки соединения.
• SIP применяет Session Description Protocol (SDP) для описания типа соединения, используемого в сессии, включая тип медиаданных (видео, аудио), транспортный протокол (IP, UDP, Real Time Protocol, RTP), формат данных (H.261 Video, Moving Pictures Experts Group, MPEG - Video).
• SIP использует подходящий для передачи информации протокол. Например, RTP для передачи данных реального времени или Real Time Streaming Protocol (RTSP) - для передачи потокового видео-, аудиосодержимого.

SIP описывается в IETF Request for Comments (RFC) 2543, который можно получить из хранилища IETF (http://www.ietf.org/rfc.html). До марта 1999 г. RFC 2543 не публиковался, поэтому рабочие группы IETF имели возможность применить концепции иных архитектур Internet-протоколов, которые были известны и уже хорошо себя зарекомендовали. В архитектуре SIP многие идеи позаимствованы из SMTP. Например, в SIP пользователи получают SIP-адреса (т. е. SIP URL), которые напоминают адреса SMTP (т. е. Mailto URL). В протоколе SIP заимствована также концепция HTTP. Информация о коммуникационной сессии, которая управляется SIP, напоминает то, что обычно представлено в HTTP. Например, SIP-пакет может выглядеть так, как показано на Экране 1. Из содержимого пакета видно, что пользователь George на компьютере gpc.yankees.com приглашает пользователя Jerry открыть сессию.

Экран 1. Пример запроса INVITE.

SIP предоставляет четыре ключевые функции. Две из них — Name Mapping And Redirection и Capabilities Negotiation — используются во время процедуры установления сессии.

Две другие функции — Participant Management и Capabilities Management — во время работы.

Name mapping and redirection. SIP транслирует информацию об описательных именах участников сессии (descriptive naming information) в информацию о размещении (location information) в соответствии со службами каталога и иными службами. SIP облегчает персональную мобильность участников, поэтому пользователи могут установить SIP-сессию, перемещаясь, например, со своего рабочего места с подключенным настольным компьютером в автомобиль, и объявляя, таким образом, мобильный телефон или PDA предпочтительным средством связи.

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

Participant management. Во время сеанса связи SIP позволяет участникам конференции приглашать новых участников, отключать или приостанавливать их работу.

Capabilities management. Во время сеанса связи SIP осуществляет мониторинг характеристик медиасреды и в случае необходимости выполняет корректировку настроек. Рассмотрим, например, сеанс связи с двумя участниками. У обоих имеются только аудиоустройства. Если новый участник подключается к конференции и у него имеется видеоаппаратура, SIP добавляет передачу видеоданных для нового участника конференции.

Компоненты SIP

SIP состоит из пяти компонентов: User Agent Client (UAC), User Agent Server (UAS), Proxy Server, Redirect Server и Registrar Server. UAC и UAS — компоненты, устанавливаемые на стороне клиента, тогда как службы proxy, редиректора и регистратора запускаются на сервере.

UAC

UAC представляет собой приложение, которое инициирует SIP-запрос для UAS. Сообщение SIP — это или запрос от UAC к UAS, или ответ UAS компоненту UAC. В оригинальной спецификации SIP описано шесть возможных типов запросов (или методов), которые может выдать UAC: INVITE, ACK, OPTIONS, BYE, CANCEL и REGISTER. Расширения SIP, описанные в RFC, определяют дополнительные методы — такие, как MESSAGE, INFO и NOTIFY. Например, метод SIP, показанный на Экране 1, демонстрирует использование метода INVITE и универсальный идентификатор ресурса — Request Uniform Resource Identifier (URI) sip:jerry@acme.com. Метод заканчивается указанием номера версии SIP.

Когда UAC инициирует SIP-сессию, он определяет протокол, порт и IP-адрес UAS, которому посылается запрос. При отсутствии любой информации о локально настроенном proxy-сервере (об этом подробнее чуть позже), UAC использует данные в URI запроса для определения маршрута SIP-запроса. Данный URI запроса всегда определяет хост, но не всегда — порт и протокол. Если хост через адрес IP указан явным образом, UAC пытается связаться с UAS по этому адресу. Если URI запроса специфицирует полностью определенное доменное имя Fully Qualified Domain Name (FQDN), UAC опрашивает службы DNS для разрешения имен, используя для этого ADDRESS, CNAME или другие данные в ресурсной записи. Реализация операционной системы, в которой размещен UAC, может поддерживать альтернативный механизм для определения имени хоста, например через локальные HOSTS-файлы, WINS, широковещательные пакеты; однако в RFC 2543 об их применении не упоминается. Так или иначе, если локальная операционная система определяет и возвращает имя хоста, UAC в дальнейшем использует это имя в сеансе SIP.

Если URI запроса указывает порт, UAC пытается установить соединение с UAS по этому порту. Если URI запроса не указывает порт, UAC соединяется с UDP-портом 5060 по умолчанию. Если URI запроса указывает транспортный протокол (TCP или UDP), UAC использует его. Если URI запроса не указывает транспортный протокол, UAC пытается применить UDP; в случае ошибки UAC пытается задействовать TCP.

Если в запросе INVITE указан порт и протокол, то запрос может выглядеть следующим образом:

INVITE sip:jerry@3.141.59.26:5050;
transport=TCP SIP/2.0

Однако чаще всего приложения используют укороченный формат (указывается только имя хоста), пример приведен на Рисунке 1.

UAS

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

Так же, как и статус-код HTTP, ответ SIP состоит из трехзначного целого кода возврата и текста. Результирующие SIP-коды распадаются на шесть категорий: 1xx (информационное сообщение), 2xx (успех), 3xx (перенаправление), 4xx (ошибка клиента), 5xx (ошибка сервера) и 6xx (глобальный сбой). В Section 7 в RFC 2543 результирующие коды расписаны полностью.

Какова бы ни была природа запроса UAC и итоговое действие UAS, последний посылает UAC ответ. UAS выдает более одного ответа на запрос. Например, когда UAC выдает запрос INVITE участникам конференции, UAS в ответ может послать UAC-инициатору запроса три ответа. Транзакция SIP считается полностью завершенной только тогда, когда UAS исчерпывающе ответил на инициирующий запрос. UAC выдает финальный запрос, в котором используется метод ACK, для получения подтверждения, что на запрос INVITE был дан финальный ответ. Запрос ACK UAC использует только в связке с запросом INVITE — это единственный случай применения ACK.

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

Proxy-сервер

До сих пор мы рассматривали ситуацию, когда соединение UAC и UAS устанавливалось как точка-точка, хотя, строго говоря, данный механизм — клиент-серверный. Однако наличие proxy-серверов в SIP-реализациях — общее правило. Proxy-сервер действует как посредник, который обслуживает запросы и пересылает их дальше — к другим UAC или UAS. По такой методике пользовательский UA маршрутизирует все свои SIP-транзакции через явным образом указанный proxy-сервер. На Экране 2 показан типичный пример внутриорганизационной конфигурации, когда пользователь, инициируя SIP-сессию с другим пользователем внутри той же организации, посылает сообщения по определенному маршруту через proxy-сервер до того, как эти сообщения достигнут целевого SIP-клиента.

Экран 2. Типичная внутриорганизационная конфигурация proxy-сервера.

Такая внутриорганизационная архитектура может быть расширена до межорганизационной. На Экране 3 показана межорганизационная, или федеративная, архитектура. Пользователи в каждой организации имеют собственные UA, настроенные на соответствующий proxy-сервер, а proxy в свою очередь взаимодействуют друг с другом для рассылки сообщений.

Еще один аргумент в пользу применения proxy — это преобразование имен. В случае использования почтовых служб пользователи нередко имеют адрес, который известен внешним клиентам, и внутренний адрес — для корпоративной переписки. Похожая концепция имеет место и для SIP. Proxy-сервер посылает запрос на локализацию службы, скажем Lightweight Directory Access Protocol (LDAP) Directory Service, и преобразует внешний SIP-адрес во внутренний.

В дополнение к показанной федеративной архитектуре, на Экране 3 изображено взаимодействие между компонентами SIP, когда задействованы службы преобразования имен. Когда proxy-сервер Acme получает запрос INVITE, сервер «консультируется» с соответствующей службой для выполнения в случае необходимости преобразования имени. В приведенном примере Proxy Acme предлагает адрес jerry@acme.com, а служба размещения (location service) возвращает внутренний SIP-адрес в виде js@nyc.acme.com.

Реализация службы размещения никоим образом не завязана на спецификацию SIP. Аналогично и SIP не диктует правила взаимодействия между proxy-сервером и службой размещения. Можно использовать службу размещения, а можно и не использовать. Если решено это делать, то предстоит выбрать тип службы. RTC Server задействует собственную службу размещения (не Active Directory).

В случае необходимости служба размещения может использовать множество SIP-адресов пользователей. Например, несколько SIP-адресов может понадобиться в том случае, когда получатель регистрируется в нескольких местах (с разных телефонов и компьютерных терминалов). Когда служба размещения возвращает несколько SIP-адресов, proxy предоставляет запрос INVITE каждому идентифицированному UAS. Серверы proxy пытаются опросить SIP-адрес в последовательном или параллельном режиме до тех пор, пока соединение не будет установлено, отклонено или пользователь не окажется вне зоны обслуживания.

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

Redirect Server

Одна из основных задач SIP — перенаправление запросов. Перенаправление дает пользователям возможность перемещаться, но по-прежнему быть на связи, имея тот же самый SIP-идентификатор. Например, если пользователь jerry@acme.com покинул офис и зарегистрировался с данным SIP-идентификатором в отеле, в котором остановился, SIP-сообщения, пришедшие на адрес jerry@acme.com, будут, в конце концов, маршрутизированы на адрес: room1206@la.hyatt.com.

В подобных ситуациях, учитывая тот факт, что на proxy-сервере имеется «привязка» оригинального сообщения SIP к новому адресу SIP, имеет место не совсем оптимальное отслеживание сетевого маршрута. Вместо этого, хорошо было бы иметь сервер-редиректор Acme, который сообщит вызывающей программе, что для установления контакта с получателем нужно использовать другой SIP-адрес. В этом случае серверу-редиректору необходимо предоставить доступ к службе размещения для пользователей Acme, как показано на Экране 4.

После того как proxy-сервер получает инициирующий запрос INVITE, сервер посылает запрос серверу-редиректору. Сервер-редиректор взаимодействует со службой размещения, получает новые данные о временных адресах и возвращает ответ SIP/2.0 300 Moved Temporarily. Поле Contact содержит временный адрес. Оригинальная вызывающая программа повторно выдает INVITE, но на этот раз с указанием временного адреса. Чтобы транзакция была выполнена полностью, вызывающая программа выдает запрос ACK серверу-редиректору. (На Экране 4 этот последний шаг не показан.)

Хотя proxy и редиректор — это разные компоненты, RTC Server реализует их в составе единого сервера. Сервер, который сочетает в себе функции того и другого, носит название SIP-сервер. Настройки SIP-сервера устанавливают, как будут обрабатываться сообщения SIP для различных получателей (т. е. определяют, будет сообщение направлено proxy-серверу или серверу-редиректору).

Registrar Server

Пользователи могут информировать proxy-сервер или сервер-редиректор, по какому адресу следует обращаться для установления сеанса связи. Когда пользователю понадобится изменить адрес, SIP-клиент выдает запрос REGISTER. Сервер-распорядитель (Registrar Server) принимает REGISTER и записывает содержащуюся в запросе обновленную информацию. Обычно SIP-сервер использует эти данные для передачи службе локализации, которая направляет запрос на правильный адрес.

Клиенты SIP могут контактировать с Registrar Server двумя способами. Они могут напрямую обращаться к серверу, используя данные об адресах в настройках клиента. Или обращение может быть опосредованным — с помощью широковещательного адреса sip.mcast.net (224.0.1.75). При этом запрос регистрации направляется на группу All SIP Servers. SIP-серверы «слушают» обращения по указанному адресу и соответствующим образом обрабатывают поступившие запросы SIP REGISTER.

Экран 5. Пример запроса REGISTER.

На Экране 5 показан пример запроса REGISTER. URI запроса специфицирует назначение запроса REGISTER (читайте — Registrar Server) и должен включать только данные об имени хоста и домена — в нем не может содержаться имя пользователя. Поле To идентифицирует адрес SIP пользователя, который будет регистрироваться. Когда пользователь выполняет собственно регистрацию, данные об адресах в поле To и From обычно соответствуют друг другу. Если имеет место регистрация у независимого разработчика (а в этом случае процедура может выполняться с учетом каких-либо иных характеристик пользователя), поле From содержит SIP-адрес данного разработчика.

Хотя это и не всегда требуется, запрос REGISTER может включать поле Contact. На примере Экрана 5 видно, что адрес в поле Contact отличается от адреса в поле To. Тогда proxy-сервер или редиректор в дальнейшем станут направлять запросы пользователя, указанного в поле To, по адресу, заданному в поле Contact.

Поле Expires указывает время жизни запроса регистрации в секундах.

В приведенном примере запрос REGISTER перестает быть актуальным через 12 ч. Однако если клиент не указал значение этого параметра, серверы SIP, как правило, регистрируют пользователя на 1 ч. Пользователь имеет право отменить регистрацию, повторно выдав запрос REGISTER с указанием времени жизни 0 с.

Точно так же, как на одном SIP-сервере можно объединить функции proxy-сервера и редиректора, можно добавить на тот же самый сервер функцию регистратора. Сервер RTC воплощает функции proxy, редиректора и регистратора на одном сервере SIP.

Итак, я изложил концепцию SIP, как она представлена в RFC 2543. Перед тем как рассматривать конкретные способы реализации SIP, необходимо ясно себе представлять принципы работы SIP. В одной из следующих статей будет рассказано о том, как работают и взаимодействуют продукты SIP Client (Windows Messenger) и SIP Server (RTC Server) производства компании Microsoft.

Компоновка сервера RTC

Первоначально Microsoft Real Time Communications (RTC) Server был компонентом Windows .NET Server (Win.NET Server) 2003, неотъемлемой частью операционной системы. Если вернуться к более ранним бета-версиям Win.NET Server, то в Control Panel можно заметить компонент SIP Services.

Однако разработчики Microsoft пересмотрели свои планы относительно распространения RTC Server и решили компоновать его независимо. На мой взгляд, такое изменение планов не связано со стремлением увеличить доходы корпорации. Ко времени написания статьи лицензионная политика еще не была установлена. Очевидно, однако, что теперь нет никакой возможности воспользоваться лицензией Client Access License (CAL) в качестве платы за доступ к RTC Server. Изменение компоновки теоретически означает большую гибкость при формировании RTC-среды.

Краткая история SIP

Session Initiation Protocol (SIP) не без оснований следует отнести скорее к телефонной индустрии, нежели к компьютерной. Телефонная индустрия дала начало SIP с целью улучшить обслуживание абонентов, но очень быстро специалисты-компьютерщики адаптировали SIP в качестве протокола, с помощью которого можно было упростить все виды связи в масштабе реального времени. То, что раньше было в сфере влияния обычной телефонии, с появлением Internet-коммуникаций перестало быть таковым.

Проект, который со временем стал стандартом SIP, был начат в феврале 1996 г. Самый первый проект IETF, озаглавленный Draft-Ietf-Mmusic-Sip-00, состоял только из одного типа запросов — запроса на установление соединения, Call Setup Request. Между прочим, mmusic — это не название новой поп-группы, это акроним Multiparty Multimedia Session Control. Исправления оригинального проекта привели к опубликованию в декабре 1996 г. Draft-Ietf-Mmusic-Sip-01. По-прежнему для большинства пользователей эта версия проекта оставалась неизвестной, как и ее предшественница. Спустя восемь исправлений и три года работы проект был оформлен как протокол SIP, и теперь пользователи с ним хорошо знакомы. IETF опубликовал проект под названием Draft-Ietf-Mmusic-Sip-12 в январе 1999 г.

На этот раз он содержал уже шесть типов запросов, число которых не изменилось и по сей день. С момента публикации Draft-Ietf-Mmusic-Sip-12 до RFC 2543, посвященного SIP и появившегося в марте 1999 г., произошло очень немного изменений.

На протяжении последних лет SIP продолжал изменяться. Еще важнее то обстоятельство, что появились новые рабочие группы, которые надеются получить от использования SIP определенные преимущества. Наиболее известная группа — SIP for Instant Messaging and Presence Leveraging Extensions (SIMPLE) Working Group. Эта группа расширила оригинальную спецификацию SIP, и теперь в проект введено описание доставки данных Instant Messaging (IM) через запрос MESSAGE Request. Первоначально этот запрос представлял собой механизм, с помощью которого в сервере Microsoft Real Time Communications (RTC) были реализованы функции IM.