Групповой доступ к услугам мультимедийной подсистемы на базе ip-протокола

Групповой доступ к услугам мультимедийной подсистемы на базе ip-протокола

Иллюстрации

Показать все

Реферат

Область техники, к которой относится изобретение

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

Уровень техники

Мультимедийная подсистема на базе IP-протокола (IMS) является технологией, заданной партнерским проектом третьего поколения (3GPP), чтобы предоставлять мультимедийные услуги на базе IP-протокола по сетям мобильной связи (3GPP TS 22.228). IMS предоставляет ключевые признаки для того, чтобы расширять возможности межперсональной связи конечных пользователей через интеграцию и взаимодействие услуг. IMS предоставляет возможность нового межперсонального (типа "клиент-клиент") обмена данными, а также обмена данными типа "пользователь-содержимое" (типа "клиент-сервер") по сети на основе IP.

IMS использует протокол инициирования сеанса (SIP) для того чтобы устанавливать и управлять вызовами или сеансами между абонентскими терминалами (UE) или между UE и серверами приложений (AS). Протокол описания сеанса (SDP), передаваемый посредством служебных SIP-сигналов, используется для того, чтобы описывать и согласовывать мультимедийные компоненты сеанса. Хотя SIP создан как протокол "пользователь-пользователь", IMS позволяет операторам и поставщикам услуг контролировать доступ пользователей к услугам и надлежащим образом выставлять счета пользователям. Как SIP, так и SDP переносятся посредством стандартных Интернет-протоколов UDP и TCP. SIP- или SDP-сообщения менее 1300 байтов должны транспортироваться через UDP; в противном случае используется TCP для того, чтобы транспортировать их.

В рамках IMS-сети функции управления вызовами и сеансами (CSCF) выступают в качестве SIP-объектов в рамках IMS. Архитектура 3GPP задает три типа CSCF: прокси-CSCF (P-CSCF), которая является первой точкой взаимодействия в IMS для SIP-терминала; обслуживающая CSCF (S-CSCF), которая предоставляет услуги пользователю, на которые пользователь подписан; и опрашивающая CSCF (I-CSCF), роль которой состоит в том, чтобы идентифицировать корректную S-CSCF и перенаправлять в эту S-CSCF запрос, принимаемый от SIP-терминала посредством P-CSCF.

Функциональность IMS-услуги реализуется с помощью серверов приложений (AS). Для любого данного UE один или более AS могут быть ассоциированы с этим терминалом. AS обмениваются данными с S-CSCF через интерфейс управления IMS-услугами (ISC) и встраиваются в маршрут обмена SIP-сообщениями по мере необходимости (к примеру, в результате запуска iFC, загруженных в S-CSCF для данного UE).

Пользователь регистрируется в IMS с помощью указанного метода SIP REGISTER. Он является механизмом присоединения к IMS и сообщения в IMS адреса, по которому могут быть получены идентификационные данные SIP-пользователя. В 3GPP, когда SIP-терминал выполняет регистрацию, IMS аутентифицирует пользователя с помощью информации по подписке, сохраненной в сервере собственных абонентов (HSS), и выделяет 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-пользователь обладает одними или более конфиденциальными пользовательскими идентификационными данными. Конфиденциальные пользовательские идентификационные данные назначаются посредством оператора собственной сети и используются посредством IMS, например, для целей регистрации, авторизации, администрирования и учета. Эти идентификационные данные принимают форму идентификатора доступа к сети (NAI), как задано в IETF RFC 2486. Можно, чтобы представление международного идентификатора абонента мобильной связи (IMSI) содержалось в NAI для конфиденциальных идентификационных данных. 3GPP TS 23.228 указывает следующие свойства конфиденциальных пользовательских идентификационных данных:

- Конфиденциальные пользовательские идентификационные данные не используются для маршрутизации SIP-сообщений.

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

