Способ и система для наложения ограничений на сессии

Изобретение относится к области передачи данных, в частности, к сессиям связи. Технический результат заключается в обеспечении возможности налагать ограничения на сессии таким образом, чтобы нежелательные пользователи не могли участвовать в этих сессиях или видеть содержимое сообщений этих сессий. Для этого при создании создания сессии с ограничением принимают указание ограничения на сессию, причем ограничение ограничивает тех, кого приглашенный может пригласить участвовать в сессии, либо ограничения ограничивают действия, которые приглашенный может выполнять над сообщениями сессии. Затем отправляют от приглашающего приглашенному приглашение участвовать в сессии с ограничением и принимают от приглашенного указание, что приглашенный будет участвовать в сессии и будет ли приглашенный следовать ограничению на сессию. При этом если приглашенный будет следовать ограничению на сессию, проводят сессию с приглашенным. 3 н. и 15 з.п. ф-лы, 9 ил.

 

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

Описываемое техническое решение в основном относится к сетям передачи данных и, в частности, к сессиям связи.

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

В приложениях иногда требуется устанавливать и управлять сессией между вычислительными устройствами. Сессия - это ряд взаимодействий между вычислительными устройствами, которые выполняются в течение периода времени. Например, приложения связи в реальном времени, такие как MICROSOFT MESSENGER или "голос по протоколу Интернет" ("VoIP"), устанавливают от лица пользователей сессии между взаимодействующими устройствами. Данные приложения могут использовать различные механизмы установления сессий, например "протокол создания сессии" ("SIP"). SIP является управляющим протоколом прикладного уровня, который может использоваться устройствами для взаимного обнаружения и для установления, изменения и завершения сессий между устройствами. SIP является проектом стандарта Интернет. Его спецификация "RFC 3261" доступна по адресу <http://www.ietf.org/rfc/rfc3261.txt>. Спецификация расширений SIP, относящихся к извещениям о событиях, "RFC 3265", доступна по адресу <http://www.ietf.org/rfc/rfc3265.txt>. Спецификация по определению местонахождения SIP-серверов, "RFC 3263", доступна по адресу <http://www.ietf.org/rfc/rfc3263.txt>. Спецификация по описаниям сессий, "RFC 2327", доступна по адресу <http://www.ietf.org/rfc/rfc2327.txt>. Все эти спецификации полностью включены в данный документ путем ссылки.

Приложения могут использовать SIP с другим протоколом для отправки или приема информации. Например, приложение может использовать SIP с транспортным протоколом реального времени (RTP) для передачи данных реального времени в течение сессии. Используя SIP с другими протоколами, приложения могут создавать и управлять сессией, а также обмениваться информацией в течение сессии. Протокол, используемый с SIP для обмена данными, может разбивать информацию на сообщения. Например, приложение VoIP может разбивать долгую речь на более короткие сообщения. Обмен сообщениями во время сессии называется "диалогом". SIP может использовать нижние уровни обмена данными для передачи сообщений диалога, такие как протокол управления передачей/протокол Интернет ("TCP/IP"), которые являются широко используемыми протоколами транспортного и сетевого уровней.

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

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

Сообщения SIP маршрутизируются на основе содержимого их полей заголовка. Чтобы быть корректным, SIP-запрос должен содержать по меньшей мере следующие пять полей заголовка: To ("к"), From ("от"), Contact ("контакт"), Max-Forwards ("макс. пересылок") и Via ("через"). Поле заголовка To указывает на логический идентификатор получателя запроса. Поле заголовка From указывает на логический идентификатор инициатора запроса. Поле заголовка Contact указывает на идентификатор местоположения, в котором отправитель хочет принимать последующие сообщения диалога. Поле заголовка Max-Forwards показывает количество пересылок, которые могут быть выполнены для запроса перед приходом в пункт назначения. Например, если сообщение от устройства A перед приходом на устройство назначения C передается через устройство B, о сообщении говорят, что для него выполнено две пересылки (например, на устройства В и С). Поле заголовка Via указывает путь, по которому запрос прошел до сих пор (например, последовательность сетевых адресов устройств, через которые был передан запрос) и указывает путь, по которому необходимо следовать при маршрутизации ответа. Заголовок может также содержать поля Record-Route ("запись-маршрут"), которые используются для указания, что будущие запросы и ответы должны маршрутизироваться через указанное устройство. Сетевые устройства могут вставлять указывающие на устройства поля заголовка Record-Route, когда пересылают сообщение SIP, чтобы попытаться принудительно установить для последующих сообщений маршрут через указанные устройства. Поле заголовка Record-Route может содержать идентификатор (например, сетевой адрес) устройства и параметры. Эти и другие поля заголовка описаны в указанных выше спецификациях SIP.

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

