Расширения SIP для IP Multimedia Subsystem

Два связанных расширения дают возможность пользователю определять свои предпочтения относительно предоставляемых IMS сервисов.

Расширение предпочтений вызывающего позволяет указывать желаемый тип пользовательского агента (например, стационарный или мобильный, голосовая почта или пользователь, личная или корпоративная учётная запись, поддерживаемые сервисы/методы). Параметры передаются через заголовки Accept-Contact (желаемые агенты назначения), Reject-Contact (нежелательные агенты) и Request-Disposition (как следует обрабатывать запрос в сети: перенаправлять или нет, и как искать пользователя — последовательно или параллельно).

С помощью расширения возможностей пользовательского агента терминалы могут описывать себя при регистрации, чтобы поиск по предпочтениям осуществлялся корректно. Для этого терминал перечисляет свои возможности в заголовке Contact регистрационного сообщения REGISTER.

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

В системе IMS это важно для информирования о присутствии пользователя («онлайн»/«офлайн»), оповещения о статусе собственной регистрации пользователя или прокси (P-CSCF), а также для дополнительных сервисов (например, уведомления о новых голосовых сообщениях в входящих). Специальное расширение оповещения о событиях вводит базовый фреймворк, методы SUBSCRIBE и NOTIFY, новые поля заголовков и коды ответов, а также роли subscriber (подписчик) и notifier (уведомитель). Подписчик отправляет SUBSCRIBE с URI ресурса и типом события, notifier отвечает NOTIFY с текущим состоянием ресурса. При каждом изменении состояния отправляется новое NOTIFY. Для каждого типа событий вводится event package, то есть значение для SUBSCRIBE и формат передачи информации в виде MIME-типа внутри NOTIFY.

Служебный заголовок allow-events показывает поддерживаемые типы событий, коды ответов 202 accepted и 489 bad event указывают, был ли принят запрос на подписку или отклонён из-за незнания типа события. Для уменьшения нагрузки возможен event throttling (ограничение частоты уведомлений), а conditional event notification позволяет отправлять NOTIFY только при реальных изменениях состояния.

Фреймворк оповещения о событиях только описывает подписку на события, но не регламентирует процесс их публикации. Расширение публикации состояния добавляет новый метод PUBLISH для передачи актуального состояния ресурса (указывается в request-URI) и связанного события (Event header).

Возможность отправки мгновенных сообщений определяет расширение для обмена мгновенными сообщениями, формирующее сервис, аналогичный коротким сообщениям. Сообщения независимы (не образуют диалог SIP), передаются через сигнальную сеть, разделяя ресурсы с контрольными сообщениями. Введён новый метод MESSAGE, с помощью которого можно отправить сообщение ресурсу, заданному в request-URI (тело содержит контент в формате MIME, обычно text/plain). Для диалоговых обменов мгновенными сообщениями применяется протокол MSRP.

Метод REFER позволяет клиенту запросить пользовательский агент на установление сеанса с ресурсом, который указывается в заголовке Refer-To. Типовое применение — перевод вызова: участник посылает REFER, а получатель инициирует связь c заданным агентом. REFER также подразумевает подписку на событие по результату операции.

Механизм REFER не ограничивается только переводом вызова: Refer-To может содержать любой URI, например, HTTP-адрес веб-страницы.

Базовая спецификация SIP обеспечивает гарантированную доставку только для запросов и финальных ответов (коды 2XX): их повторно передаёт отправитель до получения подтверждения (ACK). Поскольку SIP может работать как поверх надёжных транспортных протоколов (TCP), так и ненадёжных (UDP), этот механизм критически важен. В системе IMS требуется также подтверждать предварительные (provisional) ответы на INVITE (например, 180 Ringing). Расширение надёжности предварительных ответов вводит метод PRACK, который информирует отправителя предварительного ответа, что его сообщение получено. PRACK содержит поле RACK (соответствует RSeq provisional-ответа), а также CSeq с идентификатором INVITE. Для указания поддержки этого механизма применяется 100rel option tag.

Расширение UPDATE даёт возможность отправлять обновления параметров сеанса внутри диалога — до передачи окончательного ответа на INVITE. Это позволяет заранее согласовывать ресурсы для вызываемого.

IMS предъявляет требование минимизации вероятности неудачного установления сеанса после оповещения вызываемого. Одним из рисков является невозможность резервирования сетевых ресурсов — которые должны быть зарезервированы до звонка. Для этого требуется предварительный обмен параметрами IP и сессии, который может инициировать только INVITE-запрос. В базовом SIP такое взаимодействие запускает оповещение. Концепция preconditions решает эту проблему: вызывающий формулирует набор требований к сессии (например, кодеки, QoS) в оффере, а вызываемый отвечает, не запуская оповещение пока precondition не выполнены с обеих сторон.