- Приложение модуля идентификации для услуг мультимедийной подсистемы на базе IP-протокола (ISIM) должно защищенно сохранять конфиденциальные пользовательские идентификационные данные. Не должно быть возможности для UE модифицировать информацию конфиденциальных пользовательских идентификационных данных, сохраненную в ISIM-приложении.

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

- Конфиденциальные пользовательские идентификационные данные должны быть постоянно выделены подписке пользователя (это не динамические идентификационные данные) и являться допустимыми на протяжении длительности подписки пользователя в собственной сети.

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

- Конфиденциальные пользовательские идентификационные данные могут присутствовать в записях системы оплаты на основе компонентов политики оператора.

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

- HSS должен сохранять конфиденциальные пользовательские идентификационные данные.

- S-CSCF должна получать и сохранять конфиденциальные пользовательские идентификационные данные после завершения регистрации и отмены регистрации.

В дополнение к конфиденциальным пользовательским идентификационным данным каждый IMS-пользователь должен иметь одни или более общедоступные пользовательские идентификационные данные (PUI) IMS. PUI используются любым пользователем для того, чтобы запрашивать обмен данными с другими пользователями. Пользователь, например, может включать PUI (но не конфиденциальные пользовательские идентификационные данные) на визитную карточку. 3GPP TS 23.228 указывает следующие свойства PUI:

- Как нумерация в системах связи, так и схемы именования в Интернете могут использоваться для того, чтобы адресовать пользователей в зависимости от PUI, которые имеют пользователи.

- PUI должны принимать форму SIP URI (как задано в RFC 3261 и RFC 2396) или формата "tel:"-URI, заданного в RFC 3966.

- ISIM-приложение должно защищенно сохранять, по меньшей мере, одни PUI (не должно быть возможности для UE модифицировать PUI), но необязательно, чтобы все дополнительные PUI сохранялись в ISIM-приложении.

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

- PUI должны быть зарегистрированы явно или неявно до завершения IMS-сеансов, и несвязанные с завершением IMS-сеансов процедуры могут доставляться в UE пользователя, которому принадлежит PUI.

- Должна быть возможность регистрировать глобально (т.е. через один универсальный запрос к UE) пользователя, который имеет несколько PUI, через механизм в IMS (к примеру, с использованием неявного регистрационного набора). Это не должно препятствовать регистрации по отдельности пользователем некоторых из его PUI при необходимости.

- PUI не аутентифицируются посредством сети в ходе регистрации.

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

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

IMS-пользователь имеет одну или более IMS-подписок. IMS-подписка имеет конфиденциальные пользовательские идентификационные данные и, по меньшей мере, один профиль услуг. Профиль услуг содержит, по меньшей мере, одни общедоступные пользовательские идентификационные данные. Общедоступные пользовательские идентификационные данные могут быть ассоциированы только с одним профилем услуг, тогда как конфиденциальные пользовательские идентификационные данные могут быть ассоциированы больше чем с одним профилем услуг. Фиг.1 схематично иллюстрирует примерные взаимосвязи между пользователем IMS, его IMS-подписками и общедоступными и конфиденциальными пользовательскими идентификационными данными. В показанном примере абонент имеет два вида конфиденциальных пользовательских идентификационных данных, каждый из которых ассоциирован с одной IMS-подпиской, и оба ассоциированы с двумя видами общедоступных пользовательских идентификационных данных (при этом один из видов общедоступных пользовательских идентификационных данных, общедоступные пользовательские идентификационные данные-2 ассоциированы с обоими видами конфиденциальных пользовательских идентификационных данных). Профиль услуг ассоциирован с каждыми общедоступными пользовательскими идентификационными данными, причем этот профиль указывает данные об услугах для ассоциированных общедоступных пользовательских идентификационных данных. Профиль услуг создается или модифицируется, когда сервер приложений подготавливается к использованию для пользователя в сервере собственных абонентов (HSS). Каждый профиль услуг содержит один или более критериев начальной фильтрации (iFC), которые используются для того, чтобы инициировать подготовку к работе или ограничение IMS-услуг. Различия между услугами, предлагаемыми посредством профиля услуг-1 и профиля услуг-2, зависят от оператора, но могут заключать в себе различные серверы приложений (AS) и даже различные схемы тарификации/оплаты.