Сессия SIP может быть описана с использованием протокола описания сессии ("SDP"), RFC 2327. SDP может использоваться для описания мультимедийных сессий с целями объявления сессии, приглашения к сессии и других форм создания сессии. Данные SDP описывают имя и цель сессии, время активности сессии, вид представления данных сессии и информацию для приема представления данных (например, адреса и порты). SDP является расширяемым в той части, что для описания специализированной информации о сессии могут быть определены новые пары атрибут-значение.

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

РАСКРЫТИЕ ИЗОБРЕТЕНИЯ

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

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

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

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

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

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

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

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

Фиг.7 - это блок-схема алгоритма, которая иллюстрирует работу компонента действия приглашенного по приему для клиентского компонента приглашенного в одном из вариантов осуществления.

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

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

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

Предоставляется способ и система для создания сессии связи с ограничением. В одном из вариантов осуществления система связи позволяет пользователю наложить ограничение на сессию, которая проводится с другим пользователем. Если другой пользователь не согласен с ограничением или если система другого пользователя не поддерживает ограничение, тогда сессия не будет проводиться. Сессия создается "приглашающим", который задает, что с "приглашенным" должна проводиться сессия с ограничением. Система связи затем посылает приглашение, задающее ограничение для приглашенного. Если приглашенный соглашается следовать ограничению сессии, тогда приглашенный посылает ответ приглашающему. Когда приглашающий принимает указание, что приглашенный будет следовать ограничению на сессию, тогда приглашающий и приглашенный могут проводить сессию, такую как сессию мгновенного обмена сообщениями. Клиентский компонент системы связи, выполняемый на вычислительной системе приглашенного, может помочь осуществить ограничение на сессию. Например, если ограничение ограничивает тех, кого приглашенный может пригласить участвовать в сессии (например, могут участвовать только пользователи в определенном домене), то клиентский компонент может проверять каждое приглашение, посланное приглашенным для данной сессии, чтобы удостовериться, что оно не противоречит ограничению. В качестве другого примера, если ограничение ограничивает действия, которые приглашенный может выполнять над сообщением (например, запрещает копировать и вставлять сообщение), тогда клиентский компонент может проверять каждое действие приглашенного чтобы удостовериться, что оно не противоречит ограничению. Таким образом, приглашающий может налагать ограничения на сессии и быть до некоторой степени уверенным, что приглашенный будет следовать ограничениям до тех пор, пока клиентскому компоненту доверено осуществлять ограничения.

В одном из вариантов осуществления клиентский компонент системы связи может создать сессию с использованием протокола создания сессии. Когда приглашающий желает создать сессию, клиентский компонент, выполняющийся на вычислительной системе приглашающего, может выдать приглашающему подсказку наложить произвольные ограничения на сессию. Дополнительно предприятие, с которым связан приглашающий (например, приглашающий может являться служащим компании), может захотеть налагать определенные ограничения на все сессии своих пользователей. Клиентский компонент создает приглашение, которое соответствует протоколу создания сессий и протоколу описания сессий. Система связи может расширить SDP, чтобы он включал специализированные атрибуты, определяющие ограничения на сессию. Например, один из атрибутов может налагать ограничение на проведение закрытой сессии в том смысле, что никому больше не будет позволено участвовать в сессии, и ни одно из сообщений или их содержимое не должно стать доступным кому-либо еще. Клиентский компонент затем формирует SIP-приглашение с данными SDP, указывающими на ограничения приглашающего и/или предприятия. Клиентский компонент пересылает SIP-приглашение приглашенному. Клиентский компонент приглашенного при получении приглашения может определить, может ли он поддерживать запрошенные ограничения, заданные атрибутами данных SDP. Если он может поддерживать ограничения, тогда он включает эти атрибуты в состав данных SDP своего SIP-ответа на приглашение (например, сообщения SIP 200 "OK"). Если он не может поддерживать ограничение или не распознает атрибут, задающий ограничение, тогда он не включает эти атрибуты в состав своего ответа. Когда клиентский компонент поддерживает ограничение, он может выдать приглашенному подсказку, чтобы определить, хочет ли приглашенный следовать ограничениям на сессию. Если приглашенный не хочет следовать ограничению, тогда клиентский компонент не добавляет атрибут, задающий это ограничение, к данным SDP ответа. Когда клиентский компонент приглашенного принимает ответ, он проверяет атрибуты данных SDP, чтобы определить, будет ли приглашенный следовать требованиям ограничения. Если приглашенный не будет следовать ограничениям, тогда приглашающий может решить не начинать сессию, например, не посылая SIP-подтверждение.

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

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