Расширение preconditions влияет как на SIP (через новый option tag precondition и процедуры offer/answer), так и на Session Description Protocol, SDP, где появляются атрибуты: current status, desired status для резервирования и confirmation status (когда требуется подтверждение резервирования).

В IMS начальное согласование параметров осуществляется с помощью расширений provisional responses и session description updating наряду с SDP внутри сообщений. Первый оффер (SDP) вкладывается в INVITE и отражает поддерживаемые вызывающим кодеки. Ответный provisional-ответ 183 Session Progress возвращает SDP список поддерживаемых кодеков обеих сторон. PRACK к этому provisional-ответу используется для выбора кодека и начала переговоров о QoS.

Процедура согласования QoS реализуется через PRACK, инициируя резервирование ресурсов у инициатора, и завершается после получения ответа 2XX. После этого вызываемый также резервирует ресурсы, обмен UPDATE сообщает о прогрессе резервирования. Как только оба участника завершили резервирование, вызываемый оповещается о вызове.

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

Приватные расширения SIP (P-Headers) — специальные заголовки, применимые только в частных сетях с особыми топологиями и характеристиками нижних уровней. Они были созданы специально для нужд 3GPP при отсутствии универсальных решений.

Наиболее значимые поля:

• P-Charging-Vector — информация о тарификации (идентификатор сессии, адрес прокси, идентификатор оператора).
• P-Charging-Function-Address — адреса функций тарификации в домашней сети абонента.
• P-Visited-Network-ID — строка, идентифицирующая посещаемую сеть (используется при регистрации абонента в роуминге).
• P-Access-Network-Info — информация о технологии доступа (тип радиосети, идентификатор соты и др.).
• P-Called-Party-ID — исходный URI запроса, заменённый регистратором S-CSCF на актуальный контактный адрес; необходим для определения, на какой адрес-учётку был отправлен вызов.
• P-Associated-URI — дополнительные URI, ассоциированные с регистрируемым пользователем; передаются в ответе 200 OK на REGISTER.

Есть дополнительные приватные заголовки для работы с пользовательской базой:

• P-User-Database — адрес базы данных пользователя (HSS). Хотя HSS представлен единой логической сущностью, с целью масштабируемости и надёжности он может быть распределён; тогда для выбора нужного HSS используется SLF. Попадая на пограничный прокси I-CSCF, запрос прокси SLF, получает нужный HSS и передаёт его адрес через P-User-Database S-CSCF, который затем работает напрямую с HSS (например, для аутентификации при регистрации).
• P-Profile-Key — ключ для быстрого поиска профиля пользователя в HSS, особенно полезен при использовании маскированных (регулярных выражений) сервис-идентификаторов.

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

Базовый механизм — заголовок P-Asserted-Identity: после успешной аутентификации прокси вставляет этот заголовок с подтверждённой идентичностью, чтобы другие узлы доверенного домена могли использовать её без повторной проверки. Для пользователя с несколькими публичными идентичностями определён заголовок P-Preferred-Identity — он позволяет явно указать, какая из идентичностей окажется в P-Asserted-Identity.

Если запрошена приватность, прокси должны удалять P-Asserted-Identity при передаче за пределы доверенного домена (внешним адресатам).

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

Доступ к сервисам IMS предполагает аутентификацию и авторизацию пользователя (в S-CSCF) и установку защищённого соединения между P-CSCF и терминалом. Для этих целей применяются различные механизмы:

• HTTP-аутентификация типа digest access authentication (базовый механизм SIP), приводящий к созданию защищённого соединения (Transport Layer Security) между пользователем и прокси.
• HTTP Digest с использованием AKA — более защищённый механизм для сотовых сетей, использующий данные смарт-карты пользователя и обычно создающий две ассоциации безопасности (IPsec) между P-CSCF и терминалом.

Расширение для согласования механизмов безопасности вводит три новых поля заголовка:

• Терминал добавляет заголовок security-client, перечисляя поддерживаемые механизмы, алгоритмы аутентификации и шифрования в REGISTER.
• P-CSCF отвечает с security-server, где перечислены механизмы с приоритетом.
• Пользователь отправляет новое REGISTER по установленному защищённому каналу, указывая security-verify (то же, что и security-server). Это защищает согласование от атак типа «человек посередине»: несоответствие security-server и security-verify раскрывает атаку. Перехватчик не может изменить security-verify, так как оно передаётся уже внутри нового защищённого соединения.

