SIP-расширения для IP-мультимедийной подсистемы

Протокол инициации сеанса ( SIP ) — это протокол сигнализации, выбранный Проектом партнерства третьего поколения (3GPP). для создания и управления мультимедийными сеансами с несколькими участниками IP Multimedia Subsystem (IMS). Таким образом, это ключевой элемент в структуре IMS.

SIP был разработан Инженерной группой Интернета (IETF) в качестве стандарта для управления сеансами мультимедийной связи в сетях Интернет-протокола (IP). Он характеризуется своим положением на прикладном уровне набора протоколов Интернета . Несколько расширений SIP, опубликованных в рекомендациях протокола запроса комментариев (RFC), были добавлены к базовому протоколу для расширения его функциональности.

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

Требования 3GPP для SIP

3GPP установил несколько общих требований для работы IMS. К ним относятся эффективное использование радиоинтерфейса за счет минимизации обмена сигнальными сообщениями между мобильным терминалом и сетью, минимальное время установки сеанса путем выполнения задач до установления сеанса, а не во время установления сеанса, минимальная поддержка, необходимая в терминале, поддержка сценариев роуминга и отсутствия роуминга с управлением мобильностью терминалов (поддерживается сетью доступа, а не SIP) и поддержка адресации IPv6 .

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

Другими особыми требованиями являются:

• Поддержка качества обслуживания с контролем политики и оплаты, а также согласованием и распределением ресурсов перед оповещением конечного пользователя.
• Идентификация пользователей для целей аутентификации, авторизации и учета . Безопасность между пользователями и сетью, а также между сетевыми узлами является основной проблемой, которую необходимо решить с помощью механизмов взаимной аутентификации , таких как частные и открытые ключи и дайджесты , а также авторизации расширений мультимедиа. Также должна быть возможность предоставить как вызывающему, так и вызываемому абоненту личности своих собеседников с возможностью скрыть эту информацию, если потребуется. Анонимность при установлении сеанса и конфиденциальность также важны.
• Защита SIP-сигнализации с поддержкой целостности и конфиденциальности на основе первичной аутентификации и симметричных криптографических ключей ; также необходимы восстановление и проверка ошибок.
• Освобождение сеанса, инициированное сетью (например, в случае, если пользовательский терминал выходит из зоны покрытия или у него заканчивается кредит).
• Механизмы маршрутизации источников . Маршрутизация чтобы сообщений SIP имеет свои собственные требования в IMS, поскольку все попытки установления сеанса, исходящие от терминала, должны проходить через P-CSCF и S-CSCF, эти серверы функций управления сеансом вызова (CSCF) могли должным образом предоставлять свои услуги. Для определенных сообщений также могут быть особые требования к пути.
• Взаимодействие между IMS и телефонной сетью общего пользования (PSTN).

Наконец, также необходимо, чтобы другие протоколы и сетевые службы, такие как DHCP или DNS, адаптированы для работы с SIP, например, для определения местоположения исходящего прокси-сервера (P-CSCF) и универсального идентификатора ресурса SIP (URI) для разрешения IP-адреса соответственно.

Механизм переговоров о расширении

Существует механизм в SIP для согласования расширения между пользовательскими агентами (UA) или серверами, состоящим из трех полей заголовка : supported , require и unsupported , которые UA или серверы (т. е. пользовательские терминалы или функция управления сеансом вызова (CSCF) в IMS) могут использовать для указания расширения, которые они понимают. Когда клиент инициирует диалог SIP с сервером, он указывает расширения, которые ему необходимы для использования, а также другие расширения, которые понятны ( поддерживаются ), а затем сервер отправит ответ со списком необходимых ему расширений . Если эти расширения не указаны в сообщении клиента, ответом сервера будет ошибка. Аналогично, если сервер не поддерживает ни одно из необходимых расширений клиента, он отправит ответ об ошибке со списком неподдерживаемых расширений. Такие расширения называются тегами опций , но SIP также можно расширить с помощью новых методов . В этом случае пользовательские агенты или серверы используют заголовок Allow , чтобы указать, какие методы они поддерживают. Чтобы потребовать использования определенного метода в конкретном диалоге, они должны использовать тег опции, связанный с этим методом.

