Глава 2. Протокол инициализации сессии (SIP)

Структура протокола SIP

SIP представляет собой многоуровневый протокол. Его функционирование описывается

 комплексом слабо связанных независимых этапов обработки. Если элемент сети SIP содержит

некий уровень, это означает, что он поддерживает группу правил, определённых для

 данного уровня. Однако не каждый элемент, работающий по протоколу SIP, содержит

 все уровни. Кроме того, элементы, специфицированные для работы в SIP, являются

 логическими, а не физическими. В действительности физический элемент SIP может

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

 на него обязанностей.

Нижний уровень SIP отвечает за синтаксис и кодирование. Кодирование определено с

использованием расширенной грамматики Backus-Naur Form (BNF).

 Полное BNF-описание для SIP содержится в RFC 3261, структура сообщений SIP будет

 рассмотрена в разделе 2.2.

Второй уровень программной реализации протокола является транспортным.

Он определяет, как клиент посылает запросы и принимает ответы и как сервер получает

 запросы и посылает ответы по сети. Транспортный уровень протокола описан в разделе 2.10.

Третий уровень – это уровень транзакций. Транзакция – это запрос, отосланный клиентской

 стороной с использованием транспортного уровня SIP серверной стороне, вместе со всеми

ответами на этот запрос, отосланными серверной стороной клиенту. Уровень транзакций

осуществляет  повторную передачу сообщений прикладного уровня, определяет соответствие

 ответов запросу и уведомляет верхний уровень проткокола в случае таймаута.

Любая операция, которую выполняет клиент агента пользователя (UAC), реализуется с

 помощью серии транзакций. Описание работы уровня транзакций приведено в параграфе

2.3.2. Агенты пользователя (UA) и прокси-серверы с сохранением состояний транзакций

 (stateful прокси-серверы) содержат уровень транзакций. В противоположность им

прокси-сервер без сохранения состояний  (stateless прокси-сервер) не включает

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

транзакцией и серверную часть, называемую серверной транзакцией. Каждая из них

представлена конечным автоматом (state machine), связанным с обработкой определённого

типа запроса.

Уровень, находящийся выше уровня транзакций, называется пользователем транзакций

(transaction user - TU). Каждый их объектов SIP, кроме stateless прокси-сервера, является

 пользователем транзакций. Когда TU желает отослать запрос, он создаёт отдельную клиентскую

 транзакцию и передаёт ей запрос вместе с IP-адресом, портом и типом транспортного протокола

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

клиентскую транзакцию, может также отменить её. Когда клиент отменяет транзакцию, он

запрашивает, чтобы сервер прекратил дальнейшую обработку запроса, возвратился в исходное

состояние и этой передал транзакции ответ с определённым кодом ошибки. Это осуществляется

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

свои функции в отношении отменяемой транзакции (См параграф 2.3.5).

SIP элементы, которыми являются клиент и сервер агента пользователя, stateful и stateless

прокси-серверы и сервер регистрации, содержат программное обеспечение - ядро (core),

 которое отличает их друг от друга. Ядра, за исключением ядра stateless прокси-сервера,

являются пользователями транзакций (TU). Несмотря на то, что функционирование ядер

UAC и UAS зависит от типа запроса, существуют некоторые общие правила для всех типов

запросов. Эти правила описаны в разделе 2.1. Для UAC эти правила касаются процесса

 создания запроса, для UAS они касаются обработки запроса и создания ответа. Поскольку

регистрация играет важную роль в протоколе SIP, UAS, который может работать c запросом

REGISTER, имеет своё название – сервер регистрации (registrar). Раздел 2.3.3 описывает работу

ядер UAC и UAS для запроса REGISTER. В разделе 2.3.4. освещается работа UAC и UAS с запросом

 OPTIONS, используемого для получения информации о функциональных возможностях UA. 

 Остальные запросы, определённые в основной RFC для SIP (RFC 3261), отсылаются в

режиме диалога. Диалог представляет собой равноправное взаимодействие двух агентов

пользователя по протоколу SIP, которое длится определённое время. Диалог устанавливает

 последовательность сообщений между UA и обеспечивает верную маршрутизацию запросов.

 Запрос INVITE является единственным типом запроса, устанавливающим диалог, определённым

в рекомендации RFC 3261 (Однако впоследствии расширения протокола определили еще два

таких запроса – SUBSCRIBE и REFER). Когда UAC отсылает запрос в режиме диалога,

он помимо выполнения общих правил UAC, описанных в разделе 2.1, следует правилам для

работы с запросами в ходе диалога. Параграф 2.3.1 даёт понятие о диалогах и описывает

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

режиме диалога.

 Наиболее важный тип запроса в протоколе SIP – это INVITE, который устанавливает

сессию между участниками соединения. Сессия – это совокупность участников соединения и 

медиапотоков между ними, созданных с целью обмена информацией.  Параграф 2.3.6 описывает

 процедуры создания сессий, приводящие к созданию одного или более диалогов.

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

запроса INVITE в режиме диалога. В параграфе 2.3.8 отражено, как разрушается сессия.

2.1. Назначение и функциональность агента пользователя (UA)

Агент пользователя (UA) - это логический объект, который может выполнять как функции

клиента агента пользователя, так и функции сервера агента пользователя. В сети SIP он

 представляет оконечное оборудование абонента. Соответственно, агент пользователя

 состоит из клиента агента пользователя (UAC), генерирующего запросы, и сервера агента

пользователя (UAS), который формирует ответы. Работа UAC и UAS зависит от типа запроса

 и от того, происходит ли передача запроса или ответа в процессе диалога. Далее в этом

 разделе будет рассмотрена работа UAC и UAS вне диалога.

2.1.1. Клиент агента пользователя (UAC)

Клиент агент пользователя – это часть программного обеспечения агента пользователя,

 которая создает новые запросы, отправляет их и обрабатывает принятые ответы.

Запросы генерируются в результате внешних воздействий (нажатия кнопок пользователем,

 сигнала из телефонной линии).

2.1.1.1. Создание запроса

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

строку, содержащую тип запроса, поле Request-URI и версию SIP, и  следующий базовый набор

полей заголовков: To, From, CSeq, Call-ID, Max-Forwards и Via. Эти заголовки, как и Request-URI,

 обязательны для всех SIP-запросов. Данные шесть заголовков являются основными частями

 SIP-сообщения, поскольку совместно обеспечивают большинство требуемых сервисов по

маршрутизации сообщений, включающих адресацию сообщений, маршрутизацию ответов,

ограничение распространения сообщения, сохранение очередности сообщений и уникальную

идентификацию транзакций. В разделе 2.2.2 наряду с основными будут подробно рассмотрены

все существующие заголовки. 

Ниже будет рассмотрена работа UAC вне диалога. Примерами запросов, отсылаемых вне диалога,

 является запрос INVITE (См. раздел 2.3.1), устанавливающий сессию, и запрос OPTION для

запроса информации о функциональных  возможностях (См. раздел 2.3.4.)

Формирование поля Request-URI

Поле Request-URI указывает на пользователя или сервис, к которому адресован запрос.

Исходное значение поля Request-URI сообщения устанавливается таким же, как URI в поле To.

Исключение составляет тип запроса REGISTER; подробно процесс установки Request-URI для

сообщения REGISTER описан в  разделе 2.3.3. По причинам обеспечения анонимности (privacy)

или из соображений удобства может быть нежелательно устанавливать в полях Request-URI и To

одинаковые значения, особенно, если инициирующий UA предвидит, что Request-URI будет

изменён в процессе передачи.

В некоторых случаях наличие предустановленного маршрута может повлиять на Request-URI

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

последовательность URI, которая идентифицируют последовательность  серверов, по которой

UAC пошлёт исходящие запросы вне диалога. Обычно предустановленный маршрут

 устанавливается в UA пользователем или поставщиком услуг (service provider), или же при

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

маршрута один URI, соответствующий исходящему прокси-серверу.

При наличии предустановленного маршрута, должны выполняться процедуры по заполнению

 полей Request-URI и Route, детализированные в параграфе 2.3.1.2 (даже несмотря на то, что

диалога не существует) при использовании желаемого Request-URI в качестве URI удалённого

узла.

Формирование заголовка To

Поле заголовка To устанавливает желаемого логического получателя запроса - публичный адрес

 получателя (address-of-record) 

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

 конечным получателем запроса. 

Поле To может содержать SIP или SIPS URI. Схема SIPS означает, что ресурсы достижимы только 

при условии обеспечения 

безопасности (например, с помощью протокола TLS). 

При необходимости могут использоваться и другие URI-схемы (например, схема «tel» (RFC 2806)).

 Все реализации SIP должны поддерживать схему SIP URI, а любая реализация, которая поддерживает

протокол TLS, должна поддерживать схему SIPS URI. Поле To позволяет также отображать имя

пользователя.

Обычно поле заголовка To заполняется через интерфейс пользователя вручную или с использованием

адресной книги. Зачастую пользователь не вводит адреса полностью, а вместо этого вводит строку букв или цифр (например, «anton»);  UA сам решает как интерпретировать эту строку. Использование строки ввода для формирования пользовательской части SIP-адреса (user part) предполагает, что UA желает определить имя домена, находящееся по правую сторону от «@»  SIP URI (например, sip:anton@niits.ru). Использование строки ввода для формирования пользовательской части SIPS адреса подразумевает, что UA желает установить безопасное соединение, имя домена также определяется. Правая часть адреса может указывать домашний домен (home domain) инициатора запроса; в этом случае вызываемый пользователь также находится в данном домене. Тогда SIP элемент, ответственный за пересылку сообщений в данном домене осуществляет обработку исходящего запроса. Это необходимо для таких функций, как «быстрый вызов», которые требуют интерпретации части пользователя в домашнем домене.

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

Пример поля заголовка To:

To: Anton <sip:anton@niits.ru>

Формирование заголовка From

Поле заголовка From содержит логический идентификатор инициатора сообщения, как правило, публичный

адрес вызывающего пользователя. Также как поле To оно содержит URI и, опционально, отображаемое

имя (display name), что удобно для вызываемого пользователя. Заголовок используется SIP-элементами

 для  того, чтобы определить правила обработки, применимые к запросу (например, автоматическое

 отклонение вызова). Важно, чтобы URI в заголовке From не содержал IP-адреса или FQDN (Fully Qualified

Domain Name) хоста, с которым работает UA, так как это не логические имена.

Заголовок From предусматривает присутствие отображаемого имени (display name).

UAC

 должен использовать отображаемое имя "Anonymous", если идентификационная информация

пользователя

(identity) неизвестна.

Обычно, поле заголовка From запросов, которые создаёт UA, заполняется на основании  значения,

предварительно определённого пользователем или администратором локального домена пользователя.

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

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

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

заголовки From их запросов.

Поле From должно содержать новый параметр «tag», созданный клиентом UA.

Примеры:

