Компоненты и протоколы SIP

Система, использующая SIP, может рассматриваться состоящей из клиентов, серверов и индивидуальных сетевых элементов. RFC 3261 определяет клиента и сервер следующим образом:

Индивидуальные элементы стандартной конфигурации включают в себя:

Агент пользователя: Агент пользователя резидентно присутствует в каждой конечной станции SIP. Он выполняет две роли.

Агент пользователя клиента UAC (User Agent Client): Посылает запросы SIP. Агент пользователя сервера UAS (User Agent Server): получает SIP-запросы, генерирует отклики, принимает, отклоняет или перенаправляет запросы

Сервер переадресации: Сервер переадресации используется во время инициализации сессии, чтобы определить адрес запрашиваемого устройства. Сервер переадресации отсылает полученную информацию устройству, инициировавшему запрос, направляя UAC, который может использоваться для контакта с альтернативным URI (Universal Resource Identifier). URI является универсальным идентификатором, используемым для именования любого ресурса в Интернет. URL, используемое для Web адресов имеет тип URI. Подробнее это рассмотрено в RFC 2396 [1].

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

Регистратор: Регистратор является сервером, который принимает запросы REGISTER и помещает информацию, которую он получает (SIP-адрес и ассоциированный IP-адрес регистрирующего устройства) из этих запросов, в службу локализации для домена, который им обслуживается.

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

В RFC 3261 в качестве логических устройств определены различные серверы. Они могут быть использованы в качестве отдельных серверов в Интернет или они могут объединяться в рамках одного приложения, которое работает резидентно на определенном физическом сервере

Рис. 1. Протоколы и компоненты SIP

На рис. 1 показано, как некоторые SIP компоненты связаны друг с другом и с протоколами, которые они используют. Агент пользователя А использует SIP для установления сессии с другим агентом пользователя B, который выступает в роли сервера. Диалог запуска сессии использует SIP и включает один или более прокси серверов, чтобы переадресовать запросы и отклики между двумя агентами пользователя. Агенты пользователя используют также протокол SDP (Session Description Protocol), который служит для описания медийной сессии.

Прокси серверы могут, если это требуется, работать в качестве серверов переадресации. Система DNS (Domain Name System) является важной частью, реализующей протокол SIP. Обычно, UAC осуществляет запрос, используя доменное имя UAS, а не IP-адрес. Прокси сервер вынужден консультироваться у DNS-сервера, чтобы найти прокси сервер для зоны места назначения.

Из эксплуатационных соображений SIP часто работает поверх UDP (User Datagram Protocol), и обеспечивает свои собственные механизмы обеспечения надежности доставки, но может использовать и TCP. Если необходим безопасный или криптографический транспортный механизм, сообщения SIP могут передаваться посредством протокола TLS (Transport Layer Security).

С протоколом SIP ассоциирован SDP, описанный в RFC 2327 [4]. SIP используется для приглашения одного или более партнеров для участия в сессии, в то время как кодированные SDP тела сообщений содержат информацию о типе медиа данных (например, голос, видео). После того как эта информация отправлена и подтверждена, все участники знают IP-адреса, доступную полосу и тип данных. Затем начинается передача информации, с использованием соответствующего транспортного протокола. Обычно используется RTP. Во время сессии участники, используя сообщения SIP, могут изменить параметры сессии, такие как новые медиа типы или новые участники сессии.

Универсальные локаторы ресурсов SIP

Ресурсы в конфигурации SIP идентифицируются URI. Примерами ресурсов могут служить:

• Обмен данными в реальном масштабе времени.
• Появление многоканального телефонного вызова.
• Почтовый ящик системы обмена сообщениями.
• Телефонной номер услуг шлюза.
• Группа (такая как "группа продаж" или "группа поддержки") в организации.

URI SIP имеют формат, базирующийся на формате адресов e-mail, в частности user@domain. Существует две общие схемы. Обычные URI имеют форму:

sip:ааа@itep.com

