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

Изобретение относится к системам мультимедийных услуг. Технический результат заключается в упрощении доступа к услугам мультимедийной подсистемы на базе IP-протокола группами пользователей, которые требуют альтернативной обработки относительно стандартной обработки пользователей мультимедийной подсистемы на базе IP-протокола. Функциональные инструкции добавляются в подписку группы пользователей, сохраненную в мультимедийной подсистеме на базе IP-протокола, инструктирующие узлам в мультимедийной подсистеме на базе IP-протокола приспосабливать свое стандартное функционирование к этой конкретной группе пользователей. Инструкции в подписке конкретной группы пользователей предоставляют узел мультимедийной подсистемы на базе IP-протокола, которая более не должна быть конкретной для определенных типов пользователей, но имеет стандартный способ работы, который модифицируется посредством инструкций для специализированной работы только для конкретной группы пользователей. 6 н. и 9 з.п. ф-лы, 11 ил.

 

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

Настоящее изобретение относится к групповому доступу к услугам мультимедийной подсистемы на базе 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 могут быть идентификационными данными, которые пользователь предоставляет друзьям и семье, к примеру "[e-mail]", тогда как общедоступные пользовательские идентификационные данные-2 и общедоступные пользовательские идентификационные данные-3 могут быть идентификационными данными, которые пользователь предоставляет деловым контактам, к примеру, "[e-mail]" и "[e-mail]".

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

Для понимания, более подробное описание стандартной процедуры регистрации приводится далее со ссылкой на фиг.2. Прежде чем UE может устанавливать сеанс или включать IMS-услуги, оно должно регистрироваться в IMS. В следующем примере Joe Black регистрируется под своими общедоступными идентификационными данными "[e-mail]" в 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 "[e-mail]". 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, а именно "[e-mail]". Сообщение 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:[phone]". 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:[e-mail], user=phone", и он преобразуется в Tel URI "Tel: [phone]". 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: [phone]" на адрес IP-PBX2, а именно "[e-mail]" и вставляет адрес назначения в поле заголовка "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, "[e-mail]", 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, чтобы изменять их стандартный способ функционирования на этот альтернативный способ, содержатся в подписке. В качестве дополнительного варианта подписка может содержать специальную инструкцию, разрешающую обновление определенных элементов подписки при регистрации абонентского устройства или узла доступа на эту подписку.

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

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

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

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

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

Краткое описание чертежей

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

Фиг.2 схематично иллюстрирует стандартную процедуру регистрации в IMS согласно предшествующему уровню техники.

Фиг.3 схематично иллюстрирует решение методом "обхода ошибки" предшествующего уровня техники для случая исходящего вызова в рамках архитектуры IMS согласно предшествующему уровню техники.

Фиг.4 схематично иллюстрирует решение методом "обхода ошибки" предшествующего уровня техники для случая входящего вызова в рамках архитектуры IMS согласно предшествующему уровню техники.

Фиг.5 схематично иллюстрирует архитектуру IMS с последовательностью служебных сигналов при регистрации для IP-PBX согласно варианту осуществления настоящего изобретения.

Фиг.6 схематично иллюстрирует архитектуру IMS с последовательностью служебных сигналов при регистрации для SIP-прокси-сервера согласно варианту осуществления настоящего изобретения.

Фиг.7 схематично иллюстрирует архитектуру IMS с последовательностью служебных сигналов при регистрации для SIP-прокси-сервера с обновлением на основе регистрации.

Фиг.8 схематично иллюстрирует архитектуру IMS с последовательностью служебных сигналов для вызывающей стороны для IP-PBX согласно варианту осуществления настоящего изобретения на основе инициирующего Tel URI.

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

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

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

Подробное описание изобретения

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

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

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

Фактический режим работы IMS относительно точки доступа должен быть определен самое позднее при регистрации. До этого момента IMS может иметь независимый (стандартный) от UE режим работы. С другой стороны, все узлы CSCF в IMS, а также другие узлы, такие как HSS, не должны быть приспособлены осуществлять только специальные функции. Они должны приспосабливать эти режимы работы для URI, обслуживаемого в этот момент, а не только обслуживать специальный URI. Это должно сохранять возможность балансирования нагрузки во всей IMS.

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

