RU2359422C2

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

Info

Publication number: RU2359422C2
Application number: RU2007101524/09A
Authority: RU
Inventors: Дирк ТРОССЕН (US); Дирк ТРОССЕН; Дана ПАВЕЛ (US); Дана ПАВЕЛ
Original assignee: Нокиа Корпорейшн
Priority date: 2004-06-23
Filing date: 2005-06-15
Publication date: 2009-06-20
Also published as: EP1759513A1; JP4944022B2; CA2571413A1; ZA200700589B; CN101002451A; US20050289097A1; KR20070037748A; JP2008504727A; KR100876197B1; RU2007101524A; US8903820B2; JP5001416B2; CN101002451B; EP1759513B1; MXPA06014825A; JP2011061825A; WO2006000866A1; CA2571413C; HK1099855A1

Abstract

Изобретение относится к системам связи. Технический результат заключается в усовершенствовании процедуры подписки. Раскрыты система и способ для предоставления уведомления о событиях. Способ управления сервером событий и блоком подписчика, включает прием на сервере событий от блока подписчика сообщения с заявкой на подписку, которое включает семантику запроса; в ответ на прием сообщения с заявкой на подписку, анализ семантики запроса для определения, принять или отвергнуть заявку на подписку; и принятие заявки на подписку в том случае, если запрос успешно проанализирован и распознан, и если соответствующие данные о ресурсах доступны серверу событий. 6 н. и 55 з.п. ф-лы, 3 ил.

Description

ОБЛАСТЬ ТЕХНИКИ

Данное изобретение относится в общем к беспроводным коммуникационным системам и средствам, а более конкретно к беспроводным терминалам и сетевым узлам, которые используют протокол SIP (протокол инициирования сессии).

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

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

В документе «Уведомление о событии в контексте протокола SIP», A.Roach, RFC3265, июль 2002 (в дальнейшем называемом просто «RFC3265»), описана инфраструктура SIP-событий, позволяющая предоставлять событийную информацию для любого узла Интернет. Ожидается, что эта процедура станет ключевым элементом в рамках SIP-инфраструктуры. Примерами информации такого типа являются «присутствие», информация о местоположении, доступность контента или сервиса, SIP-события контроля доступа, как описано в некоторых из упомянутых ниже родственных патентных заявках.

Как указано в RFC3265, основная идея заключается в том, что сетевые объекты могут подписываться на состояние ресурса или вызова для различных ресурсов или вызовов в сети, и эти объекты (или объекты, действующие от их лица) могут посылать уведомления, когда эти состояния изменяются. Типичным потоком сообщений будет:

I-SUBSCRIBE→I	Запрос подписки на уведомление о состоянии
I←200-I	Подтверждение подписки
I←Notify-I	Передача информации о текущем состоянии
I-200→I	Подтверждение
I←Notify-I	Передача информации о текущем состоянии
I-200→I	Подтверждение

Сроки действия подписок истекают, и их необходимо обновлять последующими сообщениями SUBSCRIBE.

Несколько полезных определений:

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

«Шаблон-пакет событий» - это «пакет событий» специального типа, который определяет множество состояний, которое может применяться для всех возможных «пакетов событий», включая его самого.

Уведомление - это действие уведомителя по отправке сообщения NOTIFY подписчику для уведомления подписчика о состоянии ресурса.

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

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

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

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

Миграция подписки - это действие по переносу подписки от одного уведомителя к другому уведомителю.

Метод SUBSCRIBE используется для запроса текущего состояния и обновлений состояния удаленного узла.

Дж.Розенберг в документе «Шаблон-пакет событий информации наблюдателя для протокола SIP», 'draft-ietf-simple-winfo-package-05.txt', янв.31, 2003, определил шаблон-пакет информации наблюдателя для инфраструктуры SIP-событий. Информация наблюдателя в этом контексте относится к множеству пользователей, которые подписаны на определенный ресурс в рамках определенного пакета событий. Информация наблюдателя динамически изменяется по мере того, как пользователи подписываются, отказываются от подписки, принимаются или отвергаются. Пользователь может подписаться на информацию и, таким образом, может узнавать об изменениях этой информации. Этот определенный пакет событий называется шаблоном-пакетом, так как он может применяться к любому пакету событий, включая самого себя.

