УСТРОЙСТВО И СПОСОБ ОБЕСПЕЧЕНИЯ СОВМЕСТНОГО ИСПОЛЬЗОВАНИЯ ДАННЫХ КОНФЕРЕНЦИИ

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

Настоящее изобретение имеет отношение в целом к беспроводным системам и способам коммуникаций и, более конкретно, касается беспроводных терминалов и беспроводных узлов сети, которые используют Протокол Инициирования Сессии (Session Initiation Protocol, SIP) для установления и проведения конференции со многими участниками.

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

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

Вначале следует отметить, что SIP включает механизм, обеспечивающий доступ к данным, называемый в целом косвенным предоставлением контента. А именно, IETF проект "draft-ietf-sip-content-indirect-mech-03", озаглавленный "A Mechanism for Content Indirection in Session Initiation Protocol (SIP) Messages" (S. Olson, June 2, 2003) ("Механизм косвенного предоставления контента в сообщениях Протокола Инициирования Сессии (SIP)") описывает механизм, предусматривающий косвенную передачу контента в SIP сообщениях. В целом назначение SIP состоит в том, чтобы создавать, изменять или заканчивать сессии с одним или большим количеством участников, и сообщения SIP, подобно HTTP, синтаксически состоят из начальной строки, одного или большего количества заголовков и необязательного тела сообщения. Однако, в отличие от HTTP, SIP не предназначен для общего использования.

Имеются различные причины, по которым может быть желательно косвенно определить контент тела сообщения SIP. Для приложений, ограниченных по полосе частот, типа сотовых беспроводных приложений, косвенность обеспечивает средства, позволяющие аннотировать (косвенный) контент метаданными, которые могут использоваться получателем, чтобы определить, нужно ли ему извлекать контент по линии связи с ограниченными ресурсами. Возможно также, что размер контента, который будет передан, мог бы потенциально переполнить промежуточные сигнальные прокси, таким образом излишне увеличивая время задержки в сети. Для чувствительных ко времени SIP-приложений это может быть недопустимым. Использование косвенного предоставления контента может сгладить эти дефекты, перемещая передачу контента из сети передачи SIP сигналов в потенциально отдельный канал передачи данных. Возможны также сценарии, при которых связанные с сессией данные (тело сообщения), которые должны быть переданы, непосредственно не находятся в конечной точке или у агента пользователя (User Agent, UA). В таких сценариях желательно иметь механизм, посредством которого SIP сообщение может давать косвенную ссылку на желаемый контент. Сторона-получатель может использовать эту косвенную ссылку, чтобы получить контент через не-SIP канал передачи, такой как HTTP (протокол передачи гипертекста), FTP (протокол передачи файлов) или LDAP (облегченный протокол доступа к каталогам). В проекте IETF заявлено, что цель косвенного предоставления контента - обеспечить альтернативный транспортный механизм для SIP MIME частей тела сообщения. За исключением механизма транспортировки, косвенные части тела сообщения эквивалентны непосредственно передаваемым частям тела сообщения и должны проходить ту же самую обработку.

Настоящий изобретатель и другие предварительно определили требования для управления конференцией и предложили основанную на компонентах масштабируемую структуру управления конференцией, основанную на SIP и на Простом Протоколе Доступа к Объектам (Simple Object Access Protocol, SOAP). В этом отношении может быть сделана ссылка на документ "A SIP-based Conference Control Framework" ("Основанная на SIP структура управления конференцией"), Petri Koskelainen, Henning Schuizrinne and Xiaotao Wu, NOSSDAV'02, May 12-14, 2002, Miami Beach, FL, USA.

Также представляет интерес интернет-проект, озаглавленный "А Framework for Conferencing with the Session Initiation Protocol" ("Структура для конференц-связи с Протоколом Инициирования Сессии"), J. Rosenberg, draft-ietf-sipping-conferencmg-framework-01, October 27, 2003.

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

