ОБРАБОТКА ПЕРЕНАПРАВЛЕНИЯ ЗАПРОСА В IMC

ОБЛАСТЬ ТЕХНИКИ, К КОТОРОЙ ОТНОСИТСЯ ИЗОБРЕТЕНИЕ

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

УРОВЕНЬ ТЕХНИКИ

В Интернете существует много приложений, которые требуют создания сеанса и управления им, под сеансом понимают обмен данными между несколькими участниками. Реализация этих приложений усложняется из-за практических действий участников: пользователи могут перемещаться между конечными точками, они могут быть адресуемыми по нескольким именам и они могут осуществлять связь в нескольких разных средах - иногда одновременно. Были созданы многочисленные протоколы, позволяющие переносить различные формы данных мультимедийного сеанса реального времени, например голос, видео или текстовые сообщения. Протокол инициирования сеанса (SIP) действует во взаимодействии с этими протоколами благодаря тому, что конечным точкам Интернета (именуемым пользовательскими агентами) разрешается открываться друг другу и соглашаться на описание сеанса, который бы они хотели совместно использовать. Для определения местоположения предполагаемых участников сеанса и для других функций SIP допускает создание инфраструктуры сетевых хостов (именуемых прокси-серверами), на которые пользовательские агенты могут посылать регистрации, приглашения на сеансы и другие запросы. SIP это быстрый, универсальный инструмент для создания, изменения и окончания сеансов, который действует независимо от транспортных протоколов более низкого уровня и вне зависимости от типа устанавливаемого сеанса.

Более подробно SIP, заданный IETF (проблемной группой проектирования Интернета), описан в RFC (запросе на комментарии) 3261. Как отмечено выше, SIP позволяет устанавливать, обрабатывать и освобождать сквозные мультимедийные сеансы. Существует несколько дополнений к протоколу SIP, которые, например, допускают извещение о событии на основе SIP, что является основой для «услуги присутствия» на основе SIP и других услуг.

3GPP IMS (мультимедийная подсистема на основе IP проекта сотрудничества третьего поколения) использует SIP для достижения широкого диапазона функциональных возможностей в (беспроводной) сети 3GPP.

S-CSCF (обслуживающие функции управления состоянием вызова) в IMS загружают критерии фильтрации (FC) из HSS (домашней системы абонента). FC оцениваются по одному, то есть S-CSCF проверяет входящий запрос на основании открытой идентификации пользователя в Request-URI (запросе - универсальном идентификаторе ресурса) на предмет согласования с первым или начальным FC (наивысшего приоритета). Если он согласуется, то S-CSCF направляет его на соответствующий сервер приложений (СП, AS), указанный в FC, и добавляет идентификатор диалога в корневой заголовок, указывающий обратно на S-CSCF.

Когда запрос отправляется обратно от СП и вновь принимается на S-CSCF, S-CSCF идентифицирует запрос по идентификатору диалога и проверяет на согласование со следующими по порядку FC более низкого приоритета, и применяет критерии фильтрации к методу SIP, который принят от СП, с которым был установлен контакт ранее. В зависимости от результата предыдущего процесса S-CSCF может контактировать с одним или несколькими сервером(ами) приложений.

Из-за некоторых особых услуг СП может перенаправлять запрос (например, переадресация вызова). В этих случаях, для СП может быть нежелательно, чтобы S-CSCF осуществлял последующие FC. Согласно уровню техники СП не может влиять на такое поведение S-CSCF.

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

Последняя версия стандарта 3GPP TS 24.229, выпуск 5 (v.5.3.0), задает процедуры окончания на S-CSCF в общем виде, без учета специальных эффектов выполняемых услуг. Перенаправление запроса изменяет данные Request-URI сеанса, на который оказывается воздействие, что требует специальной обработки в S-CSCF, которая не может быть выполнена согласно общему описанию стандарта. Согласно уровню техники, описанному в главе 5.4.3.3 "Запрос, оканчивающийся на обслуживаемом пользователе" 3GPP TS 24.229, v.5.3.0, в случае перенаправления запроса, например переадресации вызова, выполнение остальных процедур приведет к конфликту с целью переадресации вызова. Согласно общему описанию в пункте 11 главы 5.4.3.3 "Запрос, оканчивающийся на обслуживаемом пользователе" 3GPP TS 24.229, v.5.3.0, Request-URI перезаписывается, что исключает саму возможность переадресации вызова. Другими словами, согласно уровню техники S-CSCF строит Request-URI с помощью содержимого сохраненного URL контакта (универсальный указатель ресурса), при этом пользователь, обслуживаемый S-CSCF, доступен, причем URL контакта определяется из открытой идентификации пользователя пункта назначения.

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

