Обработка сообщений в подсистеме мультимедиа на базе протокола ip

Изобретение относится к системам IP мультимедиа. Технический результат заключается в усовершенствовании процедуры вызова. Раскрыт сервер приложения протокола установления сессии, относящийся к подсистеме мультимедиа на базе протокола IP, содержащий средство обработки для обработки сообщения, полученного от обслуживающей функции вызова/управления состоянием, причем средство выполнено с обеспечением возможности обработки сообщения на основании заголовка сообщения, содержащего URI обслуживаемого пользователя, причем указанный заголовок добавлен обслуживающей функцией вызова/управления состоянием и отличен от идентификаторов P-Asserted Identity и R-URI. 3 н. и 8 з.п. ф-лы, 8 ил.

 

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

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

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

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

Подсистема мультимедиа на базе протокола IP (IMS) представляет собой технологию, определенную Проектом партнерства третьего поколения (3GPP), с целью оказания услуг в сфере мультимедиа на базе протокола IP в сетях мобильной связи (3GPP TS 22.228, TS 23.218, TS 23.228, TS 24.228, TS 24.229, TS 29.228, TS 29.229, TS 29.328 и TS 29.329, Выпуски с 5 по 7). IMS обладает главными признаками, способствующими расширению круга возможностей межличностного общения между конечными пользователями путем использования стандартизированных устройств доступа к услугам IMS, которые способствуют появлению новых, богатых возможностями услуг связи типа «абонент-абонент» (клиент-клиент) и «абонент-контент» (клиент-сервер) в сетях на базе протокола IP. В IMS используется протокол установления сессии (SIP) для инициирования вызовов или сессий между терминалами пользователей (или терминалами пользователей и серверами приложений) и управления указанными вызовами или сессиями. Протокол описания сессии (SDP), передаваемый посредством сигналов SIP, используется для описания и передачи компонентов различных средств в рамках сессии. При том что SIP был создан как протокол связи «пользователь-пользователь», IMS позволяет операторам и провайдерам, предоставляющим услуги, управлять доступом пользователей к услугам и взимать с пользователей соответствующую плату.

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

Пользователь регистрируется в IMS посредством определенного способа SIP REGISTER. Такая регистрация представляет собой механизм присоединения к IMS и объявления в IMS адреса, по которому можно идентифицировать пользователя SIP. Пользователь получает от S-CSCF уникальный унифицированный идентификатор ресурса (URI), который S-CSCF должна использовать, когда она начнет диалог. В соответствии с 3GPP в случае, когда терминал SIP выполняет регистрацию, IMS удостоверяет пользователя и выделяет этому пользователю S-CSCF из совокупности доступных S-CSCF. Хотя критерии выбора S-CSCF не установлены в рамках 3GPP, среди таких критериев могут быть разделение нагрузки и требования к обслуживанию. Следует отметить, что выделение S-CSCF имеет ключевое значение для управления доступом пользователя к услугам, основанным на IMS (и взимания платы). Операторы могут создать механизм предотвращения прямых сессий SIP типа «пользователь-пользователь», которые в противном случае происходили бы без участия S-CSCF.

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

В сети обслуживания IMS предусмотрены серверы приложения (AS), целью которых является реализация функциональности обслуживания в рамках IMS. Серверы приложений предоставляют услуги конечным пользователям в системе IMS и могут быть либо присоединены в качестве конечных точек посредством интерфейса Mr, определенного 3GPP, либо «привлечены» посредством S-CSCF через интерфейс ISC, определенный 3GPP. В последнем случае S-CSCF применяет исходные критерии фильтрации (IFC) для того, чтобы определить, какие серверы приложений должны быть «привлечены» при установлении сессии SIP. Для различных вызовов могут быть применены различные IFC. S-CSCF получает IFC от HSS в качестве составной части профиля пользователя, относящегося к данному пользователю, во время процедуры регистрации в IMS. Определенные серверы приложений будут совершать те или иные действия в зависимости от идентификаторов пользователя (вызываемый или вызывающий абонент, в зависимости от того, какой из них «принадлежит» сети, управляющей сервером приложений). Например, в случае переадресации вызовов соответствующий (конечный) сервер приложения определит новую конечную сторону, которой будет перенаправлен вызов, адресованный данному абоненту.