From: "Anton" <sips:anton@niits.ru> ;tag=a48s

From: sip:+79213434329@gateway.protei.ru;tag=887s

From: Anonymous <sip:c8oqz84zk7z@privacy.org>;tag=hyh8

Формирование заголовка Call-ID

Заголовок Call-ID – это уникальный идентификатор, объединяющий группу сообщений. Он должен совпадать

 для всех запросов и ответов, отправляемых любым из двух UA в процессе диалога.

При создании нового диалога, заголовок Call-ID должен быть выбран UAC как уникальный идентификатор.

Все SIP агенты пользователя должны иметь средства, чтобы гарантировать, что Call-ID, созданный ими,

 не будет случайно генерирован другим UA. Когда запросы отправляются повторно после получения ответа

 с кодом ошибки, требующего коррекции запроса, (например, запрос на предоставление отклика

аутентификации), эти повторные запросы не рассматриваются как новые и не нуждаются в новом

значении заголовка Call-ID (См. пункт «Обработка ответов класса 4хх» параграфа 2.1.1.2). 

При генерации значений Call-ID рекомендуется использовать случайные криптографические

 идентификаторы (по RFC 1750), их использование обеспечивает некоторую защиту от взлома сессий

и уменьшает вероятность возникновения коллизий Call-ID.  Реализации могут использовать форму

localid@host. Значения заголовка Call-ID чувствительны к регистру и должны сравниваться побайтно.

Пример:

Call-ID: f81d4fae-7dec-11d0-a765-00a0c91e6bf6@niits.ru

Формирование заголовка CSeq

Поле заголовка CSeq служит средством для идентификации и упорядочивания транзакций. Оно содержит

 порядковый номер и тип запроса. Для запросов вне диалога, кроме REGISTER, значение порядкового

 номера может быть произвольным. Величина порядкового номера выражается 32-разрядным целым

 числом и должна быть меньше, чем 2³¹. Клиент может выбирать любой механизм для создания значений

 заголовка CSeq.

Пример:

CSeq: 4711 INVITE

Формирование заголовка Max-Forwards

Поле заголовка Max-Forwards служит для ограничения числа пересылок запроса на пути к месту

назначения. Оно состоит из целого числа, которое уменьшается на единицу при каждой пересылке.

 Если значение этого заголовка достигнет 0 до того, как запрос достигнет места назначения, это

 сообщение будет отклонено ответом с кодом ошибки 483 (Too Many Hops).

UAC должен вставлять заголовок Max-Forwards в каждый отправляемый запрос. Рекомендуемая величина

для его значения: 70. Величина выбрана достаточно большой, чтобы гарантировать, что запрос не будет

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

прокси-сервера при возникновении петли. Меньшие величины рекомендуется использовать с

осторожностью и только в сетях, где агенту пользователя известна топология сети.

Формирование заголовка Via

Поле заголовка Via указывает один из узлов, используемых для проведения транзакции и идентифицирует

 местоположение (location), куда должен быть отправлен ответ. SIP элемент, добавляет собственное

значение заголовка Via только после выбора следующего узла, которому будет передан запрос.

Когда UAC создает запрос, он должен вставить в него поле Via. Также необходимо указать название

протокола – SIP, и его версию - 2.0. Поле заголовка Via должно содержать параметр «branch». Этот

параметр используется для идентификации транзакции, созданной данным запросом. Он используется  и

клиентом, и сервером.

Значение параметра «branch» должно быть уникальным для всех запросов, отправляемых UA. 

Исключение составляют запрос CANCEL и запрос ACK на ответы, отличные от класса 2хх. 

Запрос CANCEL будет иметь то же значение параметра «branch», что и запрос, который он отменяет.

 Запрос ACK на ответ, отличный от класса 2хх также будет иметь тот же параметр «branch», 

что и INVITE, ответ на который он подтверждает. Уникальность этого параметра облегчает его 

использование в качестве идентификатора транзакции. Параметр «branch», вставляемый 

элементом сети SIP, должен всегда начинаться с "z9hG4bK". Эти семь символов, называемых

 «magic cookie», используют для того, чтобы серверы, получившие запрос, могли определить, 

что идентификатор транзакции уникален в мировом масштабе.  

Другие параметры заголовка Via («maddr», «ttl» и «sent-by») будут установлены во время

обработки запроса транспортным уровнем протокола SIP.

Формирование заголовка Contact

Поле заголовка Contact содержит SIP или SIPS URI, который может быть использован для связи с

 пользователем UA, пославшим сообщение (получатель может использовать этот адрес для

 своих будущих запросов). Этот заголовок должен присутствовать и содержать только один

 SIP или SIPS URI в любом запросе, результатом которого может стать установление диалога.

 Таким запросом, например, является INVITE. Для этих запросов масштаб заголовка Contact

должен быть глобальным, т.е. значение поля заголовка Contact содержит URI, на который UA

 желает получать запросы, и этот URI должен быть действительным, даже если используется

 в последующих запросах вне диалога.

Если поле Request-URI или первое значение заголовка Route содержит SIPS URI, поле Contact

 также должно содержать SIPS URI. Заголовок Route служит для принудительной маршрутизации

запроса в соответствии со списком прокси-серверов.

Формирование заголовков Supported и Require

Если UAC поддерживает расширения SIP определяющие новые функции для SIP элементов,

которые могут быть использованы сервером в ответах, UAC должен включить в запрос

заголовок Supported со списком идентификаторов (option tag) поддерживаемых функций.

Список оption-tag уникально идентифицирует новые функциональные возможности для SIP

 в соответствии с расширениями SIP, определёнными в дополнительных RFC. Это делается

для того, чтобы предотвратить требование серверов на то, чтобы клиенты реализовывали

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

 получить обслуживание.   Расширения, описанные в RFC не имеющих статуса Standard,

 не используются в заголовке Supported  запроса, так как они зачастую используются 

для определения нестандартизованных расширений фирм-производителей.

Если UAC хочет потребовать, чтобы UAS понял расширение, которое UAC применит к

запросу для обработки запроса, он должен вставить в запрос поле заголовка Require,

 указывающее option-tag для этого расширения. Если UAC хочет применить расширение

 к запросу и потребовать, чтобы каждый пройденный прокси-сервер понимал  это расширение,

он должен вставить в запрос заголовок Proxy-Require, указывающий  option-tag для

этого расширения.

Дополнительные компоненты сообщения

После того, как создается новый запрос, и заголовки, описанные выше составляются должным

 образом, добавляются необязательные заголовки в соответствии с типом запроса.

SIP-запросы могут содержать закодированное MIME тело сообщения (См. Multipurpose Internet

 Mail Extensions Part Two: Media Types", RFC 2046). Независимо от типа тела, которое содержит

запрос, конкретные заголовки должны быть составлены так, чтобы описывать содержимое

 тела сообщения (заголовки Content-Disposition, Content-Encoding, Content-Language, Content-Length,

 Content-Type). См параграф 2.2.2).

Отправка запроса

При отправке запроса первоначально определяется место назначения. Если местная политика

безопасности не определена по-иному, адрес места назначения должен быть определен с

 применением DNS-процедур, описанных в RFC 3263: "SIP: Locating SIP Servers".  Если первым в

маршруте стоит strict router (прокси-сервер, удаляющий содержимое Request-URI при наличии

в сообщении заголовка Route), то вышеуказанные  DNS-процедуры должны быть применены к

полю Request-URI, содержащемуся в стартовой строке запроса. В противном случае эти

процедуры применяются к первому значению заголовка Route или к Request-URI, если

заголовок Route отсутствует. Эти процедуры устанавливают упорядоченную последовательность

состоящую из адреса, порта и типа транспортного протокола для запроса. Независимо от того,

какой URI используется в качестве входящего для процедур «Locating SIP Servers», если Request-URI

 указывает на SIPS ресурс, UAC должен выполнять эти процедуры, как если бы входящим URI был SIPS URI.

Местная политика может предусматривать наличие альтернативного набора мест назначения для

использования в запросах. Если Request-URI содержит SIPS URI, то соединение с любым

 альтернативным местом назначения должно проходить с использованием протокола TLS.

 Более того,  ограничений для альтернативных мест назначения не существует, если запрос

 не содержит заголовка Route. Это представляет собой упрощённую альтернативу

предустановленному маршруту, как способу указания исходящего прокси-сервера. Однако такой

 подход для конфигурирования исходящего прокси-сервера не рекомендуется, вместо этого лучше

использовать предустановленный маршрут с единственным URI. Если запрос содержит поле

заголовка Route, то он будет отправлен на сервер, определенный в верхнем значении Route,

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

 Route и Request-URI, что и UA. В частности, UA, сконфигурированный исходящим прокси-сервером,

 должен пытаться отправить запрос по адресу, указанному в первом значении поля заголовка Route,

вместо поддержки политики отправки всех сообщений исходящему прокси-серверу. Этим гарантируется,

 что исходящие прокси-серверы, которые не добавляют поле заголовка Record-Route, выпадут из

 маршрута последующих запросов. Оконечные точки, которые не могут определить первое значение

для поля заголовка Route, делегируют выполнение этой задачи исходящему прокси-серверу.

UAC должен следовать процедурам, определённым в "SIP: Locating SIP Servers", RFC 3263 для stateful

SIP элементов, посылая запросы по каждому адресу, пока не будет установлено соединение с сервером.

 Каждая попытка составляет новую транзакцию, и поэтому каждый новый запрос содержит заголовок

Via с новым параметром «branch» в первом значении.

2.1.1.2. Обработка ответов

Ответы сначала обрабатываются транспортным уровнем SIP, а потом направляются на уровень

 транзакций. Уровень транзакций производит их обработку и затем передаёт вышестоящему уровню –

уровню пользователя транзакций (transaction user, TU). Большая часть обработки ответов TU  зависит

 от типа запроса, на который был передан ответ. Однако некоторые основные этапы обработки не

зависят от типа запроса.

Ошибки уровня транзакций

В некоторых случаях, ответ, переданный уровнем транзакций, не является SIP сообщением,

это означает уведомление об ошибке уровня транзакций. Когда с уровня транзакций приходит

уведомление об ошибке истечения времени (timeout error), оно должно обрабатываться, как ответ

 с кодом 408 (Request Timeout). Когда с транспортного уровня SIP приходит сообщение о критической

ошибке (fatal transport error), то оно должно быть трактовано, как ответ 503 (Service Unavailable).

 Обычно это означает критическую ICMP-ошибку в протоколе UDP или нарушение соединения в TCP.

Неизвестные ответы

UAC должен расценивать любой неизвестный окончательный ответ, как эквивалентный x00 ответу

того же класса, и должен быть готов обрабатывать ответы x00 любого класса. Например, если UAC

получает неизвестный ответ с кодом 431, он делает вывод о том, что запрос содержал ошибку, и

трактует ответ, как 400 (Bad Request). UAC должен трактовать любой неизвестный предварительный