СУЩНОСТЬ ИЗОБРЕТЕНИЯ

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

Согласно изобретению эта задача решается посредством способа обработки запроса услуги по п.1, способа обработки услуги по п.16 и способа манипулирования запросом услуги по п.26.

Кроме того, вышеуказанная задача решается за счет устройства по п.12 и устройства для обработки запроса услуги по п.27.

Кроме того, вышеуказанная задача решается за счет блока по п.22 и блока для обработки запроса услуги по п.28.

Кроме того, вышеуказанная задача решается за счет компьютерного программного продукта по п.13 и компьютерного программного продукта по п.23.

Кроме того, вышеуказанная задача решается за счет мультимедийной базовой сети на основе IP по п.29.

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

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

КРАТКОЕ ОПИСАНИЕ ЧЕРТЕЖЕЙ

Фиг.1А - блок-схема способа обработки запроса услуги согласно настоящему изобретению.

Фиг.1В - блок-схема способа обработки услуги согласно настоящему изобретению.

Фиг.2 - блок-схема устройства обслуживания и блока обработки в мультимедийной базовой сети на основе IP согласно настоящему изобретению.

Фиг.3 - схема сигнализации, иллюстрирующая обработку запроса услуги согласно варианту осуществления настоящего изобретения.

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

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

ОПИСАНИЕ ИЗОБРЕТЕНИЯ

На фиг.1А показан способ обработки запроса услуги в мультимедийной базовой сети на основе IP. На этапе S11 запрос услуги для пользователя принимается устройством, обслуживающим пользователя. Например, этот запрос услуги был инициирован первым пользователем ко второму пользователю. Будучи принят на этапе S12, запрос услуги переадресуется в блок для обработки услуги. Затем, на этапе S16, результат обработки принимается от блока обработки и, на основании принятого результата обработки, на этапе S17 определяется, следует ли остановить обработку запроса услуги для второго пользователя.

На фиг.1В показан способ обработки услуги согласно запросу услуги, переадресованному в блок обработки. На этапе S13 запрос услуги, инициированный первым пользователем ко второму пользователю, принимается от устройства, обслуживающего второго пользователя. На этапе S14 услуга обрабатывается, и на этапе S15 в устройство возвращается результат обработки, на основании которого в устройстве можно определить (на этапе S17 на фиг.1А), следует ли остановить обработку запроса услуги для второго пользователя.

На фиг.2 показана мультимедийная базовая сеть на основе IP (сеть IMC) 29, выполненная с возможностью осуществления этапов S11-S17, показанных на фиг. 1А и 1В. В частности, сеть 29 IMC содержит устройство 20 обслуживания, обслуживающее пользователя для обработки запроса услуги для обслуживаемого пользователя, и блок 28 обработки для обработки услуги, соответствующей запросу услуги.

Устройство 20 обслуживания содержит первый приемный блок 22 для приема запроса услуги для обслуживаемого пользователя, блок 21 переадресации для переадресации принятого запроса услуги в блок 28 обработки для обработки услуги, второй приемный блок 23 для приема результата обработки от блока 28 обработки и блок 24 определения для определения, на основании принятого результата обработки, следует ли остановить обработку запроса услуги для обслуживаемого пользователя.

Блок 28 обработки содержит приемный блок 25 для приема запроса услуги от устройства 20 обслуживания, блок 26 обработки для обработки услуги и блок 27 возвращения для возвращения результата обработки в устройство 20 обслуживания, на основании которого в устройстве 20 можно определить, следует ли остановить обработку запроса услуги для второго пользователя.

Согласно варианту осуществления изобретения блок 28 обработки может включать в результат обработки указание для остановки обработки запроса услуги для обслуживаемого (второго) пользователя. Соответственно, устройство 20 обслуживания выполнено с возможностью проверки, включает ли в себя результат обработки, полученный от блока 28 обработки, указание для остановки обработки запроса услуги для второго пользователя и, в случае наличия указания, остановления обработки запроса услуги для второго пользователя. Устройство 20 обслуживания также может быть выполнено с возможностью проверки правильности указания.

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

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

