вычисление критерия начальной фильтрации

Формула изобретения

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

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

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

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

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

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

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

8. Функция управления сеансом вызова для использования в сети IP мультимедийной подсистемы, включающая в себя: средство для приема сообщения протокола инициации сеанса, причем сообщение содержит запрашиваемый унифицированный идентификатор ресурсов; средство для применения к сообщению критерия начальной фильтрации; передатчик для отправки сообщения на сервер приложений; средство для приема сообщения, возвращаемого с сервера приложений; средство для продолжения вычисления критерия начальной фильтрации (IFC); средство для определения того, содержит ли возвращенное сообщение унифицированный идентификатор ресурсов новой цели; и средство для замены запрашиваемого унифицированного идентификатора ресурсов в сообщении унифицированным идентификатором ресурсов новой цели.

Описание изобретения к патенту

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

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

Предшествующий уровень техники

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

Эти сервисы могут быть основаны на архитектуре IP мультимедийной подсистемы (IMS), которая является технологией, определенной проектом партнерства третьего поколения (3GPP) для предоставления услуг IP-мультимедиа по сетям мобильной связи (3GPP TS 22.228, TS 23.228, TS 24.229, TS 29.228, TS 29.229, TS 29.328 и TS 29.329 Версии 5-7).

IMS использует протокол инициации сеанса (SIP) для установления и управления вызовами или сеансами между пользовательскими терминалами (либо между пользовательскими терминалами и серверами приложений). Протокол описания сеанса (SDP), поддерживаемый передачей сигналов по SIP, используется для описания и согласования мультимедийных средств сеанса. Фиг.1 схематично показывает, как IMS встраивается в архитектуру сети мобильной связи, касательно домена доступа 3GPP PS.

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

Как показано на Фиг.2, когда S-CSCF принимает сообщение, она проверяет сохраненные IFC. Если входящее сообщение удовлетворяет условиям точки срабатывания в IFC, то S-CSCF передает сообщение на AS, указанный посредством IFC. После обработки сообщения AS сообщение возвращается на S-CSCF, после чего проверяется следующий IFC. IFC может быть предоставлен приоритетный номер, следовательно, если несколько IFC, относящихся к пользователю, хранятся в S-CSCF, то IFC проверяются в порядке очередности приоритетов.

Интерфейс между S-CSCF и AS является интерфейсом управления услугами IMS (ISC), который использует передачу сигналов по SIP для взаимодействия между AS и S-CSCF.

Спецификация 3GPP IMS TS 24.229 версии 7.5.1 описывает механизм, который позволяет AS выполнять изменение цели запроса SIP посредством изменения Request-URI (запрашиваемого унифицированного идентификатора ресурсов), содержащегося в сообщении. Когда сообщение возвращается с AS на S-CSCF, S-CSCF обнаруживает изменение Request-URI и прерывает проверку вычисления критерия начальной фильтрации (IFC), как показано на Фиг.3. Сообщение передается непосредственно для обработки исходящего запроса, кроме того, никакие IFC с низшими приоритетами не проверяются, что предотвращает активизацию других AS.

Основная мотивация для механизма возникает из требования в услуге переадресации вызова, которая позволяет AS изменять целевой адрес получателя запроса SIP. На тот момент не предусматривалось, что любая другая услуга потребует, чтобы AS изменил Request-URI запроса SIP. Однако теперь рассматриваются случаи, в которых может потребоваться, чтобы AS изменил идентификатор Request-URI запроса SIP без прерывания процедуры вычисления IFC на S-CSCF. Примеры таких случаев включают в себя следующее:

1. Пользователь, имеющий открытый идентификатор абонента IMS (IMPU), может использовать несколько экземпляров UE. AS принимает запрос, который адресован IMPU пользователя, и выбирает абонентскую службу SIP (UA), как правило, терминал пользователя, к которому обращаются с помощью URI глобально маршрутизируемой UA (GRUU) или контакта, в качестве конечной точки. Когда AS желает инициировать завершение сеанса с пользовательским оборудованием (UE), возникает проблема, если IMPU, выделенный UE, совместно используется с другими UE. Для полного контроля за тем, какому UE отправляется запрос на завершение сеанса, AS должен изменить цель запроса с IMPU на адрес выбранной конечной точки.

2. Подобная проблема возникает, когда AS изменяет IMPU пользователя. Это может потребоваться, например, когда AS принимает IMPU с URI TEL и отправляет другой с URI SIP, и наоборот.

3. AS может требоваться для изменения Request-URI входящего запроса с URI SIP на URI TEL. Это изменение необходимо, поскольку с устройствами, соединенными с сетью с использованием телефонной коммутируемой сети общего пользования (PSTN), возможно связаться только с использованием телефонных номеров.

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

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

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

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

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

принимают сообщение, возвращаемое с сервера приложений,

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

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

Таким способом принимается решение о продолжении вычисления IFC, даже если унифицированный идентификатор ресурсов адресата был изменен.

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

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

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

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

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

средство для вычисления критерия начальной фильтрации для применения к сообщению;

передатчик для отправки сообщения на сервер приложений;

средство для приема сообщения, возвращаемого с сервера приложений;

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

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

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

приемник для приема сообщения, причем сообщение содержит унифицированный идентификатор ресурсов адресата:

средство для исправления унифицированного идентификатора ресурсов сообщения;

средство для включения в сообщение индикатора отмены целевого адреса; и

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

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

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

применяют к сообщению, по меньшей мере, один критерий начальной фильтрации;

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

принимают сообщение, возвращаемое с сервера приложений;

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

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

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

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

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

средство для применения к сообщению критерия начальной фильтрации;

передатчик для отправки сообщения на сервер приложений;

средство для приема сообщения, возвращаемого с сервера приложений;

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

средство для замены унифицированного идентификатора ресурсов адресата в сообщении на унифицированный идентификатор ресурсов новой цели.

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

Фиг.1 схематично иллюстрирует способ встраивания подсистемы IMS в архитектуру мобильной сети, в случае домена доступа 3GPP PS;

Фиг.2 схематично иллюстрирует инициирование серверов приложений посредством S-CSCF в ответ на удовлетворяющий критерий начальной фильтрации;

Фиг.3 схематично иллюстрирует инициирование сервера приложений посредством S-CSCF в ответ на удовлетворяющий критерий начальной фильтрации, где сервер приложений изменяет целевой URI;

Фиг.4 схематично иллюстрирует инициирование серверов приложений посредством S-CSCF согласно настоящему изобретению;

Фиг.5 изображает последовательность передачи сигналов, когда индикатор отмены изменения цели связан с IFC в профиле пользователя;

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

Фиг.7 изображает последовательность передачи сигналов, когда новая цель передается посредством сервера приложений, и

Фиг.8 изображает последовательность передачи сигналов, где в S-CSCF используется логика отмены изменения цели.

Подробное описание

S-CSCF способна определить, был ли идентификатор Request-URI изменен посредством AS. Если определено, что Request-URI был изменен, то S-CSCF решает, продолжать ли вычисление критерия начальной фильтрации (IFC). Это показано на Фиг.4. Первый критерий начальной фильтрации IFC-1 применяется к входящему сообщению на S-CSCF. Сообщение передается на сервер приложений AS-1, указанный в IFC1. Затем сообщение возвращается с AS-1 на S-CSCF. S-CSCF определяет, был ли изменен идентификатор Request-URI. Если нет, к сообщению применяется следующий критерий начальной фильтрации IFC-2. Если S-CSCF решает, что идентификатор Request-URI был изменен, то S-CSCF решает, возобновлять ли вычисление IFC. В случае отрицательного результата сообщение передается непосредственно для обработки исходящего запроса на S-CSCF. Альтернативно, если S-CSCF решает, что вычисление IFC должно быть возобновлено, то сообщение с исправленным идентификатором Request-URI передается для вычисления на IFC-2. Этот процесс повторяется для каждого IFC.

