Результат интеллектуальной деятельности: УПРАВЛЕНИЕ ГРУППАМИ В СЕТИ СВЯЗИ

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

Изобретение относится к области техники управления группами в сети связи.

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

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

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

Альянс открытой мобильной связи (www.openmobilealliance.org) продолжает работу над архитектурным решением для динамического управления группами. В качестве части архитектуры, идентифицируется логический узел для выполнения выбора унифицированного идентификатора ресурса (URI), на основании определенных условий или критериев. URI идентифицирует члена группы. Функция выбора предназначена для осуществления выбора членов группы на основании критериев (условий совпадения) и затем выдачи на запрашивающий узел совокупности членов группы, которые удовлетворяют критериям.

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

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

Функция основанного на критериях/условии выбора URI может использоваться многими службами, такими как услуги связи с переключением между приемом и передачей поверх сотовой связи (PoC) или мгновенного обмена сообщениями (IM). Любая основанная на сеансе групповая связь может использовать эту функцию для управления членами группы, такого как выбор членов группы при установлении сеанса, добавление или удаление индивидуумов в отношении активного сеанса, отправка сообщений выбранным индивидуумам и т.д., на основании результата выбора.

Функция основанного на критериях/условии выбора URI, определенная OMA, выдает список URI членов группы, которые удовлетворяют критериям/условиям, каждый раз, когда производится выбор. Эта информация во многих случаях недостаточна, чтобы конечный пользователь или авторизатор услуги принимал решение о наполнении группы. Например, не выдается информация типа «почему Мэри в списке, а Джон не в списке» или предположение о том, какие действия следует выполнять в таких обстоятельствах.

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

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

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

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

В качестве варианта выбора, запрос отправляется в сообщении ПОДПИСКА (SUBSCRIBE) протокола инициирования сеанса, а сообщение уведомления отправляется в сообщении УВЕДОМЛЕНИЕ (NOTIFY) протокола инициирования сеанса.

Сообщение уведомления факультативно включает в себя дополнительную информацию об удовлетворении критерия в элементе расширяемого языка разметки в теле сообщения УВЕДОМЛЕНИЕ протокола инициирования сеанса.

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

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

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

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

Процессор факультативно выполнен с возможностью формирования запросного сообщения ПОДПИСКА протокола инициирования сеанса, и сообщение уведомления факультативно отправляется в сообщении УВЕДОМЛЕНИЕ протокола инициирования сеанса.

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

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

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

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

фиг.2 схематично иллюстрирует на структурной схеме узел авторизатора услуг согласно варианту осуществления изобретения; и

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

ПОДРОБНОЕ ОПИСАНИЕ

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

. Общее количество элементов группы, удовлетворяющих критериям/условиям;

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

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

Для того чтобы снабжать запрашивающий узел обновлениями удовлетворения критериев, комплект событий SIP, который описан в RFC 4575, «Комплект событий SIP для состояния конференции» («A SIP Event Package for Conference State»), может быть расширен. Комплект событий SIP, например, может использоваться услугой уведомления конференции. Комплект событий SIP для услуги уведомления конференции преимущественно используется для информирования набора абонентов о состоянии участников конференции. Отметим, что даже в случаях, где применение изобретения не является непосредственно связанным со службой конференций, можно использовать этот комплект событий для информирования абонентов о состоянии другого объекта на основании набора определенных критериев, таких как географическое местоположение, состояние присутствия или другая имеющая отношение к пользователю или объекту информация. Поэтому сценарий конференции используется в качестве примера в последующем описании, но следует иметь в виду, что изобретение равным образом применяется к любому сценарию, в котором оценивается состояние объекта. Функция основанного на критериях/состоянии выбора может использоваться перед установлением конференции или для получения информации о том, какие пользователи удовлетворяют данным критериям.