ответ, отличный от 100, как ответ с кодом 183 (Session Progress). UAC должен быть способен

 обрабатывать и 100, и 183 ответы.

Заголовки Via

Если в ответе представлено более одного значения поля заголовка Via, UAC должен отбросить

сообщение, так как в этом случае сообщение, по-видимому, было неправильно маршрутизировано

или искажено.

Обработка ответов класса 3хх

При поступлении ответа перенаправления (например, ответа с кодом 301), клиенты должны использовать

адрес (адреса) из поля Contact при составлении одного или нескольких новых запросов, основанных на

перенаправленном запросе. Клиент начинает работу  с начального списка адресов вызываемого

пользователя (target set), включающего только один URI - Request-URI оригинального запроса.

Если отправитель желает сформировать новые запросы после получения перенаправляющего ответа

класса 3хх на предшествующий запрос, он помещает новые адреса в target set. UAC может выбрать,

 какие из URI, расположенных в поле Contact, поместить в target set. Клиент, обрабатывающий ответы

 класса 3хх, не должен добавлять один и тот же URI в target set более одного раза. Если оригинальный

запрос содержит SIPS URI в Request-URI, клиент может перенаправить запрос на не SIPS URI, но должен

информировать пользователя о перенаправлении запроса не небезопасный URI.

По мере того, как target set растёт, UAC может генерировать новые запросы, используя адреса

выбранные из target set в любом порядке. Простейшим механизмом для этого является

упорядочивание в соответствии со значением параметра «q» каждого значения заголовка Contact.

Параметр «q» определяет приоритеты среди адресов, содержащихся в заголовке Contact

путём варьирования значения в пределах от 0 до 1.   Запросы могут генерироваться последовательно

или параллельно. Один подход состоит в обработке групп в порядке уменьшения значения параметра

 «q» последовательно и обработке адресов в каждой группе с определённым значением параметра

«q» параллельно. Другой подход предусматривает последовательную обработку в порядке

уменьшения значения параметра «q», произвольно выбирая между адресами с одинаковым значением q.

Если при обращении на контактный адрес из списка приходит ответ об ошибке, SIP элемент переходит

к следующему адресу в списке. Когда список заканчивается, запрос отбрасывается.

Ошибки определяются по кодам ответов (коды со значением более 399). Об ошибках, произошедших

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

клиентская транзакция. Некоторые коды ответов показывают, что запрос может быть передан снова;

такие запросы не должны расцениваться как ошибки.

Когда приходит ошибка при обращении на определённый контактный адрес, клиент должен попытаться

 отослать запрос на следующий контактный адрес. Это повлечёт за собой создание новой клиентской

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

Для того, чтобы создать запрос на основании контактного адреса, полученного в ответе класса 3хх,

UAC должен полностью скопировать URI из списка адресов target set в Request-URI, за исключением

параметров «method-param» и «header». Параметры «header»  используются для создания значений

 полей заголовков для новых запросов, заменяя значения, связанные с перенаправленным запросом.

В некоторых случаях в контактном адресе (адресе, содержащемся в заголовке Contact) указываются

другие заголовки. Значения этих заголовков могут быть добавлены к  значениям заголовков в

оригинальном перенаправленном запросе. Как правило, если поле заголовка может принимать

 разделённый запятыми список значения параметров, то новое значение поля заголовка может

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

 Если же поле заголовка не поддерживает множественность значений, то  значение в оригинальном

перенаправленном запросе может быть перезаписано значением из контактного адреса. Например,

если контактный адрес возвращен со следующим значением:

sip:anton@niits.ru?Subject=organization&Call-Info=http://www.niits.ru,

то любое поле заголовка Subject в оригинальном перенаправленном запросе перезаписывается, но

HTTP URL просто добавляется к существующим значениям поля заголовка Call-Info.

Рекомендуется, чтобы UAC использовал поля заголовков To, From и Call-ID, применявшиеся в

перенаправленном запросе, но UAC, например, может обновить значение поля заголовка Call-ID

для новых запросов. В результате, сформированный новый запрос, отправляется с использованием

 новой клиентской транзакции и, следовательно, он будет иметь новое значение параметра «branch»

 в верхнем поле Via.

В остальном, запросы, отправленные при получении ответа перенаправления, будет иметь те же поля

заголовков и тела сообщения, что и оригинальный запрос.

В некоторых случаях, значения поля заголовка Contact могут запоминаться  клиентом временно или

постоянно в зависимости от кода ответа и присутствия интервала истечения времени действия.

Обработка ответов класса 4хх

Отдельные коды ответов класса 4xx требует особых действий от UA по обработке в не зависимости

от типа запроса, на который приходит ответ.

·       ответ с кодом 401 (Unauthorized) или 407 (Proxy Authentication Required) означает, что запрос

требует проведения процедур аутентификации. Получив ответ, UAC будет выполнять процедуру

аутентификации для последующего запроса.

·       Код ответа 413 (Request Entity Too Large) означает, что запрос содержит тело, слишком большой

длины, чтобы UAS мог его принять. При этом UAC заново передает запрос, убирая тело сообщения или уменьшая его.

·       Код ответа  415 (Unsupported Media Type) означает, что формат данных, содержащихся в запросе – тип

тела сообщения, не поддерживается UAS. В этом случае UAC должен заново отправить запрос, приняв во

 внимание список поддерживаемых типов в поле заголовка Accept , список поддерживаемых кодеков в поле

Accept-Encoding и список поддерживаемых языков в поле Accept-Language, содержащихся в ответе.

·       ответ с кодом 416 (Unsupported URI Scheme) означает, что тип URI, использованный в Request-URI, не

поддерживается сервером. В этом случае UAC должен заново послать запрос, используя SIP URI.

·       ответ с кодом 420 (Bad Extension) означает, что запрос содержит  заголовки Require или Proxy-Require,

 указывающие option-tag для функции, которая не поддерживается прокси-сервером или UAS. UAC в этом случае

 должен заново передать запрос, убрав из него все расширения, указанные в поле заголовка Unsupported ответа.

·       Ответ с кодом 494 (Security Agreement Required) передаётся сервером при выполнении процедуры выбора

 механизма обеспечения безопасности. Ответ должен включать заголовок Security-Server со списком механизмов

обеспечения безопасности, поддерживаемых сервером. UAC должен выбрать подходящий механизм безопасности и

 применить его при отсылке запроса.

Во всех описанных выше случаях, запрос передается заново с соответствующими изменениями. Новый запрос

составляет новую транзакцию и будет иметь такие же значения заголовков Call-ID, To и From, как и предыдущий

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

При получении других ответов класса 4хх передача запроса может производиться заново в зависимости от типа

запроса и конкретного случая использования.

2.1.2. Сервер агента пользователя (UAS)

Сервер агента пользователя принимает запросы и генерирует ответы, основываясь на действиях пользователя,

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

2.1.2.1. Процедура обработки запросов

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

Серверы агента пользователя обрабатывают запросы пошагово, как указано в данном разделе

(то есть начиная с аутентификации, затем анализа типа запроса, полей заголовков и так далее).

Определение типа запроса

Когда запрос прошел аутентификацию (или она была пропущена), UAS должен выяснить тип запроса.

Если UAS определил, но не поддерживает тип запроса, он должен отправить ответ с кодом 405

(Method Not Allowed); в этом ответе должно присутствовать заголовок Allow, который содержит список типов

 запросов, поддерживаемых UAS.

В случае поддержки сервером типа запроса, обработка сообщения продолжается.

Определение типа заголовка

Если UAS не понимает заголовка, представленного в запросе, он должен игнорировать этот заголовок и продолжать

 обработку сообщения. UAS игнорирует все неопознанные заголовки, которые необязательны для обработки запроса.

Обработка полей To и Request-URI

В поле заголовка To вызывающий пользователь указывает адрес получателя запроса. UAS может поступать

произвольным образом при выработке решения о приёме запроса, заголовок To которого идентифицирует не

 данный UAS. Однако рекомендуется, чтобы UAS принимал запросы, даже если они содержат неизвестную схему URI

 (например, схему «tel») в поле To, или если поле To не адресует ни текущего, ни одного из существующих

 пользователей этого UAS. Если все же, UAS решает отклонить запрос, он должен создать ответ с кодом 403

(Forbidden) и передать его серверной транзакции (понятие серверной транзакции даётся в разделе 2.3.2)

 для отсылки.

Поле Request-URI идентифицирует UAS, который должен обработать запрос. Если в Request-URI используется схема

адресации, неподдерживаемая сервером, запрос должен быть отклонён и отправлен ответ с кодом 416

 (Unsupported URI Scheme). Если Request-URI не идентифицирует адрес, для которого UAS готов принять запрос,

 сообщение отбрасывается и отправляется ответ с кодом 404 (Not Found). Обычно, UA, который использует

сообщение REGISTER для связки публичного адреса пользователя (address-of-record) с конкретным контактным

адресом, должен опознавать запросы, Request-URI которых совпадает с его контактным адресом.

 Другие возможные источники для значения полученного Request-URI включают заголовки Contact запросов и

ответов, отправленных UA для установления или обновления параметров диалога.

Обработка одинаковых запросов

Если запрос не содержит параметра «tag» в поле заголовка To, ядро UAS (UAS core) должно проверить запрос на

предмет происходящих транзакций. Если «tag» заголовка From, заголовки Call-ID и CSeq точно совпадают с

 аналогичными полями, связанными с происходящей транзакцией, но запрос не соответствует этой транзакции,

ядро UAS должно составить ответ с кодом 482 (Loop Detected) и передать его серверной транзакции.

Одинаковые запросы могут придти на сервер более одного раза, следуя различными путями, вероятнее всего из-за

размножения запросов прокси-сервером. Ядро UAS обрабатывает первый такой запрос и отправляет

 ответ с кодом 482 (Loop Detected) на последующие запросы.

Обработка заголовка Require

После того, как UAS решает, что запрос предназначен для него, он приступает к анализу заголовка Require в случае

его наличия.

Поле заголовка Require используется UAC, чтобы сообщить UAS о SIP расширениях, которые должны поддерживаться

 UAS  для правильной обработки запроса.  Если UAS не понимает какого-либо идентификатора расширения option-tag,

 указанного в поле Require, он должен отослать ответ с кодом 420 (Bad Extension). UAS должен добавить в ответ

 заголовок Unsupported со списком непонятных опций, указанных в поле заголовка Require запроса.

Заметим, что заголовки Require и Proxy-Require не должны использоваться в запросе CANCEL, а также в запросе

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

 в таких запросах.

Запрос ACK на ответ класса 2xx должен содержать только те значения Require и Proxy-Require, которые

 присутствовали начальном запросе, например:

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

опции (options) понятны обеим сторонам, и будет замедляться, только если существуют разногласия, как в

 приведенном выше примере. Для хорошо согласованной пары клиент-сервер взаимодействие происходит быстро,