Фиг.1 - это дисплейная страница, которая иллюстрирует в одном из вариантов осуществления пользовательский интерфейс, обеспечиваемый клиентским компонентом приглашающего, посредством которого приглашающий может пригласить приглашенного участвовать в сессии. Дисплейная страница 100 включает в себя поле 101 ввода имени приглашенного, флаги 102 ограничений и кнопку 103 подачи на рассмотрение. Приглашающий вводит имя приглашенного в поле ввода имени приглашенного и отмечает соответствующие флаги для требуемых ограничений. Приглашающий затем выбирает кнопку подачи на рассмотрение для отправки приглашенному приглашения.

Фиг.2 - это дисплейная страница, которая иллюстрирует пользовательский интерфейс в одном их вариантов осуществления, обеспечиваемый клиентским компонентом приглашенного, через который приглашенный может согласиться следовать ограничениям сессии. Дисплейная страница 200 включает в себя поле 201 имени приглашающего, ограничения на область 202 сессии, кнопку 203 принятия ограничений и кнопку 204 отказа от ограничений. Поле имени приглашающего содержит имя приглашающего. Ограничения на область сессии перечисляют различные ограничения на сессию, в которой приглашающий пригласил участвовать приглашенного. В данном примере ограничения на сессию заключаются в том, что не должны пересылаться сообщения, и не должны приглашаться участвовать в сессии пользователи в других доменах. Если приглашенный соглашается следовать ограничениям сессии, тогда приглашенный выбирает кнопку принятия ограничений. В противном случае приглашенный выбирает кнопку отказа от ограничений. Пользовательский интерфейс может позволить приглашенному принять или отказаться от ограничений путем выбора. После того, как приглашенный соглашается следовать ограничениям, клиентский компонент приглашенного посылает ответ, указывающий на ограничения, которые поддерживает клиентский компонент приглашенного и которым приглашенный согласен следовать.

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