В варианте осуществления изобретения, критерии, которые должны оцениваться, описаны с использованием расширения стратегии, описанной в RFC 4745, «Общая стратегия: формат документа для выражения предпочтений конфиденциальности» («Common Policy: A Document Format for Expressing Privacy Preferences»). Общая стратегия определяет набор правил, состоящих из набора условий, набора действий и, в одном из вариантов выбора, набора преобразований. Условия предписывают, к кому будет применяться действие и/или преобразование. Этот набор правил отправляется в теле начального запросного сообщения ПОДПИСКА SIP.

Функция выбора URI отправляет уведомления об обновлениях в зависимости от используемых критериев оценки с использованием расширения комплекта событий SIP для состояния конференции. Обновления отправляются в теле запросов УВЕДОМЛЕНИЕ SIP. Отображение и использование разных элементов и атрибутов XML описаны ниже:

• <conference-info>: Содержит различную информацию о запрошенной услуге оценки.

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

• state: Указывает, содержит ли уведомление информацию обо всех объектах, принимающих участие в конференции («full» («полное»)), содержит ли только информацию, которая изменилась после того, как было выдано последнее уведомление («partial»(«частичное»)), или прекратила ли подписка существовать, либо была ли удалена целевая группа объектов («удаленное»).

• <conference-description>: Дает информацию о группе услуг или список ресурсов, когда такая группа предопределена.

• <display-text>: Текст отображения группы услуг или списка ресурсов,

• <subject>, <free-text>, <keywords> могут быть заполнены информацией, как описано в RFC4575, когда она может быть извлечена из группы услуг или списка ресурсов.

• <conf-uris>: Содержит набор URI, которые идентифицируют оцениваемый сеанс.

• <service-uris>: Содержит набор URI, которые могут использоваться, чтобы контактировать с услугой оценки, то есть SIP URI SIP, куда может быть выдана эпизодическая услуга оценки.

• <maximum-user-count>: Определяет максимальное количество пользователей, которое услуга может обрабатывать за сеанс. В случае, если это количество превышено, услуга будет применять локальные стратегии для определения, к каким пользователям применяется услуга.

• <available-media>: Это не используется.

• <host-info>: Используется таким же образом, как в RFC4575

• <conference-state>: Описывает состояние сеанса оценки:

• <user-count>: Количество пользователей, которые принимаются во внимание для оценки, когда принят запрос подписки, независимо от того, удовлетворяет пользователь каким бы то ни было критериям или нет.

• <active>: Указывает активен или нет сеанс оценки.

• <users>/<user>: Описывает пользователя, который является частью целевой группы. Пользователь контролируется, чтобы определить, удовлетворяет ли пользователь какому-нибудь из критериев.

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

• state: Этот атрибут указывает, содержит ли элемент полную информацию о пользователе («full»), только информацию, которая изменилась после предыдущего уведомления («partial»), или что пользователь больше не принимается во внимание для оценки.

• <display-text>: Этот элемент содержит ориентированный на пользователя текст для отображения конечным пользователям. Он может извлекаться из группы услуг или из списка ресурсов.

• <associated-aors>: Этот элемент может содержать дополнительные URI, ассоциативно связанные с пользователем, то есть URI TEL или адреса электронной почты.

• <user>/<endpoint>: Этот элемент определяет одно из устройств, используемых пользователем. Нормально, элемент пользователя будет содержать только один элемент endpoint (конечная точка).

• entity: URI, ассоциированный с этой конечной точкой, который должен быть уникальным в контексте пользователя. В терминах SIP, он будет URI контакта.

• state: Этот атрибут указывает, содержит ли элемент полную информацию о конечной точке («full»), только информацию, которая изменилась после предыдущего уведомления («partial»), или эта конечная точка больше не принимается во внимание для оценки.

• <display-text>: Этот элемент содержит текст отображения для конечной точки.

• <status>: Как в RFC4575, но только 'connected' ('присоединен'), 'disconnected' ('отсоединен') и 'pending' ('ожидающий') будут использоваться, если пользователь удовлетворяет по меньшей мере одному из заданных критериев, или нет.