так как не тратится время на механизмы согласования. К тому же, это устраняет проблемы, возникающие, когда

 клиент требует возможностей, которые сервер не поддерживает.

Обработка содержимого тела сообщения

Допустим, что UAS понимает все расширения, требуемые клиентом, тогда UAS изучает тело сообщения и поля

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

(указывается в Content-Type), языком (указывается в Content-Language) или кодеком

(указывается в Content-Encoding), и это тело является обязательным (указывается в Content-Disposition),

 UAS должен отбросить запрос и отправить ответ с кодом 415 (Unsupported Media Type). Ответ должен содержать

заголовок Accept со списком всех типов тел сообщения, которые понимает UAS, в случае наличия в запросе тел

 сообщения с типами, не поддерживаемыми сервером. Если запрос содержит типы кодеков содержимого, непонятные

 UAS, ответ должен содержать заголовок Accept-Encoding со списком кодировок, понятных UAS. Также если запрос

 имеет содержимое на непонятном для UAS языке, ответ должен содержать заголовок Accept-Language со списком

языков, понятных UAS. После этих проверок, тело обрабатывается в зависимости от типа запроса и типа тела.

Применение расширений

При формировании ответа UAS не должен использовать расширения, если поддержка этих расширений клиентом не

была указана в заголовке Supported запроса. Если требуемые расширения не поддерживаются, сервер должен

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

когда сервер не может обработать запрос без требуемого расширения, он может отправить ответ с кодом 421

(Extension Required). Этот ответ показывает, что правильный ответ не может быть сгенерирован без поддержки

определенного расширения. Требуемое расширение или расширения должны быть включены в поле Require ответа.

Любые расширения к ответам, кроме ответа с кодом 421, должны быть указаны в заголовке Require, включённом в

ответ. Сервер не должен применять расширения, не указанные в заголовке Supported запроса.

После того, как все вышеописанные действия выполнены, дальнейшая обработка запросов зависит от его типа.

2.1.2.2. Создание ответа

Когда UAS создаёт ответ на запрос, он следует общим процедурам, описанным ниже. Также может потребоваться

 выполнение дополнительных действий, которые зависят от конкретного кода ответа.

После завершения выполнения всех процедур, связанных с созданием ответа UAS возвращает ответ серверной

транзакции, от которой был получен запрос.

Отсылка предварительного ответа

Основное правило при генерации ответа, вне зависимости от типа запроса, состоит в том, что серверы UA должны

отправлять предварительные ответы только на запросы INVITE. При этом они должны как можно быстрее  создавать

 на запросы кроме INVITE  окончательные ответы.

При формировании ответа с кодом 100 (Trying) заголовок Timestamp (указывает, когда UAC отослал сообщение UAS)

 из запроса должен быть в точности скопировано в него. Это выполняется в целях оценки клиентом времени RTT.

 Если происходит задержка при генерировании ответа, UAS должен добавить значение задержки к значению,

содержащемуся в поле заголовка Timestamp в ответе. Это значение должно содержать разницу между временем

получения запроса и временем отправки ответа, выраженную в секундах.

Заголовки и параметры «tag»

Поле From ответа должно совпадать с аналогичным полем запроса, равно как и  поля Call-ID, Cseq и Via  ответа

должно совпадать с полями Call-ID, Cseq и Via запроса. Помимо этого значения поля Via должны совпадать со

 значениями поля Via в запросе  и должны сохранять порядок следования.

Если запрос содержал «tag» в поле To, то поле To в ответе должно совпадать с тем, что было в запросе.

В случае если поле To в запросе не содержит «tag»,  то URI в поле To ответа должен совпадать с URI в поле

To запроса; дополнительно, UAS должен добавить «tag» в поле To ответа (за исключением ответа с кодом 100

 (Trying), в котором «tag» может уже присутствовать). Тот же «tag» должен быть использован для всех ответов

на этот запрос, предварительных и окончательных (исключая ответ с кодом 100 (Trying)).

Действие UAS без сохранения состояний

UAS без сохранения состояний (stateless) – это UAS, который не запоминает состояния текущих транзакций.

Он нормально отвечает на запросы, но в отличие от UAS с сохранением состояний (stateful) не сохраняет состояния

транзакций после отправки ответов. Если stateless UAS получает повторно переданный запрос, он повторно

формирует ответ и повторно его отсылает так же, как это происходило при получении первого запроса. UAS

может быть stateless , только если обработка идентичных запросов одного типа приводит к генерации одинаковых

ответов. Stateless UAS не использует уровень транзакций: он принимает запрос напрямую от транспортного уровня

SIP и отправляет ответ также напрямую транспортному уровню.

Основная роль stateless UAS состоит в поддержке неаутентифицированных запросов, которые требуют передачи

ответа с запросом аутентификации. Если бы эти запросы поддерживались с сохранением состояния,

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

бы созданием большого числа транзакций, что в свою очередь могло бы замедлить или остановить обработку

 вызовов в UAS.

Наиболее важные функции stateless UAS перечислены ниже:

·        stateless UAS не должен отправлять предварительных (1xx) ответов

·        stateless UAS не должен повторно передавать ответы

·        stateless UAS должен игнорировать запросы ACK

·        stateless UAS должен игнорировать запросы CANCEL

·        параметры «tag» заголовка To должны формироваться для ответов таким образом – для одинаковых запросов

должна генерироваться одинаковые параметры «tag».

В остальном, stateless UAS работает так же как stateful UAS. Для каждого нового запроса UAS может выбрать, как

 работать – сохранением или без сохранения состояний.

2.2. Сообщения протокола SIP

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

Протокол SIP – это текстовый протокол, использующий набор символов ISO 10646 в кодировке UTF-8 (RFC 2279).

Сообщения протокола SIP представляют собой либо запрос от клиента серверу, либо ответ сервера клиенту.

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

символов и синтаксисе. Сообщения обоих типов состоят из:

·       стартовой строки;

·       одного или нескольких полей заголовков;

·       пустой строки, обозначающей конец полей заголовков;

·       тела сообщения (необязательно).

Рис 2.1 Структура сообщения протокола SIP

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

каретки и перевода строки (CRLF). Пустая строка должна быть независимо от того, присутствует тело сообщения

 или нет.

Стартовая строка представляет собой начальную строку любого SIP-сообщения. Если сообщение является

запросом, в этой строке указывается тип запроса, адресат и номер версии протокола. Если сообщение является

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

расшифровка, предназначенная только для пользователя.

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

 сведений, т.е. переносят необходимую для обслуживания данного сообщения информацию. О типе заголовка

 можно узнать из его имени. За исключением различий в наборе символов, многие SIP-сообщения и синтаксис

 полей заголовков схожи с используемыми в HTTP/1.1, хотя SIP и не является расширением HTTP.

Сообщения  протокола SIP могут содержать так называемое тело сообщения. В запросах ACK, INVITE и OPTIONS

тело сообщения содержит описание сеансов связи, например, в формате протокола SDP, а запрос BYE не содержит

тело сообщения.

2.2.2. Заголовки сообщений

Формат заголовка

Поля заголовков SIP-сообщений похожи на поля заголовков HTTP-сообщений по синтаксису и семантике.

В частности, SIP поля заголовков соответствуют описаниям синтаксиса HTTP/1.1 для заголовков сообщений и

правилам для расширения полей заголовков на несколько строк.

Каждое поле заголовка состоит из имени поля, символа «двоеточие» и значения поля:

   Имя поля: значение поля

Формальная грамматика для полей заголовков позволяет использовать любое количество пробелов (SP) для

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

и ограничиваются одним пробелом для отделения двоеточия от значения.

Subject:            уведомление

Subject      :      уведомление

Subject            :уведомление

Subject: уведомление

В приведенных выше примерах все строки равнозначны, но последняя предпочтительнее.

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

пробелом (SP) или символом горизонтальной табуляции (HT). Обрыв строки (line break) и пустое пространство

 (whitespase) расцениваются как один символ пробела SP. Следующие ниже строки эквивалентны.

Subject: Я знаю, что ты здесь, подними трубку!

Subject: Я знаю,

         что ты здесь,

         подними трубку!

Порядок следования заголовков не имеет значения. Однако рекомендуется размещать поля заголовков, которые

 требуются для обработки прокси-серверу (Via, Route, Record-Route, Proxy-Require, Max-Forwards, Proxy-Authorization

и другие), в начале сообщения для ускорения анализа и обработки. Важным является порядок следования ряда

заголовков с одинаковыми именами полей. Последовательности полей заголовков с одинаковыми именами могут

 содержаться в сообщении только в том случае, если содержимое поля представляет собой список значений,

 разделённых запятой. Возможно объединить такие заголовки в одну пару «имя поля: значение поля», не изменяя

семантики сообщения, путём добавления каждого последующего значения к первому значению поля заголовка;

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

WWW-Authenticate, Authorization, Proxy-Authenticate, и Proxy-Authorization. Последовательности заголовков с

 такими именами также могут присутствовать в сообщении, но объединить их невозможно, поскольку грамматика

данных заголовков не придерживается общих правил для SIP-заголовков.

            Реализации должны быть способны обработать последовательности заголовков с одинаковым именами

 со значениями, представленными как в форме последовательности, разделённой запятыми, так и в виде

 «одно значение на строку».

            Примеры последовательностей заголовков, приведённые ниже, правомерны и эквивалентны.

      Route: <sip:anton@niits.ru>

      Subject: Уведомление

      Route: <sip:vladimir@protei.ru>

      Route: <sip:alexander@loniis.ru>

      Route: <sip:anton@niits.ru>, <sip:vladimir@protei.ru>

      Route: <sip:alexander@loniis.ru>

      Subject: Уведомление

      Subject: Уведомление

      Route: <sip:anton@niits.ru>, <sip:vladimir@protei.ru>,

             <sip:alexander@loniis.ru>

Следующие последовательности заголовков правомерны, но не равнозначны.

      Route: <sip:anton@niits.ru>

      Route: <sip:vladimir@protei.ru>

      Route: <sip:alexander@loniis.ru>

      Route: <sip:vladimir@protei.ru>

      Route: <sip:anton@niits.ru>

      Route: <sip:alexander@loniis.ru>

      Route: <sip:anton@niits.ru>,<sip:alexander@loniis.ru>,

             <sip:vladimir@protei.ru>

Формат значения заголовка зависит от имени заголовка. Это всегда будет последовательность текстовых октетов

 в UTF-8 кодировке или комбинация символьных фраз (tokens), пустого пространства (whitespace), разделительных

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

формата для значений, основанного на последовательности пар имя параметра – значение параметра,

 разделённых знаком точка с запятой.  

Имя поля: значение поля; имя параметра=значение параметра; имя параметра=значение параметра…

            Несмотря на то, что заголовок может включать неограниченное число параметров, одно и то же имя