Фиг.4 - это блок-схема, которая иллюстрирует компоненты системы связи в одном из вариантов осуществления. Система связи включает в себя клиентские компоненты приглашающего и приглашенного и может включать в себя серверные компоненты, когда для осуществления ограничений используется сервер. Клиентские вычислительные системы 410 и серверная вычислительная система 420 соединены через канал 430 связи, такой как Интернет. Клиентские вычислительные системы включают в себя компонент 411 пользовательского интерфейса, компонент 412 действия приглашенного по приему, компонент 413 приема приглашения и компонент 414 отправки приглашения. Компонент пользовательского интерфейса обеспечивает пользовательский интерфейс на Фиг.1-3. Компонент отправки приглашения вызывается, когда приглашающий хочет отправить приглашение. Компонент выдает пользователю приглашение на ввод ограничений на сессию и затем посылает приглашаемому приглашение, указывающее ограничения на сессию. Компонент приема приглашения вызывается, когда приглашенный принимает приглашение. Компонент выдает приглашенному подсказку установить, согласен ли приглашенный следовать ограничениям на сессию, которые поддерживает клиентский компонент. Если да, тогда компонент посылает приглашающему ответ, указывающий что приглашенный будет следовать ограничениям сессии. Компонент действия приглашенного по приему вызывается во всех случаях, когда приглашенный выполняет действие, относящееся к сессии. Действия могут включать в себя попытку пригласить другого пользователя участвовать в сессии, попытку переслать сообщение сессии или попытку скопировать и вставить содержимое сообщения. Компонент определяет, согласуется ли действие с ограничениями на сессию. Если нет, компонент блокирует действие. Серверная вычислительная система включает в себя компонент 421 регистрации, регистрационное хранилище 422, компонент 423 приема приглашения, компонент 424 приема подтверждения, компонент 425 приема сообщения и хранилище 426 сессии. Компонент регистрации и регистрационное хранилище могут быть обычными SIP-компонентами для регистрации пользователей, которые имеются в распоряжении для участия в сессиях. Компонент регистрации может выполнять регистрацию, как определено в SIP. Компонент приема приглашения вызывается, когда сервер принимает приглашение, которое было отправлено приглашенному, от приглашающего. Серверная вычислительная система может выполнять функции сервера-посредника SIP. Компонент приема приглашения может сохранять указание ограничения на сессию. Компонент приема подтверждения вызывается, когда сервер принимает ответ приглашающего приглашенному, которым приглашающий подтверждает, что сессия может быть начата. Серверная вычислительная система может также включать в себя компонент для обработки ответа, отправленного приглашенным приглашающему, и записи ограничений, которым приглашенный согласился следовать. Компонент приема сообщения вызывается, когда принимается сообщение сессии. Компонент приема сообщения устанавливает, согласуются ли сообщения от приглашенного ограничениям на сессию и, если нет, уничтожает сообщения. Хранилище сессии сохраняет ограничения на сессию, так что они могут быть осуществлены.

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

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

Фиг.5 - это блок-схема алгоритма, которая иллюстрирует работу компонента отправки приглашения для клиентского компонента приглашающего в одном из вариантов осуществления. Компонент вызывается, когда приглашающий хочет отправить приглашение. Компонент выдает приглашающему подсказку для ввода ограничений на сессию и может применять ограничения масштаба предприятия. Компонент затем посылает приглашение приглашенному. Когда компонент принимает указание, что приглашенный согласился следовать ограничениями на сессию, приглашающий посылает приглашенному подтверждение и указывает, что сессия может быть начата. На этапе 501 компоненту подается на вход имя приглашенного и ограничения, которые должны быть наложены на сессию. На этапе принятия решения 502, если существуют какие-либо ограничения масштаба предприятия, которые должны быть наложены на сессии, тогда компонент переходит к этапу 503, иначе компонент переходит к этапу 504. На этапе 503 компонент добавляет ограничения масштаба предприятия. На этапе 504 компонент создает данные SIP, которые идентифицируют приглашающего и приглашенного. На этапе 506 компонент создает данные SDP, которые включают в себя атрибуты для ограничений, которые должны быть наложены на сессию. На этапе 506 компонент посылает приглашенному приглашение. На этапе 507 компонент принимает ответ от приглашенного. На этапе 508 принятия решения, если ответ представляет собой ответ "OK", тогда компонент переходит к блоку 509, иначе компонент завершает работу, указывая, что создание сессии потерпело неудачу. На этапе 509 принятия решения, если ответ указывает, что приглашенный будет следовать ограничениям на сессию, тогда компонент переходит к этапу 510, иначе компонент завершает работу, указывая, что создание сессии потерпело неудачу. На этапе 510 компонент посылает приглашенному подтверждение и затем завершает работу, указывая, что создание сессии было успешным.