Инфраструктура событий протокола SIP, как показано в RFC3265, это способ предоставления контекстной информации в целом. Например, «присутствие» предоставляет определенную порцию контекстной информации с использованием определенного пакета событий протокола SIP. Однако текущее решение по подписке на события протокола SIP, например присутствие, информацию наблюдателя и информацию о состоянии вызова, предоставляет только подписку на информацию о состоянии, которая связана с определенным ресурсом, при этом определенный ресурс адресуется как URI (универсальный идентификатор ресурса) протокола SIP. Например, подписка на событие присутствия привязана к так называемому «объекту присутствия», представляющему пользователя, с которым связана информация о присутствии. Следовательно, при подписке на информацию о состоянии подписчик подписывается на информацию о состоянии определенного, априорно известного ресурса (адресуемого при помощи URI протокола SIP). В настоящее время невозможно подписаться на информацию о состоянии, которая извлекается из множества информации о состоянии, связанного с определенными URI.

Основываясь на предшествующем, можно понять, что при использовании текущей модели подписки на такие вопросы (запросы) протокола SIP, как:

«Какие персоны (ресурсы) находятся на встрече, которая проходит в определенном месте?»

и

«Какие персоны (ресурсы) сейчас на работе и не заняты, местоположение работы - Бостон?»,

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

Легко видеть, что подобное решение не масштабируемо; если представить обширный домен, например, мобильного оператора, подобное решение могло бы легко перегрузить подписчика поддержкой подписок и обработкой входящих уведомлений, а равно и сервер событий протокола SIP созданием такого большого числа подписок. Также подобное решение могло бы легко потерпеть неудачу, например, упустив определенные домены, которые содержатся на определенном сервере событий протокола SIP, но неизвестны подписчику.

То есть подписчик может «пропустить» определенные ресурсы просто потому, что он не знает / не осведомлен о значимости определенных ресурсов для ответа на запрос. Например, определенный сервер событий протокола SIP может содержать информацию о событиях для ресурсов двух различных доменов: «domain1.com» и «domain2.com». Предположим в этом случае, что подписчик осведомлен о наличии первого домена, но не осведомлен о втором домене. Следовательно, подписчик не подпишется на релевантные ресурсы второго домена и, таким образом, потенциально может «упустить» важную информацию.

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

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

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

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

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

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

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

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

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

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

фиг.1 иллюстрирует общую архитектуру и основные логические объекты данного изобретения;

фиг.2 иллюстрирует различные этапы процесса и сообщения в соответствии с изобретением; и

фиг.3 показывает блок-схему сервера событий протокола SIP, показанного на фиг.1.

ПОДРОБНОЕ ОПИСАНИЕ ВАРИАНТОВ ПРЕДПОЧТИТЕЛЬНОГО

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

Данная патентная заявка связана со следующими патентными заявкам США, принадлежащими заявителю: Д.Троссен, «Интеграция регистрации и обнаружения сервисов в среде SIP», №10/179, 244, подана 06/26/2002; Д.Троссен, «Регистрация, запрос и уведомление о контенте и сервисах с использованием пакетов событий протокола SIP», №10/330,146, подана 12/30/2002; Д.Троссен, К.Мехта, «Способ предупреждения при контроле доступа с использованием пакетов событий протокола SIP», №10/353.014, подана 01/29/2003; Д.Троссен, «Запрашивание пакетов SIP-событий с использованием метода OPTIONS протокола SIP или с использованием обнаружения сервисов», №10/418,313, подана 04/18/2003; и с Д.Троссен, Д.Павел, «Применение семантического связывания в шаблонах-пакетах событий протокола SIP», №10/465, 455, подана 06/19/2003; эти заявки полностью включены в настоящее описание путем ссылки.