параметра не может использоваться более одного раза.

            Для имён полей заголовков не имеет значение, в каком регистре они написаны. Значения полей, имена

параметров и значения параметров также регистронезависимы, если это не определено по-иному в описании

определённого заголовка. Если не определено иначе, значения, заключённые в кавычки, являются зависимыми

от регистра. Например,

Contact: <sip:anton@niits.ru>;expires=3600

эквивалентно

CONTACT: <sip:anton@niits.ru>;ExPiReS=3600

и

Content-Disposition: session;handling=optional

эквивалентно

content-disposition: Session;HANDLING=OPTIONAL

Два следующих поля заголовков не равнозначны.

Warning: 370 niits.ru "Требуется большая пропускная способность"

Warning: 370 niits.ru "ТРЕБУЕТСЯ БОЛЬШАЯ ПРОПУСКНАЯ СПОСОБНОСТЬ"

Некоторые заголовки имеют смысл только в запросах или ответах. Они называются заголовками запроса и

заголовками ответа, соответственно. Если заголовок появляется в сообщении не своей категории

(например, заголовок запроса в ответе), то он игнорируется.

При передаче сообщений протокола SIP, упакованных в сигнальные сообщения протокола UDP, существует

 вероятность того, что размер запроса или ответа превысит максимально-допустимый размер для данной сети,

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

 подобно тому, как это делается в протоколе SDP.  Ниже приведен список таких заголовков.

Таблица 2.1 Сжатые имена заголовков

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

·       Accept

Заголовок Accept сообщает, тела сообщений каких типов, принимает клиент. Серверное приложение, которое может

 возвращать содержимое тела в разных форматах, должно проверить содержимое поля заголовка, чтобы принять

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

значений в заголовке Accept информирует  о том, что не поддерживаются никакие типы. Если в сообщении нет

 заголовка Accept, то сервер должен применить значение по умолчанию - application/sdp.

Accept: application/sdp;level=1, application/x-private, text/html

·       Accept-Encoding

Заголовок Accept-Encoding похож на Accept, он сообщает о поддерживаемых типах кодирования содержимого в

ответе. Наличие пустого заголовка в сообщении также допускается. Это равнозначно:  Accept-Encoding: identity,

 что значит: кодирование запрещено. Если заголовок отсутствует в сообщении, сервер устанавливает значение

по умолчанию - identity. В этом заключается некоторое расхождение с протоколом HTTP, где в случае отсутствия

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

предпочтительнее.

Пример:

Accept-Encoding: gzip

·       Accept-Language

Заголовок Accept-Language используется в запросах, чтобы указать предпочтительные языки для ключевых фраз,

 описаний сеансов связи, оповещений о текущем состоянии, содержащихся в ответах в качестве тел сообщения.

В случае если заголовок отсутствует, сервер устанавливает, что клиент поддерживает все языки.

Правило упорядочивания языков в списке по предпочтительности базируется на параметре «q». Пример: 

Accept-Language: da, en-gb;q=0.8, en;q=0.7

·       Alert-Info

Заголовок Alert-Info, присутствующий в запросе INVITE, предписывает использование альтернативного сигнала

вызова для UAS. Когда заголовок содержится в ответе с кодом 180 (Ringing), он устанавливает альтернативный

сигнал КПВ для UAC. В основном этот заголовок вставляется прокси-сервером для обеспечения функции

отличительного звукового сигнала вызова. Пользователь должен иметь возможность отключить эту функцию.

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

 с которыми не были установлены доверительные отношения. Пример:  

Alert-Info: <http://www.niits.ru/sounds/moo.wav>

·       Allow

Заголовок Allow cодержит список типов запросов, поддерживаемых агентом пользователя, сформировавшим

сообщение. Все типы запросов, понимаемые UA, включая ACK и CANCEL, должны входить в этот список.

Отсутствие заголовка Allow не означает, что отсылающий сообщение UA не поддерживает никаких типов запросов;

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

запросов он поддерживает.  

Применение заголовка Allow в ответах на запросы (за исключением ответов на запрос OPTION) приводит к

 уменьшению числа передаваемых сообщений. Пример:

Allow: INVITE, ACK, OPTIONS, CANCEL, BYE

·       Allow-Events

Заголовок Allow-Events в случае присутствия содержит список, состоящий из идентификаторов функциональных

возможностей для информирования клиента о событиях определённого типа - event package, поддерживаемых

 клиентом (если посылается в запросе) или сервером (если посылается в ответе). Другими словами, оконечная точка,

 отсылающая заголовок Allow-Events, информирует, что она может  обрабатывать запросы SUBSCRIBE и создавать

 запросы NOTIFY для всех типов событий, идентифицированных с помощью event package в заголовке.

Терминал, поддерживающий один или несколько event package, должен помещать соответствующий заголовок

Allow-Events, указывающий все поддерживаемые типы событий (events), во все типы запросов, которые инициируют

 диалог, такие как INVITE, и в ответы на них, а также в ответы на запрос OPTIONS.

Заметим, что заголовок Allow-Events не должен вставляться прокси-серверами. Пример:

Allow-Events: refer

·       Authentication-Info

Заголовок Authentication-Info используется для взаимной аутентификации с использованием системы аутентификации

 HTTP Digest. UAS может включить данный заголовок в ответ класса 2хх на запрос, который был успешно

аутентифицирован, с использованием значения отклика, содержащимся в заголовке Authorization. Пример:

Authentication-Info: nextnonce="47364c23432d2e131a5fb210812c"

·       Authorization

Поле заголовка  Authorization содержит отклик аутентификации агента пользователя. Этот заголовок вместе с

заголовком Proxy-Authorization отступает от общих правил, касающихся множественности значений в поле

заголовка. Эти правила описаны в начале данного раздела. Заголовки с одинаковыми именами могут присутствовать

 в сообщении в любом количестве, но не могут объединяться в один общий заголовок, как это происходит с прочими

 заголовками. Более подробная информация о заголовке содержится  в разделе 2.6.3.

Authorization: Digest username="Anton", realm="niits.ru",

nonce="84a4cc6f3082121f32b42a2187831a9e",

response="7587245234b3434cc3412213e5f113a5432"

·       Call-ID

Заголовок Call-ID – уникальный идентификатор сеанса связи или всех регистраций отдельного клиента.

Значение идентификатору присваивает сторона, которая инициирует вызов. Возможна и такая ситуация:

к одной мультимедийной конференции относятся несколько соединений – все они будут иметь разные

идентификаторы Call-ID.

Заголовок состоит из буквенно-числового значения и имени рабочей станции, которая присвоила этому

идентификатору. Между ними должен стоять символ «@». Значения Call-ID регистрозависимы и могут

сравниваться побайтно. Примеры:

Call-ID: f81d4fae-7dec-11d0-a765-00a0c91e6bf6@loniis.ru

i:f81d4fae-7dec-11d0-a765-00a0c91e6bf6@192.0.2.4

·       Call-Info

Заголовок Call-Info содержит дополнительную информацию о вызывающем или вызываемом пользователе в

зависимости от того, где находится заголовок: в запросе или в ответе. Назначение URI, содержащегося в заголовке, описывается параметром «purpose». Значение этого параметра icon определяет изображение, предназначенное для визуального представления вызывающего или вызываемого пользователя. Значение info даёт общее описание пользователя, например, с помощью web-страницы. Значение card определяет электронную визитную карточку, содержащую имя пользователя, организацию, номер телефона, адрес электронной почты и т.д., например, карту формата Vcard ("vCard MIME Directory Profile", RFC 2426) или LDIF ("The LDAP Data Interchange Format (LDIF) – Technical Specification", RFC 2849).

Использование заголовка Call-Info может представлять угрозу безопасности пользователя.

Если вызываемый пользователь воспользуется URI, приведёнными злонамеренным пользователем, то он может

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

 Поэтому, рекомендуется, чтобы UA представлял информацию в Call-Info только в том случае, если может

удостоверить подлинность SIP элемента, создавшего заголовок, и доверяет этому SIP элементу.

 Этот элемент не обязательно должен быть UA; заголовок может быть вставлен в запрос прокси-сервером.

 Пример:    

Call-Info: <http://www.serv1.niits.ru/anton/photo.jpg> ;purpose=icon,

           <http://www.serv1.niits.ru/anton/> ;purpose=info

·       Contact

Поле заголовка Contact несёт в себе URI, значение которого зависит от типа передаваемого запроса или ответа.

 Как правило в заголовке Contact находится текущий адрес пользователя, на который он может принимать входящие

сообщения. Заголовок Contact может содержать отображаемое имя (display name), адрес с его параметрами и

параметры заголовка.

Для заголовка Contact определены параметры «q» и «expires». Они используются только в случае, когда заголовок

присутствует в запросе REGISTER, ответе на него или в ответе класса 3хх.

Когда значение поля заголовка содержит отображаемое имя, URI со всеми его параметрами заключается в символы

«<» и «>». В противном случае все параметры, следующие за URI, будут трактоваться как параметры заголовка.

Отображаемым именем может быть комбинацией символьных фраз или строка, заключённая в кавычки, когда

существует необходимость в более длинной характеристике.

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

 даже если отображаемое имя отсутствует. Между отображаемым именем и «<» допускается наличие линейного

пробела (LWS). Эти правила действительны также в отношении заголовков To и From.

Заголовок Contact выполняет роль, похожую на роль заголовка Location в HTTP.  Однако заголовок протокола HTTP

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

запятой в качестве скрытых знаков, они могут быть приняты за разграничители значений заголовков или параметров

 соответственно.

Пример:   

Contact: "Alexander" <sip:alexander@loniis.ru>

         ;q=0.7; expires=3600,

         "Alexander" <mailto:alexander@loniis.ru> ;q=0.1

·       Content-Disposition

Заголовок Content-Disposition описывает, как будет интерпретироваться клиентом или сервером агента пользователя

тело сообщения, или - для тел сообщений типа multipart (состоящих из нескольких частей) - часть тела сообщения.

Этот SIP заголовок дополняет информацию о типе тела сообщения, содержащуюся в заголовке Content-Type.

В протоколе SIP определено несколько значений для заголовка Content-Disposition. Значение session указывает,

что часть тела описывает сессию для вызова любой из двух сторон или для одностороннего проключения речевого

тракта в предответном состоянии. Значение render означает, что часть тела сообщения должна быть отражена на

дисплее или другим образом представлена пользователю. Если заголовок Content-Disposition утерян, то сервер

должен  для тел сообщения типа application/sdp определять значение Content-Disposition – session, а для тел

остальных типов - значение render.

Значение icon указывает на то, что часть тела сообщения содержит изображение, пригодное для визуального

представления вызывающего или вызываемого пользователя; это изображение может быть использовано UA для

визуального информирования пользователя о полученном сообщении, помимо этого оно может удерживаться во

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

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

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