Следует отметить, что на Фиг.4 проверка того, был ли изменен Request-URI, показана в качестве происходящей перед проверкой того, возобновлять ли вычисление критерия IFC или же передать сообщение непосредственно для обработки исходящего запроса на S-CSCF. Порядок этих двух проверок может быть обратным.

Существует несколько различных способов, с помощью которых S-CSCF может определить, возобновлять ли вычисление IFC после изменения Request-URI сообщения. Три возможных способа описываются ниже:

1. Индикатор отмены изменения цели включен в качестве части профиля пользователя, сохраненного на HSS и загруженного на S-CSCF при регистрации пользователя в сети. Индикатор отмены изменения цели связывается с конкретным IFC. Когда S-CSCF принимает SIP, возвращенный с измененной целью посредством AS, инициированного посредством IFC с помощью индикатора отмены изменения цели, S-CSCF не будет прерывать вычисление IFC, но возобновит процедуру, несмотря на изменение цели.

2. Индикатор отмены изменения цели вводится в качестве части передачи сигналов по ISC между S-CSCF и AS. AS, который изменяет цель запроса, также может включать индикатор отмены изменения цели в запрос SIP, отправляемый на S-CSCF. Индикатор отмены изменения цели может находиться в любой подходящей части сообщения SIP, включая заголовок или тело сообщения. S-CSCF считывает индикатор отмены изменения цели в сообщении SIP и возобновляет вычисление IFC. Существуют дополнительные альтернативные способы, посредством которых AS может передать о изменении цели, а также передать индикатор отмены на S-CSCF по ISC следующим образом:

a. AS изменяет Request-URI и включает в себя четкий индикатор отмены изменения целевого адреса в запросе SIP;

b. AS сохраняет Request-URI неизменным, но новый целевой адрес отправляется в запросе SIP (например в заголовке SIP);

3. В S-CSCF вводится новая логика для анализа адреса измененной цели запроса для определения того, продолжать или остановить вычисление IFC. Эта логика определяет, является ли измененная цель другим IMPU, принадлежащим пользователю, или цель получена из IMPU, принадлежащего пользователю, или же она является пользовательским агентом (UA) SIP, зарегистрированным в настоящее время на пользователя. Если любое из этих условий удовлетворяется, то S-CSCF возобновляет вычисление IFC, в противном случае сообщение SIP передается для обработки исходящего запроса.

Сейчас будут более подробно описаны три вышеупомянутых примера.

1. Индикатор отмены изменения цели, связанный с IFC в профиле пользователя.

Последовательность передачи сигналов для этого варианта осуществления показана на Фиг.5.

1.1. Индикатор отмены изменения цели включается в качестве части профиля пользователя на HSS. Индикатор отмены изменения цели связывается с IFC, который указывает на конкретный AS. Индикатор отмены изменения цели загружается на S-CSCF в качестве части профиля пользователя при выделении пользователю S-CSCF (как правило, при регистрации пользователя или при завершении запроса к незарегистрированному пользователю с получением завершающих сервисов). Индикатор отмены изменения цели является дополнением к существующему профилю пользователя, сохраненному на HSS, и кэшируемому посредством S-CSCF.

1.2. Когда S-CSCF принимает запрос на завершение начального SIP для обслуживаемого пользователя, она выполняет вычисление IFC посредством сравнения принятого запроса с сохраненными IFC в их предварительно определенном порядке приоритетов. Если запрос соответствует IFC, то вычисление прерывается, а запрос пересылается на AS, указанный посредством результата сравнения IFC.

1.3. Когда AS принимает запрос SIP и решает изменить цель запроса, он включает новую цель в Request-URI запроса SIP и возвращает запрос SIP обратно на S-CSCF.