В примере общедоступные пользовательские идентификационные данные-1 ассоциированы с профилем услуг-1, тогда как общедоступные пользовательские идентификационные данные-2 и общедоступные пользовательские идентификационные данные-3 ассоциированы с профилем услуг-2. В типичном сценарии общедоступные пользовательские идентификационные данные-1 могут быть идентификационными данными, которые пользователь предоставляет друзьям и семье, к примеру "Big_Joe@priv.operator.com", тогда как общедоступные пользовательские идентификационные данные-2 и общедоступные пользовательские идентификационные данные-3 могут быть идентификационными данными, которые пользователь предоставляет деловым контактам, к примеру, "+46111222333@operator.com" и "joe.black@operator.com".

3GPP задает понятие так называемого неявного регистрационного набора для того, чтобы идентифицировать набор PUI, которые работают как группа и регистрация которых выполняется и отменяется совместно, когда любые из PUI набора регистрируются или их регистрация отменяется. После регистрации терминала IMS-пользователя или после приема запроса на установление соединения для терминала пользователя, когда еще не зарегистрирован, S-CSCF после запуска посредством I-CSCF запрашивает сведения по подписке (также обозначаемые как пользовательский профиль) от HSS, идентифицированного посредством конфиденциальных и общедоступных пользовательских идентификационных данных, принимаемых в триггере от I-CSCF. Как описано выше, подписка (пользовательский профиль) содержит один или более профилей услуг, и каждый профиль услуг содержит один или более видов общедоступных пользовательских идентификационных данных. См., например, пользовательский профиль 1 на фиг.1. Все общедоступные пользовательские идентификационные данные в пользовательском профиле совместно обозначаются как неявный регистрационный набор.

Для понимания, более подробное описание стандартной процедуры регистрации приводится далее со ссылкой на фиг.2. Прежде чем UE может устанавливать сеанс или включать IMS-услуги, оно должно регистрироваться в IMS. В следующем примере Joe Black регистрируется под своими общедоступными идентификационными данными "Big_Joe@operator1.com" в IMS оператора 1, где он имеет IMS-подписку. Фиг.1 приводит общее представление сообщений. Фактический процесс регистрации состоит из 2 фаз. В первой фазе незащищенная регистрация отправляется в S-CSCF. S-CSCF аутентифицирует UE/PUI на первом этапе и отправляет отклик обратно в UE с помощью SIP-сообщения 401. UE использует отклик для того, чтобы вычислять ответ, который отправляется в последующем сообщении REGISTER для фазы 2 регистрации. Помимо вычисления ответа этот промежуточный этап между этими двумя фазами также используется посредством UE для того, чтобы согласовывать защищенный IP-канал (IP-Sec) с P-CSCF. Когда S-CSCF принимает вторую регистрацию, она завершает авторизацию и регистрирует UE/PUI. Когда регистрация заканчивается, SIP-сообщение 200 отправляется обратно в UE. После завершения регистрации S-CSCF дополнительно регистрирует PUI во всех релевантных IMS-приложениях, как указано посредством iFC в пользовательском профиле, полученном из HSS.

Прежде чем UE может ассемблировать сообщение REGISTER, оно должно обнаруживать IP-адрес P-CSCF. Этот адрес может быть сохранен в UE, но более вероятно только псевдоним P-CSCF сохраняется, и UE требует получения корректного IP-адреса через DHCP и/или DNS. UE затем ассемблирует сообщение REGISTER и отправляет его в P-CSCF. Сообщение (1 по фиг.2) приводится ниже в упрощенной форме. Поясняются только поля, релевантные для описания настоящего изобретения,.