• Элементы <referred>, <joining-method>, <joining-info>, <disconnection-method>, <disconnection-info> и <media> не используются.

• <call-info> используется так же, как описано в RFC4575

• <sidebar-by-ref> и <sidebar-by-val> не используются.

Дополнительно, один новый элемент определен под элементом <endpoint>:

• <rule-info>: Содержит информацию о том, каким критериям удовлетворяет пользователь в момент времени, когда выдается уведомление.

В качестве примера, чтобы проиллюстрировать изобретение, фиг.1 является схемой сигнализации, иллюстрирующей вариант осуществления изобретения. Фиг.1 показывает Авторизатора 1 услуги, который является запрашивающим узлом, который запрашивает информацию о состоянии участников конференции. Авторизатор 2 динамической группы (показанный как Авторизатор Dyn-G на фиг.1) выполняет функцию оценки критериев и информирования Авторизатора 1 услуги о том, какие пользователи удовлетворяют запрошенным критериям, и осуществляет изменения в отношении того, какие пользователи удовлетворяют запрошенным критериям. Также представлен Авторизатор 3 присутствия, у которого Авторизатор 2 Dyn-G осуществляет подписку. Совместно используемый сервер 4 XDMS используется для выдачи списка ресурсов Авторизатору 2 Dyn-G, и узел 5 поискового посредника используется для выполнения поиска XDM. Узел 5 поискового посредника пересылает поисковый запрос XDM на отдельные серверы XDM в сети, которые могут содержать запрошенную информацию, и объединяет все запрошенные ответы. Авторизатор 2 Dyn-G затем может брать URI из списка ресурсов, полученного с совместно используемого сервера 4 XDM, и URI из результатов поиска XDM в качестве целевых объектов для критериев оценки. Следующая нумерация соответствует нумерации, показанной на фиг.1:

S1. Запрос ПОДПИСКА SIP отправляется из Авторизатора 1 услуги к Авторизатору 2 динамической группы. Это сообщение ПОДПИСКА должно осуществлять подписку на динамическую группу OMA. Группа содержит в себе список с записью для sip:alice@example.com и поисковый запрос XDM. Этот поиск XDM превращается в sip:bob@example.com. Примером сообщения ПОДПИСКА является следующее:

ПОДПИСКА sip:dynas@example.com SIP/2.0

Через: SIP/2.0/UDP enabler.example.com;branch=z9hG4bKnashds7

Событие: conference;dynamic

Кому: <sip:dynas@example.com>

От: <sip:service-enabler@example.com>;tag=12341234

Контакт: sip:service-enabler.example.com

ID вызова: knsd08alas9dy@example.com

CSeq: 1 SUBSCRIBE

Истекает: 3600

Длина контента:...

Тип контента: application/dynamic-group+xml

<group xmlns="urn:oma:xml:poc:list-service"

xmlns:drl=" urn:oma:xml:dynas:list-service"

xmlns:xsearch="urn:oma:xml:xdm:search"

xmlns:rl="urn:ietf:params:xml:ns:resource-lists"

S2. Авторизатор 2 динамической группы отправляет ответ SIP 200 OK Авторизатору 1 услуги. Примером сообщения SIP 200 OK является следующее:

SIP/2.0 200 OK

Через: SIP/2.0/UDP host.example.com; branch=z9hG4bKnashds7

;received=192.0.2.1

Кому: <sip:dynas@example.com>;tag=abcd1234

От: <sip:service-enabler@example.com>;tag=12341234

ID вызова: knsd08alas9dy@example.com

CSeq: 1 SUBSCRIBE

Контакт: sip:dynas.example.com

Истекает: 3600

Длина контента: 0

S3. Разрешить список ресурсов: Авторизатор 2 динамической группы получает список ресурсов с совместно используемого сервера 4 XDMS.