телефонного вызова после того, как  был отослан предварительный ответ с кодом 180 (Ringing).

Любые MIME тела со значением заголовка Content-Disposition, которое предписывает передачу содержимое

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

Параметр «handling-param» описывает действия UAS при получении сообщения с непонятными  значениями

заголовков Content-Disposition и Content-Type. Для этого параметра существуют значения: optional и required.

Если значение параметра «handling-param» отсутствует, то по умолчанию должно подразумеваться значение

 required.   

В случае если заголовок Content-Disposition отсутствует, MIME-тип обуславливает значение по умолчанию для

Сontent-Disposition. В противном случае выставляется значение render. Пример:

     Content-Disposition: session

·       Content-Encoding

Заголовок Content-Encoding используется в качестве модификатора типов тела сообщения. Когда данный заголовок

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

соответственно какие следует применить механизмы декодирования для получения тела сообщения типа,

обозначенного в поле заголовка Content-Type.

Первостепенно Content-Encoding предназначен для того, чтобы обеспечить компрессию тела сообщения с

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

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

регистронезависимы.

Клиент может закодировать содержимое тела в запросах. Сервер может закодировать содержимое тела в ответах.

Причём, UAS должен использовать только типы кодирования, которые были перечисленные в поле заголовка 

Accept-Encoding запроса.

Пример:

Content-Encoding: gzip

·       Content-Language

Основное назначение заголовка Content-Language – определить и изменить содержимое тела сообщения в

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

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

Content-Language в сообщении подразумевается, что содержимое предназначено для пользователей любых

языковых групп. 

Заголовок Content-Language может применяться не только к текстовым телам, но и к телам других типов. 

Пример:

Content-Language: fr

·       Content-Length

Заголовок Content-Length указывает отображённый в десятичном виде размер тела сообщения, посланного

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

 не взирая на тип тела сообщения. Если в качестве транспорта выступает потоко-ориентированный протокол

(такой как TCP), заголовок Content-Length должен использоваться обязательно.  

Размер тела сообщения не учитывает пустой строки, отделяющей заголовки от тела сообщения. Разрешёнными

значениями для Content-Length является любое число, большее или равное нулю. Когда в передаваемом сообщении

тело отсутствует, в поле заголовка Content-Length выставляется ноль.  

Возможность не включать заголовок Content-Length в сообщение упрощает создание cgi-подобных сценариев,

которые динамически генерируют ответы.

Пример:

      Content-Length: 349

·       Content-Type

Заголовок Content-Type определяет тип тела сообщения, посланного получателю. Content-Type должен входить в

сообщение, если тело сообщения не пустое. Если же тело пустое, а Content-Type присутствует, он показывает,

что тело определённого типа имеет нулевую длину (например, пустой аудио-файл).

Примеры:

     Content-Type: application/sdp

c: text/html; charset=ISO-8859-4

·       CSeq

Заголовок CSeq - уникальный идентификатор запроса, относящегося к одному соединению. Он служит для корреляции

 запроса с ответом на него, а также для различия первоначальных запросов с переадресованными.

 Заголовок состоит из двух частей: натурального числа из диапазона чисел от 1 до 2³² и типа запроса.

Часть типа запроса является регистрозависимой. Сервер должен проверять значение величины CSeq в

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

из запроса в ответ.

Пример:

   CSeq: 4711 INVITE

·       Date

Заголовок Date содержит дату и время первой отправки сообщения. В отличие от HTTP/1.1, протокол SIP

 поддерживает самый новейший, среди описанных в RFC 1123, формат даты, он переводит любой часовой пояс к

стандарту GMT, хотя  RFC 1123 не запрещает использовать другие форматы. Поле заголовка Date может быть

 использовано любой оконечной системой без встроенных часов с автономным батарейным питанием для получения

информации о текущем времени. Однако это требует знания клиентами отклонения своих часовых поясов от GMT. 

Пример:

                         Date: Sat, 13 Nov 2010 23:29:00 GMT

·       Error-Info

Заголовок Error-Info является указателем на дополнительную информацию об ответе, содержащем код ошибки.

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

программном клиенте на ПК до функции предоставления аудио для оконечных точек, соединённых через шлюзы.

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

ошибки и указанием причины, и воспроизведением звукового сигнала, существует возможность предусмотреть оба

 варианта в поле заголовка Error-Info. Впоследствии клиент самостоятельно решает, какой тип индикации ошибки

 предоставить вызывающему пользователю.

UAC обрабатывает SIP или SIPS URI в поле заголовка Error-Info также, как контактный адрес в заголовке Contact

перенаправляющего сообщения, и может сгенерировать новое сообщение INVITE, направляемое автоинформатору.

 Автоинформатор, предоставляющий вызывающему пользователю записанное уведомление, может находиться по

 адресу, использующему  схему адресации, отличную от «sip», например «tel».

Примеры:

                  SIP/2.0 404 The number you have dialed is not in service

        Error-Info: <sip:not-in-service-recording@niits.ru>

·       Event

В заголовке должен быть указан ровно один тип события (представленный в виде идентификатора - event package),

 на которое осуществляется подписка (subscription) или передаётся уведомление (notification).

В целях обеспечения соответствия сообщений NOTIFY и SUBSCRIBE значение типа события («event-type») и параметр

 «id» (в случае присутствия) сравниваются побайтно. Заголовок Event, содержащий параметр «id», никогда не будет

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

 не учитываются.

Пример.

Event: refer; id=1234

·       Expires

Заголовок Expires устанавливает время, по истечении которого сообщение или его содержимое станет

недействительным. Конкретное значение заголовка зависит от типа запроса.  Присутствует в запросах

REGISTER и INVITE. В запросе REGISTER указывает, сколько времени регистрация остается действительной.

В запросах INVITE он ограничивает количество времени, в течение которого URI будет оставаться действительным

на приемнике - оставаться в кэш-памяти. Если этот заголовок отсутствует, на сервере не будет осуществляться

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

 между 0 и (2³² –1), измеренное с момента получения запроса.

Пример:

                  Expires: 5

·       From

Заголовок From содержит URI отправителя запроса. Заметим, что адрес отправителя запроса может не совпадать с

 адресом инициатора диалога. Адрес из заголовка From запроса копируется  в одноимённый заголовок ответа.

Отображаемое имя должно информировать пользователя об инициаторе запроса. В случае если не удаётся

 установить личность вызывающего пользователя,  в качестве display name (отображаемого имени) фигурирует

«Anonymous».  В случае, если URI содержит запятую, точку с запятой или вопросительный знак, он заключается

в угловые скобки, даже если отображаемое имя отсутствует.

Два заголовка From считаются эквивалентными, когда совпадают их URI и параметры. При сравнении параметры

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

 что отображаемое имя и наличие либо отсутствие угловых скобок не влияют на результат сравнения.

Примеры:

    From: "Vladimir" <sip:vladimir@protei.ru> ;tag=a48s

    From: sip:+79213434329@gateway.protei.ru;tag=887s

·       In-Reply-To

В поле заголовка In-Replay-To перечисляются уникальные идентификаторы сеансов связи (Call-ID),

инициированных отправителями с данным пользователем. Эти идентификаторы по мере поступления буферизируются

 клиентом и впоследствии включаются в поле заголовка In-Replay-To в ответном вызове. Это позволяет системам

автоматического распределения вызовов маршрутизировать ответный вызов инициатору первого звонка.

Также это даёт возможность вызываемым пользователям отфильтровывать вызовы т.е. принимать только ответные

 вызовы от пользователей, с которыми ранее осуществлялись сеансы связи, инициированные самим вызываемым

пользователем. Однако, этот заголовок не является заменой аутентификации в запросах. 

Пример:

In-Reply-To: 70710@lonis.ru, 17320@loniis.ru

·       Max-Forwards

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

 через которые проходит запрос. Значение заголовка должно быть целым числом в пределах от 0 до 255,

отражающим оставшееся количество пересылок, которое разрешено осуществить сообщению.

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

значения рекомендуется брать 70.

Заголовок Max-Forwards должен вставляться теми элементами, которые иначе не могут гарантировать обнаружение

 петли.

Пример:

                  Max-Forwards: 6

·       Min-Expires

Заголовок Min-Expires несёт в себе минимальный период обновления, который подходит для управляемых сервером

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

которое сохраняет регистрирующий сервер registrar. Поле заголовка содержит десятичное целое число секунд

от 0 до (2³² –1). Заголовок используется в ответе 423 (Interval Too Brief).

Пример:

         Min-Expires: 60

·       MIME-Version

Заголовок MIME-Version указывает версию стандарта MIME-информации,  помещённой в тело сообщения.

Пример:

          MIME-Version: 1.0

·       Organization

Заголовок Organization содержит название организации, к которой относится SIP-элемент, выдающий запросы или

ответы. Это поле заголовка может использоваться клиентским программным обеспечением для фильтрации вызовов.

Пример:

             Organization: Niits

·       Path

Между UA и сервером регистрации, исходя из особенностей топологии сети, может находиться один или несколько

 прокси-серверов. Запрос REGISTER должен проходить через эти прокси-серверы. Однако REGISTER не обеспечивает

механизма по обнаружению и записи последовательности этих посредников для дальнейшего использования.

Такой механизм  предоставляет заголовок Path. Заголовок используется в запросах REGISTER и ответах класса

2хх на них.

Поле заголовка Path может быть добавлено в запрос REGISTER любым SIP элементом, через который проходит

запрос. Значения заголовка Path размещаются в чёткой последовательности: по мере продвижения

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

Кроме того, также как в заголовке Route поля заголовка могут быть объединены. Сервер регистрации отображает в

 заголовке ответа на REGISTER все значения в обратном порядке, и указанные посредники доставляют ответ обратно

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

и может в дальнейшем использовать её для своих задач.

Path отличается от Record-Route тем, что заголовок Path применяется в запросах REGISTER и ответах класса 2хх на

 него, которые передаются вне диалога в то время, как заголовок Record-Route используется только в режиме

 диалога. Более того, информация из  Record-Route используется только в рамках существующего диалога,

 а информация из Path – для использования в будущих диалогах.

Значения заголовка Path придерживаются синтаксиса, определённого для заголовка Route.

Поскольку заголовок Path является расширением SIP, поддержка этого заголовка агентом пользователя может

быть указана с помощью option-tag «path» в заголовке Supported. Пример:

Path: <sip:P3.niits.ru;lr>,<sip:P1.niits.ru;lr>

·       Priority

Заголовок Priority указывает на срочность запроса с точки зрения клиента. В нём содержится приоритет

 SIP-запроса для конечного пользователя или его UA. К примеру, содержимое поля данного заголовка влияет на

маршрутизацию вызова и процесс принятия его сервером. Сообщения, не содержащие заголовка Priority,

 расцениваются, как сообщение с приоритетом normal. Заголовок Priority никаким образом не воздействует на