Тип сообщения - это REGISTER. Cseq и Call-ID (Идентификатор вызова) задают уникальный идентификатор этой транзакции регистрации. Сообщение, по сути, является только заголовком сообщения без рабочих данных (таких как речевые или видеопакеты), следовательно, Content-Length (Длина содержимого) задается равным 0. Начальный адресат задается посредством "SIP: operator1.com", поскольку именно здесь UE хочет регистрироваться. Поле From (От) предоставляет общедоступные пользовательские идентификационные данные Joe Black, которые он хочет использовать. Поле To (В) является идентичным, поскольку именно для него запрашивается начальная регистрация. Поле Contact (Контакт) содержит текущий IP-адрес UE, expires (истекает) указывает оставшийся период аренды, когда IP-адрес арендуется на определенный период времени. Оно указывает, как долго SIP URI в поле To привязан к IP-адресу в поле Contact.

Поле Route (Маршрут) содержит каждый раз следующий SIP-объект, в который отправляется сообщение. Каждый SIP-объект, через который проходит сообщение, добавляет себя в заголовок Via (Через), чтобы создавать тем самым обратный канал. Max-Forwards (Максимальное число перенаправлений) уменьшается на единицу после прохождения каждого SIP-объекта, чтобы предотвращать то, что сообщение начинает "прыгать" в IP-сети. Когда значение становится равным 0, сообщение удаляется.

Когда сообщение достигает P-CSCF, P-CSCF удаляет свой адрес из заголовка Route и помещает его в заголовок Via. Затем P-CSCF начинает анализ того, в какую I-CSCF следует перенаправлять сообщение. Эта I-CSCF может быть в другой сети другого оператора. Следовательно, она использует запрошенный URI в поле REGISTER и DNS для того, чтобы разрешать доменное имя, и последующие запросы DNS, NAPTR, SRV и AAAA, для того чтобы получать I-CSCF адрес. P-CSCF, тем не менее, может не знать точно то, будет ли I-CSCF выполнять функцию SIP-объекта или выступать только в качестве маршрутизатора к еще одной другой I-CSCF. Следовательно, она помещает адрес не в поле маршрута, а в поле адресата базового UDP-сообщения, которое транспортирует регистрационное SIP-сообщение. Дополнительно P-CSCF включает в себя поле Path (Путь) с собственными идентификационными данными. S-CSCF может использовать поле Path в качестве точного местоположения для того, чтобы отправлять все будущие ответы в UE, поскольку само UE защищено, P-CSCF является входом защищенного IP-туннеля в UE. Отправка сообщения 2 в таком случае выглядит следующим образом:

Когда принято, I-CSCF помещает свой адрес в заголовок Via. Затем она требует получения адреса S-CSCF. Поэтому она выполняет запрос 3 информации о местоположении в HSS. HSS отвечает с помощью ответа 4 с информацией о местоположении. Затем он использует полученный адрес S-CSCF или определяет адрес S-CSCF и помещает в поле Route. Сообщение 5 теперь выглядит следующим образом:

Теперь, когда S-CSCF приняла сообщение, она начинает сначала с верификации того, возможна ли запрошенная регистрация, известен ли PUI. Поэтому она выполняет запрос 6 информации о местоположении в HSS. HSS отвечает с помощью ответа 7 с информацией о местоположении. PUI известен, но регистрация запрещена, поскольку полная аутентификация еще не выполнена. Следовательно, S-CSCF отправляет 401 сообщение непрохождения авторизации обратно в UE. Это сообщение содержит поле WWW-аутентификации, которое содержит ключи оклика. Полные сведения по аспектам аутентификации и безопасности можно найти в 3GPP TS 33.203 и RFC 3329.