В целом, SIP-конференция - это случай многосторонней беседы. Слабо связанная конференция - конференция без скоординированных отношений сигнализации среди участников. Слабо связанные конференции часто используют широкое вещание для распределения участия в конференции. Сильно связанная конференция - конференция, в которой единственный агент пользователя, так называемый фокус, поддерживает диалог с каждым участником. Фокус играет роль централизованного менеджера конференции и адресуется посредством URI (унифицированного идентификатора ресурса) конференции. Фокус - это SIP агент пользователя, к которому обращаются посредством URI конференции и который идентифицирует конференцию (то есть это уникальный экземпляр в беседе со множеством участников). Фокус поддерживает отношения обмена SIP сигналами с каждым участником конференции. Фокус ответственен за обеспечение, некоторым способом, того, чтобы каждый участник получал информацию, которая составляет конференцию. Фокус также осуществляет политику конференции. Фокус - это логическая роль. URI конференции - это URI, обычно SIP URI, который идентифицирует фокус конференции. Элемент программного обеспечения, который соединяет пользователя или автомат с конференцией, называется участником. Участник реализует, как минимум, агента пользователя SIP, но может также включать, например, клиента протокола управления политикой конференции. Служба уведомления конференции - логическая функция, обеспечиваемая фокусом. Фокус может действовать как уведомитель, принимая подписки в состав конференции и уведомляя подписчиков относительно изменений ее состояния. Состояние включает состояние, поддерживаемое самим фокусом, политику конференции, и медиаполитику. Сервер политики конференции - это логическая функция, которая может сохранять политику конференции и управлять ею. Политика конференции - полный набор правил управления работой конференции. Она разделяется на политику участия и медиаполитику. В отличие от фокуса, не существует экземпляра сервера политики конференции для каждой конференции. Но для каждой конференции имеется экземпляр политики участия и медиаполитики. Политика конференции - это полный набор правил для конкретной конференции, которая управляется сервером политики конференции. Она включает политику участия и медиаполитику. Для каждой конференции имеется экземпляр политики конференции. Политика участия - это набор правил, используемых сервером политики конференции в отношении участия в определенной конференции. Эти правила включают директивы, касающиеся ресурсов конференции, того, кто может и кто не может присоединиться к конференции, определения ролей, доступных на конференции, и обязанностей, связанных с этими ролями, и политики того, кому и какие роли разрешается запросить. Медиаполитика - набор правил, используемых сервером политики конференции в отношении состава информации конференции. Медиаполитика используется фокусом, чтобы определить характеристики смешивания для конференции. Медиаполитика включает правила, согласно которым участники получают информацию от других участников, и способы, которыми эта информация комбинируется для каждого участника. В случае звукового общения, эти правила могут включать относительные уровни, с которыми смешиваются звуки отдельных участников. В случае видео эти правила могут указывать, является ли видео мозаичным, показывает ли видео самого громкого оратора, и так далее. Протокол управления политикой конференции (Conference Policy Control Protocol, CPCP) - протокол, используемый клиентами, чтобы управлять политикой конференции. Микшер - это компонент, который получает набор потоков информации одинакового типа, смешивает их информацию способом, присущим данному типу информации, и перераспределяет результат каждому участнику. Это включает информацию, транспортируемую посредством протокола RTP (см. RFC 1889). В содержании документа drafl-ietf-sipping-conferencing-framework-01, из которого взяты эти различные определения, микшер рассматривается как обобщение концепции микшера, определяемой в RFC 1889, поскольку он применим для не-RTP информации, например, сессии мгновенного обмена сообщениями. Конференц-сервер (сервер конференц-связи) - это физический сервер, который содержит, как минимум, фокус. Он может также включать сервер политики конференции и микшеры.

Таким образом, с учетом этих определений, обратимся к фиг.1. Центральным компонентом SIP конференции является фокус 1. Фокус 1 обеспечивает обмен SIP сигналами с каждым участником 2 конференции (участник может быть назван агентом пользователя (UA), как показано на фиг.2). В результате получается топология звезды. Фокус 1 ответственен за обеспечение того, чтобы потоки информации, которые составляют конференцию, были доступны участникам 2 конференции. Фокус 1 исполняет эту функцию с помощью одного или большего количества микшеров 3, каждый из которых смешивает множество входных потоков информации, чтобы произвести один или большее количество выходных потоков информации. Фокус 1 использует медиаполитику, чтобы определить надлежащую конфигурацию микшеров 3. Фокус 1 имеет доступ к политике конференции (состоящей из политики участия и медиаполитики), экземпляр которой существует для каждой конференции. Фактически политику конференции можно представить как базу данных, описывающую способ, согласно которому должна функционировать конференция. Проведение этой политики возлагается на фокус 1. Фокус 1 не только нуждается в доступе к чтению из базы данных, ему требуется также знать, когда база данных изменилась. Такие изменения могут заканчиваться передачей сигнализации SIP (например, выбывание пользователя из конференции), и большинство изменений будут требовать, чтобы подписчикам, использующим сервис конференции, были бы посланы уведомления об этом. Конференция представлена идентификатором URI, которым идентифицируется фокус 1. Каждая конференция имеет уникальный фокус 1 и уникальный URI, идентифицирующий этот фокус 1. Запросы к URI конференции направляются к фокусу 1 этой конкретной конференции. Пользователи обычно присоединяются к конференции, посылая INVITE (ПРИГЛАСИТЬ) на URI конференции. Если позволяет политика конференции, INVITE принимается фокусом 1, и пользователь зачисляется в участники конференции. Пользователи могут покидать конференцию, посылая BYE (ПРОЩАНИЕ), как это делается в обычном телефонном разговоре. Аналогичным образом, фокус 1 может прервать диалог с участником 2, изменяя политику конференции так, чтобы указать, что участнику больше не разрешен доступ к конференции. Фокус 1 может также инициировать приглашение INVITE, изменяя политику конференции так, чтобы указать, что фокус 1 желает привлечь участника в конференцию.