использование коммуникационных ресурсов, например, на приоритет при пересылке пакетов маршрутизаторами.

Поле заголовка может содержать значения: non-urgent (несрочное), normal (нормальное), urgent (срочное) и

 emergency (экстренное); могут быть определены и  дополнительные значения. Рекомендуется, чтобы значение

emergency выставлялось только в случае экстренных вызовов на соответствующие службы.

Примеры: 

        Subject: У нас случился пожар!

        Priority: emergency

   или

        Subject: Планы на выходные

        Priority: non-urgent

·       Privacy

Существуют SIP-заголовки, содержимое которых агент пользователя не может самостоятельно скрыть от просмотра

 другими элементами сети, например зашифровать, поскольку их использование необходимо для маршрутизации

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

пользователю, активировавшему функцию анонимности. Агент пользователя должен иметь средства для того,

чтобы запросить такие сервисы обеспечения анонимности (privacy services). Для этой цели используется заголовок

Privacy. UA помещает в сообщение заголовок Privacy, когда существует необходимость воспользоваться сервисами

 анонимности, предоставляемыми сетью.

На сегодняшний день в поле заголовка могут находиться значения: header, session, user, none, critical. Значение

header означает, что пользователь запрашивает сокрытие тех заголовков (таких как Via и Contact), которые не могут

 быть полностью удалены из раздела идентифицирующей информации без вмешательства посредников.

Значение session означает, что пользователь запрашивает анонимность для сессии (сессий), описание которой,

например, содержится в SDP-теле, инициированной этим сообщением. Выполнение этого запроса приведёт к тому,

 что IP-адрес, с которого будет поступать трафик в ходе сессии, окажется замаскированным. Значение  user обычно

 выставляется теми прокси-серверами, у которых есть предварительная договорённость с пользователем для того,

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

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

помещать значение user только в запросы REGISTER. Значение none указывает, что выполнение функций по

обеспечению анонимности не требуется. Значение  critical сообщает, что функции по обеспечению анонимности

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

Когда заголовок сформирован, он должен состоять или из значения none или одного или более значений  user, header

и session, каждое из которых может быть указано единожды; значение (значения) может сопровождаться

индикатором  critical.

Privacy: none

·       Proxy-Authenticate

Заголовок Proxy-Authenticate содержит запрос аутентификации, состоящий из поля, отображающего схему

аутентификации, и ряд параметров, необходимый для проведения процедуры аутентификации с данным

прокси-сервером  для указанного Request-URI. Данный заголовок включается в состав ответа с кодом 407

(Proxy Authentication Required) или с кодом 401 (Unauthorized). Более подробная информация о заголовке

содержится  в разделе 2.6.3.

Пример:

        Proxy-Authenticate: Digest realm="niits.ru",

        qop="auth", nonce="f84f1cec41e6cbe5aea9c8e88d359",

        opaque="", stale=FALSE, algorithm=MD5

·       Proxy-Authorization

Заголовок Proxy-Authorization идентифицирует пользователя прокси-серверу, который требует аутентификации.

 Значение поля заголовка состоит из отклика аутентификации, содержащего информацию аутентификации агента

пользователя для прокси-сервера, обслуживающего область запрашиваемого ресурса. Если запрос

идентифицирован и область специфицирована, та же самая идентификационная информация может быть

 использована для других запросов, направляемых в данную область.

Proxy-Authorization  вместе с заголовком Authorization отступают от общих правил, касающихся множественности

 значений в поле заголовка. Заголовки с одинаковыми именами могут присутствовать в сообщении в любом

 количестве, но не могут объединяться в один общий заголовок, как это происходит с прочими заголовками. 

Более подробная информация о заголовке содержится  в разделе 2.6.3.

Пример:

  Proxy-Authorization: Digest username="Anton", realm="niits.ru",

  nonce="c60f3082ee1212b402a21831ae",

  response="245f23415f11432b3434341c022"

·       Proxy-Require

Заголовок Proxy-Require указывает функции прокси-сервера, которые должны им поддерживаться.

Пример:

                       Proxy-Require: 100rel

·       P-Asserted-Identity

Заголовок P-Asserted-Identity используется в сообщениях между логическими элементами SIP, между которыми

 существуют доверительные отношения (обычно между посредниками), для переноса информации,

удостоверяющей пользователя (как правило его публичного адреса). Значение заголовка состоит из URI и

 опционального отображаемого имени. URI может иметь схему sip, sips, или tel. Также возможно присутствие двух

значений в заголовке; тогда одно из них должно быть со схемой sip или sips, а второе – со схемой tel. Использование

 данного заголовка целесообразно только в пределах домена доверия (Trust Domain).

Прокси-сервер в домене доверия может получить сообщение от узла, с которым у него установлены доверительные

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

 P-Asserted-Identity, он должен произвести процедуру аутентификации инициатора сообщения и после этого 

 поместить полученную информацию, идентифицирующую пользователя, в поле заголовка P-Asserted-Identity

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

 информацию в заголовке P-Asserted-Identity, как если бы она аутентифицировала пользователя.

Прокси-сервер, отсылающий сообщение прокси-серверу или UA, c которым  у него не установлены доверительные

 отношения, должен удалить все значения заголовка P-Asserted-Identity, если вызывающий пользователь запросил

 обеспечение секретности для своей информации. Пример:

  P-Asserted-Identity: "Anton" <sip:anton@niits.ru>

  P-Asserted-Identity: tel:+79213434329

·       P-Preferred-Identity

Заголовок P-Preferred-Identity используется в сообщениях, которые агент пользователя отправляет

 прокси-серверу, с которым у него установлены доверительные отношения. Заголовок переносит информацию,

удостоверяющую пользователя, которую инициатор сообщения желает использовать в качестве значения

заголовка P-Asserted-Identity, которое  пользующийся доверием элемент вставит в сообщение. Заголовок

P-Preferred-Identity может состоять из одного значения и иметь схему sip, sips, или tel. Также возможно

присутствие двух значений в заголовке; тогда одно из них должно быть со схемой sip или sips, а второе – со схемой

tel. Пример.

P-Preferred-Identity: "Anton" <sip:anton@niits.ru>

·       P-Media-Authorization

Заголовок P-Media-Authorization предназначен для контроля доступа к услуге обеспечения QoS средствами SIP.

 Использование данного заголовка способствует предотвращению атак типа denial-of-service (отказ в обслуживании). Конечно для такой цели могло быть использовано тело сообщения, но при этом отсутствовала бы возможность сквозного шифрования тела. Заголовок P-Media-Authorization включается в сообщение прокси-сервером, осуществляющим контроль доступа к QoS, во все предварительные ответы (кроме ответа с кодом 100), первый надёжный 1хх или 2хх ответ и во все повторные передачи этого надёжного ответа для UAС или в запрос INVITE, ACK, UPDATE и PRACK - для UAS.

Заголовок P-Media-Authorization содержит один или более идентификаторов для предоставления доступа к QoS.

UA использует все идентификаторы из последнего полученного запроса/ответа от прокси-сервера,

предоставляющего доступ к QoS, при запросе резервирования ресурсов для медиапотоков, используемых в

ходе сессии (в случае использования протокола RSVP совместно с SIP идентификаторы, полученные в заголовке

 P-Media-Authorization  используются в сообщении PATH). Эти идентификаторы используются для

 санкционирования применения QoS для медиапотока (потоков). Заголовок P-Media-Authorization может быть

 использован только в SIP запросе или ответе, который допускает наличие offer или answer в теле сообщения

(SDP-предложение или SDP-ответ с  описанием сеанса связи). 

·       The P-Associated-URI

Этот заголовок, являясь расширением SIP, позволяет регистрирующему серверу возвращать агенту пользователя

список существующих контактных адресов для конкретного зарегистрированного публичного адреса. Заголовок

 P-Associated-URI содержится в ответе с кодом 200 (OK) на запрос REGISTER и содержит список контактных адресов.

Если registrar поддерживает данное расширение, он должен всегда вставлять заголовок P-Associated-URI в ответ

 200 (OK) на REGISTER не зависимо от того, какую процедуру осуществлял UA пользователя: регистрацию,

изменение регистрации или удаление регистрации и не зависимо от числа зарегистрированных контактных

 адресов для публичного адреса.

·       P-Called-Party-ID

Заголовок P-Called-Party-ID помещает прокси-сервер (обычно в запрос INVITE). В заголовок заносится значение

поля Request-URI из полученного прокси-сервером запроса (Это происходит до замены начального Request-URI

контактным адресом). В Request-URI, как известно, содержится публичный адрес вызываемого пользователя.

Поэтому, изучая содержимое заголовка P-Called-Party-ID, UAS определяет на какой публичный адрес было послано

 приглашение (например, пользователь может одновременно использовать личный и рабочий публичные адреса

для принятия приглашений к сеансу связи). Сервер может использовать эту информацию, для подачи пользователю

различных аудиовизуальных вызывающих сигналов в зависимости от того, на какой из публичных адресов

пользователя пришёл вызов. Пример. 

P-Called-Party-ID: sip:anton-work@niits.ru

·       P-Visited-Network-ID

Сети, построенные в соответствии с 3GPP (3^rd Generation Partnership Progect), предусматривают так называемые

домашние сети (home network) и сети временного пребывания (visited network). Каждая домашняя сеть должна

 иметь роуминговые соглашения (roaming agreements) с одной или несколькими сетями временного пребывания.

 Наличие таких соглашений позволяет мобильному терминалу, покинувшему домашнюю сеть, использовать

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

Одним из условий домашней сети для принятия сообщения регистрации от UA, переместившегося в одну из сетей

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

пребывает UA. Чтобы проверить это условие, необходимо передать информацию о сети временного пребывания

домашней сети. При наличии соглашений с сетью временного пребывания домашняя сеть предоставит

«блуждающему» UA требуемые сервисы.

Заголовок P-Visited-Network-ID используется для доставки идентификатора сети, где временно находится UA,

для сервера регистрации или домашнего прокси-сервера (home proxy); заголовок включает в запрос прокси-сервер

сети временного нахождения. Этот идентификатор должен быть известен и серверу регистрации, и домашнему

прокси-серверу домашнего домена, и прокси-серверам в сети временного нахождения UA. Как правило, заголовок

P-Visited-Network-ID используется для запроса REGISTER, хотя может применяться и в других запросах.

Для того, чтобы предотвратить конфликты, связанные с дублированием идентификаторов, значение заголовка

P-Visited-Network-ID должно выбираться с осторожностью. Идентификатор должен быть уникален в глобальном

масштабе. Пример.

P-Visited-Network-ID: "Visited network number 1"

·       P-Access-Network-Info

Когда  UA создаёт SIP запрос или ответ, и знает, что он  будет надёжно (с подтверждением) отослан SIP

прокси-серверу, который предоставляет услуги данному UA, он вставляет в сообщение заголовок

 P-Access-Network-Info. Этот заголовок содержит информацию о сети доступа, которую использует UA