Сообщение следует по такому же маршруту обратно в UE через сообщения 8, 9 и 10. Обратный маршрут указывается посредством полей Via, ассемблированных в ходе транспортировки в S-CSCF. Каждый SIP-объект удаляет первый заголовок Via (являющийся собой) и маршрутизирует в следующий заголовок Via. Помимо этого, I-CSCF включает в себя поле Service-Route (Маршрут услуги). UE может использовать его для всех остальных сообщений, затем сообщения REGISTER, так что P-CSCF освобождается от выполнения трудоемкой задачи выделения корректного I-CSCF каждый раз.

UE, принимающее сообщение непрохождения авторизации 401, теперь продолжает согласование защищенного IP-туннеля с P-CSCF. Затем оно вычисляет ответ для P-CSCF и ответ для S-SCSF. При этом первый служит для установления защищенного соединения с P-CSCF, а второй - для завершения авторизации и выполнения регистрации посредством S-CSCF. Ответы UE содержатся в поле авторизации второго сообщения REGISTER. Следующая последовательность сообщений 11, 12, 13, 14 и 15 идентична предыдущей последовательности сообщений REGISTER 1, 2, 3, 4 и 5.

S-CSCF далее проверяет то, является ли корректным ли ответ на оклик, и затем продолжает запрос 16 информации о местоположении к HSS. HSS отвечает с помощью ответа 17 с информацией о местоположении. Ответ содержит пользовательский профиль, определенный посредством HSS на основе конфиденциальных пользовательских идентификационных данных и общедоступных пользовательских идентификационных данных, представленных в запросе посредством S-CSCF. Пользовательский профиль предоставляет в S-CSCF неявный регистрационный набор всех общедоступных пользовательских идентификационных данных, которые ассоциированы с конфиденциальными пользовательскими идентификационными данными, включая профили услуг, ассоциированные с PUI. Эти PUI, таким образом, неявно регистрируются с PUI в сообщении REGISTER. IP-адрес UE привязан к PUI на период, не превышающий период, который выражен в поле истечения срока действия сообщения REGISTER. Этот период может быть меньше в зависимости от политики оператора в отношении максимального периода регистрации.

Первый этап теперь состоит в том, что S-CSCF отправляет сообщение 200 OK в UE таким же образом, как сообщение 401 непрохождения авторизации. Эта последовательность сообщений указывается посредством сообщений 18, 19 и 20.

В качестве второго этапа S-CSCF использует поля iFC в профилях услуг, содержащихся в пользовательском профиле, чтобы регистрировать PUI сообщения REGISTER в IMS-приложениях, как указано в полях iFC. Отметим, что приложение информируется только на предмет одного PUI в сообщениях 21 REGISTER для приложений. Для получения информации о других неявно зарегистрированных PUI они должны подписываться на информацию по состоянию регистрации (изменению) в S-CSCF. Аналогично, UE должно подписываться непосредственно после получения сообщения 200 OK, чтобы получать информацию по состоянию регистрации других неявно зарегистрированных PUI.

Вышеописанная регистрация упрощена до основ, необходимых для того, чтобы понимать преимущества настоящего изобретения. Для дополнительных подробностей следует обратиться к справочникам современного уровня техники, таким как "The IMS" ISBN 978-0-470-01906-1.

В случае Joe Black, описанном ранее, один пользователь имеет одну подписку с несколькими PUI. Другой возможный случай использования IMS заключает в себе совокупность пользователей, имеющих подписку уровня группы на IMS, но при этом сами отдельные пользователи не имеют подписки. В общем, группа защищена посредством точки доступа, которая управляет обработкой SIP-сеансов для IMS от имени группы. Вместо группы в IMS регистрируется точка доступа, в отличие от UE. Тем не менее, желательно или даже необходимо давать возможность прямого внутреннего и внешнего дозвона к этим пользователям. Это может иметь место, например, в случае, если организация имеет подписку на IMS и имеет отдельные станции или терминалы сотрудников, присоединенные к частной телефонной станции на базе IP (IP-PBX). Терминалы сотрудников могут иметь или не иметь поддержку SIP-клиентов. Во втором случае IP-PBX выполняет трансляцию между обменом служебными сигналами согласно стандарту SIP и без использования SIP. Хотя, конечно, может быть возможным для IMS записывать отдельные PUI для каждого терминала (в рамках того же неявного регистрационного набора), это становится неэффективным по мере того, как размер группы возрастает. ETSI TISPAN задает такую корпоративную сеть как корпоративная сеть следующего поколения (NGCN).