Первая ситуация регистрации показана на фиг.5, где PBX, IP-PBX1, регистрируется от имени группы терминалов. Собственные идентификационные данные IP-PBX1 - это "[e-mail]". Диапазон номеров для представленной группы - это +31 161 24 XXXX. Номера сообщений на фиг.5 совпадают с номерами по фиг.2. Последовательность сообщения является полностью идентичной; IP-PBX регистрируется таким же образом, как UE на фиг.2. Основное различие состоит в том, что подписка теперь содержит элементы, которые заставляют IMS работать в другом режиме для обычного UE. Первое отличие состоит в том, что вместо обычных PUI теперь подписка в HSS для IP-PBX1 содержит PUI с подстановочными символами в дополнение к URI собственной IP-PBX1. В этом конкретном случае URI с подстановочными символами - это Tel URI; "tel: [phone]!*!" Последовательность символов !*! указывает любое число из 4 цифр. Любой Tel URI, который совпадает с подстановочными символами, неявно регистрируется, когда IP-PBX1 регистрируется под своими основными PUI "[e-mail]". Вместо одного URI с одним подстановочным символом также могут использоваться поддиапазоны чисел в комбинации с Tel URI без подстановочных символов. Это должно давать возможность использовать различные профили услуг для различных поддиапазонов или выделенных чисел. Тем не менее, следует обращать внимание на то, что любой совпадающий URI всегда имеет только один ассоциированный профиль услуг. Хотя теперь упрощается то, что посредством неявной регистрации терминалы в рамках IP-PBX1 по-прежнему распознаются посредством IMS, сообщение от IMS должно проходить через IP-PBX, которая, в свою очередь, передает их в терминалы. Это может включать в себя модификацию сообщений вследствие ограничений корпоративной сети. Поскольку основные процедуры с помощью SIP-сообщений могут не изменяться, значение полей, тем не менее, может быть модифицировано для целей приспосабливания к потребностям IP-PBX1, пока базовые операции IMS не подвержены риску. На практике эти модификации ограничены P-CSCF и S-CSCF, поскольку сообщения REGISTER исключаются. Подробный способ реализации посредством наборов правил приводится в конце подробного описания.

Вторая ситуация регистрация представлена посредством фиг.6. Здесь корпоративный SIP-прокси-сервер регистрируется от имени SIP-терминалов, подключенных к нему через корпоративную сеть. Диапазон URI для SIP-терминалов - это "[e-mail]". Собственные PUI SIP-прокси-сервера - это "[e-mail]". Прокси-сервер может быть сервером согласно стандарту RFC 3261 или может быть специально приспособлен для потребностей корпоративной сети. Также регистрация полностью сопоставима с регистрацией обычного UE. Прокси-сервер регистрирует себя аналогично UE. Номера сообщений на фиг. 6 соответствуют номерам по фиг.2 и 5. Помимо этого, различие состоит в подписке. Что касается IP-PBX, подписка также содержит после собственных PUI прокси-сервера PUI с подстановочными символами. В общей форме, это подстановочные символы SIP URI, которые могут быть аналогичными "!#!@enterprise1.com". Символы !#! означают строку из алфавитно-цифровых символов. Кроме того, любой SIP URI, совпадающий с подстановочными символами SIP URI, неявно регистрируется, когда регистрируется сам прокси-сервер.

Также здесь могут использоваться алфавитно-цифровые поддиапазоны, задавая смешивание SIP URI с подстановочными символами и SIP URI без подстановочных символов, которые могут быть ассоциированы с различными профилями услуг. Одним подходящим примером является пример администратора, имеющего SIP URI без подстановочных символов специальных iFC, чтобы иметь возможность задавать параметры в IMS-приложениях. Хотя не упомянуто, также Tel URI может быть добавлен либо как имеющий подстановочные символы либо как не имеющий подстановочных символов, как описано выше для фиг.5.