Рабочая группа, известная как ETSI TISPAN, развивает применение IMS для доступа посредством широкополосной сети фиксированных операторов. Одной из задач данной группы является разработка дополнительных услуг, основанных на IMS, определенной 3GPP. Такие дополнительные услуги будут определены отдельными спецификациями, хотя они также окажут влияние на основные спецификации, такие как TS24.229. На Фиг. 2 представлена схема прохождения сообщений в рамках IMS в случае с SIP INVITE со стороны, инициирующей вызов, в соответствии с TS24.229 (раздел 5.4.3.2). На этапе 1) INVITE отправляют с оборудования пользователя (UE) к P-CSCF. Заголовок этого сообщения INVITE включает в себя так называемый идентификатор предпочитаемого прокси (P-Preferred identity), а также идентификатор URI для P-CSCF самого верхнего уровня в заголовке пути SIP и URI для S-CSCF в качестве второй записи. UE также включает идентификатор партнера по связи в идентификатор запроса Request-URI. При получении INVITE P-CSCF проверяет, имеет ли UE, инициировавшее сессию, право использовать идентификатор, определенный как P-Preferred identity, и, если это так, включает этот идентификатор в качестве идентификатора, подтвержденного прокси P-Asserted Identity, в исходящее сообщение INVITE. P-Asserted Identity представляет собой идентификатор, который используется надежными единицами SIP, как правило, посредниками, для передачи идентификатора пользователя, посылающего сообщение SIP, в том виде, в котором он был удостоверен при аутентификации. P-CSCF определяет S-CSCF, выделенную для UE, пославшего сообщение, путем считывания информации из заголовка пути, и на этапе 2) пересылает измененное сообщение INVITE этой S-CSCF.

S-CSCF обрабатывает вызов в соответствии с процедурой, установленной для отправителя. Путем использования P-Asserted Identity S-CSCF проверяет, не наложены ли на UE, инициировавшее вызов, какие-либо имеющие значение ограничения, например, не наложен ли на данное UE запрет на пользование запрашиваемой услугой. S-CSCF также использует P-Asserted Identity и процедуру для отправителя для определения IFC для данного UE. В примере, проиллюстрированном Фиг.2, предполагается, что в соответствии с IFC требуется, чтобы S-CSCF переслала (этап 3) сообщение INVITE к определенному серверу приложения (AS). S-CSCF включает URI соответствующего AS на самом верхнем уровне в заголовок пути SIP. Также на последующем уровне она включает свой собственный URI вместе с исходным идентификатором диалога (ODI). ODI генерируется S-CSCF и является уникальным идентификатором вызова для S-CSCF. В свою очередь, AS также выполнит аутентификацию на основании идентификатора P-Asserted Identity, содержащегося в сообщении (процедура для отправителя). Подходящий тип процедуры для AS определяет S-CSCF (например, путем отправки сообщения в соответствующий порт AS). Когда AS отправляет сообщение INVITE (этап 4) обратно к S-CSCF, AS удаляет свой URI из заголовка пути, оставляя URI, принадлежащий S-CSCF, и отметку ODI. Отметка ODI позволяет S-CSCF определить, что сообщение INVITE относится к уже существующему диалогу.

С точки зрения логики AS может потребоваться установление новой сессии, и в этом случае необходимо предусмотреть механизм, который позволял бы AS заменить исходный идентификатор запроса R-URI на URI нового конечного пользователя (существующие технические спецификации в настоящий момент не предусматривают такого сценария переадресации). В данном случае идентификатор происхождения сообщения, то есть P-Asserted Identity сообщения INVITE на этапе 4), может представлять собой или идентификатор UE, инициировавшего сессию, или идентификатор AS, или идентификатор третьей стороны, от имени которой AS устанавливает новую сессию. В таком случае S-CSCF повторит проверку наличия ограничений вызова и определит IFC на основании идентификатора P-Asserted Identity, содержащегося в «новом» сообщении INVITE, если используется процедура для отправителя. Однако возможна также и передача от AS к S-CSCF информации о том, что используется процедура для получателя вызова, и в таком случае проверки выполняют на основании R-URI сообщения INVITE. Если на основании IFC не требуется «привлечение» каких-либо других AS, то S-CSCF пересылает сообщение INVITE по идентификатору запроса Request URI (R-URI), содержащемуся в сообщении INVITE. Таким идентификатором может быть или R-URI, содержащийся в исходном сообщении INVITE, или новый R-URI, содержащийся в новом сообщении INVITE, если оно отличается от прежнего.