Альтернативное решение схематично проиллюстрировано на фиг. 3 и 4, которые показывают IP-PBX (обозначенные "IP-PBX1" и "IP-PBX2") в качестве точки доступа, которая обслуживает множество пользовательских терминалов. Один вызывающий терминал показан как добавочный номер 1234, и один показан как "Добавочн. 5678". Первый терминал запрашивает сеанс ко второму. Пользователи в организации 1 и 2 имеют специализированное приложение организации магистральных коммерческих сетей (BT-AS) в IMS. Это приложение требует наличия идентификационных данных вызывающей/инициирующей стороны или вызываемой/завершающей стороны, чтобы предоставлять определенные услуги. Это решение использует так называемые идентификационные данные общедоступных услуг (PSI), которые идентифицируют общедоступные сетевые IMS-услуги для пользователей. Решение задает в пределах HSS, в профиле услуг подписки для IP-PBX, PSI с подстановочными символами, которые совпадают с PUI, указанными для терминалов, принадлежащих IP-PBX, предоставляя доступ к определенным приложениям в IMS. Решение предоставляет метод "обхода ошибки" для случаев вызывающей и вызываемой стороны с использованием PSI вместе с BT-AS для целей межпользовательских сеансов. Регистрация IP-PBX1 и 2 идентична регистрации стандартного UE, в котором IP-PBX регистрируется в собственных PUI.

Фиг.3 иллюстрирует решение методом "обхода ошибки" для случаев инициирующей (вызывающей) стороны, т.е. когда терминал в рамках PBX инициирует вызов к удаленному терминалу. IP-PBX1 принадлежит организации 1 и имеет в качестве собственных PUI "PBX1@operator1.com". IP-PBX1 имеет в качестве группового кода 850, а в качестве диапазона номеров - +31 161 24 xxxx. Сотрудник Alice запрашивает, чтобы устанавливать сеанс от своего терминала с добавочным номером 1234 с Bob в организации 2, имеющим добавочный номер 5678 в рамках IP-PBX2 с групповым кодом 851, заданным посредством IP-PBX1.

Запрос 101 от Alice принимается в IP-PBX1, которая ассемблирует исходящий запрос 102 в направлении P-CSCF. Формат сообщения выглядит следующим образом:

Когда принято, исходящая P-CSCF не распознает P-Preferred-Identity, содержащиеся в INVITE. Она использует в качестве P-Asserted-Identity по умолчанию PUI IP-PBX1, а именно "pbx1@operator1.com". Сообщение 103, теперь отправляемое посредством P-CSCF в S-CSCF, выглядит следующим образом:

В S-CSCF используется P-Asserted-Identity сообщения для того, чтобы проверять пользовательский профиль IP-PBX1, и находит профиль услуг с iFC, сообщающими S-CSCF привлекать BT-приложение. S-CSCF, следовательно, отправляет принятое сообщение 104 INVITE в BT-приложение. Сервер BT-приложений проверяет достоверность и подтверждает, что инициирующий пользователь - это пользователь, который идентифицирован в заголовке "From", и заменяет заголовок P-Asserted-Identity идентификационными данными вызывающего пользователя, а именно, "tel:+31161241234". BT-приложение возвращает сообщение 105 INVITE, модифицированное с помощью нового подтвержденного идентификатора для Alice. Сообщение теперь выглядит следующим образом:

Возвращаясь в S-CSCF, необходимо выполнить поиск 106 ENUM для того, чтобы преобразовывать запрошенный Tel URI в известный SIP URI. Приспособленное сообщение 107 INVITE затем отправляется в функцию управления на сопряженной границе (I-BCF) оператора 1 для дополнительной транспортировки в сеть оператора 2. В завершение, сообщение INVITE выглядит следующим образом:

Дополнительно ссылаясь на фиг.4, сообщение INVITE поступает в I-BCF оператора 2. Она должна перенаправлять сообщение как принятое 201 в I-CSCF. I-CSCF распознает URI SIP-запроса, соответствующий номеру телефона, и преобразует его в Tel URI. В этом примере соединения Alice с Bob, URI SIP-запроса - это "sip:+31161255678@operator2.com, user=phone", и он преобразуется в Tel URI "Tel: +31161255678". I-CSCF затем отправляет запрос 202 информации о местоположении в HSS согласно обычным процедурам IMS. HSS определяет, что Tel URI совпадает с подстановочными символами PSI, и отвечает с помощью ответа 203 с информацией о местоположении в I-CSCF с идентификационными данными выделенной S-CSCF. Здесь используется такой же механизм, который используется для еще незарегистрированного терминала, подписанного, по меньшей мере, на одно приложение. I-CSCF перенаправляет сообщение 204 SIP в выделенную S-CSCF. Сообщение в таком случае выглядит следующим образом:

Далее S-CSCF действует так, как действовала бы для еще незарегистрированного терминала. Она получает пользовательский профиль от HSS, который содержит, по меньшей мере, один профиль услуг с совпадающим PSI с подстановочными символами от HSS. Этот профиль включает в себя iFC-триггер, который инструктирует S-CSCF маршрутизировать сообщение 205 в сервер приложений организации магистральных коммерческих сетей (BT-AS). Сервер приложений заменяет URI SIP-запроса "Tel: +31161255678" на адрес IP-PBX2, а именно "pbx2@operator2.com" и вставляет адрес назначения в поле заголовка "To", удаляя предыдущее содержимое, которое в таком случае теряется. Возвращенное сообщение 206 после этого выглядит следующим образом:

Поскольку теперь новый URL находится в запрошенном поле INVITE, S-CSCF должна перенаправлять сообщение 207, принятое от BT-AS, в I-CSCF, поскольку URI запроса изменился, и, следовательно, новая завершающая сторона становится целевой. После этого сообщение поступает в дополнительную I-CSCF, которая выполняет запрос 208 информации о местоположении к HSS, чтобы определять S-CSCF, выделенную для IP-PBX2, перед доставкой сообщения в эту выделенную S-CSCF. HSS предоставляет ответ 209 с информацией о местоположении, и I-CSCF перенаправляет сообщение 210 INVITE в S-CSCF.

Поскольку IP-PBX2, вероятнее всего, уже зарегистрирован, S-CSCF знает контактный адрес для IP-PBX2. Перед отправкой запроса INVITE в P-CSCF на предмет IP-PBX2 сначала iFC в профилях услуг пользовательского профиля для IP-PBX2 проверяются на предмет триггеров дополнительных IMS-приложений, указанных в качестве параметра посредством сообщения 211 и возвращаемого сообщения 212. Когда нет триггеров или после ответа последнего приложения, S-CSCF добавляет контактный адрес для IP-PBX2 в качестве нового запрошенного URI. Чтобы сохранять старый URI, "pbx2@operator2.com", S-CSCF добавляет P-Called-Party-Id, содержащий этот URI. Сообщение 213, перенаправленное в P-CSCF, теперь выглядит следующим образом:

P-CSCF перенаправляет сообщение 214 в IP-PBX2, как инструктировано в заголовке INVITE. IP-PBX2 отвечает за установление подключения к терминалу Bob через корпоративную сеть организации 2. В случае если терминал адресата является SIP-терминалом, по получении сообщения IP-PBX2 может осуществлять доставку сообщения в терминал, на основе адреса, содержащегося в поле заголовка "To". Если терминал адресата не является SIP-терминалом, то терминал IP-PBX2 должен обрабатывать завершение согласно определенной конкретной для приложения логике.