для осуществления IP-взаимодействия. Как правило, заголовок игнорируется прокси-серверами, находящимися

между UA и SIP прокси-сервером, предоставляющим услуги. Прокси-сервер, предоставляющий услуги, может

 проверить заголовок P-Access-Network-Info и использовать информацию, содержащуюся там, для предоставления

услуг определённого типа в зависимости от значения заголовка. Некоторые услуги более или наоборот менее

 подходят для пользователя в зависимости от типа доступа; также некоторые услуги могут быть предоставлены с

бульшим качеством, когда прокси-сервер владеет детальной информацией о сети доступа (поскольку могут быть

адаптированы под конкретного пользователя). Перед тем, как переслать запрос дальше, этот прокси-сервер

удаляет заголовок  P-Access-Network-Info из сообщения. UA, предоставляющий информацию должен доверять

прокси-серверу, который предоставляет сервисы – только в этом случае гарантируется, что прокси-сервер

удалит заголовок перед пересылкой за пределы домена, в котором находится прокси-сервер и тем самым не

нарушит секретности переданной информации. Такой прокси-сервер обычно находится в домашней сети.  

·       P-Charging-Function-Addresses

В процесс предоставления доступа и обеспечения услуг вовлечено множество элементов распределенной

архитектуры сети. Существует необходимость передать каждому SIP прокси-серверу, вовлечённому в транзакцию,

  информацию об адресе элементов SIP сети, решающих задачи по начислению платы. Это требуется для передачи

 на них записей сгенерированных прокси-серверами. 

В 3GPP архитектуре определено два типа функциональных элементах, занимающихся начислением платы: Charging

Collection Function (CCF) и Event Charging Function (ECF). CCF используется при кредитной системе расчетов

 (postpaid),  ECF используется при авансовой системе (prepaid).

SIP прокси-сервер, который получает SIP запрос, может поместить в него заголовок P-Charging-Function-Addresses

перед тем как осуществить пересылку запроса, это возможно только если в запросе не было заголовка с таким

названием. Заголовок состоит из списка адресов одного или более элементов сети, ведущих начисление платы

ССF или ECF, куда прокси-сервер должен отослать информацию, касающуюся начисления платы. Прокси-сервер,

получивший сообщение с таким заголовком также будет знать, по какому адресу передавать записи, содержащие

 информацию для начисления платы. Агенты пользователя не должны осуществлять работу с данным заголовком.

 Пример.

P-Charging-Function-Addresses: ccf=192.1.1.1; ccf=192.1.1.2;

                                     ecf=192.1.1.3; ecf=192.1.1.4

• P-Charging-Vector

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

координации действий сетевых элементов, таких как прокси-серверы, что выражается в корреляции записей

для начисления платы, сгенерированных разными элементами сети SIP, но относящихся к одной сессии.

 Корреляционная информация включает уникальный глобальный идентификатор (вектор) начисления платы,

который значительно упрощает билинговые функции.

Идентификатор начисления платы определён, как совокупность информации о начислении платы. Информация

может быть помещена в идентификатор несколькими сетевыми элементами (включая SIP прокси-серверы) и ими же

удалена. В идентификаторе содержится три типа корреляционной информации: значение IMS Charging Identity (ICID),

 адрес прокси-сервера, который создал это значение ICID и  Inter Operator Identifiers (IOI). ICID – значение,

идентифицирующее диалог или транзакцию вне диалога в целях начисления платы. Оно используется для

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

 должен включать две компоненты: локальное уникальное значение и доменное имя или IP-адрес SIP прокси-сервера,

 сгенерировавшего локальное значение. IOI идентифицирует обе сети, в которых находятся участники диалога или

 транзакции вне диалога.

Для переноса идентификатора определён заголовок  P-Charging-Vector. SIP прокси-сервер в случае отсутствия

заголовка P-Charging-Vector может поместить его самостоятельно в начальный запрос или ответ для диалога с

теми параметрами, которые ему доступны. SIP прокси-сервер, который получает запрос, содержащий заголовок

 P-Charging-Vector, может использовать значение ICID при создании новых записей для начисления платы.

Заголовок используется либо в пределах частного административного домена, либо между доменами, между

которыми установлены доверительные отношения. Пример.

P-Charging-Vector: icid-value=1234bc9876e;

                         icid-generated-at=192.0.6.8;

                         orig-ioi=home1protei.ru

·       P-DCS-Trace-Party-ID

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

пришедшего запроса - Сustomer originated trace, которая обеспечивают вызываемой стороне возможность

обратиться к правоохранительным органам в случае злонамеренного телефонного вызова. В SIP эта услуга может

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

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

определения информации, идентифицирующей пользователя не пользующегося доверием UAC, в  запрос INVITE

  помещается дополнительный заголовок P-DCS-Trace-Party-ID. Заголовок P-DCS-Trace-Party-ID не присутствует в

 других запросах и ответах.

Элемент, адресованный значением поля Request-URI, выполняет определённые поставщиком услуг функции записи

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

находится в заголовке P-DCS-Trace-Party-ID. UAC, с которым установлены доверительные отношения, не использует

 заголовок P-DCS-Trace-Party-ID.

• P-DCS-OSPS

Некоторые вызовы имеют особые требования к обработке, которые не могут быть удовлетворены обычными

агентами пользователя. Например, когда пользователь занят вызовом, а в это время приходит другой вызов,

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

операторами ТфОП, требуют особой обработки вызовов. В том числе сервисы «Проверка занятости линии» (BLV)

 и «Вмешательство в разговор в случае необходимости» (EI), инициированные оператором с Operator Services

 Position System (OSPS) на ТфОП. Для того, чтобы проинформировать SIP агента пользователя, что входящему

вызову должно быть придано особое значение, используется заголовок P-DCS-OSPS. Его значение указывает

на то, что запрашивается определённый способ обработки вызова.

На данное время существует три значения для данного заголовка: BLV (busy line verification), EI (emergency interrupt)

 и RING (operator ringback). Если при получении запроса INVITE, содержавшего в заголовке P-DCS-OSPS значение BLV

или EI,   пользователь решил принять вызов, UAS передаёт UAC ответ, c кодом,  указывающим на незанятость

абонента. Так как значения EI и RING передаются только в установленных диалогах они могут появляться в

запросах UPDATE. Заголовок P-DCS-OSPS не может быть послан в запросе от UAC, не пользующегося доверием.

Как правило заголовок вставляется контроллером медиа-шлюза (Media Gateway Controller). Пример.

P-DCS-OSPS: BLV

·       P-DCS-BILLING-INFO

В процессе предоставления услуг требуется производить сбор биллинговой информации и её доставку биллинговой

системе. Эту функцию может выполнить SIP прокси-сервер. Более того, прокси-серверы задействованные в вызове,

 между которыми существуют доверительные отношения, могут обмениваться биллинговой информацией,

относящейся к участникам вызова. Для записей об изменении состояния баланса (Accounting records)  необходимо

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

Заголовок P-DCS-BILLING-INFO содержит идентификатор, который может быть использован устройством,

 генерирующим учётные записи, для ассоциирования записей различного назначения, возможно от различных

источников, с информацией, касающейся снятия платы со счёта (billable account). Также заголовок содержит

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

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

доверием UA – применим только в сегменте сети с доверительными отношениями и должен быть удалён при выходе

 за пределы сегмента.

• P-DCS-LAES и P-DCS-REDIRECT

Заголовок P-DCS-LAES содержит информацию, необходимую для выполнения легального электронного наблюдения

 (Lawfully Authorized Electronic Surveillance). Информация представляет собой адрес и порт устройства,

занимающегося электронным наблюдением, для доставки двустороннего потока сигнальных сообщений,

относящихся к этому вызову. Заголовок может также включать дополнительный адрес и порт для доставки элементу

сети SIP, занимающемуся наблюдением, медиа-информации, передающейся в ходе вызова. Этот заголовок

 используется только между прокси-серверами и агентами пользователя, между которыми установлены

доверительные отношения.

Заголовок P-DCS-Redirect содержит идентифицирующую вызов информацию, необходимую для поддержки 

требований легального электронного наблюдения для перенаправленных вызовов. Содержит первоначально

 указанный адрес, адрес перенаправленного запроса и количество предпринятых перенаправлений. 

Этот заголовок также используется только между прокси-серверами и  агентами пользователя, между которыми

установлены доверительные отношения.

·       RAck

Заголовок RAck помещается в запрос PRACK в целях обеспечения надежной доставки предварительных ответов.

 Он включает два численных значения и поле типа запроса. Первое значение - значение, взятое из поля заголовка

RSeq подтверждаемого предварительного ответа. Следующее значение и тип запроса копируются из поля заголовка

CSeq подтверждаемого ответа. Поле типа запроса в заголовке RAck чувствительно к смене регистра. Пример:

RAck: 776656 1 INVITE

·       Reason

Один и тот же SIP запрос может быть передан по различным причинам. Например, запрос CANCEL может отсылаться

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

пользователя до ответа вызываемой стороны. Несмотря на то, что протокол и поведение системы одинаково в обоих

 случаях, смысл передаваемого сообщения может существенно различаться. В реализациях, которых не

предусмотрено расширение, связанное с заголовком Reason, при получении CANCEL по второй причине вызов может

 быть расценен как упущенный; в то же время этот запрос будет расценен также, если вызов будет принят на другом

терминале пользователя.

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

 заголовок Reason. Заголовок Reason также предназначен для инкапсуляции кода окончательного ответа в

предварительный ответ. Это функция способствует решению проблемы, обозначаемой аббревиатурой HERFP

(Heterogeneous Error Response Forking Problem) - ситуации, когда  элемент, размножающий запросы, не может

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

по которому отправил запрос.

Заголовок Reason может содержаться в любом запросе, передаваемом в режиме диалога, в любом запросе CANCEL

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

параметром «cause», указывающим код SIP-ответа. Также значение может быть – «Q.850» с параметром «cause»,

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

с рекомендацией ITU-T Q.850 для систем сигнализации DSS1 и OKC№7 (подсистема ISUP).  SIP-сообщение может

содержать более одного значения поля заголовка Reason, однако в этом случае значения должны быть различны

 (например, одно SIP и другое Q.850). Реализации игнорируют значения заголовка Reason, которые им не понятны. 

Клиенты и серверы могут игнорировать этот заголовок, что не повлияет не процесс обработки. Пример.

Reason: SIP ;cause=200 ;text="Call completed elsewhere"

     Reason: Q.850 ;cause=16 ;text="Terminated"

·       Record-Route

Заголовок Record-Route вставляется прокси-серверами в запросы для того, чтобы последующие запросы в процессе

 диалога маршрутизировались через данные прокси-серверы.

Пример:

       Record-Route: <sip:serv10.protei.ru;lr>,

                     <sip:site3.niits.ru;lr>

• Refer-To