SIP-расширения

Настройки вызывающего абонента и возможности пользовательского агента

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

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

Используя расширение возможностей пользовательского агента, Пользовательские агенты (терминалы) могут описывать себя при регистрации, чтобы другие могли искать их в соответствии с заголовками расширения предпочтений вызывающего абонента. Для этого они перечисляют свои возможности в поле заголовка «Контакт» сообщения «РЕГИСТРАЦИЯ».

Уведомление о событии

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

Уведомление о событии необходимо в структуре IMS для информирования о присутствии пользователя (т. е. «онлайн» или «оффлайн») другим, которые могут ожидать возможности связаться с ним, или для уведомления пользователя и его P-CSCF о его собственной регистрации. штата, чтобы они знали, доступны ли они и какие общедоступные идентификаторы они зарегистрировали. Кроме того, уведомление о событии можно использовать для предоставления дополнительных услуг, таких как голосовая почта (т. е. для уведомления о наличии новых голосовых сообщений в папке «Входящие »).

С этой целью расширение уведомления о конкретных событиях определяет структуру уведомления о событиях в SIP с двумя новыми методами: SUBSCRIBE и NOTIFY, новыми полями заголовка и кодами ответа, а также двумя ролями: подписчик и уведомитель . Объект, заинтересованный в информации о состоянии ресурса ( подписчик ), отправляет сообщение SUBSCRIBE с универсальным идентификатором ресурса (URI) ресурса в начальной строке запроса и типом события в заголовке Event . Затем объект, отвечающий за отслеживание состояния ресурса ( уведомитель ), получает запрос SUBSCRIBE и отправляет обратно сообщение NOTIFY с заголовком состояния подписки , а также информацию о состоянии ресурса в теле сообщения. . Всякий раз, когда состояние ресурса изменяется, уведомитель новое сообщение NOTIFY отправляет подписчику . Каждый тип событий, на которые может подписаться подписчик, определяется в новом пакете событий . Пакет событий описывает новое значение для заголовка события SUBSCRIBE , а также тип MIME для передачи информации о состоянии события в сообщении NOTIFY.

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

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

Государственное издание

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

Структура публикации состояния определяет новый метод: PUBLISH, который используется для запроса публикации состояния ресурса, указанного в URI запроса, со ссылкой на событие, указанное в заголовке Event , и с информацией, содержащейся в сообщении. тело.

Мгновенный обмен сообщениями

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

Эта функциональность поддерживается новым методом MESSAGE, который можно использовать для отправки мгновенного сообщения ресурсу, указанному в URI запроса, с содержимым, переносимым в теле сообщения. Этот контент определяется как тип MIME , причем является text/plain наиболее распространенным .

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

Перевод вызова

Расширение метода REFER определяет механизм запроса пользовательского агента связаться с ресурсом, который идентифицируется URI в поле заголовка Refer-To сообщения запроса. Типичным использованием этого механизма является передача вызова: во время вызова участник, отправляющий сообщение REFER, сообщает получателю связаться с пользовательским агентом, указанным по URI в соответствующем поле заголовка. Сообщение REFER также подразумевает подписку на событие на результат операции, чтобы отправитель знал, сможет ли получатель связаться с третьим лицом.

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

Надежность предварительных ответов

В базовой спецификации SIP 2ХХ надежно передаются только запросы и окончательные ответы (т.е. коды ответа ), то есть они передаются отправителем повторно до тех пор, пока не придет сообщение подтверждения (т.е. соответствующий код ответа на запрос или запрос ACK, соответствующий коду ответа 2ХХ) . Этот механизм необходим, поскольку SIP может работать не только с надежными транспортными протоколами ( TCP ), гарантирующими доставку сообщения, но и с ненадежными ( UDP ), не дающими никаких гарантий доставки, и даже возможно, что оба типа протоколов присутствуют в различных частях транспортной сети.