Настоящее изобретение решает вышеупомянутые и другие проблемы путем введения улучшенного пакета событий протокола SIP, который предусматривает подписку на сложные запросы в рамках одного диалога. Фактический запрос является частью подписки, и в ответ сервер событий протокола SIP исполняет требуемую логику приложения для определения соответствующего списка ресурсов для удовлетворения запроса и ответа на него. Использование данного изобретения снимает нагрузку с подписчика и выполняет функции по согласованию там, где находятся релевантные данные, а именно - на самом сервере событий протокола SIP. Также изобретение поддерживает использование произвольной семантики для запросов, поддерживает онтологии для повторного использования семантики и интегрирует такие методы контроля доступа, как протокол конфигурации доступа, основанный на языке XML (см. документ IETF (работа в процессе) «Протокол конфигурации доступа языка XML» Дж.Розенберг, май 2003), называемый ниже ХСАР.

На фиг.1 показана упрощенная архитектурная схема системы 10, которая подходит для использования данного изобретения. Система 10 включает подписчика 12, локальные SIP-прокси 14, 16, сеть 18 (например, IP-сеть), сервер 20 событий протокола SIP, сервер 22 онтологии (опционально) и менеджер 24 политики авторизации.

Сервер 20 событий протокола SIP реализует события протокола SIP и для удобства предполагается совместимым с процедурами документа «Уведомление о событиях в среде протокола SIP», A.Roach, RFC3265, июль 2002. Предполагается, что сервер 20 событий протокола SIP является кандидатом для подписки для вышеупомянутого потенциального подписчика 12.

SIP-прокси 14 и SIP-прокси 16 ответственны за обработку сообщений протокола SIP и, соответственно, пересылку их указанному объекту. Обратим внимание, что SIP-прокси 14, 16 представляют собой примеры вариантов осуществления объектов, которые занимаются пересылкой регистраций/подписок/уведомлений, как положено в инфраструктуре событий протокола SIP по RFC3265. Другие механизмы могут также использоваться, как вариант осуществления настоящего изобретения. Однако последующее описание ссылается на серверы 14 и 16 событий протокола SIP без ограничения общей сущности настоящего изобретения.