Третья ситуация регистрация представлена посредством фиг.7. Здесь корпоративный SIP-прокси-сервер регистрируется от имени SIP-терминалов, подключенных к нему через корпоративную сеть. Диапазон URI для SIP-терминалов - это "[e-mail]". Собственные PUI SIP-прокси-сервера - это "[e-mail]". Прокси-сервер может быть сервером согласно стандарту RFC 3261 или может быть специально приспособлен для потребностей корпоративной сети. Также регистрация полностью сопоставима с регистрацией обычного UE. Прокси-сервер регистрирует себя аналогично UE. Номера сообщений на фиг. 7 соответствуют номерам по фиг.2, 5 и 6. Сообщения, которые отличаются, имеют "a" в качестве суффикса.

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

Хотя профиль обновляется в S-CSCF, HSS опрашивается посредством I-CSCF в случаях вызываемой/завершающей стороны. Для этого требуется, чтобы HSS содержал, по меньшей мере, максимум PUI с подстановочными символами, чтобы иметь возможность распознавать, что терминал обслуживается посредством точки доступа, и выделять надлежащий S-CSCF для него.

Обновления могут иметь форму готового пользовательского профиля или его конкретных элементов. Более подробные примеры приводятся в конце подробного описания. Информация обновления должна содержаться в регистрационных сообщениях SIP. Ниже приводится пример, в котором информация обновления содержится в поле Contact. Сообщение 1a и 11a теперь выглядят следующим образом:

Отметим, что только поле Contact отличается от обычного формата сообщения для регистрации. Поскольку поле Contact сохраняется по всему потоку к S-CSCF, сообщения 2a, 5a, 12a и 15a имеют идентичное дополнение к полю Contact. S-CSCF, в частности, выполнена с возможностью распознавать "update=" в поле Contact и выполнять обновление. Поскольку оператор, возможно, захочет исключать, что каждое UE имеет признак обновления, в подписку может быть добавлен специальный индикатор, который предоставляет признак обновления в S-CSCF. S-CSCF обновляет пользовательский профиль, полученный из HSS, с помощью информации обновления. Это выполняется до регистрации начальных PUI для IMS-услуг, сообщения 21 и 22. Также политикой оператора является предоставление возможности дополнительного обновления при повторной регистрации и наличия S-CSCF, приспособленной для этого.

Если PBX или SIP-прокси-сервер указывается в регистрации, также может быть рассмотрена точка доступа любого другого типа. Базовый способ регистрации для групповой подписки является идентичным для всех типов точек доступа. Вместо самостоятельного выполнения регистрации посредством PBX или SIP-прокси-сервера это может быть выполнено посредством функции, которая регистрируется от имени SIP-прокси-сервера или PBX. Такая функция, например, может находиться в пограничном узле, таком как пограничный шлюз для обмена служебными сигналами. Пограничный узел может находиться между PBX или SIP-прокси-сервером и P-CSCF или может содержать P-CSCF. Другим примером устройства, которое может выступать в качестве хоста для функции регистрации, является интегрированное устройство доступа или собственный шлюз в абонентских пунктах.

Первый случай инициирующей/вызывающей стороны согласно изобретению приводится на фиг.8. Номера сообщений идентичны сообщениям обхода ошибки, представленным посредством фиг.3, только в случае существенного различия суффикс "a" добавляется к номеру сообщения. IP-PBX1 принадлежит организации 1 и имеет в качестве собственных PUI "[e-mail]". 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, на основе неявного регистрационного набора, который содержит PUI с подстановочными символами. Далее она задает P-Asserted-Identity, идентичный P-Preferred-Identity. Сообщение 103a, теперь отправляемое посредством P-CSCF в S-CSCF, выглядит следующим образом:

В S-CSCF, она использует P-Asserted-Identity сообщения для того, чтобы проверять пользовательский профиль, имеющий в качестве PUI Tel URI для P-Asserted-Identity. Она по-прежнему может переходить к BT-AS, как инструктировано посредством iFC, принадлежащих профилю услуг, ассоциированному с PUI Alice, но это более не является обязательным для того, чтобы получать корректный P-Asserted-Identity для Alice. Критерии начальной фильтрации не должны ошибочно пониматься как инструкции в смысле управления функционированием узлов. Они просто улучшают выбор IMS-услуг, которые могут быть подготовлены или не могут быть подготовлены для пользователя. Пример, по которому следует переходить к BT-AS, так или иначе заключается в том, чтобы преобразовывать поле From и To до полного Tel URI Alice и Bob вместо номера согласно контексту IP-PBX1.

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

Второй случай инициирующей/вызывающей стороны согласно изобретению приводится на фиг.9. Номера сообщений идентичны сообщениям обхода ошибки, представленным посредством фиг.3, только в случае существенного различия суффикс "b" добавляется к номеру сообщения. SIP-прокси-сервер принадлежит организации 1 и имеет в качестве собственных PUI "[e-mail]". SIP-прокси-сервер действует от имени диапазона SIP URI "!#! @enterprise 1.com". Сотрудник Alice запрашивает, устанавливать сеанс от своего терминала с SIP URI [e-mail] с Bob в организации 2, имеющей SIP URI "[e-mail]", обрабатываемый посредством SIP-прокси-сервера в организации 2.

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

Также когда принято посредством исходящей P-CSCF, она распознает P-Preferred-Identity, содержащийся в INVITE, на основе неявного регистрационного набора, который содержит PUI с подстановочными символами. Далее она задает P-Asserted-Identity, идентичный P-Preferred-Identity. Сообщение 103a, теперь отправляемое посредством P-CSCF в S-CSCF, выглядит следующим образом:

В S-CSCF она использует P-Asserted-Identity сообщения для того, чтобы проверять пользовательский профиль, имеющий в качестве PUI, SIP URI для P-Asserted-Identity. Она по-прежнему может переходить к XX-AS, как инструктировано посредством iFC, принадлежащих профилю услуг, ассоциированному с PUI Alice, но это более не является обязательным для того, чтобы получать корректный P-Asserted-Identity для Alice. Установление вызова продолжается согласно обычным процедурам. Следует отметить, что заголовки "Request URI", "From", "To" and "P-Asserted-ID" не изменяются посредством операции групповой обработки (по меньшей мере, не каким-либо способом, который отличается от этого, что происходит для обычных не входящих в группу пользователей). Возвращаясь в S-CSCF, она перенаправляет сообщение 107 INVITE в функцию управления на сопряженной границе (I-BCF) оператора 1 для дополнительной транспортировки в сеть оператора 2. В завершение сообщение INVITE выглядит следующим образом:

Первый случай вызываемой/завершающей стороны согласно изобретению приводится посредством фиг.10. Номера сообщений идентичны сообщениям обхода ошибки, представленным посредством фиг. 4. IP-PBX1 принадлежит организации 1 и имеет в качестве собственных PUI "[e-mail]". IP-PBX1 имеет в качестве группового кода 850, а в качестве диапазона номеров - +31 161 24 xxxx. Сотрудник Alice запрашивает, устанавливать сеанс от своего терминала с добавочным номером 1234 с Bob в организации 2, имеющим добавочный номер 5678 в рамках IP-PBX2 с групповым кодом 851, заданным посредством IP-PBX1. Сообщение INVITE поступает в I-BCF оператора 2, который перенаправляет сообщение 201 в I-CSCF. Сообщение выглядит следующим образом:

I-CSCF распознает URI SIP-запроса, соответствующий номеру телефона, и преобразует его в Tel URI. В этом примере соединения Alice с Bob, URI SIP-запроса - это "sip:[e-mail], user=phone", и он преобразуется в Tel URI "Tel: [phone]". I-CSCF затем отправляет запрос 202 информации о местоположении в HSS согласно обычным процедурам IMS. После этого HSS определяет, что Tel URI совпадает с подстановочными символами PUI, и отвечает с помощью ответа 203 с информацией о местоположении в I-CSCF с идентификационными данными выделенной S-CSCF. I-CSCF перенаправляет сообщение 204 SIP в выделенную S-CSCF. Сообщение в таком случае выглядит следующим образом:

Далее S-CSCF действует так, как действовала бы для обычного зарегистрированного терминала. Она распознает запрошенный Tel URI как совпадающий с URI с подстановочными символами. Пользовательский профиль доступен в S-CSCF. В принципе, S-CSCF может перенаправлять непосредственно в P-CSCF без необходимости проходить сначала через BT-AS. Когда профиль включает в себя триггеры iFC для IMS-приложений, он по-прежнему может необязательно проходить через IMS-приложения. Здесь, в качестве примера преобразования формата внешнего номера Bob в формат корпоративного номера для IP-PBX2. Когда нет триггеров или после ответа последнего приложения, S-CSCF может перенаправлять сообщение в релевантную P-CSCF. Обычно заголовок INVITE должен содержать URI UE. Затем IP-PBX2 должна быть адресована, поскольку она отвечает за доставку терминалу. S-CSCF меняет свой обычный режим работы на основе инструкций посредством специальной информации в пользовательском профиле IP-PBX2. Следовательно, она добавляет контактный адрес для IP-PBX2 в качестве нового запрошенного URI. Чтобы сохранять старый URI, 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 должен обрабатывать завершение согласно определенной конкретной для приложения логике.

Второй случай вызываемой/завершающей стороны согласно изобретению приводится посредством фиг.11. Номера сообщений идентичны сообщениям обхода ошибки, представленным посредством фиг. 4. Сообщение INVITE поступает в I-BCF оператора 2. Вместо Tel URI сообщение в таком случае содержит SIP URI. Приглашение по-прежнему исходит от Alice к Bob, только Bob в данном случае размещается в рамках SIP-прокси-сервера в организации 2. I-BCF перенаправляет сообщение 201 в I-CSCF. Сообщение выглядит следующим образом:

Также I-CSCF принимает сообщение INVITE и опрашивает HSS. HSS распознает математику PUI с подстановочными символами и возвращает корректную S-CSCF, которой следует достигать. I-CSCF не требует преобразования контекста телефонного номера в первом случае вызываемой/завершающей стороны. Она перенаправляет сообщение 204 непосредственно в S-CSCF.

Далее S-CSCF действует так, как действовала бы для обычного зарегистрированного терминала. Она распознает запрошенный Tel URI как совпадающий с URI с подстановочными символами. Пользовательский профиль доступен в S-CSCF. В принципе, S-CSCF может перенаправлять непосредственно в P-CSCF без необходимости проходить сначала через BT-AS. Когда профиль включает в себя триггеры iFC для IMS-приложений, он по-прежнему может необязательно проходить через IMS-приложения. Когда нет триггеров или после ответа последнего приложения, S-CSCF может перенаправлять сообщение в релевантную P-CSCF. Обычно заголовок INVITE должен содержать URI UE. Далее SIP-прокси-сервер должен быть адресован, поскольку он управляет доставкой в терминал. S-CSCF меняет свой обычный режим работы на основе инструкций посредством специальной информации в пользовательском профиле SIP-прокси-сервера. Поэтому она добавляет контактный адрес для SIP-прокси-сервера в качестве дополнительного поля Route в рамках поля Route для направления в P-CSCF. S-CSCF по-прежнему может добавлять P-Called-Party-Id, содержащий запрошенный URI, но этого необязательно. Сообщение 213, перенаправленное в P-CSCF, теперь выглядит следующим образом:

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

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

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

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

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

Чтобы предоставить дополнительное понимание, поясняются подробнее 2 примера правила подстановочных символов и правила форматирования сообщений.