1.4. Когда S-CSCF принимает запрос SIP, возвращаемый посредством AS, она проверяет, была ли изменена цель запроса, а также связан ли индикатор отмены изменения цели с IFC, который инициировал сообщение, отправляемое на AS. S-CSCF проверяет, была ли изменена цель запроса посредством сравнения идентификатора Request-URI сообщения SIP, отправляемого на AS, с Request-URI сообщения SIP, принятого c AS. Следующие действия могут привести к:

1.4.a. Если цель запроса не была изменена, то вычисление IFC возобновляется согласно нижеупомянутому этапу 1.5;

1.4.b. Если установлен индикатор отмены изменения цели для AS, указанного посредством IFC, который инициировал этот запрос, то вычисление IFC возобновляется согласно этапу 1.5;

1.4.c. Если цель запроса была изменена, а индикатор отмены изменения цели для AS, указанного посредством IFC, который инициировал этот запрос, не установлен, то вычисление IFC не возобновляется, а сообщение передают для обработки исходящего запроса;

1.5. В тех случаях, когда S-CSCF должна возобновить вычисление IFC, как требуется посредством вышеупомянутых этапов 4a и 4b, S-CSCF возобновляет вычисление IFC посредством сравнения запроса SIP, принятого с AS, c сохраненными IFC от следующего IFC в предварительно определенном порядке приоритетов. Если запрос соответствует IFC, то вычисление прерывается, а запрос пересылается на AS, указанный посредством сравнения IFC. Процедура продолжается с этапа 3.

2a. Индикатор отмены изменения цели, передаваемый посредством AS

Последовательность передачи сигналов для этого варианта осуществления показана на Фиг.6 и описана следующим образом:

2a.1. Когда S-CSCF принимает запрос на завершение начального SIP для обслуживаемого пользователя, она выполняет существующую процедуру вычисления IFC посредством сравнения принятого запроса с сохраненными IFC в предварительно определенном порядке приоритетов пользователя. Если запрос SIP соответствует IFC, то вычисление прерывается, а запрос пересылается на AS, указанный посредством результата сравнения IFC.

2a.2. Когда AS принимает запрос SIP и решает изменить цель запроса, он пересылает запрос SIP обратно на S-CSCF с новой целью в Request-URI запроса SIP, а также включает новый индикатор отмены изменения цели в запрос SIP для информирования S-CSCF о продолжении вычисления IFC.

2a.3. Когда S-CSCF принимает запрос SIP, возвращаемый посредством AS, она определяет, изменилась ли цель запроса, а также включен ли индикатор отмены изменения цели в принятый запрос. S-CSCF удаляет из запроса любой принятый индикатор отмены изменения цели перед дальнейшей обработкой на этапе 2.4 или перед выполнением обработки исходящего запроса. В результате этапа 2.3 могут произойти следующие действия:

2a.3.a. Если цель запроса не была изменена, то вычисление IFC возобновляется согласно этапу 2a.4;

2a.3.b. Если цель запроса была изменена и в запросе от AS принят индикатор отмены изменения цели, указывающий «отмену», то вычисление IFC возобновляется согласно этапу 2a.4;

2а.3.c. Если цель запроса была изменена, но принятое от AS сообщение SIP не содержит индикатора отмены изменения цели, то вычисление IFC не возобновляется, а сообщение передается для обработки исходящего запроса.

2a.4. Если вычисление IFC возобновляется, то S-CSCF возобновляет существующую процедуру вычисления IFC посредством сравнения принятого запроса с сохраненными критериями IFC из следующего IFC в предварительно определенном порядке приоритетов. Если запрос соответствует IFC, то вычисление прерывается, а запрос пересылается на AS, указанный посредством результата сравнения IFC. Процедура продолжается с этапа 2.2.

2b. Новая цель, передаваемая посредством AS