Запрос услуги первого пользователя, принятый устройством 20 обслуживания для второго пользователя, может включать в себя идентификатор пункта отправки (идентификатор вызова) первого пользователя, и блок 28 обработки может включить идентификатор пункта отправки второго пользователя в результат обработки, определив в ходе обработки услуги, что запрос услуги следует перенаправить от второго пользователя третьему пользователю. Затем, в процедуре переадресации, устройство 20 обслуживания может обнаружить, что идентификатор пункта отправки, включенный в результат обработки, является идентификатором пункта отправки второго пользователя, и может переадресовать запрос услуги на основании идентификатора пункта отправки, включенного в результат обработки. Однако в случае, когда идентификатор пункта отправки, включенный в результат обработки, не является идентификатором пункта отправки второго пользователя, устройство 20 обслуживания может включить идентификатор пункта отправки второго пользователя в запрос услуги, подлежащий переадресации. Альтернативно, в процедуре переадресации устройство 20 обслуживания может всегда использовать идентификатор пункта отправки, включенный в результат обработки.

Согласно варианту осуществления изобретения идентификатор пункта отправки первого пользователя заменяется идентификатором пункта отправки второго пользователя. Альтернативно, идентификатор пункта отправки второго пользователя добавляется к идентификатору пункта отправки первого пользователя.

Ниже вариант осуществления изобретения будет описан со ссылкой на фиг.3-5.

На фиг.3 показана схема сигнализации, в которой пользователь A (первый пользователь) посылает начальный запрос услуги пользователю B (второму пользователю). Запрос услуги принимается устройством в IMC, обслуживающим пользователя B (устройством обслуживания), например S-CSCF (обслуживающей функцией управления состоянием вызова). S-CSCF переадресует начальный запрос услуги соответствующему серверу приложений СП (блоку обработки) для пользователя B, на котором запрос услуги обрабатывается. После этого СП возвращает результат обработки на S-CSCF. До сих пор процесс соответствует 3GPP TS 24.229, версия 5.3.0, выпуск 5, глава 5.4.3.3 "Запрос, оканчивающийся на обслуживаемом пользователе".

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

Согласно фиг.3 S-CSCF пользователя B обнаруживает из результата обработки, принятого от СП, что обработку окончания для пользователя B следует остановить. Прежде чем остановить обработку окончания, S-CSCF может осуществлять взимание платы, относящейся к функциям, описанным в пунктах 5-7 главы 6.4.3.3 "Запрос, оканчивающийся на обслуживаемом пользователе" 3GPP TS 24.229, v.5.3.0, выпуск 5.

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

На фиг.4 показан пример варианта осуществления фиг.3. Согласно фиг.4 начальный запрос, отправленный на S-CSCF для В, включает в себя R-URI (запрос - универсальный идентификатор ресурса) (идентификатор пункта назначения) пользователя B. S-CSCF переадресует запрос на СП пользователя B. При обработке услуги СП для В может обнаруживать перенаправление запроса услуги, например, пользователю C. Поскольку в этом случае S-CSCF для В не должна применять последующие критерии фильтрации, то СП для В может установить указание, что S-CSCF для В не должна оценивать дальнейшие критерии фильтрации.

СП может устанавливать это указание как часть, например, Request-URI запроса, посылаемого обратно на S-CSCF. Это может быть тег в Request-URI, например:

sip:Georg.Mayer@miesbach.de; FC=off

где "sip:Georg.Mayer@miesbach.de" - это R-URI пользователя C.

Это указание также можно устанавливать другими способами (например, дополнительный заголовок, параметр другого заголовка и т.д.).

Затем S-CSCF должна проверить, разрешено ли СП, от которого она приняла обратно запрос, устанавливать указание. Если его разрешено устанавливать, то S-CSCF должна остановить оценку последующих FC и немедленно обработать перенаправление запроса (или, по меньшей мере, сразу же после выполнения вышеупомянутых операций взимания платы). Другими словами, когда S-CSCF для В обнаруживает тег "FC=off" в результате обработки, возвращенном от СП для В, она останавливает обработку окончания для пользователя B и входит в роль пункта отправки, например, для обработки переадресации вызова по Request-URI, указанному в возвращенном результате обработки.