Сервер 22 онтологии предусматривает регистрацию и запрос онтологии. В целях данного изобретения онтологии могут рассматриваться, чтобы получить семантику информации из различных источников и дать ей точное, единообразное и декларативное описание (см., например, Y.Ding, D.Fensel, «Системы библиотек онтологии: Ключ к успешному повторному использованию онтологий»,

http://www.semanticweb.org/SWWS/program/full/paper58.pdf, авг. 2001).

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

В предпочтительном в настоящее время варианте осуществления данного изобретения предполагается, что и подписчик 12, называемый также блок подписчика, и сервер 20 событий включают интерфейс к сети 18 и соответствующим образом запрограммированную управляющую логику 12А и 20A-20F (см. фиг.3), соответственно, для реализации данного изобретения.

Настоящее изобретение предоставляет способ, делающий возможными такие запросы к данным о событиях протокола SIP, как:

и

«Какие персоны (ресурсы) сейчас находятся на работе в Бостоне и не заняты?»

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

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

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

Настоящее изобретение предоставляет поддержку повторного использования семантики запроса через онтологии путем использования способов косвенного предоставления контента для тела подписки, а также поддерживает контроль доступа путем интеграции контроля доступа в процесс определения списка ресурсов. Черновик документа IETF "draft-ietf-sip-content-indirect-mech-03", озаглавленный «Механизм косвенного предоставления контента в сообщениях протокола SIP» (С.Олсон, 2 июня, 2003), описывает стандартный механизм для предоставления косвенного контента в сообщениях протокола SIP. Также можно сослаться на С.Олсон, «Требования к косвенному контенту протокола SIP», черновик документа IETF, сен. 2002.

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

Обратимся к фиг.3. В целях реализации настоящего изобретения сервер 20 событий протокола SIP также включает, помимо логики 20А, предоставляющей функциональность по RFC3265, и сетевого интерфейса 20В, логику 20С, предоставляющую поддержку способа косвенного предоставления контента, или какого-либо иного способа для получения данных с сервера 22 онтологии, для случая, когда используются один или более серверов онтологии для определения семантики запроса. Сервер 20 событий протокола SIP также включает логику 20D для интерпретации семантики запроса, которая предоставлена серверу событий протокола SIP подпиской с использованием пакета события resource_query, как описано ниже, с тем чтобы определить список ресурсов, который будет удовлетворять семантике запроса, а также чтобы определить, способен ли сервер 20 приложений SIP поддерживать требуемый список ресурсов. Логика 20D показана соединенной с локальным источником данных 21 о ресурсах. Сервер 20 событий протокола SIP также включает логику 20Е для реализации семантики желаемого запроса, который был предоставлен серверу 20 событий протокола SIP подпиской с использованием пакета события resource_query. Подобная реализация предпочтительно оперирует данными 21 о ресурсах, которые хранятся локально на сервере 20 событий протокола SIP. Однако также возможно, что эти данные о ресурсах получают полностью или частично из внешнего источника, как обсуждается ниже при описании пакета событий. Сервер 20 событий протокола SIP также предпочтительно включает логику 20F для поддержки политики авторизации для обеспечения секретности данных о ресурсах, например в соответствии с протоколом ХСАР. Однако эта конкретная функциональность не обязательна и может рассматриваться как опциональная. Менеджер 24 политики авторизации предусматривает определение политики авторизации для определенных данных о ресурсах и может следовать, например, процедуре Розенберга, в отношении коммуникации между пользователями таких политик, например, сервером 20 событий протокола SIP и так называемым ХСАР-сервером (представляющим собой менеджер 24 политики авторизации, как показано на фиг.1).

Далее обсуждается определение пакета событий, на которое ссылались выше. Данное изобретение определяет пакет событий протокола SIP с единственным событием, которое называется "resource_query" в дальнейшем описании. Семантика пакета событий следующая.

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

Запрос формулируется с использованием подходящего языка запросов. Точные синтаксис и семантика языка запросов находятся вне рамок изобретения. Однако нотации подобные Формату Описания Ресурсов (RDF) или языку XML подходят для использования при формулировании таких запросов. Для того чтобы распространить подобную информацию о семантике запросов среди большого числа пользователей, то есть создать общее знание семантики, изобретение поддерживает понятие использования серверов 22 онтологии при выполнении операции подписки на запрос, как обсуждается ниже.

Данные о ресурсах полагаются доступными на сервере 20 событий протокола SIP. Эти данные о ресурсах могут включать состояние, связанное с другими SIP-событиями, которые содержатся на сервере 20 событий протокола SIP. He ограничивающие изобретение примеры таких данных о ресурсах могут включать следующее:

A) Информация о присутствии, которая включает все данные, определенные в так называемых документах присутствия, например как указано в PIDF (формат данных информации присутствия) или RPID (обогащенный PIDF).

B) Информация наблюдателя, которая включает данные о подписчиках на информацию о присутствии или другие SIP-события.

C) Состояние вызова, которое включает данные о состоянии вызова.

D) Зависимые от приложения SIP-события, которые включают данные о ресурсах, описанные зависимой от приложения семантикой, например такие, как предоставленные патентной заявкой США, принадлежащей заявителю, Д.Троссен, Д.Павел, «Применение семантического связывания в шаблонах-пакетах событий протокола SIP», №10/465, 455, подана 06/19/2003.

Ресурсы обычно выражаются в виде SIP URI, при этом объект присутствия составляет ресурс, в то время как связанный с ним документ присутствия составляет данные о ресурсе для ресурса, то есть объекта присутствия.

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

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

