Расширения SIP для подсистемы IP-мультимедиа - SIP extensions for the IP Multimedia Subsystem

В Протокол инициирования сеанса (ГЛОТОК) - это протокол сигнализации, выбранный Партнерский проект третьего поколения (3GPP)[1][2] для создания и управления мультимедийными сеансами с двумя или более участниками в Подсистема IP-мультимедиа (IMS), и поэтому является ключевым элементом в структуре IMS.

SIP был разработан Инженерная группа Интернета (IETF) как стандарт для управления сеансами мультимедийной связи в Интернет-протокол (IP) сети, работающие в прикладной уровень из Пакет Интернет-протокола. Несколько Расширения SIP были добавлены в базовую спецификацию протокола с целью расширения его функциональности.[3][4][5] Эти расширения основаны на Запрос комментариев (RFC) протокол рекомендаций IETF.

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

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

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

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

Другие особые требования:[1]

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

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

Механизм согласования расширений

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

Расширения SIP

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

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

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

Используя расширение возможностей пользовательского агента,[9] пользовательские агенты (терминалы) могут описывать себя, когда они регистрируются, так что другие могут искать их в соответствии с их заголовками расширения предпочтений вызывающего абонента. Для этого они перечисляют свои возможности в Контакт поле заголовка сообщения REGISTER.

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

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

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

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

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

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

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

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

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

Мгновенное сообщение

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

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

Для того, чтобы иметь сеанс обмена мгновенными сообщениями со связанными сообщениями, Протокол передачи сеанса сообщений (MSRP)[13] должен быть использован.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Идентификация и зарядка

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

P-заголовки

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Авторизация СМИ

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

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

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

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

Дорожка

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

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

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

Расширение для обнаружения служебного маршрута при регистрации[31] состоит из Сервис-Маршрут поле заголовка, которое используется регистратором в ответе 2XX на запрос REGISTER, чтобы сообщить регистрирующемуся пользователю об объекте, который должен пересылать каждый запрос, созданный им или ею.

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

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

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

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

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

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

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

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

Косвенное обращение к контенту

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

Обход NAT

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

Инженерная группа Интернета с RFC 6314[38] суммирует и унифицирует различные методы достижения этой цели, такие как симметричная маршрутизация ответов и инициируемые клиентом соединения для сигнализации SIP, а также использование СТУН, ПОВЕРНУТЬ и ЛЕД, который объединяет оба предыдущих, для медиапотоки

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

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

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

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

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

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

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

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

Смотрите также