На фиг.5 показан еще один пример варианта осуществления фиг.3. Согласно фиг.5 начальный запрос, отправленный на S-CSCF для В, включает в себя R-URI (запрос - универсальный идентификатор ресурса) (идентификатор пункта назначения) пользователя B и заголовок P-A-ID (P-Asserted Identity) (идентификатор пункта отправки) пользователя A. S-CSCF для В переадресует запрос на СП пользователя B. Результатом обработки услуги может быть перенаправление запроса услуги пользователю C. Для обнаружения перенаправления запроса S-CSCF всегда сравнивает Request-URI, отправленный на СП и Request-URI, принятый от СП. Согласно фиг.5 R-URI изменился с В на С, поэтому S-CSCF обнаруживает, что выполненный запрос включал в себя перенаправление запроса, например переадресацию вызова.

В случае переадресации вызова заголовок P-Asserted ID следует изменить так, чтобы пользователь C имел возможность обнаруживать, что запрос или вызов от пользователя A приходит через пользователя B. Например, если пользователь C имеет запрет вызова для пользователя A, и пользователь A вызывает пользователя B, который имеет переадресацию вызова на пользователя C, то с точки зрения пользователя B переадресация не пройдет. Согласно изобретению изменение заголовка P-Asserted ID может осуществлять либо СП, реализующий услугу переадресации вызова, либо S-CSCF окончания, которая обнаруживает переадресацию вызова (в случае, когда СП не изменил заголовок). Согласно фиг.5 СП для В уже изменил P-A-ID с А на В. Изменение заключается либо в замене заголовка P-Asserted ID на IMPU (открытая идентификация пользователя в мультимедийной системе на основе IP) обслуживаемого пользователя (это может быть также другой IMPU обслуживаемого пользователя), как показано на фиг.5, либо во введении IMPU обслуживаемого пользователя (опять же, это может быть также другой IMPU обслуживаемого пользователя) в начало исходного заголовка P-Asserted ID, то есть 'P-A-ID = B,A'. Согласно фиг.5 затем вызов переадресуется с P-A-ID = B.

После того как S-CSCF для В обнаружит переадресацию вызова, S-CSCF для В может выполнять задания, связанные со взиманием платы, которые описаны в пунктах 5, 6 и 7 главы 5.4.3.3 "Запрос, оканчивающийся на обслуживаемом пользователе" 3GPP TS 24.229, v.5.3.0, выпуск 5. Если пользователь B установил переадресацию вызова, то пользователь B должен заплатить за переадресованную часть вызова с В в С.

По завершении функций, связанных со взиманием платы, S-CSCF окончания меняет свою роль с S-CSCF окончания на S-CSCF начала и начинает действовать, как описано в главе 5.4.3.2 "Запрос, инициируемый обслуживаемым пользователем" 3GPP TS 24.229, v.5.3.0, выпуск 5, причем обслуживаемый пользователь в этой S-CSCF начала является IMPU переадресации, хранящимся в заголовке P-Asserted ID, то есть пользователем B. Другими словами, S-CSCF для В входит в роль пункта отправки и переадресует начальный запрос услуги пользователю C в соответствии с 3GPP TS 24.229, v.5.3.0, выпуск 5, глава 5.4.3.2 "Запрос, инициируемый обслуживаемым пользователем".

S-CSCF для В должна гарантировать, что все ограничения/установки, заданные для вызовов, исходящих от В, выполнены.

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

Следует заметить, что задания взимания платы, показанные в блоке 5 на фиг.5, также могут выполняться в варианте осуществления, показанном на фиг.4, после обнаружения, что обработку окончания для B следует остановить, и до фактической остановки обработки окончания для B. Кроме того, изменение P-A-ID также можно применять к варианту осуществления, показанному на фиг.4.

Кроме того, следует заметить, что вышеприведенные примеры можно комбинировать по-разному. Например:

В отношении изменения R-URI:

а) СП для В просто изменяет R-URI без какого-либо особого указания в результате обработки.

b) СП для В обозначает изменение R-URI в результате обработки.

Для изменения P-A-ID имеются два места для вариантов:

Место изменения:

0. Нет изменения (это также возможный вариант, хотя при этом С не будет знать об участии В).

1. Производится на СП для В.

2. Производится в S-CSCF для В после обнаружения перенаправления.

Способ изменения:

Х. Замена А на В.

Y. Замена А на В,А.

Тогда возможны следующие комбинации: 0, 1X, 1Y, 2X и 2Y.

С учетом также изменения R-URI возможны следующие комбинации: a0, b0, a1X, b1X, a1Y, b1Y, a2X, b2X, a2Y и b2Y.

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