Способ и устройство идентификации ims-услуги
Изобретение относится к системам IP-мультимедиа. Технический результат заключается в усовершенствовании предоставления услуг связи. Заявлен способ указания услуг(и) связи подсистемы IP-мультимедиа, к которой относится сообщение протокола инициирования сеанса, причем способ содержит включение одного или более идентификаторов услуги связи в сообщение протокола инициирования сеанса в качестве тега признака сообщения. 3 н. и 9 з.п. ф-лы, 11 ил.
Область техники, к которой относится изобретение
Настоящее изобретение относится к способу и устройству идентификации услуги подсистемы IP-мультимедиа (IMS), а в частности, для идентификации IMS-услуги, к которой относится IMS-связь или запрос на связь.
Уровень техники
Услуги IP-мультимедиа предоставляют динамическую комбинацию речи, видео, обмена сообщениями, данных и т.д. в рамках одного сеанса. За счет роста числа базовых приложений и форм мультимедийной информации, которые можно комбинировать, число услуг, предлагаемых конечным пользователям, возрастает, и опыт межличностной коммуникации обогащается. Это приводит к новому поколению персонализированных услуг мультимедийной связи с широкими возможностями, в том числе так называемых услуг "комбинированного IP-мультимедиа", которые подробнее рассматриваются ниже.
Подсистема IP-мультимедиа (IMS) - это технология, заданная посредством Партнерского проекта третьего поколения (3GPP), чтобы предоставлять услуги IP-мультимедиа по сетям мобильной связи (3GPP TS 22.228, TS 23.228, TS 24.229, TS 29.228, TS 29.229, TS 29.328 и TS 29.329 редакция 5 и редакция 6). IMS предоставляет ключевые признаки, чтобы расширить возможности межличностной связи конечных пользователей за счет использования стандартизированных средств разрешения IMS-услуг, которые упрощают новые усовершенствованные услуги межличностной связи (клиент-клиент), а также услуги типа "пользователь-содержимое" (клиент-сервер) по IP-сетям. IMS использует протокол инициирования сеанса (SIP) для того, чтобы устанавливать и управлять вызовами или сеансами между абонентскими терминалами (или абонентскими терминалами и серверами приложений). Протокол описания сеанса (SDP), передаваемый посредством служебных SIP-сигналов, используется для того, чтобы описывать и согласовывать мультимедийные компоненты сеанса. Хотя SIP создан как протокол "пользователь-пользователь", IMS позволяет операторам и поставщикам услуг контролировать доступ пользователей к услугам и надлежащим образом выставлять счета пользователям.
Фиг.1 схематично иллюстрирует то, как IMS интегрируется в архитектуру мобильных сетей в случае сети GPRS/PS-доступа. Функции управления вызовами/сеансами (CSCF) работают в качестве SIP-прокси для IMS. Архитектура 3GPP задает три типа CSCF: прокси-CSCF (P-CSCF), которая является первой точкой взаимодействия в IMS для SIP-терминала; обслуживающая CSCF (S-CSCF), которая предоставляет услуги пользователю, на которые подписан пользователь; и опрашивающая CSCF (I-CSCF), роль которой состоит в том, чтобы идентифицировать корректную S-CSCF и перенаправлять в эту S-CSCF запрос, принимаемый от SIP-терминала посредством P-CSCF.
Пользователь регистрируется в IMS с помощью указанного метода SIP REGISTER. Он является механизмом присоединения к IMS и сообщения в IMS адреса, по которому могут быть получены идентификационные данные SIP-пользователя. В 3GPP, когда SIP-терминал выполняет регистрацию, IMS аутентифицирует пользователя и назначает S-CSCF этому пользователю из набора доступных S-CSCF. Хотя критерии назначения S-CSCF не заданы посредством 3GPP, они могут включать в себя требования по совместному использованию и обслуживанию. Следует отметить, что назначение S-CSCF представляет большую важность для управления (и выставления счетов) пользовательским доступом к IMS-услугам. Операторы могут предоставлять механизм недопущения непосредственных SIP-сеансов "пользователь-пользователь", который в противном случае обходит S-CSCF.
В ходе процесса регистрации функция I-CSCF отвечает за выбор S-CSCF, если S-CSCF еще не выбрана. I-CSCF принимает требуемые характеристики S-CSCF из сервера собственных абонентов (HSS) домашней сети и выбирает соответствующую S-CSCF на основе принятых характеристик. (Следует отметить, что назначение S-CSCF также передается для пользователя посредством I-CSCF в случае, если пользователь вызывается посредством другой стороны, и пользователю в данный момент не назначена S-CSCF). Когда зарегистрированный пользователь в дальнейшем отправляет запрос на сеанс в IMS, P-CSCF может перенаправить запрос в выбранную S-CSCF на основе информации, принятой от S-CSCF в ходе процесса регистрации.
В рамках сети IMS-услуг серверы приложений (AS) предоставляются для реализации функциональности IMS-услуг. Серверы приложений предоставляют услуги конечным пользователям в IMS-системе и либо могут быть соединены как конечные точки по определенному проектом 3GPP Mr-интерфейсу, либо могут быть "вовлечены" посредством S-CSCF по определенному проектом 3GPP ISC-интерфейсу. Во втором случае исходные критерии фильтрации (IFC) используются посредством S-CSCF для того, чтобы определять то, какие серверы приложений должны быть "вовлечены" в ходе установления SIP-сеанса. IFC принимаются посредством S-CSCF от HSS в ходе процедуры IMS-регистрации как часть пользовательского профиля.
Фиг.2 иллюстрирует интерфейс управления IMS-услугами (ISC) между AS и S-CSCF, а также другие интерфейсы в IMS. Хотя AS на фиг. 2 показан как имеющий только один интерфейс с S-CSCF, следует принимать во внимание, что на практике ISC-интерфейс распространяется по сети связи, к которой подключены большинство (или все) CSCF-серверы сети данного оператора, позволяя AS обмениваться данными со всеми этими функциями CSCF. (Другие объекты, проиллюстрированные на фиг. 1, должны быть хорошо известны специалистам в данной области техники).
Дополнительный интерфейс (Ut) предусмотрен между AS и абонентским терминалом (TS23.002), хотя он не показан на чертеже. Ut-интерфейс позволяет пользователю управлять информацией, связанной с его услугами, к примеру, созданием и назначением открытых ключей услуг, администрированием политик авторизации, которые используются, например, посредством услуг "присутствия", администрированием политик конференций и т.д.
Раскрытие изобретения
Поскольку требуются IMS-услуги, различные услуги связи, вероятно, требуют различной обработки посредством IMS и посредством абонентских терминалов. Более конкретно:
- различные услуги могут требовать "вовлечения" различных серверов приложений по ISC-интерфейсу;
- сеансы могут маршрутизироваться различным терминалам конечного пользователя, которые данный пользователь зарегистрировал в IMS, в зависимости от услуги, к которой относится сеанс (сопоставление характеристик терминала с типом услуги может быть использовано, например, для того чтобы избежать разветвления);
- различные функциональные объекты в терминале получателя могут быть предназначены для того, чтобы обрабатывать различные услуги (например, PoC и P2P-мультимедиа);
- сетевые операторы могут иметь различные уровни авторизации для различных услуг;
- различные корректные политики авторизации мультимедиа могут быть применены к различным услугам. Например, речь (аудио) в PoC не требует такой же поддержки качества обслуживания в сети, как P2P-мультимедиа, и, соответственно, формы мультимедийной информации назначаются надлежащим образом;
- сетевой оператор может иметь различные правила изменения в зависимости от IMS-услуги;
- требования по межсетевому взаимодействию для услуги (к примеру, отложенный обмен IMS-сообщениями, MMS) могут зависеть от IMS-услуги.
Протокол описания сеанса (SDP) для SIP задает так называемое поле m-строки, которое определяет исходный тип формы мультимедийной информации, которая должна быть использована для IMS-услуги. Например, m-строка может задавать "audio 20000 RTP/AVP 0" или "video 20000 RTP/AVP 0". (Формат m-строки описан в IETF RFC (2327). 20000 - это номер порта, который должен быть использован, а RTP - это протокол. AVP задаются для различных протоколов, и значения, назначаемые AVP, имеют различный смысл в зависимости от протоколов. Конкретное значение, например, может выражать то, какой кодек должен быть использован). Предполагалось, что информация m-строки может быть использована для того, чтобы идентифицировать тип IMS-услуги связи. Тем не менее, успех IMS привел к тому, что имеется ряд различных услуг связи, использующих один и тот же тип формы мультимедийной информации. Например, и PoC, и межличностное мультимедиа может применять тип мультимедийной информации "аудио". Информация m-строки, как результат, не может быть использована для того, чтобы уникально идентифицировать IMS-услугу связи. Эта проблема идентифицирована авторами настоящего изобретения в статье по 3GPP, озаглавленной "IMS Communication Service Identifier (ServID)".
Согласно первому аспекту настоящего изобретения, предусмотрен способ указания услуг(и) связи подсистемы IP-мультимедиа, к которой относится сообщение протокола инициирования сеанса, причем способ содержит включение одного или более идентификаторов услуги связи в сообщение протокола инициирования сеанса в качестве тега признака сообщения, при этом идентификатор услуги связи идентифицирует одну из множества услуг связи.
SIP-сообщение может включать в себя один или более идентификаторов услуг связи в качестве тегов признаков, к примеру, в случае сообщения SIP REGISTER.
Тег признака может быть включен в заголовок Contact, заголовок Accept-Contact или заголовок Reject-Contact в ходе регистрации или в качестве предпочтений вызывающего абонента в ходе установления сеанса либо доставки сообщений для SIP-сообщений, которые не базируются на сеансах, к примеру, сообщения SIP MESSAGE.
Согласно второму аспекту настоящего изобретения, предусмотрен способ идентификации приложения, размещающегося в абонентском терминале, к которому относится сообщение протокола инициирования сеанса, при этом способ содержит включение ссылки на приложение в сообщение протокола инициирования сеанса.
Ссылка на приложение может быть включена в заголовок SIP-сообщения в качестве тега признака, к примеру, в заголовок Contact в сообщениях REGISTER и в заголовки Accept-Contact либо Reject-Contact в других SIP-сообщениях (к примеру, INVITE). Альтернативно, ссылка на приложение может быть включена в качестве a-строки, дополняющей m-строку в SDP-части SIP-сообщения. Ссылки на приложения могут быть включены и как тег признака, и как a-строка в одно SIP-сообщение, к примеру, идентифицирующее главное приложение и вспомогательное приложение соответственно.
Предпочтительный вариант настоящего изобретения комбинирует первый и второй аспекты настоящего изобретения. В абонентском терминале или сетевом IMS-узле, IMS-стек идентифицирует соответствующую услугу связи на основе идентификатора услуги связи, содержащегося в принятом сообщении протокола инициирования сеанса, и перенаправляет сообщение в функциональный (программный) объект, который реализует эту услугу. Этот функциональный объект упоминается в данном документе как услуга связи. Услуга связи, которая принимает идентификаторы сообщений, идентифицирует соответствующее приложение на основе ссылки на приложение, содержащейся в сообщении протокола инициирования сеанса, и перенаправляет сообщение в это приложение.
Согласно третьему аспекту настоящего изобретения, предусмотрен способ, позволяющий множеству услуг связи быть ассоциативно связанными вместе в рамках подсистемы IP-мультимедиа или в абонентском устройстве, при этом способ содержит идентификацию каждой ассоциативно связанной услуги как тега признака в сообщении протокола инициирования сеанса.
Например, изобретение может предоставлять возможность ассоциативного связывания множества одновременных IMS-услуг связи, к примеру, P2P-мультимедиа с обменом IMS-сообщениями, и/или взаимоувязывать IMS-услуги связи с другими одновременными сеансами услуг, к примеру, речи с коммутацией каналов.
В предпочтительном варианте осуществления изобретения этот третий аспект комбинируется с одним или обоими из первого и второго аспектов изобретения.
Другие аспекты изобретения включают в себя:
- абонентские терминалы и сетевые узлы, содержащие средство для вставки в сообщение протокола инициирования сеанса идентификатора услуги связи в качестве тега признака сообщения;
- абонентские терминалы и сетевые узлы, содержащие средство для вставки в сообщение протокола инициирования сеанса ссылки на приложение; и
- абонентские терминалы и сетевые узлы, содержащие средство для вставки в сообщение протокола инициирования сеанса.
Согласно дополнительным аспектам изобретения, один или более новых информационных SIP-элементов (параметров) могут быть стандартизированы так, чтобы передавать одно или более из: идентификатора услуги связи, ссылки на приложение и MCS-спецификатора (идентификатора ассоциативного связывания услуг связи).
Краткое описание чертежей
Фиг.1 схематично иллюстрирует интеграцию подсистемы IP-мультимедиа в системы мобильной связи 3G;
Фиг.2 схематично иллюстрирует конкретные объектные сущности подсистемы IP-мультимедиа, включающие в себя сервер приложений и обслуживающую функцию управления вызовами/режимами;
Фиг.3 иллюстрирует пример сообщения SIP REGISTER, содержащего в себе идентификаторы услуг связи;
Фиг.4 иллюстрирует пример сообщения SIP INVITE, содержащего в себе идентификаторы услуг связи;
Фиг.5 схематично иллюстрирует архитектуру UE, которая применяет идентификаторы услуг связи и ссылки на приложения;
Фиг.6 схематично иллюстрирует архитектуру терминала, в котором одно приложение реализует связь на базе SIP, которая является коммерческой для приложения;
Фиг.7 иллюстрирует пример сообщения SIP REGISTER, содержащего в себе идентификаторы услуг связи и ссылки на приложения;
Фиг.8 иллюстрирует пример сообщения SIP INVITE, содержащего в себе идентификаторы услуг связи и ссылки на приложения;
Фиг.9 схематично иллюстрирует архитектуру UE, которая применяет идентификаторы услуг связи, ссылки на приложения и спецификаторы нескольких услуг связи;
Фиг.10 иллюстрирует пример сообщения SIP INVITE, содержащего в себе идентификаторы услуг связи, ссылки на приложения и спецификаторы нескольких услуг связи; и
Фиг.11 иллюстрирует пример SIP-сообщения, содержащего в себе идентификаторы услуг связи, ссылки на приложения и спецификаторы нескольких услуг связи.
Осуществление изобретения
Возможность идентификации конкретной услуги подсистемы IP-мультимедиа (IMS), к которой относится сообщение протокола инициирования сеанса (SIP), предоставляет ряд преимуществ. Они уже рассмотрены выше. В данном случае предполагается упростить эту идентификацию посредством включения в SIP-сообщение "идентификатора услуги связи", и, в частности, посредством включения идентификатора услуги связи в качестве тега признака.
Соответствующий тег признака включается в один из заголовков Contact (REGISTER), Accept-Contact или Reject-Contact SIP-сообщения в качестве одного из "предпочтений вызывающего абонента". Примеры идентификаторов услуг следующие:
"+g.communication service =+g.p2p.multimedia"
"+g.communication service =+g.poc.talkburst"
"+g.communication service =+g.instant.messaging"
"+g.communication service =+g.deferred.multimedia.messaging",
где, к примеру, суффикс "multimedia" идентифицирует IMS-услугу связи.
Фиг.3 иллюстрирует структуру (частично) сообщения SIP REGISTER, которое идентифицирует услуги связи, которые поддерживаются отправителем сообщения (абонентским устройством), посредством включения идентификаторов услуг связи в заголовок Contact. Теги признаков в сообщениях регистрации оповещают сеть о характеристиках терминала. Сеть (к примеру, в S-CSCF) может использовать эту информацию, чтобы сопоставлять предпочтения вызывающего абонента, выражаемые посредством инициатора SIP-сеанса, с набором зарегистрированных терминалов получателя, который в наибольшей степени соответствует запрошенным предпочтениям вызывающего абонента. В проиллюстрированном примере поддерживаемые услуги следующие: мультимедиа; речевой пакет; и обмен мультимедийными сообщениями. Это сообщение REGISTER отправляется посредством UE в обслуживающую функцию управления вызовами/сеансами (S-CSCF).
Фиг.4 иллюстрирует структуру (частичную) сообщения SIP INVITE, которое используется для того, чтобы начать специализированную IMS-услугу связи. Сообщение INVITE идентифицирует в заголовке Accept-Contact форму мультимедийной информации, поддерживаемую посредством инициирующего UE, т.е. аудио, видео, данные, а также услугу, к которой относится сообщение, т.е. межличностное (P2P) мультимедиа. M-строка SDP-части сообщения указывает то, что первоначально сеансом является сеанс только аудио. Другие формы мультимедийной информации, аудио и данные, идентифицированные в заголовке Accept-Contact, - это формы мультимедийной информации, которые могут быть использованы в сеансе, но не применяются первоначально. Конечным получателем этого сообщения является равноправный UE, идентифицированный посредством примера "SIP URI SIP-URI1@operator.com". Тем не менее, вероятно, что S-CSCF, обслуживающая инициирующий UE, проанализирует сообщение и может принять решение о том, следует или нет перенаправлять сообщение, в зависимости от услуги, идентифицированной посредством идентификатора услуги связи. Если абонент авторизован на то, чтобы использовать услугу P2P-мультимедиа, INVITE перенаправляется принимающему UE (выбранному при необходимости на основе характеристик). Выставление счетов также может инициироваться на базе услуги или SIP AS, вовлеченных в канал SIP-сообщений.
В качестве усовершенствования в описанный подход идентификатор услуг связи в теге признака может быть дополнен номером версии соответствующей услуги.
В типичном UE конкретные (стандартизированные) услуги связи, вероятнее всего, обрабатываются посредством приложений, которые в большинстве случаев предоставляются "специализированно" изготовителями терминалов. Эти приложения могут соответствовать определенным согласованным стандартам и упоминаются в данном документе как приложения "по умолчанию" для стандартизированной IMS-услуги на основе связи. Примеры включают в себя приложения по умолчанию для обработки сеансов P2P-мультимедиа и PoC. Другие приложения, размещающиеся в UE, могут не быть стандартизированными, например, приложения, связанные с играми, или специализированные корпоративные офисные приложения. Фиг.5 иллюстрирует приложения и услуги связи, размещающиеся в UE, поверх IMS-стека.
Полезной является возможность задавать в SIP-сообщении приложение, которое должно быть использовано для того, чтобы обрабатывать конкретную услугу связи, посредством "ссылки на приложение". Это полезно, когда IMS-услуга связи позволяет приложениям обмениваться данными согласно правилам, процедурам и ассоциативно связанным формам мультимедийной информации, заданным для услуги связи. Приложение, которое использует IMS-услугу связи, не реализует часть услуги для SIP-связи, но использует (т.е. "совмещает") услугу связи для этой цели через внутренний интерфейс. Ссылка на приложение идентифицирует приложение, находящееся поверх услуги связи. Также отметим, что приложение может реализовать связь на базе SIP, которая является специализированной для приложения, и в этом случае приложение должно быть идентифицировано с помощью идентификатора услуги связи. Это проиллюстрировано на фиг. 6.
Ссылка на приложение может быть реализована как тег признака или как a-строка, дополняющая m-строку в SDP-части SIP-сообщения. Оба варианта имеют свои преимущества и недостатки.
Ссылка на приложение в качестве тега признака
Включение ссылки на приложение в качестве тега признака имеет преимущество в том, что данный механизм может быть использован для всех SIP-сообщений (т.е. не только для передающих SDP). Этот механизм также указывает получателю конечную точку, для которой должно быть использовано приложение в отношении услуги связи, которая должна быть установлена. Это приложение является "главным" приложением сеанса и управляет добавлением типов мультимедийной информации в него. Тем не менее, такой механизм может быть использован только при установлении сеанса и не подходит для указания "дополняющей функциональности" в ходе установленного сеанса, к примеру, чтобы уточнять, какая передающая среда при RE-INVITE должна быть использована для конкретной функциональности. Например, использование подхода тега признаков само по себе не позволяет задавать выражение, что протокол пересылки сеанса сообщения (MSRP) должен быть использован для Whiteboarding, а не для PictureViewer.
Ссылка на приложение как a-строка, дополняющая m-строку в SDP
Этот механизм имеет преимущество в том, что он может быть использован для того, чтобы указывать "дополняющую функциональность" в установленном SIP-сеансе. Приложение получателя выражается в a-строке, которая следует после m-строки, указывающей первоначальный тип мультимедийной информации, который должен быть использован. Тем не менее, данный механизм может быть использован только для SIP-сообщений, которые передают SDP-тело (к примеру, не для сообщения SIP MESSAGE).
Посредством комбинирования этих двух подходов недостатки могут быть устранены. Соответственно, предлагается предоставить возможность ссылке на приложение быть передаваемой и как тег признака, и в SDP-теле. Тег признака используется для того, чтобы указывать "главное приложение" для сеанса. Для стандартизированных услуг связи оно является "приложением по умолчанию", и ему может быть присвоено то же значение, что и идентификатору услуги связи. Например:
"Communication Service Identifier = P2P Multimedia
Application References P2P Multimedia"
Разумеется, можно опускать ссылку на приложение, когда приложение является приложением по умолчанию.
В приложениях, специализированных для оператора или изготовителя, которые используют стандартизированные услуги связи, ссылка на приложение содержит название этого приложения. Например:
"Communication Service Identifier = P2P Multimedia
Application Reference= OperatorOfficeHelper"
Тег признака всегда используется для того, чтобы указывать приложение получателя, когда тип SIP-сообщения не передает SDP-тело (к примеру, сообщение SIP MESSAGE).
A-строка в SDP-теле используется для того, чтобы дополнять m-строку, чтобы прояснять контекст, в котором используется m-строка, когда тип SIP-сообщения передает SDP-тело (к примеру, INVITE).
Фиг.7 иллюстрирует структуру сообщения SIP REGISTER, где теги признаков, идентифицирующие услуги связи, поддерживаемые посредством отправляющего UE, идентифицируются в заголовке Contact. Фиг.8 иллюстрирует структуру сообщения SIP INVITE для инициирования сеанса между инициирующим UE и UE, идентифицированным посредством SIP URI SIP-URI1@operator.com. Идентификатор услуги связи (+gp2p.multimedia) включается как один тег признака, тогда как ссылка на приложение (+gcommunication service) включается как второй тег признака, чтобы идентифицировать главное приложение. A-строка включается для того, чтобы идентифицировать дополнительное приложение (3gpp.VideoSharing), которое может быть вовлечено в этот же сеанс посредством главного приложения.
Существует потребность в возможности идентифицировать в рамках IMS и в UE параллельные услуги связи (IMS-услуги и другие услуги, к примеру, речь с коммутацией каналов (CS)), которые ассоциативно связаны с приложением. Идентификатор, упоминаемый в данном документе как MCS-спецификатор, предоставляет приложению возможность коррелировать несколько параллельных сеансов IMS-услуг связи (к примеру, P2P-мультимедиа и обмен IMS-сообщениями), а также взаимоувязывать IMS-услуги связи с другими сеансами услуг не-IMS, к примеру, CS-речи.
MCS-спецификатор может быть использован, например, для того, чтобы определять тариф, который должен быть применен к сеансу. В одном примере CS-речь может быть комбинирована с IMS-услугой P2P-мультимедиа для совместного использования видео, реализованного как комбинационная услуга (CSI). Наличие MCS-спецификатора позволяет сети определять это и применять различные правила и ставки по выставлению счетов к IMS-части связи для передачи видео, правила и ставки по выставлению счетов, которые отличаются от применяемых, когда передается видео по IMS в "контексте не-CSI", т.е. IMS в автономном контексте.
Фиг.9 иллюстрирует пример, в котором конкретное приложение, в данном случае специализированное для сетевого оператора справочное приложение OperatorOfficeHelper, использует IMS-услугу связи P2P-мультимедиа и услугу CS-речи. Чтобы иметь содержательную связь, OperatorOfficeHelper должен быть установлен в терминалах, участвующих в сеансе связи. Ссылке на приложение присваивается значение OperatorOfficeHelper, и она кодируется с тегом признака. Идентификатору услуги связи присваивается значение P2P-мультимедиа, а MCS-спецификатору присваивается значение IMS P2P-мультимедиа и CS-речь. Пример этой структуры SIP INVITE, содержащей идентификатор нескольких услуг связи, показан на фиг. 10.
Фиг.11 иллюстрирует пример структуры сообщения SIP MESSAGE, которое может быть отправлено в комбинации с услугами CS-речь и P2P-мультимедиа. В этом примере предполагается, что сообщение SIP MESSAGE отправляется вместе с услугой связи обмена IMS-сообщениями. Сообщение SIP MESSAGE передает следующие параметры:
Communication Service Id = IMS Messaging
Application Reference = OperatorOfficeHelper
MCS-Qualifiers, CS-Speech, P2P Multimedia, IMS Messaging.
Специалисты в данной области техники должны принимать во внимание, что различные модификации вышеописанных вариантов осуществления могут выполняться без отступления от области применения настоящего изобретения. Например, другие механизмы могут быть использованы для того, чтобы выражать идентификаторы услуг связи, ссылки на приложения и MCS-спецификаторы в SIP-сообщениях. В частности, можно задавать новые информационные SIP-элементы (заголовки/параметры) для этой цели.
1. Способ указания услуг(и) связи подсистемы IP-мультимедиа, к которой относится сообщение протокола инициирования сеанса, причем способ содержит этапы, на которых включают один или более идентификаторов услуги связи в сообщение протокола инициирования сеанса, при этом идентификатор услуги связи идентифицирует одну из множества услуг связи, и включают ссылку на приложение в сообщение, при этом ссылка на приложение идентифицирует приложение терминала, которое должно быть использовано для обработки идентифицированных услуг(и) связи; в котором упомянутые один или более идентификаторов услуги связи включаются в сообщение протокола инициирования сеанса в качестве тега признака.
2. Способ по п.1, в котором упомянутый тег признака включается в один из заголовков Contact, Accept-Contact или Reject-Contact сообщения протокола инициирования сеанса.
3. Способ по любому из предшествующих пунктов, в котором упомянутая ссылка на приложение включается в заголовок сообщения протокола инициирования сеанса в качестве тега признака.
4. Способ по п.3, в котором упомянутый тег признака включается в один из заголовков Contact, Accept-Contact или Reject-Contact сообщения протокола инициирования сеанса.
5. Способ по п.1, в котором множество ссылок на приложения включаются в сообщение протокола инициирования и как тег признака, и как а-строка.
6. Способ по п.5, в котором ссылка на приложение, включенная как тег признака, идентифицирует главное приложение, а ссылка на приложение, включенная в а-строку, идентифицирует вспомогательное приложение.
7. Способ управления абонентским терминалом или сетевым IMS-узлом, содержащий этапы, на которых в IMS-стеке идентифицируют соответствующую услугу связи на основе идентификатора услуги связи, содержащегося в принятом сообщении протокола инициирования сеанса, и перенаправляют сообщение в эту услугу, принимают сообщение в идентифицированной услуге связи и идентифицируют соответствующее приложение в абонентском терминале или в сетевом IMS-узле на основе ссылки на приложение, содержащейся в сообщении протокола инициирования сеанса, и перенаправляют сообщение в это приложение.
8. Способ указания услуг(и) связи подсистемы IP-мультимедиа, к которой относится сообщение протокола инициирования сеанса, причем способ содержит этапы, на которых включают один или более идентификаторов услуги связи в сообщение протокола инициирования сеанса, при этом идентификатор услуги связи идентифицирует одну из множества услуг связи, и включают ссылку на приложение в сообщение, при этом ссылка на приложение идентифицирует приложение терминала, которое должно быть использовано для обработки идентифицированных услуг(и) связи; в котором упомянутая ссылка на приложение включается как а-строка, дополняющая m-строку в части описания сеанса сообщения протокола инициирования сеанса.
9. Способ по п.8, в котором упомянутая ссылка на приложение включается в заголовок сообщения протокола инициирования сеанса в качестве тега признака.
10. Способ по п.9, в котором упомянутый тег признака включается в один из заголовков Contact, Accept-Contact или Reject-Contact сообщения протокола инициирования сеанса.
11. Способ по п.8, в котором множество ссылок на приложения включаются в сообщение протокола инициирования и как тег признака, и как а-строка.
12. Способ по п.11, в котором ссылка на приложение, включенная в тег признака, идентифицирует главное приложение, а ссылка на приложение, включенная в а-строку, идентифицирует вспомогательное приложение.