На фиг.2 представлены в общем виде функции конференции. Участник 2 может взаимодействовать с фокусом 1, используя расширения типа REFER (ССЫЛКА), чтобы получить доступ к функциям управления расширенным запросом. Участник 2 может SUBSCRIBE (ПОДПИСАТЬСЯ) на URI конференции, и будет связан со службой уведомления конференции, обеспечиваемой фокусом 1. Посредством этого механизма он может узнавать об изменениях состава участников (фактически, состоянии диалогов), о медиаполитике и политике участия. Участник 2 может общаться с сервером 4 политики конференции (conference policy server, CPS), используя протокол 5 управления политикой конференции (СРСР). С помощью протокола 5 управления политикой конференции участник 2 может влиять на политику 6 конференции. Сервер 4 политики конференции не должен наличествовать на любой конкретной конференции, хотя всегда имеется политика 6 конференции. Интерфейсы между фокусом 1 и политикой 6 конференции, сервером 4 политики конференции и политикой 6 конференции, предназначены, прежде всего, для того, чтобы показать логические роли, вовлеченные в конференцию. Для полноты на фиг.2 также показан сервис 7 уведомлений конференции, подключенный к участнику 2 через интерфейс подписки.

Для всей рамочной структуры, описанной в документе draft-ietf-sipping-conferencing-framework-01, основным является то, что конференция уникально идентифицируется посредством URI, и этот URI идентифицирует фокус 1, который является ответственным за конференцию. URI конференции уникален, так что не может быть двух конференций, имеющих одинаковые URI конференции. URI конференции - это всегда URI SIP или SIPS (Secure SIP, безопасный протокол SIP). URI конференции не прозрачен для любых участников, которые могут использовать его, то есть не имеется никакого способа посмотреть на URI и узнать наверняка, идентифицирует ли он фокус 1, в отличие от пользователя или интерфейса на шлюзах телефонной сети общего пользования. Однако контекстная информация, окружающая URI (например, параметры заголовка SIP) может указывать на то, что URI представляет конференцию. Если на URI конференции послан SIP запрос, этот запрос направляется к фокусу 1, и только к фокусу 1. Элемент или система, которая создает URI конференции, отвечает за гарантированное соблюдение этого свойства. Идентификатор URI конференции может представлять долговременную конференцию или группу по интересам, или URI конференции может представлять кратковременную конференцию, например, по конкретному случаю.

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

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

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

Изобретение касается концепции манипуляции политикой конференции, при этом пользователь может создавать конференцию на сервере политики конференции, используя Протокол Управления Политикой Конференции (СРСР), и устанавливать различные параметры конференции, типа Списков Управления Доступом (Access Control Lists, ACL), "списков телефонов" пользователей и RTP потоков информации.

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

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

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

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

В одном аспекте это изобретение обеспечивает способ совместного использования данных участниками конференции в SIP конференции. Способ включает, в ответ на запрос агента пользователя (UA) участника конференции на создание элемента совместно используемых данных, информирование агента пользователя в SIP сообщении об адресе места хранения, связанного с сервером совместного использования данных (data sharing server, DSS) конференц-сервера, где агент пользователя может хранить совместно используемые данные для использования другими участниками конференции; сохранение данных по адресу места хранения и установление по меньшей мере одной политики, которая управляет доступом к совместно используемым данным и/или их распределением в отношении других участников конференции.

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

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

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