URI могут также включать пароль, номер порта, и сопряженные параметры. Если требуется безопасная передача, sip: заменяется на sips:. В последнем случае сообщения SIP передаются с привлечением протокола TLS.

Примеры работы

Спецификация SIP достаточно сложна; главный документ, RFC 3261, содержит 269 страниц. Для пояснения работы протокола рассмотрим несколько примеров.

На рис. 10.35 показана успешная попытка пользователя А установить сессию с пользователем B, чье URI bbb@itep.com. [9] UAC А сконфигурирован для работы с прокси сервером (выходной сервер) в своем домене и начинает работу с посылки сообщения INVITE прокси серверу, которое указывает на намерение подключить к сессии UAS (1); сервер подтверждает получение запроса (2). Хотя UAS B определяется его URI, выходной прокси сервер должен учесть возможность того, что B в данный момент не доступен или что B поменял адрес. Соответственно, выходной прокси сервер должен переадресовать запрос INVITE прокси серверу, который ответственен за домен itep.com. Выходной прокси сервер, таким образом, консультируется с локальным серером DNS, чтобы получить IP-адрес прокси сервера itep.com (3), путем запроса ресурсной записи DNS SRV, которая содержит информацию о прокси для домена itep.com.

Рис. 2.

DNS-сервер откликается (4) отправкой IP-адреса прокси сервера itep.com. Прокси сервер А может теперь переадресовать сообщение INVITE выходному прокси серверу (5), который посылает подтверждение сообщения (6). Входной прокси сервер теперь консультируется с сервером локализации для определения адреса B (7), а сервер локализации откликается посылкой адреса B, что позволяет послать ему сообщение SIP (8)..

Прокси сервер может теперь послать сообщение INVITE B (9). Посылается отклик от B к А (10, 11, 12), в то время как UAS B обращается к локальному медийному приложению (например, телефонии). Когда медиа приложение воспринимает вызов, UAS B посылает отклик OK А (13, 14, 15)..

Наконец, UAC А посылает сообщение подтверждения UAS B, чтобы подтвердить получения окончательного отклика (16). В этом примере, ACK посылается непосредственно от А к B, обходя два прокси. Это происходит потому, что конечные точки уже знают адрес своего партнера из обмена INVITE/200 (OK). Медиа сессия началась, А и B могут обмениваться данными через одно или более RTP-соединения..

Рис. 3.

В следующем примере (рис. 10.36) используется два типа сообщений, которые пока еще не входят в стандарт SIP, но которые описаны в документе RFC 2848 [5] и которые вероятно будут включены в последующие версии SIP. Эти типы сообщений поддерживают телефонные приложения. Предположим, что в предыдущем примере А была проинформирована о том, что B не доступен. UAC А может выдать сообщение SUBSCRIBE (1), указывающее, что он хочет быть проинформирован, когда B будет доступен..

Этот запрос будет переадресован в нашем случае через два прокси к серверу PINT (Public Switched Telephone Network [PSTN]-Internet Networking – общедоступную коммутируемую телефонную сеть) (2, 3). Сервер PINT работает как шлюз между IP-сетью, из которой пришел запрос установить телефонное соединение, и телефонной сетью, которая осуществляет соединение с адресатом. В этом примере, мы предполагаем, что логика сервера PINT совмещена со службой локализации. Может также случиться, что B подключен к Интернет, а не к PSTN, в этом варианте нужна система, эквивалентная логике PINT, чтобы обрабатывать запросы SUBSCRIBE. В этом примере, мы предполагаем, что функциональность PINT встроена в службу локализации. Служба локализации авторизует подписку, прислав сообщение OK (4), которое передается А (5, 6). Служба локализации, затем немедленно посылает сообщение NOTIFY с текущим статусом B (7, 8, 9), которое подтверждается UAC А (10, 11, 12)..