Фиг.3 представляет собой схему прохождения сообщения SIP INVITE в рамках IMS со стороны получателя вызова (TS24.229; раздел 5.4.3.3). На этапе 1) сообщение INVITE приходит от I-CSCF (не показана) и включает в себя R-URI, указывающий на вызываемую сторону. S-CSCF использует этот R-URI для проверки наличия ограничений, которые могут быть наложены на вызываемую сторону, а также для получения IFC. В этом случае IFC не указывают на необходимость установления контакта с AS. S-CSCF получает загруженные ранее заголовки пути для вызываемой стороны на основании R-URI и отправляет INVITE на UE на основании этих записей в заголовке пути. В соответствии с ранее загруженным в S-CSCF путем сообщение INVITE принимает P-CSCF, а P-CSCF отправляет сообщение INVITE на UE, в соответствии с заголовком контакта.

На Фиг.4 показан альтернативный сценарий прохождения сообщения INVITE, согласно которому вызов от терминала отправителя (UE-O) передают на терминал переадресации (UE-F), с которого его пересылают на терминал получателя (UE-T). Процедура переадресации вызова выполняется сервером приложения (AS-F). Вызов проходит по следующей схеме:

1) Сообщение INVITE отправляют с UE-O в адрес UE-F (R-URI). Функция обслуживания вызова/управления состоянием для отправителя вызова (S-CSCF O) выполняет процедуру для отправителя вызова, как описано со ссылкой на Фиг.2.

2) После взаимодействия с AS-O (в R-URI на данном этапе не вносят каких-либо изменений) S-CSCF O отправляет сообщение INVITE к I-CSCF (не показана), являющейся частью внутренней сети UE-F. I-CSCF считывает адрес в S-CSCF, по которому зарегистрирован UE-F, с сервера абонентских данных (HSS). Сообщение INVITE направляют к вышеуказанной S-CSCF, т.е. S-CSCF терминала переадресации (S-CSCF F). S-CSCF F проверяет требования к ограничению доступа и получает IFC на основании процедуры (для получателя вызова), описанной выше со ссылкой на Фиг.3, т.е. на основании R-URI, содержащегося в сообщении INVITE. Согласно сценарию, проиллюстрированному Фиг.4, сообщение INVITE посылают к AS-F, где приводится в действие переадресация вызова.

3) AS-F дает разрешение на выполнение процедуры на основании R-URI (в случае процедуры для получателя вызова).

4) Затем AS-F меняет R-URI в заголовке сообщения INVITE с идентификатора UE-F на идентификатор UE-T. Измененное сообщение INVITE отправляют обратно к S-CSCF F.

5) S-CSCF F отправляет сообщение INVITE на I-CSCF сети UE-T, и I-CSCF (не показана) направляет к HSS запрос с целью получения адреса UE-T в S-CSCF получателя вызова (S-CSCF T) и пересылает INVITE к S-CSCF T.

6) S-CSCF T выполняет процедуру для получателя вызова, как описано со ссылкой на Фиг.3, на основании R-URI, содержащегося в сообщении INVITE (т.е. R-URI UE-T).

Раскрытие изобретения

Возвращаясь к Фиг.4, на этапе 5) в качестве дополнения необходимо, чтобы S-CSCF F проверила наличие каких-либо ограничений, налагаемых на переадресовывающего пользователя, UE-F. Для этого S-CSCF обычно использует процедуру для отправителя вызова, как показано на Фиг.2. Однако при отсутствии каких-либо особых процедур, осуществляемых AS-F, сообщение INVITE, возвращаемое AS-F к S-CSCF F, будет включать в себя запись идентификатора P-Asserted Identity, принадлежащего UE-O. Если бы от S-CSCF F требовалось выполнение проверки стороны, отправившей вызов, в отношении сообщения INVITE с использованием идентификатора P-Asserted Identity, то S-CSCF F не смогла бы найти запись, содержащую такой идентификатор, поскольку он не «принадлежит» S-CSCF F (а принадлежит S-CSCF O).