S4. Когда Авторизатор динамической группы анализирует элемент <list-service>/<list>, он находит запись <drl:xsearch>. Таковая указывает, что требуется поиск XDM. Авторизатор динамической группы выполняет поиск с использованием поискового посредника 5 по запросу, предусмотренному в записи <drl:xsearch>. Поиск разрешается в одиночный URI: sip: bob@example.com

S5. Запрос ПОДПИСКА SIP отправляется от Авторизатора 2 динамической группы на Авторизатор 3 присутствия для каждого целевого URI, предусмотренного записями в элементе <list-service>/<list>. В этом примере, sip:alice@example.com задан статически, а Sip:bob@example.com является результатом поискового запроса XDM. Примерный запрос ПОДПИСКА является следующим:

ПОДПИСКА sip:alice@example.com SIP/2.0

Через: SIP/2.0/UDP dynas.example.com;branch=z9hG4bKnashds67wer8

Кому: "Alice" <sip:alice@example.com>

От: <sip:service-enabler@example.com>; tag=12341234

Контакт: sip:dynas.example.com

ID вызова: knsd56yklas9dy@dynas.example.com

CSeq: 1 SUBSCRIBE

Событие: presence

Истекает: 3600

S6. Ответ SIP 200 OK отправляется от Авторизатора 3 присутствия на Авторизатор 2 динамической группы. Примером SIP 200 OK является следующее:

SIP/2.0 200 OK

Через: SIP/2.0/UDP dynas.example.com; branch=z9hG4bKnashds67wer8

;received=192.0.2.1

Кому: "Alice" <sip:alice@example.com>;tag=abcd1234

От: <sip:service-enabler@example.com>;tag=12341234

ID вызова: knsd56yklas9dy@dynas.example.com

CSeq: 1 SUBSCRIBE

Контакт: sip:presence.example.com

Истекает: 3600

Длина контента: 0

S7. Сообщение УВЕДОМЛЕНИЕ SIP отправляется от Авторизатора 3 присутствия на Авторизатор 2 динамической группы. Сообщение УВЕДОМЛЕНИЕ подтверждает, что состояние пользователя было подвергнуто подписке, и включает в себя начальный список членов группы, удовлетворяющих критериям. Примерный запрос УВЕДОМЛЕНИЕ SIP является следующим:

УВЕДОМЛЕНИЕ sip:dynas.example.com SIP/2.0

Через: SIP/2.0/UDP presence.example.com;branch=z9hG4bK8sdf2

Кому: "Ann" <sip:ann@example.com>;tag=abcd1234

От: <sip:service-enabler@example.com:;tag=12341234

ID вызова: knsd56yklas9dy@dynas.example.com

CSeq: 1 NOTIFY

Максимальное количество пересылок: 70

Событие: presence

Состояние подписки: pending; expires=3599

Контакт: sip:presence.example.com

Тип контента: application/pidf+xml

Длина контента:...

[Документ PIDF]

S8. Ответ SIP 200 OK отправляется от Авторизатора 2 динамической группы на Авторизатор 3 присутствия. Примерным ответом SIP 200 OK, в этом примере, является следующий:

SIP/2.0 200 OK

Через: SIP/2.0/UDP presence.example.com;branch=z9hG4bK8sdf2

;received=192.0.2.2

Кому: <sip:ann@example.com>; tag=abcd1234

От: <sip:service-enabler@example.com>;tag=12341234

ID вызова: knsd56yklas9dy@dynas.example.com

CSeq: 1 NOTIFY

S9. Запрос УВЕДОМЛЕНИЕ SIP отправляется из Авторизатора 2 динамической группы на Авторизатора 1 услуги. Примерный запрос уведомления SIP является следующим:

УВЕДОМЛЕНИЕ sip:bobpc.example.com SIP/2.0

Через: SIP/2.0/UDP dynas.example.com;branch=z9hG4bK8sdf2

Кому: <sip:dynas@example.com>;tag=abcd1234