В предпочтительных вариантах осуществления этого изобретения данные посылаются на сервер совместного использования данных, используя не-SIP процедуру, а именно одну из следующих: HTTP; WebDav ((Web-based Distributed Authoring and Versioning, основанный на Web распределенный авторинг и контроль версий); RTP и TCP канал с инкапсуляцией Многоцелевых Расширений Почты Интернета (MIME).

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

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

Агент пользователя может являться сотовым телефоном или может быть его частью.

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

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

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

фиг.2 - блок-схема, показывающая участника (агента пользователя) и его связи с различными функциями конференции в соответствии с аналогами изобретения;

фиг.3 показывает конференц-сервер и его интерфейсы с агентом пользователя, в соответствии с реализацией данного изобретения; и

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

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

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

На фиг.3 показан конференц-сервер 10 и его интерфейсы с агентом 2 пользователя в соответствии с реализацией данного изобретения. Предполагается, что также имеются другие агенты 2 пользователя, показанные на фиг.3, являющиеся участниками конференции, и аналогично соединенные с конференц-сервером 10. Агент 2 пользователя подсоединен к фокусу 1 посредством SIP диалога и подсоединен к серверу 4 политики конференции (CPS) через протокол управления политикой конференции (СРСР), который модифицирован, чтобы работать в соответствии с данным изобретением, и соответственно обозначен как протокол 5' управления политикой конференции (СРСР 5'). Конференц-сервер 10 далее включает по меньшей мере один микшер 3, видеосервер 12 и, в соответствии с данным изобретением, сервер 14 совместного использования данных (DSS). Агент 2 пользователя подключен к микшеру 3, видеосерверу 12 и серверу 14 совместного использования данных через RTP аудиоинтерфейс ЗА, RTP видеоинтерфейс 12А и интерфейс совместного использования данных, который реализует протокол 14А совместного использования данных (DSP), соответственно.

В общем случае, сервер 14 совместного использования данных может быть совмещен с сервером 4 политики конференции или может быть реализован как отдельный сервер, который управляется сервером 4 политики конференции, как показано на фиг.3. Политика 6 конференции (показанная на фиг.2) может быть изменена через сервер 4 политики конференции и протокол 5' управления политикой конференции, чтобы определить, какой тип совместно используемых данных хранится сервером 14 совместного использования данных, какие участники могут читать/записывать/модифицировать совместно используемые данные и как они действуют на совместно используемые данные под управлением сервера 14 совместного использования данных. Совместно используемые данные могут быть представлены в форме файлов или в форме активных исполняемых приложений, и доступ к ним осуществляется через интерфейс совместного использования данных с использованием протокола 14А совместного использования данных, преимущественно посредством не-SIP механизма, например протокола управления передачей (Transmission Control Protocol, TCP). Один из не ограничивающих изобретение примеров исполняемого приложения - игра.

Протокол 14А совместного использования данных может быть реализован с использованием любого из следующих (не ограничивающих изобретение) механизмов транспортировки: HTTP (протокол передачи гипертекста); WebDav (Web-based Distributed Authoring and Versioning, основанный на Web распределенный авторинг и контроль версий), который является множеством расширений HTTP протокола, позволяющих пользователям совместно редактировать и администрировать файлы на удаленных Web-серверах; RTP (транспортный протокол реального времени), преимущественно с упреждающей коррекцией ошибок, которая приспособлена к групповым операциям; TCP канал с инкапсуляцией Многоцелевых Расширений Почты Интернета (Multipurpose Internet Mail Extensions, MIME); и их разновидности. Основная функция протокола 14А совместного использования данных состоит в передаче данных между клиентом (агентом 2 пользователя) и сервером 14 совместного использования данных. Также, предпочтительно, протокол 14А совместного использования данных передает некоторую минимальную информацию относительно совместно используемых данных, такую как имя, связанное с совместно используемыми данными (как в RTP заголовках или заголовках MIME, которые предшествуют фактическим данным).