Фиг.6 - это блок-схема алгоритма, которая иллюстрирует работу компонента приема приглашения для клиентского компонента приглашенного в одном из вариантов осуществления. Компонент принимает приглашение и определяет, может ли он поддерживать ограничения на сессию. Компонент затем выдает приглашенному подсказку установить, будет ли приглашенный следовать ограничениям, которые поддерживает клиентский компонент. Компонент затем отправляет приглашающему ответ "OK" указывающий ограничения, которые он поддерживает и которым согласен следовать. На этапе 601 компонент определяет ограничения, которые поддерживает и которым будет следовать клиентский компонент. На этапе 602 компонент выдает приглашенному подсказку указать, будет ли приглашенный следовать ограничениям на сессию, которые поддерживает клиентский компонент. На этапе принятия решения 603, если приглашенный соглашается следовать ограничениям на сессию, тогда компонент переходит к этапу 604, иначе компонент переходит к этапу 606. На этапе 604 компонент добавляет принятые ограничения к данным SDP SIP-ответа, которые должны быть отправлены приглашающему. На этапе 605 компонент посылает приглашающему ответ "OK", указывающий ограничения, которым будет следовать приглашенный, и затем завершает работу, показывая успешный результат. На этапе 606 компонент посылает приглашающему ответ "not OK" (неудача) и затем завершает работу, показывая, что создание сессии потерпело неудачу.

Фиг.7 - это блок-схема алгоритма, которая иллюстрирует обработку компонента действия приглашенного по приему для клиентского компонента приглашенного в одном из вариантов осуществления. Компонент вызывается всякий раз, когда приглашенный выполняет действие, относящееся к сессии с ограничением. Компонент определяет, согласуется ли действие с ограничениями на сессию. Если нет, компонент блокирует действие. На этапе 701 компонент сравнивает действие с ограничениями на сессию. На этапе 702 принятия решения, если действие согласуется с ограничениями на сессию, тогда компонент продолжает выполнять действие, иначе компонент переходит к этапу 703. На этапе 703 компонент уведомляет приглашенного, что действие не согласуется с ограничениями на сессию, и может также уведомить приглашающего. Компонент затем завершает работу, указывая, что действие потерпело неудачу.

Фиг.8 - это блок-схема алгоритма, которая иллюстрирует работу компонента приема сообщения для серверного компонента в одном из вариантов осуществления. Компонент вызывается каждый раз, когда сервер принимает сообщение от приглашенного в рамках сессии. Компонент определяет, согласуется ли сообщение с ограничениями на сессию. На этапе 801 компонент сравнивает сообщение с ограничениями на сессию. На этапе 802 принятия решения, если сообщение согласуется с ограничениями на сессию, тогда компонент переходит к этапу 804, иначе компонент переходит к этапу 803. На этапе 803 компонент извещает приглашенного и/или приглашающего, что сообщение не согласуется с ограничениями на сессию и затем завершает работу, указывая, что сообщение не будет переслано. На этапе 804 компонент пересылает сообщение и затем завершает работу, указывая, что сообщение было переслано.

Фиг.9 - это блок-схема алгоритма, которая иллюстрирует работу компонента приема приглашения для серверного компонента в одном из вариантов осуществления. Компонент вызывается, когда сервер принимает от приглашающего приглашение. Компонент сохраняет ограничения на сессию, так что сервер может позднее осуществить ограничение на сессию. На этапе 901 компонент сохраняет сессионную информацию, включающую в себя идентификационные данные сессии, идентификационные данные приглашенного и приглашающего и ограничения на сессию. На этапе 902 компонент пересылает приглашение. На этапе 903 компонент ожидает получения ответа "OK" от приглашенного. На этапе 904 принятия решения, если был принят ответ "OK" и ответ указывает, что приглашенный будет следовать ограничениям на сессию, тогда компонент переходит к этапу 905, иначе компонент указывает, что создание сессии потерпело неудачу. На этапе 905 компонент готовится проверять сообщения сессии, чтобы осуществлять ограничения на сессию. Компонент затем завершает работу, показывая успех. Компонент может также ожидать приема подтверждения от приглашающего.

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

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

2. Способ по п.1, в котором сессия создается с использованием протокола создания сессии.

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

4. Способ по п.3, в котором прием индикации от приглашенного включает в себя прием сообщения "ОК" протокола создания сессии с атрибутом.

5. Способ по п.1, в котором сессия является сессией мгновенного обмена сообщениями.

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

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

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

9. Машиночитаемый носитель по п.8, в котором операция проведения включает в себя недопущение выполнения приглашенным любого действия, которое не согласуется с ограничением на сессию.

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

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

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

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

14. Машиночитаемый носитель по п.8, в котором сессия является сессией мгновенного обмена сообщениями.

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

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

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

18. Машиночитаемый носитель по п.17, в котором сервер является сервером-посредником.