От: <sip:service-enabler@example.com>;tag=12341234

ID вызова: knsd08alas9dy@example.com

CSeq: 1 NOTIFY

Максимальное количество пересылок: 70

Событие: conference; dynamic

Состояние подписки: active; expires=3599

Контакт: sip:dynas.example.com

Тип контента: application/conference-info+xml

Длина контента:...

10. Ответ SIP 200 OK отправляется от Автризатора 1 услуги на Авторизатор 2 динамической группы. Примерным ответом SIP 200 OK является следующий:

SIP/2.0 200 OK

Через: SIP/2.0/UDP presence.example.com;branch=z9hG4bK8sdf2

Кому: <sip:dynas@example.com>;tag=abcd 1234

От: <sip:service-enabler@example.com>;tag=12341234

ID вызова: knsd08alas9dy@example.com

CSeq: 1 NOTIFY

S11. Состояние присутствия целевого члена группы изменяется (в этом случае, целевым членом группы является сущность <sip:ann@example.com>).

S12. Изменение состояния инициирует отправку запроса УВЕДОМЛЕНИЕ SIP от Авторизатора 3 присутствия на Авторизатор 2 динамической группы. Примерный запрос УВЕДОМЛЕНИЕ SIP является следующим:

NOTIFY sip:user@host.example.com SIP/2.0

Через: SIP/2.0/UDP presence.example.com;branch=z9hG4bK8uer7834

Кому: <sip:ann@example.com>;tag=abcd1234

От: <sip:service-enabler@example.com>;tag=12341234

ID вызова: knsd56yklas9dy@dynas.example.com

CSeq: 2 NOTIFY

Максимальное количество пересылок: 70

Событие: presence

Состояние подписки: active; expires=3599

Контакт: sip:pa.example.com

Тип контента: application/pidf+xml

Длина контента:...

[Документ PIDF]

S13. Ответ SIP 200 OK отправляется от Авторизатора 2 динамической группы на Авторизатор 3 присутствия. Примерным ответом SIP 200 OK является следующий:

SIP/2.0 200 OK

Через: SIP/2.0/UDP presence.example.com;branch=z9hG4bK8uer7834

;received=192.0.2.2

Кому: <sip:ann@example.com>;tag=abcd1234

От: <sip:service-enabler@example.com>;tag=12341234

ID вызова: knsd56yklas9dy@dynas.example.com

CSeq: 2 NOTIFY

S14. Запрос УВЕДОМЛЕНИЕ SIP отправляется от Авторизатора 3 динамической группы на Авторизатор 1 услуги, чтобы уведомить Авторизатора услуги об изменении состояния целевого члена группы. Примерный запрос УВЕДОМЛЕНИЕ SIP является следующим:

УВЕДОМЛЕНИЕ sip:bobpc.example.com SIP/2.0

Через: SIP/2.0/UDP dynas.example.com;branch=z9hG4bK8sdf2

Кому: <sip:dynas@example.com>;tag=abcd1234

От: <sip:service-enabler@example.com>;tag=12341234

ID вызова: knsd08alas9dy@example.com

CSeq: 2 NOTIFY

Максимальное количество пересылок: 70

Событие: conference;dynamic

Состояние подписки: active; expires=3599

Контакт: sip:dynas.example.com

Тип контента: application/conference-info+xml

Длина контента:...

S15. Ответ SIP 200 OK отправляется от Авторизатора 1 услуги на Авторизатор 2 динамической группы, как изложено ниже:

SIP/2.0 200 OK

Через: SIP/2.0/UDP presence.example.com; branch=z9hG4bK8sdf2

Кому: <sip:dynas@example.com>;tag=abcd1234

От: <sip:service-enabler@example.com>;tag=12341234

ID вызова: knsd08alas9dy@example.com

CSeq: 2 NOTIFY