Распознавание с подстановочными символами основано на определенных символах. Это означает, что когда жестко закодированы, эти последовательности не могут возникать, если они не являются целевыми. Посредством первого индикатора они ограничиваются только определенными подписками, которые задали этот параметр. Инструкция, присутствующая в нем, указывает символы и что они означают. В качестве примера '!*!' означает 4 цифры или '!#!' означает 1-20 алфавитно-цифровых символов. В первом примере может быть очевидным то, что когда PABX использует 4 последние цифры, является случаем, отличным от того, когда PABX использует только 3 последние цифры.

Другой пример инструкции - это правило форматирования, как для S-CSCF, где IP-PBX, требует, чтобы поле Requested URI содержало адрес конечного адресата (сохраняло исходный запрашиваемый URI);

Поместим SIP-URI для IP-PBX, который должен принимать сообщение от P-CSCF, в заголовок Route под заголовком Route P-CSCF. Пример такого правила форматирования для S-CSCF, где IP-PBX требует, чтобы запрошенный URI конечного адресата находился в поле заголовка P-Called-Party-ID; скопируем значение запрошенного URI в поле заголовка P-Called-Party-ID, заменим поле Requested URI на адрес IP-PBX, в который следует доставлять сообщение. Для правил форматирования содержимое одного поля копируется или перемещается в другое. Содержимое не формируется. Возможный синтаксис для набора инструкций приводится посредством примера далее:

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

И

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

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

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

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

5. Способ упрощения доступа к услугам сети мультимедийной подсистемы на базе IP-протокола по п.1, содержащей, по меньшей мере, одно из прокси-функции управления сеансами вызовов, обслуживающей функции управления сеансами вызовов и сервера собственных абонентов, посредством пользовательских терминалов, находящихся за точкой доступа к упомянутой сети, причем точка доступа ассоциирована с подпиской в сети мультимедийной подсистемы на базе IP-протокола, при этом способ содержит этапы, на которых:
проверяют, присутствует ли индикатор управления в упомянутой подписке, и когда присутствует:
при регистрации мультимедийной подсистемы на базе IP-протокола упомянутой точки доступа в сети мультимедийной подсистемы на базе IP-протокола, распространяют общедоступные пользовательские идентификационные данные и функциональные инструкции в неявном регистрационном наборе в обслуживающую функцию управления сеансами вызовов, выделяемую упомянутой точке доступа, и в прокси-функцию управления сеансами вызовов, к которой упомянутая точка доступа присоединена,
при обработке сообщения INVITE, предназначенного для пользовательского терминала за упомянутой точкой доступа, сохраняют первоначальный запрошенный UPI в заголовке P-Called-Party-Identity и заменяют первоначальный запрошенный URI на общедоступные пользовательские идентификационные данные точки доступа, как указано правилом форматирования в упомянутых функциональных инструкциях, посредством обслуживающей функции управления сеансами вызовов,
перенаправляют модифицированное сообщение INVITE в прокси-функцию управления сеансами вызовов.

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

7. Способ по п.5, в котором упомянутый неявный регистрационный набор отправляется при регистрации посредством сервера собственных абонентов в обслуживающую функцию управления сеансами вызовов и в прокси-функцию управления сеансами вызовов, в ответе назначения сервера, в заголовке P-Associated-URI сообщения 200 ОК.

8. Способ по п.5, в котором упомянутый неявный регистрационный набор предоставляется в обслуживающую функцию управления сеансами вызовов посредством сервера собственных абонентов в рамках запроса профиля активной доставки после того, как упомянутая подписка модифицирована.

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

10. Способ по п.5, в котором упомянутый неявный регистрационный набор содержит, по меньшей мере, одну инструкцию обновления.

11. Способ по п.5, в котором упомянутая точка доступа является частной телефонной станцией на базе IP.

12. Способ по п.5, в котором упомянутая точка доступа является SIP-прокси-сервером.

13. Способ по п.5, в котором неявный регистрационный набор предоставляется при получении запроса на установление сеанса связи, когда отменена регистрация упомянутой подписки.

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

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