Решением данной проблемы могла бы стать замена P-Asserted Identity UE-O на соответствующий идентификатор UE-F, выполняемая AS-F. Однако такое решение вряд ли будет одобрено операторами, которые предпочтут оставить P-Asserted Identity без изменений от начала до конца. С точки зрения операторов поле идентификатора P-Asserted Identity похоже на обычный идентификатор линии прохождения вызова в телефонной сети общего пользования (PSTN). Поэтому следует искать другие решения данной проблемы.

При том что переадресовывающий пользователь, как правило, будет рассматриваться в качестве отправителя вызова согласно сценарию переадресации вызова, такое восприятие совсем необязательно, и вышеуказанного пользователя можно рассматривать также и как получателя вызова. В данном случае, получив сообщение INVITE от AS-F, S-CSCF будет стремиться провести проверку в отношении получателя вызова для данного сообщения INVITE. (Сообщение, отправленное от AS-F к S-CSCF, будет содержать параметр, который укажет на то, следует ли обработать данное сообщение по процедуре для получателя вызова или для отправителя вызова.) Однако такая проверка также не удастся, поскольку R-URI, содержащийся в сообщении INVITE, указывает на UE-T, и этот R-URI принадлежит S-CSCF T, а не S-CSCF F. Изменение P-Asserted Identity, разумеется, не будет решением для данной проблемы.

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

Задачей настоящего изобретения является преодоление вышеуказанных проблем наряду с избежанием необходимости изменения P-Asserted Identity, содержащегося в сообщении протокола установления сессии (SIP). Эта и другие задачи решаются путем добавления в функции S-CSCF нового заголовка в сообщение SIP перед пересылкой сообщения к серверу приложения, причем указанный новый заголовок содержит URI пользователя, которого обслуживает S-CSCF и к которому относится данное сообщение.

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

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

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

пересылают сообщение в сервер приложения; и

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

Указанный этап, на котором обрабатывают сообщение в сервере приложения, может включать в себя этап, на котором R-URI, содержащийся в сообщении, меняют на URI пользователя, которому следует перенаправить сообщение, и возвращают сообщение к обслуживающей функции вызова/управления состоянием.

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

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

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

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

Указанный дополнительный заголовок идентифицируют посредством идентификатора заголовка, который подлежит распознаванию как в S-CSCF, так и в AS. Обычно такой заголовок представляет собой префикс, например, “P-Served User Identity”.

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

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

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

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

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

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

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

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

Фиг.1 представляет собой схематичное изображение интеграции подсистемы мультимедиа на базе протокола IP в систему мобильной связи третьего поколения;

Фиг.2 представляет собой схему прохождения сообщения SIP INVITE со стороны отправителя вызова в IMS;

Фиг.3 представляет собой схему прохождения сообщения SIP INVITE со стороны получателя вызова в IMS; и

Фиг.4 представляет собой схему прохождения сообщения SIP INVITE согласно сценарию переадресации вызова в рамках IMS;

Фиг.5 изображает структуру заголовка сообщения для сообщения SIP INVITE, посылаемого от S-CSCF к серверу приложения;

Фиг.6 изображает структуру заголовка сообщения для сообщения SIP INVITE, посылаемого от сервера приложения к S-CSCF;

Фиг.7 изображает структуру заголовка сообщения для сообщения SIP INVITE, посылаемого от S-CSCF ко второму серверу приложения; и

Фиг.8 представляет собой схему сигнального обмена между единицами IMS с использованием структуры сообщения по Фиг.7.

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

Выше описаны проблемы, имеющие отношение к обработке сообщения согласно сценарию «переадресации» в подсистеме мультимедиа на базе протокола IP. Желательно иметь возможность предусмотреть механизм для обработки переадресации вызовов, который позволял бы и серверу приложения (AS), и S-CSCF разрешать доступ, проверять требования к ограничениям и/или определять IFC для соответствующего пользователя, т.е. для того пользователя, которого обслуживает S-CSCF, причем указанный механизм работал бы с процедурой для отправителя вызова и получателя вызова для обеспечения надлежащей гибкости.