Далее, со ссылкой на фиг.2, узел 1 Авторизатора услуги снабжен процессором 6 для формирования сообщения ПОДПИСКА SIP, описанного на этапе S1, передатчиком 7 для отправки сообщения ПОДПИСКА SIP на Авторизатор 2 динамической группы и приемником 8 для приема сообщения УВЕДОМЛЕНИЕ SIP, описанного на любом из S9 или S14, приведенных выше.

Далее, со ссылкой на фиг.3, Авторизатор 2 динамической группы снабжен приемником 9 для приема сообщения ПОДПИСКА SIP, описанного на этапе S1, процессором 10 для определения, какие члены группы удовлетворяют критерию, и передатчиком 11 для отправки Авторизатору 1 услуги сообщения УВЕДОМЛЕНИЕ SIP, как описано на этапах S9 и S14.

Изобретение делает принятие решения более гибким для запросчика функции основанного на условии выбора URI. Если запросчик является конечным пользователем (человеком), получающаяся в результате информация является более обогащенной и более пригодной для гибкого принятия решения. Если запросчик является авторизатором услуги (автоматом), другие модели принятия решения могут использоваться в зависимости от характера услуги в сочетании с дополнительным элементом <rule-info>. Изобретение делает обработку у запросчика более эффективной, так как механизм частичного уведомления информирует запросчика, какой аспект состояния целевого члена группы изменился. Обогащенная информация, поставляемая в уведомлениях, может использоваться для иных целей, нежели управление сеансом. Одним из примеров могло бы быть формирование статистических отчетов.

Расширение группы списка OMA

Далее представлено примерное расширение для схемы совместно используемой группы OMA, чтобы снабжать расширенный список ресурсов динамическими записями, такими как поиск XDM и поиск присутствия SIMPLE.

<?xml version="1.0" encoding="UTF-8"?>

<xsd:schema targetNamespace="urn:oma:xml:dynas:list-service"

elementFormDefault="qualified"

xmlns:tns="urn:oma:xml:dynas:list-service"

xmlns:xsd="http://www.w3.org/2001/XMLSchema"

xmlns:ls="urn:oma:xml:poc:list-service"

xmlns:rl="urn:ietf:params:xml:ns:resource-lists" xmlns:pref="urn:oma:xml:xdm:search">

Функциональные возможности XDM определены в технических условиях OMA XDM Core v2.0. Та схема использует тип xsearch-type xml, определенный в технических условиях OMA XDM Core v2.0. Два атрибута «target» и «domain» имеют тот же самый смысл, что и такие же параметры uri запроса, определенные в технических условиях MA XDM Core v2.0.

Функциональные возможности поиска PAG сейчас изучаются в OMA. Мы предпочли определить элемент способом, очень похожим на поиск XDM.

Расширение общей стратегии

Далее описано примерное расширение, выполненное в отношении схемы общей стратегии, чтобы предоставить основанные на дополнительном комплекте событий SIP динамические условия для присутствия и для основанной на местоположении информации о geo-priv. Элемент <dynamic-condition> определяет набор критериев и может содержать в себе:

• <xpath-condition>: Описывает условие, основанное на выражении XPath, которое будет применяться к телу запроса УВЕДОМЛЕНИЕ, принятого для подписки, выпущенной для данного комплекта событий. Условие удовлетворено, если выражение XPath не возвращает пустую последовательность.

• <location-condition>: Описывает географическое очертание. Условие удовлетворено, когда географическое очертание, полученное из узла определения местоположения, перекрывается с предусмотренным этим условием.

Тип xpath-condition задает атрибут «event-package»

(«комплект событий»), который предписывает комплект событий

для использования в качестве критериев. Содержимое элемента

ограничено выражением XPATH, как определено в разделе 5 в

RFC 4661.

Расширение комплекта конференции:

Ниже представлено примерное расширение для комплекта конференции. Расширение предусматривает новый элемент <rule-info>, который содержит информацию о том, какое динамическое правило было подобрано для каждого отдельного пользователя.

Были использованы следующие аббревиатуры

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