Решение методом "обхода ошибки", проиллюстрированное на фиг.2, имеет недостаток в том, что требуется два обхода CSCF в совокупности. Это приводит к увеличению времени прохождения сообщения. Помимо этого, информация, первоначально содержащаяся в заголовке "To", теряется, как и исходный URI-запрос, который вставлен вызывающим абонентом. Без первоначального заголовка "To" определенные приложения в вызываемом терминале могут не функционировать. Помимо этого, метод "обхода ошибки" требует того, чтобы BT-приложение или что-либо с аналогичной функцией было доступным, чтобы иметь возможность создавать корректный P-Asserted-ID.

Вместо IP-PBX, как задано в этом методе "обхода ошибки", компания может использовать стандартный SIP прокси-сервер согласно RFC 3261 для мобильных терминалов с поддержкой SIP. Также в этом случае компания может иметь групповую подписку на IMS вместо отдельных подписок. Базовые операции для SIP-прокси-сервера идентичны операциям для IP-PBX в том, что для случая завершения вызова, запрошенный URI должен содержать адрес SIP-прокси-сервера. Именно SIP-прокси-серверу должен извлекать конечного адресата из заголовка "To".

Основная проблема вышеописанного метода "обхода ошибки" состоит в том, что исходный запрошенный URI заменяется на IP-PBX или адрес SIP-прокси-сервера в случае групповых подписок. Чтобы иметь возможность маршрутизировать сообщение INVITE конечному адресату, требуются модификации в IP-PBX или SIP-прокси-сервере, которые работают согласно стандарту RFC 3261, поскольку этот стандарт предполагает, что конечный адресат будет в запрошенном URI.

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

Сущность изобретения

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

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

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

Описание дополнительно раскрывает различные типы функциональных инструкций.

Дополнительный аспект описания раскрывает усовершенствованное решение проблемы, касающейся запрошенного URI в завершающих запросах INVITE, при обслуживании пользователей в рамках корпоративной IP-PBX по стандарту RFC 3261 стандартный или SIP-прокси-сервера, имеющих одну подписку, применяя функциональные инструкции в этой подписке. Усовершенствованное решение содержит инструкцию для S-CSCF, чтобы копировать запрошенный URI в заголовок P-Called-Party-Identity и заменять запрошенный URI на контактный адрес точки доступа.

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

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

В третьем примере это усовершенствованное решение осуществляется посредством включения в неявный регистрационный набор, ассоциированный с подпиской, общедоступных пользовательских идентификационных данных с подстановочными символами. "С подстановочными символами" или "подстановочные символы" следует понимать здесь как означающий общедоступные пользовательские идентификационные данные, которые содержат символ или символы, которые поддерживают один или более неопределенных знаков. Общедоступные пользовательские идентификационные данные с подстановочными символами должны иметь профиль услуг, ассоциированный с ними. Любой узел в мультимедийной подсистеме на базе IP-протокола, которая выполняет проверки или обработку на основе неявного регистрационного набора, должен действовать в соответствии с принимаемыми общедоступными пользовательскими идентификационными данными, совпадающими с общедоступными пользовательскими идентификационными данными с подстановочными символами таким же образом, как если бы принимаемые общедоступные пользовательские идентификационные данные совпадали с какими-либо стандартными общедоступными пользовательскими идентификационными данными в рамках неявного регистрационного набора. Вместо представления диапазона общедоступных пользовательских идентификационных данных с использованием общедоступных пользовательских идентификационных данных с подстановочными символами такой диапазон может быть представлен посредством субдомена. Например, диапазон Tel URI может быть представлен посредством префикса набора номера, тогда как диапазон SIP URI может быть представлен посредством корпоративного домена.

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