Однако в таком сценарии, как структура IMS, необходимо распространить эту надежность на предварительные ответы на запросы INVITE (для установления сеанса, то есть для начала вызова). Надежность предоставления предварительных ответов предоставляет механизм подтверждения того, что предварительные ответы, такие как 180 Ringing код ответа , который позволяет вызывающему абоненту узнать, что вызываемый абонент получает предупреждение, успешно получены. Для этого в этом расширении определен новый метод: PRACK, который представляет собой сообщение запроса, используемое для сообщения отправителю предварительного ответа о том, что его сообщение получено. Это сообщение включает в себя RACK поле заголовка , которое представляет собой порядковый номер , соответствующий полю заголовка RSeq предварительного ответа, который подтверждается, а также содержит номер CSeq , который идентифицирует соответствующий запрос INVITE. Чтобы указать, что пользовательский агент запрашивает или поддерживает надежные предварительные ответы, 100rel тег опции будет использоваться .

Обновление описания сеанса

Цель расширения метода UPDATE заключается в том, чтобы позволить пользовательским агентам предоставлять обновленную информацию описания сеанса в диалоговом окне до того, как будет сгенерирован окончательный ответ на первоначальный запрос INVITE. Это можно использовать для согласования и распределения ресурсов вызова до того, как вызываемая сторона будет предупреждена.

Предварительные условия

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

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

Модель предложения/ответа SDP с использованием запросов PRACK и UPDATE.

В IMS первоначальное согласование параметров сеанса может выполняться с использованием предварительных ответов и расширений обновления описания сеанса , а также SDP в теле сообщений. Первое предложение, описанное посредством SDP, может передаваться посредством запроса INVITE и будет иметь дело с кодеками, поддерживаемыми вызывающей стороной . На этот запрос будет дан предварительный надежный код ответа 183 Session Progress , который будет содержать список поддерживаемых кодеков SDP как вызывающим, так и вызываемым абонентом. Соответствующий PRACK этому предварительному ответу будет использоваться для выбора кодека и инициирования согласования QoS .

Согласование QoS поддерживается запросом PRACK, который запускает резервирование ресурсов в сети вызывающей стороны, и на него отвечает код ответа 2XX. После отправки этого ответа вызываемая сторона также выбирает кодек и начинает резервирование ресурсов на своей стороне. Последующие запросы UPDATE отправляются для информирования о ходе резервирования, и на них отвечают коды ответа 2XX. В типичном обмене предложениями и ответами одно UPDATE будет отправлено вызывающей стороной, когда ее резервирование будет завершено, затем вызываемая сторона ответит и в конечном итоге завершит распределение ресурсов. Именно тогда, когда все ресурсы для вызова имеются, вызывающий абонент получает предупреждение.

Идентификация и взимание платы

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

P-заголовки

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

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

• P-Charging-Vector : набор информации о взимании платы, такой как значение идентификатора оплаты IMS (ICID), адрес прокси-сервера SIP, который создает значение ICID, и межоператорский идентификатор (IOI). Он может быть заполнен во время установления сеанса или как отдельная транзакция вне диалога.
• P-Charging-Function-Address : адреса функций начисления платы (функциональных объектов, которые получают записи или события начисления платы) в домашней сети пользователя. Он также может быть заполнен во время установления диалога или как отдельная транзакция и информирует каждого прокси, участвующего в транзакции.
• P-Visited-Network-ID : Идентификационная строка посещаемой сети. Он используется во время регистрации, чтобы указать домашней сети пользователя, какая сеть предоставляет услуги пользователю в роуминге , чтобы домашняя сеть могла принять регистрацию в соответствии с их соглашениями о роуминге.
• P-Access-Network-Info : информация о технологии доступа (сети, обеспечивающей соединение), например, технология радиодоступа и идентификатор соты . Он используется для информирования сервисных прокси и домашней сети, чтобы они могли оптимизировать услуги или просто чтобы они могли найти пользователя в беспроводной сети.
• P-Called-Party-ID : URI, первоначально указанный в request-URI запроса, сгенерированного вызывающим пользовательским агентом. Когда запрос достигает регистратора (S-CSCF) вызываемого пользователя, регистратор перезаписывает URI запроса в первой строке запроса с зарегистрированным контактным адресом (т. е. IP-адресом) вызываемого пользователя и сохраняет заменил запрос-URI в этом поле заголовка. В IMS пользователь может идентифицироваться по нескольким URI SIP (адресу записи), например, URI SIP для работы и другому URI SIP для личного использования, а также когда регистратор заменяет URI запроса на эффективный контакт адрес, исходный URI запроса должен быть сохранен, чтобы вызываемая сторона знала, на какой адрес записи было отправлено приглашение.
• P-Associated-URI : дополнительные URI, связанные с регистрирующимся пользователем. Он включается в ответ 200 OK на запрос REGISTER, чтобы сообщить пользователю, какие другие URI поставщик услуг связал с URI адреса записи (AOR).

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