Теперь рассмотрим сообщение INVITE, приходящее к S-CSCF F от какого-либо пользователя, инициирующего сессию (UE-O). Сообщение INVITE содержит в своем заголовке R-URI, указывающий на какого-либо из зарегистрированных в S-CSCF F пользователей (UE-F), а именно [e-mail]. Сообщение INVITE также содержит P-Asserted Identity пользователя, инициирующего сессию, а именно “John Doe” <sip:[e-mail]>, <tel:[phone]>. S-CSCF обрабатывает это сообщение с использованием процедуры для получателя вызова (что определяется сообщением, которое получают в порт с определенным номером при отсутствии каких-либо конкретных указаний в самом сообщении), и поэтому получает надлежащие IFC на основании R-URI данного сообщения. Один из таких IFC будет указывать на то, что сообщение следует отправить в сервер приложения. Определив, что сообщение следует переслать в сервер приложения, S-CSCF добавит к сообщению INVITE дополнительный заголовок. Этот заголовок в контексте настоящей заявки обозначен как “P-Served-User-Identity” и содержит идентификатор, SIP-URI или TEL URL пользователя, которого обслуживает S-CSCF и который известен S-CSCF. Заголовок также содержит указание на тип процедуры применительно к данному вызову, который должен быть применен сервером приложения. Ниже приведены примеры заголовков:

P-Served-User-Identity: sip:[e-mail];orig

P-Served-User-Identity: sip:[e-mail];termunreg

P-Served-User-Identity: sip:[e-mail];termreg

Обычно в случае переадресации вызова будет применена процедура для отправителя вызова. Заголовок P-Served-User-Identity всегда будет добавляться к сообщению безотносительно к серверу приложения, в который должно быть перенаправлено сообщение.

S-CSCF также будет выполнять стандартные операции добавления SIP URI, принадлежащий AS, в качестве самого верхнего URI заголовка пути, т.е. sip:as1.home1.net;lr, и включения своего собственного SIP URI под URI, принадлежащим AS, в заголовок пути вместе с «исходным идентификатором диалога» (ODI). Структура получившегося в результате примерного сообщения INVITE показана на Фиг.5, где URI, принадлежащий S-CSCF, добавленный к заголовку пути, представляет собой “scscf1.home1.net;lr”, а ODI - “cb03a0s09a2sdfglkj490333”. Затем сообщение пересылают в сервер приложения посредством интерфейса ISC. S-CSCF F подтверждает информацию о состоянии для сессии, к которой относится сообщение INVITE. Эта информация включает в себя ODI и идентификатор обслуживаемого пользователя F.

По получении сообщения INVITE от S-CSCF сервер приложения всегда будет выполнять процедуру разрешения доступа на основании идентификатора P-Served-User-Identity согласно процедуре (для отправителя или получателя вызова), определенной в сообщении. В случае, если требуется выполнение переадресации вызова на основании R-URI, содержащегося в сообщении INVITE, сервер приложения заменит исходный R-URI на URI пользователя, которому следует переадресовать вызов (UE-T). В качестве дополнения сервер приложения добавит параметр “orig” к заголовку пути, чтобы указать, что сообщение INVITE следует обрабатывать по процедуре для отправителя вызова. Самый верхний заголовок пути, т.е. URI сервера приложения, удаляют из сообщения, и сообщение посылают обратно в S-CSCF. Возвращаемое сообщение сохраняет заголовок P-Served-User-Identity.

При получении сообщения, содержащего заголовок P-Served-User-Identity, S-CSCF по умолчанию выполняет операцию проверки IFC на основании данных об обслуживаемом пользователе, сохраняемых среди информации о состоянии сессии, соответствующей ODI полученного сообщения. (Хотя для этих целей мог бы быть использован идентификатор пользователя, содержащийся в заголовке P-Served-User-Identity, предпочтительно в как можно большей степени избегать внесения изменений в существующие процедуры.) S-CSCF применит процедуру для получателя или отправителя вызова в зависимости от того, какая процедура определена в заголовке пути (или на основании номера порта, в котором получено сообщение INVITE от AS). Обычно пересылаемое сообщение INVITE обрабатывают согласно процедуре для отправителя вызова. (В данном примере S-CSCF не использует ту процедуру, что указана в заголовке P-Served-User-Identity, хотя возможен и такой вариант.)