На рис. 10.37 показано продолжение обмена. B подключается к системе локализации, послав сообщение REGISTER прокси серверу своего домена (1). Прокси обновляет базу данных службы локализации, отражая факт регистрации (2). Обновление подтверждается прокси (3), что подтверждает регистрацию B (4). PINT воспринимает новый статус B от сервера локализации и посылает сообщение NOTIFY, содержащее новый статус B (5). Это сообщение переадресуется А (6, 7). UAC А подтверждает получение уведомления (8, 9, 10)..

Рис. 4.

Сообщения SIP

Как было замечено, SIP является протоколом, базирующемся на текстах, с синтаксисом, сходным с HTTP. Существует два разных типа SIP сообщений, запросы и отклики. Различие форматов этих сообщений проявляется в первой строке. Первая строка запроса содержит метод, определяющий природу запроса, и URI запроса, указывающий, куда следует послать запрос. Первая строка отклика содержит код отклика. Все сообщения имеют заголовок, состоящий из нескольких строк, каждая строка начинается с метки заголовка. Сообщение может содержать в себе описание транспортируемых данных SDP. Для запросов SIP RFC 3261 определяет следующие методы:

• REGISTER (регистр): Используется агентом пользователя, чтобы проинформировать конфигурацию SIP о своем текущем IP адресе и URL, для которого желательно получать вызовы.
• INVITE (приглашение): Используется, чтобы установит медийную сессию между агентами пользователей.
• ACK: Подтверждает надежную доставку сообщения.
• CANCEL (аннулирование): Прерывает обслуживание незавершенного запроса, но не изменяет статуса завершенных вызовов.
• BYE: Завершает сессию между двумя пользователями.
• OPTIONS (опции): Запрашивает информацию об источнике запроса, но не реализует сам запрос

Например, заголовок сообщения (1) на рис. 6.2 может выглядеть следующим образом:

INVITE sip:bbb@ itep.com SIP/2.0
Via: SIP/2.0/UDP 12.26.17.91:5060
Max-Forwards: 70
To: B <sip:bbb@ itep.com
From: A <sip:aaa@iae.com;tag=1928301774
Call-ID: a84b4c76e66710@12.26.17.91
CSeq: 314159 INVITE
Contact: <sip:aaa@iae.com>
Content-Type: application/sdp
Content-Length: 142

Первая строка содержит название метода (INVITE), SIP URI, номер используемой версии протокола SIP. Последующие строки представляют собой список полей заголовка. В данном примере представлен минимально необходимый набор.

Заголовки Via показывают путь запроса через конфигурацию SIP (отправитель и промежуточные прокси), и используются при передаче по тому же маршруту откликов. Когда посылается сообщение INVITE, оно имеет только заголовок, вставленный А. Строка содержит IP адрес (12.26.17.91), номер порта (5060), и транспортный протокол (UDP), которые B должен использовать в отклике.

Заголовок Max-Forwards ограничивает число шагов, которые запрос может сделать до точки назначения. Содержимое этого поля является целым числом, которое декрементируется на 1 каждым прокси, переадресующим запрос. Если значение Max-Forwards станет равным 0, прежде чем запрос достигнет места назначения, он отвергается с кодом ошибки в отклике равным 483 (Too Many Hops – слишком много шагов).

Поле заголовка To содержит имя (B) и URI SIP или SIPS (sip:bbb@ itep.com), которому первоначально предназначался запрос. Поле заголовка From также содержит имя (A) и URI SIP или SIPS (sip:aaa@iae.com), которое указывает на отправителя запроса. Это поле заголовка имеет также свободный параметр, который содержит произвольную строку (1928301774), которая добавляется к URI UAC. Она используется для идентификации сессии.

Поле заголовка Call-ID содержит глобально уникальный идентификатор данного вызова, генерируемый из комбинации псевдослучайной строки и имени ЭВМ или IP-адреса. Комбинация тэгов To, From и Call-ID полностью определяет отношение SIP партнеров А и B.