• P-База данных пользователей : Адрес базы данных пользователей , то есть Домашнего Сервера Абонентов (HSS) , который содержит профиль пользователя, сгенерировавшего тот или иной запрос. Хотя HSS является уникальной главной базой данных, ее можно распределить по разным узлам по соображениям надежности и масштабируемости . В этом случае функция определения местоположения подписчика (SLF) необходима для поиска HSS, который обслуживает конкретного пользователя. Когда пользовательский запрос достигает I-CSCF на границе административного домена, этот объект запрашивает у SLF соответствующий HSS, а затем, чтобы предотвратить необходимость S-CSCF повторно запрашивать SLF, отправляет адрес HSS на S. -CSCF в заголовке P-User-Database . Тогда S-CSCF сможет напрямую запросить HSS, чтобы получить информацию о пользователе (например, информацию аутентификации во время регистрации).
• P-профиль-ключ : Ключ , который будет использоваться для запроса в базе данных пользователей (HSS) профиля, соответствующего URI SIP назначения конкретного запроса SIP. Он передается между прокси-серверами для более быстрого выполнения запросов к базе данных: первый прокси-сервер находит ключ, а остальные запрашивают базу данных, напрямую используя ключ. Это полезно, когда используются подстановочные идентификаторы службы, то есть идентификаторы общедоступной службы, соответствующие регулярному выражению , поскольку первый запрос должен разрешить регулярное выражение, чтобы найти ключ.

Подтвержденная личность

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

Основная функциональность поддерживается заголовком расширения P-Asserted-Identity . Когда прокси-сервер получает запрос от ненадежного объекта и аутентифицирует пользователя (т. е. проверяет, является ли пользователь тем, кем он говорит), он затем вставляет этот заголовок с удостоверением, которое было аутентифицировано, а затем пересылает запрос как обычно. Таким образом, другие прокси-серверы, которые получают этот SIP-запрос в пределах доверенного домена (т. е. сети доверенных объектов с заранее согласованной политикой безопасности), могут безопасно полагаться на идентификационную информацию, содержащуюся в заголовке P-Asserted-Identity, без необходимости повторного запроса. аутентификация пользователя.

Также определен заголовок расширения P-Preferred-Identity , чтобы пользователь с несколькими общедоступными идентификаторами мог сообщить прокси-серверу, какой общедоступный идентификатор следует включить в заголовок P-Asserted-Identity при аутентификации пользователя.

Наконец, когда запрашивается конфиденциальность, прокси-серверы должны скрывать заявленную идентификационную информацию за пределами доверенного домена, удаляя заголовки P-Asserted-Identity перед пересылкой пользовательских запросов ненадежным идентификаторам (за пределами доверенного домена ).

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

Механизмы безопасности

См. также: Безопасность IMS.

Безопасность доступа в IMS состоит из первой аутентификации и авторизации пользователя, которая выполняется S-CSCF, а затем установления безопасных соединений между P-CSCF и пользователем. Для достижения этой цели существует несколько механизмов, таких как:

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

Расширение соглашения о механизмах безопасности для SIP затем был введен для обеспечения безопасного механизма согласования алгоритмов и параметров безопасности, которые будут использоваться P-CSCF и терминалом. Это расширение использует три новых поля заголовка для поддержки процесса переговоров:

• Сначала терминал добавляет к запросу REGISTER поле заголовка Security-Client, содержащее механизмы, алгоритмы аутентификации и шифрования, которые он поддерживает.
• Затем P-CSCF добавляет к ответу поле заголовка сервера безопасности , которое содержит ту же информацию, что и клиентская, но со ссылкой на P-CSCF. Если механизмов несколько, они связаны со значением приоритета.
• Наконец, пользовательский агент отправляет новый запрос REGISTER через только что созданное безопасное соединение с согласованными параметрами, включая поле заголовка проверки безопасности , которое содержит то же содержимое, что и ранее полученное сервера безопасности поле заголовка . Эта процедура защищает механизм переговоров от атак «Человек посередине» : если злоумышленник удалил самые сильные механизмы безопасности из поля заголовка Security-Server , чтобы заставить терминал выбрать более слабые алгоритмы безопасности, то Security-Verify и Security -Поля заголовка сервера не совпадают. Содержимое поля заголовка Security-Verify не может быть изменено, поскольку оно отправляется через новую установленную безопасную ассоциацию, пока эта ассоциация не может быть взломана злоумышленником в реальном времени (т. е. до того, как P-CSCF обнаружит Человека в средняя атака . идет

Разрешение СМИ

Необходимость в IMS резервирования ресурсов для обеспечения качества обслуживания (QoS) приводит к еще одной проблеме безопасности: контролю доступа и защите от атак типа «отказ в обслуживании» . Чтобы получить ресурсы передачи, пользовательский агент должен предоставить сети токен авторизации (т. е. точку применения политики или PEP). Этот токен будет получен от его P-CSCF, который может отвечать за управление политикой QoS или иметь интерфейс с объектом управления политикой в ​​сети (т. е. функцией принятия решения о политике или PDF), который первоначально предоставляет токен авторизации.

Частные расширения для авторизации мультимедиа связать сигнализацию сеанса с механизмами QoS, применяемыми к носителям в сети, путем определения механизмов получения токенов авторизации и поля заголовка P-Media-Authorization для переноса этих токенов от P-CSCF к пользовательскому агенту. Это расширение применимо только в административных доменах с доверительными отношениями. Он был специально разработан для специализированных сетей SIP, таких как IMS, а не для общего Интернета .

Механизмы маршрутизации источника

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

Путь

Поле заголовка расширения для регистрации несмежных контактов предоставляет поле заголовка Path , которое накапливает и передает SIP URI прокси-серверов, расположенных между пользовательским агентом и его регистратором, по мере прохождения сообщения REGISTER. Таким образом, регистратор может обнаружить и записать последовательность прокси-серверов, которые необходимо передать, чтобы вернуться к пользовательскому агенту.

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

Маршрут обслуживания

Расширение для обнаружения маршрута обслуживания при регистрации состоит из поля заголовка Service-Route , которое используется регистратором в ответе 2XX на запрос REGISTER для информирования регистрирующегося пользователя об объекте, который должен пересылать каждый запрос, исходящий от него или нее.

В IMS регистратором является S-CSCF домашней сети, и также требуется, чтобы все запросы обрабатывались этим объектом, поэтому он будет включать свой собственный SIP URI в поле заголовка маршрута службы . Затем пользователь включит этот URI SIP в поле заголовка маршрута всех своих запросов, чтобы они пересылались через домашний S-CSCF.

Глобально маршрутизируемые URI пользовательского агента

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

Эти URI создаются путем добавления параметра gr к SIP URI либо к общедоступному SIP URI со значением, идентифицирующим экземпляр пользовательского агента, либо к специально созданному URI, который не раскрывает связь между GRUU и личностью пользователя. в целях конфиденциальности. Их обычно получают в процессе регистрации: регистрирующий пользовательский агент отправляет универсальное имя ресурса (URN), которое однозначно идентифицирует этот экземпляр SIP, а регистратор (т. е. S-CSCF) создает GRUU, связывает его с зарегистрированным идентификатором и экземпляром SIP. и отправляет его обратно пользовательскому агенту в ответе. Когда S-CSCF получит запрос для этого GRUU, он сможет направить запрос к зарегистрированному экземпляру SIP.

Сжатие сигналов

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

Алгоритмы сжатия выполняют эту операцию, заменяя повторяющиеся слова в сообщении их позицией в словаре, где все эти слова встречаются только один раз. В первом подходе этот словарь может быть создан компрессором для каждого сообщения и отправлен в декомпрессор вместе с самим сообщением. Однако, поскольку многие слова повторяются в разных сообщениях, расширенные операции для SigComp определить способ использования общего словаря среди последующих сообщений. Более того, чтобы ускорить процесс построения словаря последующих сообщений и обеспечить высокую степень сжатия с момента первого сообщения INVITE, SIP предоставляет статический словарь SIP/SDP. который уже построен с использованием общих условий SIP и SDP.

Существует механизм чтобы указать, что сообщение SIP желательно сжать. Этот механизм определяет параметр comp=sigcomp для URI SIP, который сигнализирует о том, что объект SIP, идентифицируемый URI, поддерживает SigComp и готов получать сжатые сообщения. При использовании в URI запроса он указывает, что запрос должен быть сжат, а в полях заголовка Via он сигнализирует о том, что последующий ответ должен быть сжат.

Косвенность контента

Чтобы получать еще более короткие SIP-сообщения и максимально эффективно использовать ресурсы, расширение косвенного доступа к контенту позволяет заменить часть тела MIME сообщения внешней ссылкой, обычно HTTP URI. Таким образом, получатель сообщения может решить, следует ли следовать ссылке для получения ресурса, в зависимости от доступной пропускной способности.

Обход NAT

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

Целевой группы по интернет- инжинирингу RFC 6314 обобщает и унифицирует различные методы для достижения этой цели, такие как симметричная маршрутизация ответов и соединения, инициируемые клиентом для сигнализации SIP, а также использование STUN , TURN и ICE , которые объединяют оба предыдущих, для медиапотоков.

Совместимость с Интернет-протоколом версии 6

Целевой группы по интернет- инжинирингу RFC 6157 описывает необходимые механизмы, гарантирующие успешную работу SIP между обеими интернет-протокола версиями во время перехода на IPv6 . Хотя сигнальные сообщения SIP могут передаваться через гетерогенные сети IPv4 / IPv6 , если прокси-серверы и записи DNS правильно настроены для ретрансляции сообщений через обе сети в соответствии с этими рекомендациями, пользовательским агентам необходимо будет реализовать расширения, чтобы они могли напрямую обмениваться медиапотоками. . Эти расширения связаны с первоначальным обменом предложением/ответом протокола описания сеанса , который будет использоваться для сбора адресов IPv4 и IPv6 обоих концов, чтобы они могли установить прямую связь.

Взаимодействие с другими технологиями

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

Существует несколько стандартов, удовлетворяющих этим требованиям, например два следующих для служб взаимодействия между КТСОП и Интернетом (т. е. сетью IMS):

• Протокол межсетевого взаимодействия PSTN (PINT) , который расширяет возможности SIP и SDP для доступа к классическим услугам телефонной связи в ТфОП (например, базовые телефонные звонки, услуги факса, получение контента по телефону).
• Службы в ТфОП, запрашивающие интернет-услуги (SPIRITS) , который обеспечивает функциональность, противоположную PINT, а именно поддержку доступа к интернет-сервисам из PSTN.

А также для шлюзов PSTN-SIP для поддержки звонков с одного конца в каждой сети:

• Протокол инициирования сеанса для телефонов (SIP-T) , который описывает практику и использование этих шлюзов.
• Сопоставление пользовательской части ISDN (ISUP) с протоколом инициации сеанса (SIP) , что позволяет транслировать сигнальные сообщения SIP в ISUP сообщения системы сигнализации № 7 (SS7), которая используется в PSTN, и наоборот.

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

См. также

• Сеть нового поколения
• Голос по IP
• ТИСПАН

Книги

• Пойкселькя, Миикка; Майер, Георг; Хартабиль, Хишам; Ниеми, Аки (10 марта 2006 г.). IMS: концепции и услуги IP-мультимедиа (2-е изд.). Джон Уайли и сыновья. ISBN  978-0-470-01906-1 . Проверено 15 ноября 2014 г.
• Камарильо, Гонсало; Гарсиа-Мартин, Майкл А. (4 ноября 2008 г.). Подсистема мультимедиа IP 3G (IMS): объединение Интернета и мира сотовой связи (3-е изд.). Джон Уайли и сыновья. ISBN  978-0-470-51662-1 . Проверено 15 ноября 2014 г.

Внешние ссылки

• Страница проекта партнерства 3-го поколения о подсистеме IP-мультимедиа
• Потоки вызовов IP-мультимедийной подсистемы