Для второго варианта, то есть получаемых извне данных о ресурсах, сервер 20 событий протокола SIP может выполнять соответствующие запросы о предоставлении данных, например подписки на SIP-события, к другим сетевым объектам. Ради упрощения в последующем описании будем полагать, что данные о ресурсах содержатся локально на сервере 20 событий протокола SIP как локальные данные 21 о ресурсах. Однако получение данных о ресурсах извне также попадает в рамки данного изобретения.

Для всех данных о ресурсах или их части могут существовать соответствующие политики авторизации, которые определяют права доступа к определенным данным о ресурсах. Как показано на фиг.1, полагается, что подобные политики авторизации могут быть доступны серверу 20 событий протокола SIP путем использования опционального менеджера 24 политики авторизации. Если подобные политики авторизации имеются, то полагается, что сервер 20 событий протокола SIP принимает их в расчет при определении списка ресурсов, которые удовлетворяют ограничениям, сформулированным в запросе при подписке.

Сервер 20 событий протокола SIP возвращает код возврата '200 OK' подписчику 12 (по RFC3265) если:

семантика запроса была полностью понята; и

соответствующие данные о ресурсах, требуемые для определения результата запроса, доступны (или могут быть сделаны доступными) серверу 20 событий протокола SIP (локально или извне);

иначе, сервер 20 событий протокола SIP возвращает подписчику 12 код ошибки по RFC3265. Типичные причины возврата кода ошибки могут включать невозможность поддержки пакета события resource_query, причины, связанные с семантикой запроса (например, недоступность требуемых ресурсов, сложность запроса) или внутренние причины (например, сложность запроса может перегрузить сервер 20 событий протокола SIP).

Предпочтительно, чтобы сервер 20 событий протокола SIP отправлял подписчику 12 уведомление (по RFC3265), как только изменяется список ресурсов, которые удовлетворяет ограничениям, сформулированным в исходном запросе при подписке. Эти изменения могут быть либо удалением одного или более ресурсов, либо добавлением одного или более ресурсов, либо комбинацией и того, и другого. Тело уведомления содержит исправленный список ресурсов, сформулированный с использованием соответствующего синтаксиса, например с использованием соответствующего формата на основе RDF или XML, для отправки списка ресурсов и изменения списка ресурсов. В соответствии с RFC3265 и черновиком документа IETF (работа в процессе) «Частичное уведомление об информации присутствия» М.Линнфорс, январь 2004, список ресурсов может передаваться либо полностью, либо частично, то есть уведомление содержит либо полный список ресурсов, которые удовлетворяют запрос подписки, либо оно содержит список обновления (только изменения) в подходящем формате.

Фиг.2 показывает шаги и сообщения, которые исполняются для получения подписки на событие resource_query.

В соответствии с RFC3265 подписчик 12 отправляет сообщение SUBSCRIBE протокола SIP (сообщение 1 на фиг.2) на сервер 20 событий протокола SIP (маршрутизируется как сообщения 2 и 3 на фиг.2 при помощи SIP-прокси 14 и 16 на сервер 20 событий протокола SIP). Заголовок сообщения SUBSCRIBE включает идентификатор события resource_query. Также в теле сообщения он включает семантику запроса, как обсуждалось выше при описании пакета события resource_query.

После приема сообщения подписки (сообщение 3 на фиг.2) сервер 20 событий протокола SIP извлекает тело сообщения и разбирает включенную семантическую информацию запроса. Для поддержки серверов 22 онтологии (для повторного использования и распространения семантических определений среди нескольких подписчиков), тело сообщения может содержать ссылки на такие онтологии. Способы косвенного предоставления контента, подобные описанному С.Олсоном, «Требования к косвенному контенту протокола SIP», черновик документа IETF, сен. 2002, используются для получения семантической информации из указанного сервера 22 (сервера онтологий) (показано как сообщения 4 и 5 на фиг.2). Полученная информация затем разбирается сервером 20 событий протокола SIP, как если бы была дана непосредственно в теле сообщения. Во время анализа семантики запроса, сервер 20 событий протокола SIP также контролирует наличие прав доступа к данным о ресурсах, которые были указаны в запросе при подписке. Хотя специфика конкретной инфраструктуры авторизации находится вне рамок изобретения, способы, подобные ХСАР, предоставляют средства для получения таких политик авторизации от ХСАР-серверов (обычно внешних). Это показано как сообщения 6 и 7 на фиг.2. Подобные получения политик авторизации могут происходить несколько раз за время разбора запроса.