Рекомендации

  1. ^ а б c Гарсия-Мартин, М. (май 2005 г.). Входные требования проекта партнерства третьего поколения (3GPP), выпуск 5, к протоколу инициации сеанса (SIP). IETF. Дои:10.17487 / RFC4083. RFC 4083. Получено 29 ноября, 2014.
  2. ^ а б Камарильо, Гонсало; Гарсия-Мартин, Мигель А. (4 ноября 2008 г.). Мультимедийная подсистема 3G IP (IMS): слияние Интернета и сотовой связи (3-е изд.). Джон Вили и сыновья. С. 55–336. ISBN  978-0-470-51662-1. Получено 15 ноября 2014.
  3. ^ Пойкселька, Миикка; Майер, Георг; Хартабил, Хишам; Ниеми, Аки (10 марта 2006 г.). IMS: концепции и услуги мультимедиа IP (2-е изд.). Джон Вили и сыновья. С. 320–331. ISBN  978-0-470-01906-1. Получено 15 ноября 2014.
  4. ^ Красная шляпа. «8.6. РАСШИРЕНИЯ SIP И IMS». redhat.com. Получено 15 ноября 2014.
  5. ^ Обучение системам и сетям. «SIP в IMS». snt.co.uk. Получено 15 ноября 2014.
  6. ^ а б Jesske, R .; Drage, K .; Холмберг, К. (июль 2014 г.). Частный заголовок (P-заголовок) Расширения протокола инициации сеанса (SIP) для 3GPP. IETF. Дои:10.17487 / RFC7315. RFC 7315. Получено 15 ноября, 2014.
  7. ^ Rosenberg, J .; Шульцринн, Х. (июнь 2002 г.). Протокол инициации сеанса (SIP): поиск серверов SIP. IETF. Дои:10.17487 / RFC3263. RFC 3263. Получено 1 декабря, 2014.
  8. ^ Rosenberg, J .; Schulzrinne, H .; Кизиват П. (август 2004 г.). Настройки вызывающего абонента для протокола инициации сеанса (SIP). IETF. Дои:10.17487 / RFC3841. RFC 3841. Получено 1 декабря, 2014.
  9. ^ Rosenberg, J .; Schulzrinne, H .; Кизиват П. (август 2004 г.). Указание возможностей пользовательского агента в протоколе инициации сеанса (SIP). IETF. Дои:10.17487 / RFC3840. RFC 3840. Получено 1 декабря, 2014.
  10. ^ Роуч, А. (июнь 2002 г.). Протокол инициации сеанса (SIP) - уведомление о конкретном событии. IETF. Дои:10.17487 / RFC3265. RFC 3265. Получено 1 декабря, 2014.
  11. ^ Ниеми, А. (октябрь 2004 г.). Расширение протокола инициации сеанса (SIP) для публикации состояния события. IETF. Дои:10.17487 / RFC3903. RFC 3903. Получено 2 декабря, 2014.
  12. ^ Кэмпбелл, B .; Ред., Розенберг; J., Schulzrinne; H., Huitema; C., и; Д., Гурл (декабрь 2002 г.). Расширение протокола инициации сеанса (SIP) для обмена мгновенными сообщениями. IETF. Дои:10.17487 / RFC3428. RFC 3428. Получено 2 декабря, 2014.
  13. ^ Кэмпбелл, B .; Ed., Mahy; Красный.; Дженнингс, К. (сентябрь 2007 г.). Протокол ретрансляции сеанса сообщений (MSRP). IETF. Дои:10.17487 / RFC4975. RFC 4975. Получено 2 декабря, 2014.
  14. ^ Спаркс, Р. (апрель 2003 г.). Метод ссылки протокола инициации сеанса (SIP). IETF. Дои:10.17487 / RFC3515. RFC 3515. Получено 2 декабря, 2014.
  15. ^ а б Rosenberg, J .; и другие. (Июнь 2002 г.). SIP: протокол инициирования сеанса. IETF. Дои:10.17487 / RFC3261. RFC 3261. Получено 15 ноября, 2014.
  16. ^ Rosenberg, J .; Шульцринн, Х. (июнь 2002 г.). Надежность предварительных ответов в протоколе инициации сеанса (SIP). IETF. Дои:10.17487 / RFC3262. RFC 3262. Получено 2 декабря, 2014.
  17. ^ Розенберг, Дж. (Октябрь 2002 г.). Метод ОБНОВЛЕНИЯ протокола инициации сеанса (SIP). IETF. Дои:10.17487 / RFC3311. RFC 3311. Получено 2 декабря, 2014.
  18. ^ Camarillo, G .; Изд., Маршалл; Мы бы.; Розенберг, Дж. (Октябрь 2002 г.). Интеграция управления ресурсами и протокола инициации сеанса (SIP). IETF. Дои:10.17487 / RFC3312. RFC 3312. Получено 3 декабря, 2014.
  19. ^ EvenHelix. «Звонок из IMS в IMS» (PDF). eventhelix.com/. Получено 3 декабря 2014.
  20. ^ Camarillo, G .; Бланко, Г. (апрель 2006 г.). Протокол инициации сеанса (SIP) P-User-Database Private-Header (P-Header). IETF. Дои:10.17487 / RFC4457. RFC 4457. Получено 5 декабря, 2014.
  21. ^ EvenHelix. «Регистрация в IMS» (PDF). eventhelix.com/. Получено 5 декабря 2014.
  22. ^ Camarillo, G .; Бланко, Г. (август 2007 г.). Протокол инициации сеанса (SIP) P-Profile-Key Private Header (P-Header). IETF. Дои:10.17487 / RFC5002. RFC 5002. Получено 5 декабря, 2014.
  23. ^ Jennings, C .; Peterson, J .; Уотсон, М. (ноябрь 2002 г.). Частные расширения к протоколу инициации сеанса (SIP) для подтвержденной идентификации в надежных сетях. IETF. Дои:10.17487 / RFC3325. RFC 3325. Получено 3 декабря, 2014.
  24. ^ Петерсон, Дж. (Ноябрь 2002 г.). Механизм конфиденциальности для протокола инициации сеанса (SIP). IETF. Дои:10.17487 / RFC3323. RFC 3323. Получено 3 декабря, 2014.
  25. ^ Драге, К. (ноябрь 2010 г.). Расширение протокола инициации сеанса (SIP) для идентификации услуг. IETF. Дои:10.17487 / RFC6050. RFC 6050. Получено 5 декабря, 2014.
  26. ^ Розенберг, Дж. (Июнь 2010 г.). Идентификация услуг связи в протоколе инициации сеанса (SIP). IETF. Дои:10.17487 / RFC5897. RFC 5897. Получено 5 декабря, 2014.
  27. ^ Niemi, A .; Arkko, J .; Торвинен, В. (сентябрь 2002 г.). Дайджест-аутентификация протокола передачи гипертекста (HTTP) с использованием аутентификации и соглашения о ключах (AKA). IETF. Дои:10.17487 / RFC3310. RFC 3310. Получено 5 декабря, 2014.
  28. ^ Arkko, J .; Torvinen, V .; Camarillo, G .; Niemi, A .; Хаукка, Т. (январь 2003 г.). Соглашение о механизме безопасности для протокола инициации сеанса (SIP). IETF. Дои:10.17487 / RFC3329. RFC 3329. Получено 5 декабря, 2014.
  29. ^ Маршалл, В. (январь 2003 г.). Расширения протокола инициации частного сеанса (SIP) для авторизации мультимедиа. IETF. Дои:10.17487 / RFC3313. RFC 3313. Получено 5 декабря, 2014.
  30. ^ Уиллис, Д .; Hoeneisen, B. (декабрь 2002 г.). Поле заголовка расширения протокола инициирования сеанса (SIP) для регистрации несмежных контактов. IETF. Дои:10.17487 / RFC3327. RFC 3327. Получено 5 декабря, 2014.
  31. ^ Уиллис, Д .; Хёнейзен, Б. (октябрь 2003 г.). Поле заголовка расширения протокола инициирования сеанса (SIP) для обнаружения служебного маршрута во время регистрации. IETF. Дои:10.17487 / RFC3608. RFC 3608. Получено 5 декабря, 2014.
  32. ^ Розенберг, Дж. (Октябрь 2009 г.). Получение и использование URI глобально маршрутизируемого пользовательского агента (GRUU) в протоколе инициации сеанса (SIP). IETF. Дои:10.17487 / RFC5627. RFC 5627. Получено 5 декабря, 2014.
  33. ^ Цена, руб .; Bormann, C .; Christoffersson, J .; Hannu, H .; Liu, Z .; Розенберг, Дж. (Январь 2003 г.). Сжатие сигналов (SigComp). IETF. Дои:10.17487 / RFC3320. RFC 3320. Получено 4 декабря, 2014.
  34. ^ Hannu, H .; Christoffersson, J .; Forsgren, S .; Leung, K.-C .; Liu, Z .; Прайс, Р. (январь 2003 г.). Сжатие сигналов (SigComp) - Расширенные операции. IETF. Дои:10.17487 / RFC3321. RFC 3321. Получено 4 декабря, 2014.
  35. ^ Гарсия-Мартин, М .; Bormann, C .; Ott, J .; Цена, руб .; Роуч, А. (февраль 2003 г.). Статический словарь протокола инициации сеанса (SIP) и протокола описания сеанса (SDP) для сжатия сигналов (SigComp). IETF. Дои:10.17487 / RFC3485. RFC 3485. Получено 4 декабря, 2014.
  36. ^ Камарильо, Г. (февраль 2003 г.). Сжатие протокола инициации сеанса (SIP). IETF. Дои:10.17487 / RFC3486. RFC 3486. Получено 4 декабря, 2014.
  37. ^ Бургер, Э. (май 2006 г.). Механизм косвенного обращения к содержимому в сообщениях протокола инициации сеанса (SIP). IETF. Дои:10.17487 / RFC4483. RFC 4483. Получено 4 декабря, 2014.
  38. ^ Boulton, C .; Rosenberg, J .; Camarillo, G .; Одет, Ф. (июль 2011 г.). Практики обхода NAT для клиент-серверного протокола SIP. IETF. Дои:10.17487 / RFC6314. RFC 6314. Получено 5 декабря, 2014.
  39. ^ Camarillo, G .; Эль, Малки; К., и; В., Гурбани (апрель 2011 г.). Переход IPv6 в протоколе инициирования сеанса (SIP). IETF. Дои:10.17487 / RFC6157. RFC 6157. Получено 5 декабря, 2014.
  40. ^ Petrack, S .; Конрой, Л. (июнь 2000 г.). Сервисный протокол PINT: расширения SIP и SDP для IP-доступа к услугам телефонной связи. IETF. Дои:10.17487 / RFC2848. RFC 2848. Получено 5 декабря, 2014.
  41. ^ Гурбани, В .; Ред., Брусиловский; А., Файнберг; И., Гато; J., Lu; Рука; М., Унмехопа (октябрь 2004 г.). Протокол SPIRITS (службы в PSTN, запрашивающие Интернет-службы). IETF. Дои:10.17487 / RFC3910. RFC 3910. Получено 5 декабря, 2014.
  42. ^ Вемури, А .; Петерсон, Дж. (Сентябрь 2002 г.). Протокол инициирования сеанса для телефонов (SIP-T): контекст и архитектура. IETF. Дои:10.17487 / RFC3372. RFC 3372. Получено 5 декабря, 2014.
  43. ^ Camarillo, G .; Roach, A .; Peterson, J .; Онг, Л. (декабрь 2002 г.). Отображение пользовательской части цифровой сети с интеграцией служб (ISDN) (ISUP) на протокол инициации сеанса (SIP). IETF. Дои:10.17487 / RFC3398. RFC 3398. Получено 5 декабря, 2014.
  44. ^ Holmberg, C .; Burger, E .; Каплан, Х. (январь 2011 г.). Протокол инициации сеанса (SIP) INFO Метод и структура пакета. IETF. Дои:10.17487 / RFC6086. RFC 6086. Получено 5 декабря, 2014.

Книги

внешняя ссылка