CSeq или поле заголовка Command Sequence содержит целое число и имя метода. Число CSeq инициализируется в начале вызова (в данном примере 314159), инкрементируется для каждого нового запроса в рамках диалога, и является традиционным порядковым номером. CSeq используется, чтобы отличить повторную передачу от нового запроса.

Поле заголовка Contact содержит SIP URI для непосредственной коммуникации между агентами пользователя. Несмотря на то, что поле заголовка Via говорит другим элементам, куда следует посылать отклик, поле заголовка Contact сообщает другим элементам, куда посылать будущие запросы для заданного диалога. Поле заголовка Content-Type указывает на тип тела сообщения. Поле заголовка Content-Length содержит длину тела сообщения в октетах.

Типы откликов SIP, определенных в RFC 3261 имеют следующие категории:

• Условный (переходной 1xx): Запрос получен и обрабатывается.
• Успех (2xx): Задание успешно получено, понято и воспринято.
• Перенаправление (3xx): Нужны дальнейшие действия, чтобы завершить реализацию запроса.
• Ошибка клиента (4xx): Запрос содержит некорректный синтаксис или не может быть обслужен сервером.
• Ошибка сервера (5xx): Сервер не смог выполнить заведомо корректный запрос.
• Глобальный отказ (Global Failure: 6xx): Запрос не может быть выполнен любым сервером

Например, заголовок сообщения (13) на рис. 6.2 может выглядеть следующим образом:

SIP/2.0 200 OK
Via: SIP/2.0/UDP server10.itep.com
Via: SIP/2.0/UDP bgb3.site3.iae.com
Via: SIP/2.0/UDP 12.26.17.91:5060
To: B <sip:bbb@itep.com;tag=a6c85cf
From: A <sip:aaa@iae.com;tag=1928301774
Call-ID: a84b4c76e66710@12.26.17.91
CSeq: 314159 INVITE
Contact: <sip:bbb@itep.com>
Content-Type: application/sdp
Content-Length: 131

Первая строка содержит номер версии SIP, которая используется, код отклика и имя. Последующие строки представляют собой список полей заголовка. Поля заголовка Via, To, From, Call-ID и CSeq копируются из запроса INVITE. (Существует три значения поля заголовка Via — одно связано с UAC А, другое введено прокси iae.com proxy, и одно добавлено прокси itep.com). Телефонный номер B добавлен в тэг параметра поля заголовка To. Этот тэг вводится обеими сторонами диалога и включается во все будущие запросы в рамках заданного вызова.

Протокол описания сессии

Протокол SDP (Session Description Protocol), определенный в RFC 2327, описывает содержимое сессий, включая телефонию, Интернет радио, приложения мультимедиа. SDP содержит информацию о [8]:

Медиа потоках: Сессия может реализовывать несколько потоков данных. В протоколе SDP в настоящее время определены аудио, видео, данные, управление и приложения (поточные), сходные с MIME типами электронной почты в Интернет.

Адресах: SDP указывает адреса места назначения, которые могут быть для медиа потоков мультикастинг-адресами.

Портах: Для каждого потока специфицируются номера UDP портов для отправителя и получателя.

Типах данных: Для каждого используемого типа потока (например, телефония), тип поля данных указывает на медиа форматы, которые могут использоваться во время сессии.

Времене старта и остановки: Эти данные используются в случае широковещательных сессий, например, телевизионных или радио программ. Указываются время начала, завершения и времена повторов сессии.

Инициаторе: Для широковещательных сессий, инициатор специфицируется, контактной информацией. Это может быть полезно, если получатель встретится с техническими трудностями.

Несмотря на то, что SDP предоставляет возможность описания мультимедиа данных, здесь нахватает механизмов согласования параметров сессии, которые намерены использовать партнеры. Документ RFC 3264 [7] предоставляет модель согласования на основе механизма предложения/отклика, в которой партнеры обмениваются SDP сообщениями с целью достичь согласия относительно природы данных, подлежащих пересылке.

Одним из применений протокола SIP является организация сессий передачи голоса по каналам Интернет (VoIP).

Ссылки