Как изложено выше, сервер 20 событий протокола SIP должным образом подтверждает сообщение подписки. Если подписка может быть предоставлена, то сервер 20 событий протокола SIP отправляет в ответ "200 OK' (сообщение 8 на фиг.2), маршрутизируемое как сообщения 9 и 10 подписчику 12. Если подписка не может быть предоставлена, то сервер 20 событий протокола SIP отправляет в ответ соответствующий код ошибки, по RFC3265 (сообщение 8 на фиг.2), маршрутизируемое как сообщения 9 и 10 подписчику 12.

Если подписка была предоставлена, сервер 20 событий протокола SIP вводит в действие и исполняет соответствующую логику приложения, которая определяет список ресурсов, которые удовлетворяют ограничениям заявки на подписку. Логика приложения списка ресурсов действует на основании семантики, данной в исходном запросе, и использует соответствующие данные о ресурсах, полученные либо локально, либо извне во время этого определения. В практическом смысле логика приложения списка ресурсов ответственна за ответ на вопросы, поставленные подпиской resource_query, путем определения соответствующего списка ресурсов на всем протяжении времени жизни подписки resource_query. Подобная функциональность может быть реализована локально на сервере 20 событий протокола SIP, и называлась выше логикой 20D приложения, которая показана на фиг.3.

В соответствии с RFC3265 сервер 20 событий протокола SIP отправляет начальное сообщение NOTIFY протокола SIP подписчику 12 (сообщение 13 на фиг.2 маршрутизируется как сообщения 14 и 15 подписчику 12), представляющее собой начальное состояние подписки. С этими целями логика приложения 20D определяет начальное множество ресурсов, которые удовлетворяют запросу подписки. Обратим внимание, что во время этого определения может быть желательно определить соответствующие политики авторизации для подписчика 12 по отношении к рассматриваемым данным о ресурсах. Для этой цели соответствующие политики авторизации получают у менеджера 24 политики авторизации, что показано как сообщения 11 и 12 на фиг.2.

Если на протяжении времени жизни подписки упоминавшаяся выше логика 20D приложения обнаруживает изменение в списке ресурсов, который удовлетворяет запросу подписки, то она порождает соответствующее уведомление подписчику 12. Обратим внимание, что для того, чтобы это обнаружение случилось, может быть желательно определить соответствующие политики авторизации для подписчика 12 по отношению к рассматриваемым данным о ресурсах. Для этой цели соответствующие политики авторизации получают у менеджера 24 политики авторизации, что показано как сообщения 16 и 17 на фиг.2.

В соответствии с RFC3265 и черновиком документа IETF (работа в процессе) «Частичное уведомление об информации присутствия». М. Линнфорс, январь 2004, сервер 20 событий протокола SIP может порождать полные уведомления о состоянии или уведомления об изменении в состоянии для подписчика 12, отправляемые как сообщение 18 на фиг.2 и маршрутизируемые как сообщения 19 и 20 на фиг 2. Таким образом, подписчик 12 принимает обновленный список ресурсов, которые удовлетворяют исходному запросу подписки.

На основании информации списка ресурсов подписчик 12 может реализовать какой-либо сервис, например контекстно-зависимый сервис (ограничения запроса составляют контекст, в котором исполняется сервис). В этом отношении запрошенные идентификаторы URI ресурсов составляют идентификаторы URI в определенном контексте.

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

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