Вообще, MIME был первоначально предназначен для расширения формата почты Интернета, чтобы позволить использовать в заголовках сообщений не-US-ASCII текстовые сообщения, нетекстовые сообщения, тела многоэлементных сообщений и не-US-ASCII информацию. MIME определен следующими RFC: RFC 2045: MIME Part One: Format of Internet Message Bodies (MIME Часть 1: Формат тел Интернет сообщений); RFC 2046: MIME Part Two: Media Types (MIME Часть 2: Типы информации); RFC 2047: MIME Part Three: Message Header Extensions for Non-ASCII Text (MIME Часть 3: Расширения заголовков сообщений для не-ASCII текста); RFC 2048; MIME Part Four: Registration Procedures (MIME Часть 4: Процедуры Регистрации); и RFC 2049: MIME Part Five: Conformance Criteria and Examples (MIME Часть 5: Критерии соответствия и примеры).

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

a) Любой участник может читать мои файлы на сервере 14 совместного использования данных;

b) Участник х (например, мой помощник) может модифицировать мои файлы на сервере 14 совместного использования данных;

c) Мой ближний круг активизируется по пятницам;

d) Я должен быть извещен, когда участник у читает файл image 1; и

e) Данные JPEG должны быть посланы всем участникам (но уменьшены до QCIF для клиентов, имеющих маленькие дисплеи). Формат QCIF (Quarter Common Intermediate Format) - это внутренний формат в четверть обычного; формат видеоконференции, который определяет частоту кадров 30 кадров в секунду, каждый кадр содержит 144 строки и 176 пикселов в строке, то есть четверть разрешения полного CIF (поддержка QCIF требуется стандартом видеоконференции ITU H.261).

В варианте осуществления изобретения, показанном на фиг.3, конференц-сервер 10 производит вывод данных участникам конференции, основываясь на своем состоянии. Например, если используется управление минимального уровня, то через микшер 3 проходит звук только от одного источника. В типичном случае любой агент 2 пользователя может разделять данные, сохраняя данные на сервере 14 совместного использования данных, и предоставлять (или запрещать) права доступа другим агентам пользователей, используя протокол 5' управления политикой конференции, как обсуждалось выше. Конференц-сервер 10 может посылать участникам конференции или помещать данные с сервера 14 совместного использования данных, возможно, управляя ими (например, видеоданные от видеосервера 12 преобразовывать в QCIF видеоданные).

Обратимся к фиг.4, где показана диаграмма сигнализации и потоков данных, которая иллюстрирует взаимодействие между клиентом агента 2 пользователя и сервером 14 совместного использования данных. На шаге А агент 2 пользователя запрашивает, чтобы сервер 14 совместного использования данных создал элемент совместно используемых данных. Этот запрос делается через протокол 5' управления политикой конференции и сервер 4 политики конференции. На шаге В сервер 14 совместного использования данных информирует агента 2 пользователя через сервер 4 политики конференции и протокол 5' управления политикой конференции об идентификаторе URI, который идентифицирует на сервере 14 совместного использования данных адрес места хранения совместно используемых данных, отведенного агенту 2 пользователя. На шаге С агент 2 пользователя посылает совместно используемые данные через протокол 14А совместного использования данных (например, с использованием HTTP) к URI, идентифицированному на шаге В. Как было отмечено ранее, в дополнение к содержанию данных предпочтительно посылается также информация для идентификации данных (например, имя данных, тип данных).

Хотя это может обеспечиваться при помощи косвенного предоставления контента SIP, в настоящей предпочтительной реализации данного изобретения полезная нагрузка SIP (SDP) используется, чтобы сообщать пользователю, участвующему в конференции, различную информацию, необходимую для обеспечения и поддержания функции совместного использования данных. Например, пользователь может быть информирован через полезную нагрузку SIP об адресе RTP звукового микшера 3, RTP видеосервера 12 и, также в соответствии с аспектом этого изобретения, об адресе сервера 14 совместного использования данных. В предпочтительной на настоящее время реализации изобретения, протокол 5' управления политикой конференции используется, чтобы определить операции и политику для данных на сервере 14 совместного использования данных.

Продолжим рассмотрение фиг.4. На шаге D протокол 14А совместного использования данных используется, чтобы указать агенту 2 пользователя на успешность операции сохранения данных, и на шаге Е агент 2 пользователя посылает по меньшей мере одну связанную с конференцией команду политики совместного использования данных, например, инструкции дать участнику конференции Бобу разрешение на чтение хранящегося файла совместно используемых данных и инструкции послать хранящийся файл совместно используемых данных (сжатый с использованием QCIF) участнику Алисе. На шаге F подтверждается прием (или исполнение) этих команд, и на шаге G посылается SIP сообщение уведомления (через SIP диалог), сообщающее клиенту, что участник Боб прочитал файл.

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

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

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

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