Последовательность передачи сигналов для этого варианта осуществления иллюстрирована на Фиг.7 и описана следующим образом:

2b.1. Когда S-CSCF принимает начальный запрос на завершение SIP для обслуживаемого пользователя, она выполняет существующую процедуру вычисления IFC посредством сравнения принятого запроса с сохраненными IFC в их предварительно определенном порядке приоритетов. Если запрос соответствует IFC, то вычисление прерывается, а запрос пересылается на AS, указанный посредством результата сравнения IFC.

2b.2. Когда AS принимает запрос SIP и решает изменить цель запроса, он пересылает запрос SIP обратно на S-CSCF без изменения Request-URI запроса. Вместо этого он добавляет новую цель в запрос SIP. Новая цель может быть включена в новый заголовок или, альтернативно, в тело сообщения.

2b.3. Запрос SIP возвращается на S-CSCF посредством AS с неизменным Request-URI. Следовательно, S-CSCF возобновляет вычисление IFC согласно существующей процедуре посредством сравнения принятого запроса с сохраненными IFC из следующего критерия IFC в предварительно определенном порядке приоритетов. Если запрос соответствует IFC, то вычисление прерывается, а запрос пересылается на AS, указанный посредством результата сравнения IFC. Процедура продолжается с этапа 3.2.

2b.4. В конце процедуры вычисления IFC, до выполнения обработки исходящего запроса, S-CSCF проверяет наличие новой цели в запросе SIP. В случае наличия новой цели S-CSCF помещает ее в Request-URI запроса, а также удаляет ее из запроса. После чего она возобновляет обычную процедуру обработки исходящего запроса на основе новой цели.

3. Логика отмены изменения новой цели в S-CSCF

Последовательность передачи сигналов для этого варианта осуществления иллюстрирована на Фиг.8 и описана следующим образом:

3.1. Когда S-CSCF принимает запрос на завершение начального SIP для обслуживаемого пользователя, она выполняет существующую процедуру вычисления IFC посредством сравнения принятого запроса с сохраненными IFC в предварительно определенном порядке их приоритетов. Если запрос соответствует IFC, то вычисление прерывается, а запрос пересылается на AS, указанный посредством результата сравнения IFC.

3.2. AS принимает запрос SIP и решает изменить цель запроса. Сообщение с запросом пересылается обратно на S-CSCF с новой целью в Request-URI запроса SIP.

3.3. Когда S-CSCF принимает запрос SIP, возвращаемый посредством AS, она определяет, была ли изменена цель запроса посредством AS, в случае положительного результата S-CSCF применяет логику для решения, корректировать ли изменение цели. Логика основана на информированности S-CSCF обо всех принадлежащих пользователю идентификаторах, включая в себя идентификаторы GRUU пользователя, в дополнение к зарегистрированным в настоящее время контактным адресам обслуживаемого пользователя. Эта новая логика определяет, принадлежит ли измененная цель обслуживаемому пользователю.

3.3.a. Если цель запроса не была изменена, то вычисление IFC возобновляется согласно этапу 3.4;

3.3.b. Если цель запроса была изменена и S-CSCF решает, что новая цель принадлежит обслуживаемому пользователю, то вычисление IFC возобновляется согласно этапу 3.4;

3.3.c. Если цель запроса была изменена и S-CSCF решает, что новая цель не принадлежит обслуживаемому пользователю, то вычисление IFC не возобновляется, а сообщение отправляется для обработки исходящего запроса;

3.4. Когда S-CSCF решает, что вычисление IFC должно быть возобновлено, S-CSCF возобновляет существующую процедуру вычисления IFC посредством сравнения принятого запроса с сохраненными IFC из следующего IFC в предварительно определенном порядке приоритетов. Если запрос соответствует IFC, то вычисление прерывается, а запрос пересылается на AS, указанный посредством результата сравнения IFC. Процедура продолжается с этапа 3.2.

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