Другое преимущество данного изобретения заключается в контроле сложности на сервере 20 событий протокола SIP. Хотя запросы на списки ресурсов легко могут стать довольно сложными, определение, предоставлять ли конкретную подписку, является функцией сервера 20 событий протокола SIP. Таким образом, в случае если очередной диалог на подписку может перегрузить сервер 20 событий протокола SIP по причине своей сложности, то подписка может быть просто отвергнута (даже несмотря на то, что сервер 20 событий протокола SIP технически способен поддержать запрашиваемую подписку). Это предусматривает простую технику контроля масштабируемости сервера 20 событий протокола SIP по отношению к поддерживаемой сложности и числу поддерживаемых подписок resource_query.

Для поддержки этой функциональности сервер 20 событий протокола SIP улучшен по сравнению с традиционными серверами в смысле обеспечения дополнительного разбора запросов и "добычи" информации или аналитической функциональности. Следует отметить, что "добыча" информации/функции анализа применяются ко множеству существующих данных, так что не требуется собирать дополнительные данные из других поддерживаемых пакетов событий на сервере 20 событий протокола SIP. Если разбор запросов и/или "добыча" информации/функции анализа не поддерживаются сервером 20 событий протокола SIP, то сервер 20 событий протокола SIP может просто отвергнуть пакет события resource_query. Таким образом, данное изобретение предоставляет модульное, масштабируемое и расширяемое решение, которое упрощает разработку поддержки таких запросов в сетях серверов 20 событий протокола SIP.

На основании данного выше описания можно понять, что данное изобретение предоставляет систему и способ, в которых запросы используются для определения множества ресурсов, находящихся в определенном состоянии. Состояние, например, может относится к конкретной контекстной информации, например текущему местоположению, деятельности, определенным предпочтениям или эмоциональному состоянию. Вместе с семантическим описанием событий высокого уровня, таким как предоставляемое системой и способом согласно патентной заявке США, принадлежащей заявителю, Д.Троссен, Д.Павел, «Применение семантического связывания в шаблонах-пакетах событий протокола SIP», №10/465, 455, подана 06/19/2003, использование данного изобретения позволяет отвечать на такие вопросы, как:

«Какие персоны (ресурсы) находятся на встрече, которая проходит в определенном месте?»;

и

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

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

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

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

Claims

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

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

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

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

5. Способ по п.1, в котором принятие заявки на подписку включает обращение к удаленному источнику данных о ресурсах; и определение доступности соответствующих данных о ресурсах.

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

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

8. Способ по п.1, в котором заявка на подписку содержит пакет события resource-query (запрос_о_ресурсах).

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

10. Способ по п.9, в котором уведомление содержит полный список данных о ресурсах, которые доступны серверу событий для определения результата запроса.

11. Способ по п.9, в котором уведомление содержит частичный список данных о ресурсах, которые доступны серверу событий для определения результата запроса, и этот частичный список содержит данные о ресурсах, которые изменились.

12. Способ по п.1, в котором сервер событий содержит сервер событий протокола инициирования сессии (SIP).

13. Способ по п.12, в котором прием сообщения с заявкой на подписку на сервере событий происходит по меньшей мере через один SIP-прокси, расположенный между по меньшей мере сервером событий протокола SIP и блоком подписчика.

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

15. Способ по п.1, в котором анализ запроса включает формирование списка ресурсов на основе семантики запроса.

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

17. Система по п.16, в которой семантика запроса задается ссылкой на сервер онтологии.

18. Система по п.16, в которой семантика запроса задается ссылкой на по меньшей мере один сервер онтологии с использованием техники косвенного контента.

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

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

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

22. Система по п.16, в которой заявка на подписку содержит пакет события resource-query.

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

24. Система по п.23, в которой уведомление содержит полный список данных о ресурсах, которые доступны серверу событий для определения результата запроса.

25. Система по п.23, в которой уведомление содержит частичный список данных о ресурсах, которые доступны серверу событий для определения результата запроса, при этом частичный список содержит данные о ресурсах, которые изменились.

26. Система по п.16, в которой сервер событий содержит сервер событий протокола инициирования сессии (SIP).

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

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

29. Система по п.16, в которой анализ запроса включает формирование списка ресурсов на основе семантики запроса.

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