Резервирование ресурсов IMS для обеспечения QoS приводит к задаче контроля доступа и защиты от DoS-атак. Для получения разрешения на передачу пользовательский агент предъявляет токен авторизации, получаемый у P-CSCF (отвечающего за контроль политик или взаимодействующего с PDF, политическим органом сети). Приватное расширение авторизации медиапотока вводит механизм получения токенов и заголовок P-Media-Authorization для передачи их между P-CSCF и терминалом. Применимо только внутри административных доменов с доверием и ориентировано на специализированные системы типа IMS, а не на общий Интернет.

Механизм маршрутизации по источнику позволяет отправителю явно задать маршрут сообщения с помощью заголовка route, где перечислены прокси, которые должны быть пройдены сообщением. В контексте IMS определён также механизм автоматического обнаружения необходимых узлов (CSCF) через расширения path и service-route.

Специальное расширение добавляет возможность вносить SIP-URI прокси на каждом этапе прохождения REGISTER в заголовок Path, чтобы регистратор мог узнать обратный маршрут к терминалу. В IMS каждый терминал обслуживается своим P-CSCF (найденным через DHCP или аналогично при входе в сеть). Все обращения должны проходить через этот прокси; при регистрации P-CSCF добавляет свой SIP-URI в Path REGISTER, а S-CSCF сохраняет полученный маршрут и использует его для обратной связи.

Расширение Service-Route предназначено для информирования терминала, какой узел (обычно собственный S-CSCF) должен обрабатывать все его исходящие запросы; Service-Route возвращается в ответе на REGISTER. Терминал затем вставляет этот SIP-URI в заголовок Route для всех исходящих запросов.

В IMS один пользователь может иметь несколько терминалов (например, мобильный телефон, компьютер) или приложений (видеотелефония, обмен сообщениями, голосовая почта), идентифицируемых одной публичной идентичностью (SIP-URI). Для адресации требуется механизм — Globally Routable User Agent URI (GRUU): уникальный URI, указывающий конкретный экземпляр агента пользователя и действующий для маршрутизации из любой точки мира. GRUU формируется путём добавления параметра gr к SIP-URI (явно, либо псевдонимом для защиты приватности). Обычно GRUU выдаётся при регистрации: терминал сообщает уникальный URN, регистратор (S-CSCF) формирует и возвращает GRUU для дальнейшей маршрутизации.

Для эффективного расходования ресурсов сети (особенно при использовании радиоинтерфейса) применяется механизм сжатия сообщений SIP — SigComp (signaling compression). Алгоритмы заменяют часто встречающиеся слова на индексы в словаре. Для ускорения формируются общие словари как для одного сообщения, так и для серии сообщений, а также статический словарь SIP/SDP. С помощью параметра comp=sigcomp указывается поддержка SigComp (в URI запроса — запрос сжат, в заголовках Via — ответ сжат). Механизм content indirection позволяет дополнительно уменьшить длину сообщений, заменяя часть MIME-тела на внешний URI (например, HTTP).

Сетевой адресный транслятор (NAT) препятствует достижимости терминалов из внешней сети. Для решения данной задачи (как для сигнального, так и для медийного трафика) применяются специальные механизмы, объединённые и рассмотренные в RFC 6314: симметричная маршрутизация ответов и подключения, инициированные клиентом (SIP signaling), а для медиа — STUN, TURN и комплексная технология ICE.

RFC 6157 описывает необходимые механизмы для корректной работы SIP в смешанных сетях во время перехода на IPv6. При наличии правильно сконфигурированных прокси и DNS, сигнальные сообщения SIP проходят между IPv4/IPv6-сетями, однако агенты пользователей должны реализовывать расширения для обмена мультимедийными потоками напрямую (в SDP-обмене осуществлять сбор адресов обеих версий протокола).

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

Обеспечивают такие возможности стандарты:

• PINT — расширение SIP и SDP для доступа к услугам классической телефонии PSTN (телефонные услуги, факс, передача контента по телефону).
• SPIRITS — обратное взаимодействие, поддержка доступа к Интернет-сервисам из PSTN.

Кроме того, реализованы решения для шлюзов PSTN-SIP:

• Session Initiation Protocol for Telephones (SIP-T) — описание архитектуры и практик интеграционных шлюзов.
• ISUP to SIP Mapping — сопоставление сообщений SIP и ISUP из SS7, используемой в PSTN.

Метод INFO в SIP предназначен для передачи пользовательской информации между терминалами вне сигнального диалога, в том числе может использоваться для передачи DTMF-сигналов при наборе номера на телефоне.