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

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

Info

Publication number
RU2426262C2
RU2426262C2 RU2008125842/09A RU2008125842A RU2426262C2 RU 2426262 C2 RU2426262 C2 RU 2426262C2 RU 2008125842/09 A RU2008125842/09 A RU 2008125842/09A RU 2008125842 A RU2008125842 A RU 2008125842A RU 2426262 C2 RU2426262 C2 RU 2426262C2
Authority
RU
Russia
Prior art keywords
message
cscf
call
user
uri
Prior art date
Application number
RU2008125842/09A
Other languages
English (en)
Other versions
RU2008125842A (ru
Inventor
ЭЛБУРГ Йоханнес ВАН (NL)
ЭЛБУРГ Йоханнес ВАН
Алф ХЕЙДЕРМАРК (SE)
Алф ХЕЙДЕРМАРК
Original Assignee
Телефонактиеболагет Лм Эрикссон (Пабл)
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Family has litigation
First worldwide family litigation filed litigation Critical https://patents.darts-ip.com/?family=35601219&utm_source=google_patent&utm_medium=platform_link&utm_campaign=public_patent_search&patent=RU2426262(C2) "Global patent litigation dataset” by Darts-ip is licensed under a Creative Commons Attribution 4.0 International License.
Application filed by Телефонактиеболагет Лм Эрикссон (Пабл) filed Critical Телефонактиеболагет Лм Эрикссон (Пабл)
Publication of RU2008125842A publication Critical patent/RU2008125842A/ru
Application granted granted Critical
Publication of RU2426262C2 publication Critical patent/RU2426262C2/ru

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/10—Architectures or entities
    • H04L65/1016—IP multimedia subsystem [IMS]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/30—Managing network names, e.g. use of aliases or nicknames
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066—Session management
    • H04L65/1101—Session protocols
    • H04L65/1104—Session initiation protocol [SIP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/14—Session management
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/14—Session management
    • H04L67/147—Signalling methods or messages providing extensions to protocols defined by standardisation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M7/00—Arrangements for interconnection between switching centres
    • H04M7/006—Networks other than PSTN/ISDN providing telephone service, e.g. Voice over Internet Protocol (VoIP), including next generation networks with a packet-switched transport layer
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2101/00—Indexing scheme associated with group H04L61/00
    • H04L2101/30—Types of network names
    • H04L2101/385—Uniform resource identifier for session initiation protocol [SIP URI]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066—Session management
    • H04L65/1101—Session protocols

Abstract

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

Description

Область техники, к которой относится изобретение
Настоящее изобретение относится к обработке сообщений протокола установления сессии в подсистеме мультимедиа на базе протокола 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), а именно userf_public1@home2.net. Сообщение INVITE также содержит P-Asserted Identity пользователя, инициирующего сессию, а именно “John Doe” <sip:user1_public1@home1.net>, <tel:+1-212-555-1111>. 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:alice@home1.net;orig
P-Served-User-Identity: sip:bob@home2.net;termunreg
P-Served-User-Identity: sip:bob@home2.net;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, а именно userf_public1@home2.net, в то время как P-Asserted-Identity представляет собой идентификатор пользователя, отправившего сообщение, а R-URI представляет собой идентификатор нового пользователя, являющегося конечным получателем сообщения. На Фиг. 8 изображена схема обмена сообщениями между S-CSCF F и двумя серверами приложений (AS) - AS-F 1 и AS-F 2.
Специалисту в данной области должно быть понятно, что в варианты выполнения изобретения, описанные выше, могут быть внесены различные изменения без отступления от объема настоящего изобретения.

Claims (11)

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 (протокол установления сессии) и для применения исходных критериев фильтрации к сообщению и, если исходные критерии фильтрации требуют пересылки сообщения в сервер приложения, также для добавления к пересылаемому сообщению заголовка, содержащего идентификатор обслуживаемого пользователя, к которому относится сообщение.
RU2008125842/09A 2005-11-25 2006-10-26 Обработка сообщений в подсистеме мультимедиа на базе протокола ip RU2426262C2 (ru)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
GB0524036.1 2005-11-15
GB0524036A GB2432748A (en) 2005-11-25 2005-11-25 SIP messaging in an IP Multimedia Subsystem wherein a local user identity is added to message header as a basis for application server processing

Publications (2)

Publication Number Publication Date
RU2008125842A RU2008125842A (ru) 2009-12-27
RU2426262C2 true RU2426262C2 (ru) 2011-08-10

Family

ID=35601219

Family Applications (1)

Application Number Title Priority Date Filing Date
RU2008125842/09A RU2426262C2 (ru) 2005-11-25 2006-10-26 Обработка сообщений в подсистеме мультимедиа на базе протокола ip

Country Status (15)

Country Link
US (2) US9392027B2 (ru)
EP (1) EP1958417B1 (ru)
JP (1) JP4955694B2 (ru)
CN (1) CN101313553B (ru)
AT (1) ATE432581T1 (ru)
CA (1) CA2630678C (ru)
DE (1) DE602006007036D1 (ru)
DK (1) DK1958417T3 (ru)
ES (1) ES2327274T3 (ru)
GB (1) GB2432748A (ru)
IL (1) IL191456A (ru)
MA (1) MA29973B1 (ru)
RU (1) RU2426262C2 (ru)
WO (1) WO2007060074A1 (ru)
ZA (1) ZA200804495B (ru)

Families Citing this family (15)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101267431B (zh) 2007-03-12 2012-09-26 中兴通讯股份有限公司 Ip多媒体子系统业务触发过程中初始请求消息的匹配方法
US8774178B2 (en) 2007-07-30 2014-07-08 Alcatel Lucent Call transfer with multiple application servers in session initiation protocol-based network
CN101136924B (zh) * 2007-09-29 2011-02-09 中兴通讯股份有限公司 一种下一代网络中主叫身份标识显示的方法
US8762553B2 (en) 2008-01-11 2014-06-24 Telefonaktiebolaget L M Ericsson (Publ) Message handling in an IP multimedia subsystem
EP2104305A1 (en) 2008-03-21 2009-09-23 Koninklijke KPN N.V. Call service handling in an IMS-based system
US9094411B2 (en) * 2008-04-16 2015-07-28 Alcatel Lucent Mechanism to resume filter criteria at a specific point
EP2112799A1 (en) 2008-04-25 2009-10-28 Koninklijke KPN N.V. Service integrity handling in an IMS-based system
WO2009146739A2 (en) * 2008-06-03 2009-12-10 Telefonaktiebolaget Lm Ericsson (Publ) Identifying user role in ip multimedia subsystem
EP3086532B1 (en) 2009-04-13 2019-11-06 BlackBerry Limited System and method for determining trust for sip messages
US8392581B2 (en) * 2009-06-09 2013-03-05 Verizon Patent And Licensing Inc. Intelligent IMS SIP session setup optimization
US8793388B2 (en) 2009-12-28 2014-07-29 At&T Intellectual Property I, L.P. Method and apparatus for processing a call to an aggregate endpoint device
US8451841B2 (en) 2009-12-28 2013-05-28 At&T Intellectual Property I, L.P. Method and apparatus for processing a call to an aggregate endpoint device
JP5272027B2 (ja) * 2011-02-21 2013-08-28 日本電信電話株式会社 呼制御方法、および呼制御システム
EP2749000B1 (en) * 2011-09-28 2015-08-19 Telefonaktiebolaget L M Ericsson (publ) Extending sip p-served user header over ims interfaces
EP3371952B1 (en) * 2015-11-05 2021-08-11 Telefonaktiebolaget LM Ericsson (PUBL) Method and apparatus for controlling services in an internet protocol multimedia subsystem

Family Cites Families (26)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6882637B1 (en) * 1999-10-14 2005-04-19 Nokia Networks Oy Method and system for transmitting and receiving packets
CN1223236C (zh) * 2001-05-28 2005-10-12 诺基亚公司 在至少两个逻辑网络单元之间路由呼叫的方法和控制装置
US7292554B2 (en) * 2001-07-05 2007-11-06 Samsung Electronics Co., Ltd. Apparatus and method for transmitting a voice frame in an ALL-IP-based mobile communication system
US6888828B1 (en) * 2001-10-02 2005-05-03 Nokia Corporation System and method for providing at least one service obtained from a service network for a user in a packet switched communication network
US8121597B2 (en) 2002-03-27 2012-02-21 Nokia Siemens Networks Oy Method of registering and deregistering a user
GB0208069D0 (en) * 2002-04-08 2002-05-22 Nokia Corp Message header for messaging service
KR100893070B1 (ko) * 2002-09-19 2009-04-17 엘지전자 주식회사 무선통신 시스템의 멀티캐스트 서비스 제공 및 수신 방법, 그리고 그 장치
US7917620B2 (en) 2003-02-20 2011-03-29 Nokia Corporation Communication system
US7412521B2 (en) * 2003-03-12 2008-08-12 Microsoft Corporation End-point identifiers in SIP
US7542556B2 (en) * 2003-03-17 2009-06-02 Alcatel-Lucent Usa Inc. Apparatus and method for providing multiple line billing in telecommunications systems
US7529839B2 (en) * 2003-03-24 2009-05-05 Nokia Corporation Request redirection handling in IMC
BRPI0408649B1 (pt) 2003-03-25 2017-11-07 Nokia Technologies Oy Method of configuring a network element, method for providing subscription services and network element
JP4008861B2 (ja) 2003-07-15 2007-11-14 富士通株式会社 無線データ伝送システム
GB0322891D0 (en) 2003-09-30 2003-10-29 Nokia Corp Communication method
WO2005055549A1 (en) 2003-12-01 2005-06-16 France Telecom System for providing services in response to a communications session message
US8028084B2 (en) * 2004-01-20 2011-09-27 Aspect Software, Inc. IP ACD using buffer server
US20050213606A1 (en) * 2004-03-25 2005-09-29 Jiun-Yao Huang Method of triggering application service using response filter criteria and IP multimedia subsystem using the same
GB0422275D0 (en) * 2004-10-07 2004-11-10 Nokia Corp Callback services in a communication system
US20060083242A1 (en) * 2004-10-20 2006-04-20 Nokia Corporation Address modification in application servers
US8804653B2 (en) * 2005-01-13 2014-08-12 Telefonaktiebolaget Lm Ericsson (Publ) System and method for call handoff between circuit switched and packet data wireless networks
US7865602B2 (en) * 2005-02-23 2011-01-04 Nokia Siemens Networks Oy System, method, and network elements for providing a service such as an advice of charge supplementary service in a communication network
US20070100981A1 (en) * 2005-04-08 2007-05-03 Maria Adamczyk Application services infrastructure for next generation networks including one or more IP multimedia subsystem elements and methods of providing the same
US20060268781A1 (en) * 2005-05-02 2006-11-30 Telefonaktiebolaget Lm Ericsson (Publ) System and method for call handoff from packet data wireless network to circuit switched wireless network
CN101185305B (zh) * 2005-05-27 2012-08-29 艾利森电话股份有限公司 Ip多媒体子系统(ims)中的呼叫前转
US8798253B2 (en) * 2005-07-29 2014-08-05 Verizon Patent And Licensing Inc. Network routing
EP2037650B1 (en) * 2007-09-12 2010-09-08 Nokia Siemens Networks Oy Providing services in case of call diversion in a communication system

Also Published As

Publication number Publication date
CN101313553A (zh) 2008-11-26
CA2630678A1 (en) 2007-05-31
EP1958417B1 (en) 2009-05-27
DK1958417T3 (da) 2009-07-20
CN101313553B (zh) 2012-11-21
MA29973B1 (fr) 2008-11-03
DE602006007036D1 (de) 2009-07-09
ES2327274T3 (es) 2009-10-27
CA2630678C (en) 2013-07-30
IL191456A (en) 2012-04-30
ZA200804495B (en) 2009-08-26
US9392027B2 (en) 2016-07-12
GB0524036D0 (en) 2006-01-04
WO2007060074A1 (en) 2007-05-31
US9648048B2 (en) 2017-05-09
EP1958417A1 (en) 2008-08-20
US20160285919A1 (en) 2016-09-29
JP4955694B2 (ja) 2012-06-20
GB2432748A (en) 2007-05-30
RU2008125842A (ru) 2009-12-27
ATE432581T1 (de) 2009-06-15
US20090213838A1 (en) 2009-08-27
JP2009517902A (ja) 2009-04-30

Similar Documents

Publication Publication Date Title
RU2426262C2 (ru) Обработка сообщений в подсистеме мультимедиа на базе протокола ip
JP4700105B2 (ja) Ｉｐマルチメディアサブシステム（ｉｍｓ）おける呼転送
KR101139072B1 (ko) Ｉｍｓ 기반 통신 개시 방법
JP4851516B2 (ja) Ｉｍｓサービスを識別する方法および装置
US9031067B2 (en) Routing messages
US20040246965A1 (en) System and method for routing messages
US9420018B2 (en) End-to-end address transfer
JP5430553B2 (ja) Ｉｐマルチメディアサブシステムにおけるユーザｉｄの処理
RU2389148C2 (ru) Способ и устройство идентификации ims-услуги
MX2008006661A (en) Message handling in an ip multimedia subsystem