При отсутствии ODI в сообщении, полученном через интерфейс ISC, S-CSCF выполнит необходимые проверки на основании либо P-Asserted Identity, либо R-URI.

После завершения проверки исходных критериев фильтрации (IFC) S-CSCF обработает сообщение INVITE на основании установленных IFC. Такая обработка может включать в себя отправку сообщения непосредственно в UE-T конечного пользователя или, возможно, пересылку сообщения на другой сервер приложения.

В некоторых случаях проверка IFC, выполняемая S-CSCF в ответ на получение сообщения SIP (INVITE) через интерфейс ISC, может потребовать пересылки сообщения на другой сервер приложения. Пример сообщения, пересылаемого на второй AS, приведен на Фиг.7. Опять же заголовок P-Served-User-Identity содержит URI пользователя F, а именно [e-mail], в то время как P-Asserted-Identity представляет собой идентификатор пользователя, отправившего сообщение, а R-URI представляет собой идентификатор нового пользователя, являющегося конечным получателем сообщения. На Фиг. 8 изображена схема обмена сообщениями между S-CSCF F и двумя серверами приложений (AS) - AS-F 1 и AS-F 2.

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

1. Способ обработки сообщения протокола установления сессии в подсистеме мультимедиа на базе протокола IP, содержащий этапы, на которых:
получают сообщение протокола установления сессии в обслуживающей функции управления вызовом/состоянием (S-CSCF), обслуживающей пользователя, идентифицируемого с помощью R-URI (запрос унифицированного идентификатора ресурса) данного сообщения;
в упомянутой обслуживающей функции управления вызовом/состоянием добавляют к сообщению дополнительный заголовок, причем указанный заголовок явно идентифицирует URI (унифицированный идентификатор ресурса) пользователя, обслуживаемого обслуживающей функцией управления вызовом/состоянием;
пересылают сообщение на сервер приложения; и
в сервере приложений (AS) обрабатывают упомянутое сообщение на основе критериев, определенных для пользователя, идентифицированного в указанном дополнительном заголовке.

2. Способ по п.1, в котором упомянутая обработка сообщения на сервере приложений заключается в том, что меняют R-URI в сообщении на URI пользователя, которому должно быть перенаправлено сообщение, и возвращают упомянутое сообщение к обслуживающей функции управления вызовом/состоянием (S-CSCF).

3. Способ по п.1 или 2, в котором упомянутое сообщение непосредственно пересылают на упомянутый сервер приложения с помощью S-CSCF или после обменов упомянутым сообщением между S-CSCF и одним или более серверами приложений.

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

5. Способ по п.2, дополнительно содержащий этап, на котором в S-CSCF получают упомянутое сообщение от сервера приложений и идентифицируют исходный R-URI на основе исходного идентификатора диалога, содержащегося в возвращенном сообщении, и определяют исходные критерии фильтрации (IFC) для обслуживаемого пользователя на основании упомянутого R-URI.

6. Способ по п.1, в котором упомянутая обработка сообщения на сервере приложений содержит реализацию процесса переадресации вызова.

7. Способ по п.1, в котором упомянутый дополнительный заголовок идентифицируют с помощью идентификатора заголовка, который является распознаваемым как в S-CSCF, так и в AS.

8. Способ по п.2, дополнительно содержащий этап, на котором упомянутое сообщение возвращают от сервера приложения к S-CSCF, причем идентификатор P-Asserted Identity является одинаковым в сообщении, изначально полученном в S-CSCF, и в сообщении, возвращенном к S-CSCF от сервера приложений, причем упомянутый идентификатор идентифицирует инициирующего пользователя.

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

10. Сервер приложения протокола установления сессии, относящийся к подсистеме мультимедиа на базе протокола IP, содержащий:
средство обработки для обработки сообщения, полученного от обслуживающей функции управления вызовом/состоянием,
причем упомянутое средство выполнено с обеспечением возможности обработки сообщения на основании заголовка сообщения, содержащего URI обслуживаемого пользователя,
причем упомянутый заголовок добавлен обслуживающей функцией управления вызовом/состоянием и отличается от идентификаторов P-Asserted Identity и R-URI.

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