31. Сервер событий по п.30, в котором семантика запроса задается ссылкой на сервер онтологии.

32. Сервер событий по п.30, в котором семантика запроса задается ссылкой на по меньшей мере один сервер онтологии с использованием техники косвенного контента.

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

34. Сервер событий по п.30, в котором заявка на подписку содержит пакет события resource-query.

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

36. Сервер событий по п.35, в котором уведомление содержит полный список данных о ресурсах, которые доступны серверу событий для определения результата запроса.

37. Сервер событий по п.35, в котором уведомление содержит частичный список данных о ресурсах, которые доступны серверу событий для определения результата запроса, при этом частичный список содержит данные о ресурсах, которые изменились.

38. Сервер событий по п.30, в котором сервер событий содержит сервер событий протокола инициирования сессии (SIP).

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

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

41. Сервер событий по п.30, в котором анализ запроса включает формирование списка ресурсов на основе семантики запроса.

42. Блок подписчика, включающий интерфейс для подключения к сети передачи данных и управляющую логику для формирования пакета события resource-query, часть тела которого содержит семантику, задающую запрос, который оперирует с данными о ресурсах на сервере событий для формирования списка соответствующих ресурсов.

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

44. Блок подписчика по п.43, в котором указанное уведомление содержит полный список данных о ресурсах, которые доступны серверу событий для определения результата запроса.

45. Блок подписчика по п.43, в котором указанное уведомление содержит частичный список данных о ресурсах, которые доступны серверу событий для определения результата запроса, при этом частичный список содержит данные о ресурсах, которые изменились.

46. Блок подписчика по п.42, в котором сервер событий содержит сервер событий протокола SIP, при этом указанный блок подписчика связан с мобильным беспроводным телекоммуникационным устройством.

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

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

49. Машиночитаемый носитель по п.48, в котором семантика запроса задается ссылкой на сервер онтологии.

50. Машиночитаемый носитель по п.48, в котором семантика запроса задается ссылкой на по меньшей мере один сервер онтологии с использованием техники косвенного контента.

51. Машиночитаемый носитель по п.48, в котором указанный сервер событий связан с менеджером политики авторизации, который определяет политику авторизации по меньшей мере для некоторых из данных о ресурсах, необходимых для определения результата запроса.

52. Машиночитаемый носитель по п.48, в котором заявка на подписку содержит пакет события resource-query.

53. Машиночитаемый носитель по п.48, в котором указанный сервер событий включает логику для отправки уведомления подписчику в ответ на обнаружение изменения в соответствующих данных о ресурсах, которые доступны серверу событий для определения результата запроса.
54 Машиночитаемый носитель по п.53, в котором уведомление содержит полный список данных о ресурсах, которые доступны серверу событий для определения результата запроса.

55. Машиночитаемый носитель по п.53, в котором уведомление содержит частичный список данных о ресурсах, которые доступны серверу событий для определения результата запроса, при этом частичный список содержит данные о ресурсах, которые изменились.

56. Машиночитаемый носитель по п.48, в котором сервер событий содержит сервер событий протокола инициирования сессии (SIP).

57. Машиночитаемый носитель по п.48, в котором указанный подписчик связан с мобильным беспроводным телекоммуникационным устройством.

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

59. Машиночитаемый носитель по п.48, в котором анализ запроса включает формирование списка ресурсов на основе семантики запроса.

60. Сервер событий, включающий:
средства для подключения к сети передачи данных; и средства для анализа семантики запроса, реагирующие на прием от подписчика сообщения с заявкой на подписку для подписки на события resource-query, при этом указанное сообщение включает семантику запроса, а указанные средства предназначены для анализа семантики запроса, чтобы определить, принять или отвергнуть заявку на подписку, при этом заявка на подписку принимается в случае, если семантика запроса успешно проанализирована и распознана, а соответствующие данные о ресурсах доступны серверу событий, локально и/или удаленно, для определения результата запроса.

61. Сервер событий по п.60, в котором семантика запроса задается по меньшей мере частично ссылкой на сервер онтологии.