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

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

Иллюстрации

Показать все

Реферат

Область техники, к которой относится изобретение

Настоящее изобретение относится к способу соединения одного абонента с одним абонентом или одного абонента с множеством абонентов в сеансе полудуплексной радиосвязи в сотовой сети связи (PoC) для услуги вызова РоС Открытого сообщества производителей мобильной связи (OMA) с использованием РоС box в качестве системы хранения вместо общего клиента РоС и передачи мультимедийных данных РоС и администрирования ими после участия в сеансе.

Уровень техники

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

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

В настоящее время осуществляется стандартизация услуги РоС, в которой используется функция полудуплексной радиосвязи (РТТ) в сотовой сети связи. Одно уникальное свойство услуги РоС, которое отличает ее от существующей услуги мобильной связи, состоит в том, что пользователь может участвовать во множестве сеансов РоС и, таким образом, может использовать услугу вызова, перемещаясь между сеансами РоС в соответствии с его желанием. Этот свойство представляет требование, состояние, которое указано в ОМА, которое представляет собой форум для спецификации услуг мобильной связи.

Услуга РоС может сопровождать услугу установления группового сеанса, как в режиме конференции. В соответствии с этим спецификация ОМА определяет клиент управления XML-документами (XDMC) и сервер управления XML-документами (XDMC) для предоставления услуги списка группы.

На фиг.1 показана схема, иллюстрирующая архитектуру XDM. Как показано на фиг.1, оборудование 10 пользователя (UE), которое запрашивает услугу РоС, соединено с ядром 30 Протокола инициирования сеанса/ протокола Интернет (SIP/IP), который поддерживает SIP и IP для передачи мультимедийных данных через сеть 20 доступа. UE 10 представляет собой устройство, которое может выполнять функцию XDMC, может находиться в терминале РоС и включает в себя XDMC 12 и клиент 11 РоС, запрашивающий услугу РоС.

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

Ядро 30 SIP/IP соединено с совместно используемыми XDMS 40, ХDМS 50 РоС, сервером 60 РоС и сервером 70 присутствия для поддержания услуги РоС. Сервер 60 РоС имеет функцию управления РоС, предназначенную для поддержания и администрирования сеанса РоС, или функцию участия в РоС, предназначенную для участия в сеансе РоС для вызова РоС со связью одного абонента с одним абонентом или вызова РоС со связью одного абонента с двумя или больше абонентами.

XDMS может быть классифицирован на XDMS 50 РоС, который является специфичным для услуги РоС, и совместно используемый XDMS 40, который обычно используется в устройствах, обеспечивающих разные услуги. Кроме того, XDMS включает в себя сервер 90 - посредник агрегирования, который обеспечивает маршрутизацию группового списка, относящегося к запросу для каждого сервера XDM, в соответствии с определенным правилом при приеме списка группы, соответствующего запросу из XDMC 12. Протоколы и подробное описание XDM, такие как создание, модификация и удаление списка группы, хорошо известны специалистам в данной области техники, и поэтому их подробное описание здесь не приведено.

Обычно SIP или расширенный SIP, то есть протокол на уровне приложения, предназначенный для управления передачей мультимедийных данных по Интернет (IP-телефония), в основном используются для передачи сеанса информации об участии при групповых переговорах РоС. SIP представляет собой стандарт, определенный в запросе Целевой группы инженерной поддержки Интернет (IETF) в комментариях (RFC), запрос на комментарий 2543. SIP представляет собой протокол управления на уровне приложения, который используется для установки, модификации и прекращения сеанса или вызова при передаче мультимедийных данных, таких как видеоданные и данные голосовой связи. SIP существует над уровнем протокола датаграммы пользователя (UDP)/TCP (протокол управления передачей)/IP, который поддерживает как сеансы одноадресной передачи, так и многоадресной передачи данных для инициирования сеансов путем приглашения участников мультимедийной конференции с использованием протокола клиент-сервер, позволяющего выполнять обмен сообщениями запросами SIP и сообщениями ответами в виде запрос/ответ.

Сообщение запроса SIP предоставляет шесть функций RPC 2543: INVITE (приглашение к участию в сеансе); ACK (принятие запроса INVITE); BYE (завершение вызова); REGISTER (регистрация в базе данных сервера переадресации агентом пользователя); CANCEL (отмена запроса в очереди); OPTIONS (варианты выбора). Сообщение ответа SIP предоставляет коды состояния, включающие в себя: 1xx (информационный ответ); 2xx (успешный ответ); 3xx (ответ перенаправления); 4xx (ошибка клиента, неудачная передача запроса); 5xx (ошибка сервера); 6xx (глобальная ошибка).

На фиг.2 схематично иллюстрируется конфигурация обычного сервера РоС. Сервер РоС выполняет как функцию управления РоС (ниже обозначается CF), предназначенную для управления общим техническим обслуживанием и администрированием сеансом РоС, так и функцию участия РоС (ниже обозначается PF), предназначенную для управления техническим обслуживанием и администрированием между каждым сеансом РоС, как поясняется ниже со ссылкой на Таблицы 1 и 2.

Таблица 1
Функция управления (CF) РоС
Обеспечивает централизованное управление сеансом РоС. Обеспечивает централизованное распространение мультимедийных данных. Обеспечивает централизованную функцию разрешения конфликтов при передаче голосовых пакетов, включающую в себя идентификацию говорящего человека, обеспечивает обработку сеанса SIP, такую как организация прекращения и т.д. сеанса SIP. Обеспечивает исполнение стратегии участия в групповых сеансах. Предоставляет информацию об участниках. Собирает и предоставляет централизованную информацию о качестве мультимедийных данных. Предоставляет централизованные отчеты о начислении счетов. Может обеспечивать транскодирование между разными кодеками. Поддерживает переговоры в рамках протокола управления передачей пакетов голосовых данных.

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

Как показано в Таблице 2, приведенной ниже, сервер РоС, выполняющий PF (или сервер участия РоС), администрирует сеанс РоС между сервером управления РоС и каждым клиентом РоС. В частности, сервер участия РоС передает предоставляемое слово между клиентами РоС и сервером управления РоС, когда клиент РоС передает запрос на предоставление слова или когда сервер управления РоС передает запрос клиенту РоС. Кроме того, сервер участия РоС передает мультимедийные данные между сервером управления РоС и клиентом РоС, выполняет транскодирование между разными кодеками и фильтрует один из двух одновременных сеансов РоС по выбору пользователя РоС, когда происходит одновременный разговор в двух активных сеансах РоС.

Таблица 2
Функция участия (PF) РоС
Предоставляет обработку сеанса РоС. Может предоставлять функцию передачи мультимедийных данных между клиентом РоС и сервером управления РоС. Может предоставлять процедуры адаптации мультимедийных данных пользователя. Может предоставлять функцию передачи сообщения управления пакетами голосовых данных между клиентом РоС и сервером управления РоС. Предоставляет обработку сеанса SIP, такую как инициирование, завершение и т.д. сеанса SIP, от имени представленного клиента РоС. Обеспечивает выполнение стратегии входящих сеансов РоС (например, управление доступом, запрет входящих сеансов РоС, предоставление доступного статуса и т.д.). Может собирать и предоставлять информацию о качестве мультимедийных данных. Предоставляет отчеты о начислении счетов участников. Может обеспечивать фильтрование мультимедийных потоков данных в случае одновременных сеансов. Может обеспечивать транскодирование между разными кодеками. Может поддерживать переговоры на уровне протокола управления пакетом голосовых данных. Сохраняет текущий режим ответа и предпочтение по запрету входящих сеансов РоС клиента РоС.

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

Для использования услуги вызова РоС пользователь РоС регистрирует свой адрес РоС в ядре 30 SIP/IP. Ядро 30 SIP/IP сохраняет информацию о пользователе РоС по запросу пользователя РоС. В соответствии с этим, когда другой пользователь РоС пытается подать запрос на групповой вызов РоС, пользователь РоС заранее регистрирует свою информацию в ядре 30 SIP/IP, как описано выше, и запрашивает групповой вызов РоС в ядре 30 SIP/IP, используя информацию идентификации группы, передаваемую из GLMS.

Ядро 30 SIP/IP выполняет адресацию в домене, местоположение которого определяется с использованием информации запрашивающего РоС пользователя, и затем передает запрос на вызов РоС в собственный (домашний) сервер 60 РоС, в котором зарегистрирован запрашивающий РоС пользователь. Что касается запроса на вызов РоС, сервер РоС 60 подготавливается к установлению сеанса РоС, получает информацию о каждом пользователе из GLMS и затем передает сигнал запроса на вызов РоС в ядро 30 SIP/IP. Когда запрос на вызов РоС выполнен для пользователей в пределах интрадомена, сервер 60 РоС выполняет как CF, так и PF. Сервер 60 РоС, управляющий пользователем РоС, которого запрашивает вызов, запрашивает вызов РоС для пользователя РоС после определения местоположения ядра 30 SIP/IP с использованием информации пользователя РоС, переданной в сервер 60 РоС.

На фиг.3 показана схема, иллюстрирующая блоки CF и PF сервера РоС. Как показано на фиг.3, клиенты 111, 121, 131 и 141 РоС обеспечивают доступ к CF 100 через PF 110, 120, 130 и 140 соответственно, устанавливая, таким образом, сеанс РоС. Когда слово будет предоставлено запрашивающему устройству, которое квалифицируется как говорящее, из CF 100, речевые мультимедийные данные соответствующего клиента РоС передают в каждый клиент РоС. Пользователь РоС, которому предоставлено слово, не может соответствующим образом говорить до тех пор, пока не будет получена информация подтверждения пользователя об участниках, принимающих участие в групповом сеансе РоС.

Система РоС, требуемая OMA, имеет следующие свойства.

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

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

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

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

Для установления заранее установленного сеанса клиент РоС предоставляет поддерживаемые параметры мультимедийных данных при учреждении протокола описания сеанса в многоцелевых расширениях электронной почты Интернет (SDP MIME), используя метод SIP INVITE, и отвечает на мультимедийные параметры, предоставляемые из сервера РоС. Клиент РоС передает пользователю РоС информацию идентификации и предварительно установленный сеанс для ответа на сообщения, принятые из сервера РоС, вместе с идентификатором унифицированного ресурса (URI) конференции. При использовании заранее установленного сеанса возможно предварительно согласовать такие параметры, как IP-адрес, номер порта, используемый кодек и протокол управления пакетом голосовых данных (TBCP) для управления пакетом голосовых данных.

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

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

Вначале клиент А, инициирующий РоС, передает сообщение на запрос SIP INVITE, который включает в себя адрес SIP и адрес получателя, с которым клиент А РоС желает говорить, в соответствующее ядро А SIP/IP. Сообщение запроса INVITE включает в себя такую информацию, как адрес РоС клиента, запрашивающего вызов, запрашиваемые параметры мультимедийных данных (поскольку запрашиваемый сеанс основан на мультимедийных данных, имеющих разные значения атрибута мультимедийных данных, такие как способ кодирования звука и видео, скорость передачи данных и тип нагрузки) и значение атрибута, которое информирует услугу РоС и так далее, и его передают в PF через соответствующие серверы мультимедийных подсистем IP (IMS) (функцию управления сеансом вызова сервера-посредника (P-CSCF) и обслуживающую функцию управления сеансом вызова (S-CSCF)) в сети IMS через запрос маршрутизации в сервере протокола динамической конфигурации главного устройства (DHCP) или сервере системы доменных имен (DNS). Поскольку блок PF, с которым соединен пользователь РоС при запросе общего вызова, может быть воплощен как совершенно отличающийся от CF, который управляет пакетом речевых данных установленного сеанса, сообщение запроса INVITE, переданное ранее, передается в CF через ядро SIP/IP соответствующей сети.

Сеть управления сеансом РоС, включающая в себя CF, передает сообщение запроса INVITE в завершающую сеть и затем принимает сообщение ответа. Сообщение ответа SIP, с помощью которого завершающая сеть отвечает, может представлять собой одно из предварительного ответного сообщения 1xx, сообщения 2xx успешного ответа и сообщения ошибочного ответа 4xx, 5xx или 6xx.

Если установлен режим автоответчика AUTO-ANSWER, CF может принимать сигнал продвижения сеанса SIP 183, и, таким образом, выполняют соединение между сервером РоС и клиентом РоС в сети устройства, запрашивающего вызов. Сигнал приема вызова получателя передают в ответ в виде продвижения сеанса SIP 183 или в виде ответа OK SIP 200 и его передают в клиент А РоС через CF и PF, серверы РоС.

После приема ответа 200 OK или ответа 183 продвижения сеанса из сервера, завершающего РоС, CF определяет, что вызов РоС соединен, и затем передает сигнал "слово предоставлено", который предоставляет слово для передачи голосового пакета клиенту А РоС. Предоставление полномочий передачи голосового пакета в соответствии с ответом (200 OK или продвижения сеанса 183) может быть разделено на подтвержденное и неподтвержденное. При приеме неподтвержденного ответа CF запрашивает функцию буфера.

После приема ответного сигнала на сигнал запроса INVITE инициирующий клиент A РоС принимает сигнал предоставления слова, который передает сигналы разрешения передачи голосового пакета (то есть сигнал контроля посылки вызова), используя протокол управления транспортного протокола режима реального времени (RTCP). В это время сигнал Floor Granted (слово предоставлено) генерируется блоком CF, который обладает полномочиями арбитража в отношении голосовых пакетов, переданных в соответствующий клиент РоС через блок PF, который управляет соответствующим клиентом РоС. Сигнал Floor Granted может быть передан без прохождения через ядро SIP/IP, поскольку он использует маршрут канала-носителя вместо SIP. И, наконец, пользователь РоС, который подтверждает контроль посылки вызова, передает мультимедийный поток (например, голосовой), используя транспортный протокол реального времени (RTP).

ОСМ Release 2 учитывает РоС Box ящик РоС, который имеет функцию, в определенной степени аналогичную обычному ящику мультимедийного сообщения (MM), для дополнительного расширения услуги РоС. В соответствии с услугой ящик РоС от имени клиента пользователя РоС, который не может участвовать в сеансе со связью одного абонента с одним абонентом или в групповом сеансе РоС в режиме реального времени, конкретная физическая или логическая система (например, ящик РоС) участвует в соответствующем сеансе РоС, сохраняет мультимедийные данные, переданные во время сеанса, и затем передает/воспроизводит сохраненные мультимедийные данные по запросу пользователя РоС.

Сущность изобретения

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

Техническое решение

Цель настоящего изобретения состоит в создании способа установки услуги ящика РоС и передачи информации об идентификаторе услуги, используя стандартный SIP, протокол описания сеанса (SDP), XCAP и протокол доступа к рассылке (PAP), так чтобы обеспечить совместимость с обычной технологией РоС, при выполнении обработки вызова для соединения сеанса с использованием ящика РоС.

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

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

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

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

Краткое описание чертежей

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

На фиг.1 показана схема, иллюстрирующая обычную архитектуру XDM.

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

На фиг.3 показана схема, иллюстрирующая блоки CF и PF сервера РоС.

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

На фиг.5 иллюстрируется формат сообщения на основе метода PUBLISH для установки услуги ящика РоС по фиг.4.

На фиг.6 и 7 иллюстрируется дополнительная конфигурация схемы XML, предназначенной для использования метода PUBLISH по фиг.5.

На фиг.8 иллюстрируется формат сообщения ответа 200 OK для уведомления о присоединении к сеансу с использованием ящика РоС по фиг.4.

На фиг.9 подробно иллюстрируется поток сигналов для передачи сообщения, сохраненного в ящике РоС по фиг.4.

Подробное описание изобретения

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

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

На фиг.4 клиент B 1201, завершающий РоС, запрашивает установку услуги РоС из собственного блока PF B 1200 (то есть сервера РоС, выполняющего функцию участия в РоС) для предоставления услуги ящика РоС, если он не участвует в сеансе РоС. При установках услуги РоС используется метод PUBLISH, который представляет собой стандартный метод SIP (S100 A1 и A2).

Клиент B, завершающий РоС, может не только запрашивать услугу ящика РоС, но также и отражать этот запрос пользователя РоС путем обозначения режима ответа в PF и типа мультимедийных данных, которые должны быть сохранены в ящике РоС 1210. Подробно сообщения PUBLISH, передаваемые на этапе S100 А1, будут описаны ниже со ссылкой на фиг.5.

После установки услуги ящика РоС на этапе S100, при приеме сообщения сеанса INVITE от произвольного клиента А 1101 РоС (S101, S102 и S103), PF B 1200 передает 200 OK в CF X 1000 (сервер РоС, выполняющий функцию управления РоС) в соответствии с установленным режимом ответа. Объект, соединенный с сеансом РоС, включает в себя идентификатор, предназначенный для уведомления о том, что субъект ответа представляет собой ящик РоС 1210, вместо клиента B 1201 РоС (S104). Информация об идентификаторе может быть передана вначале в CF X 1000 и затем другим клиентам РоС, участвующим в конференции, с использованием различных форм сообщения. Способ передачи информации идентификатора услуги ящика РоС каждому клиенту РоС может изменяться в зависимости от типа сеанса или участия в сеансе и может использовать сигнал ответа SIP или сообщение протокола RTCP (S105 и S106, C1). Подробный формат сообщения SDP MIME для сообщения SIP, используемого для передачи информации идентификатора услуги ящика РоС, будет описан ниже со ссылкой на фиг.7.

После приема ответа 200 OK из PF B 1200 CF X 1000 передает сообщение Granted and Taken (предоставлено и принято) в протокол управления мультимедийным пакетом (MBCP), используя протокол MBCP для администрирования мультимедийным пакетом (S107, S108, S109 и S110), и, таким образом, передается мультимедийный поток (S111 и S112). В это время только определенные мультимедийные данные могут быть переданы в ящик РоС 1210 в соответствии с установкой клиента РоС. Если тип мультимедийных данных, установленный клиентом РоС, представляет собой аудио, то аудиоданные будут сохранены в ящике РоС 1210. Если будут установлены как аудиоданные, так и видеоданные, оба этих типа данных будут сохранены в ящике РоС 1210.

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

После подтверждения услуги ящик РоС блок CF X 1000 может не передавать MBCD соответствующему пользователю РоС (то есть в ящик РоС), поскольку через информацию идентификатора ящика РоС 1210 определяется, что ящик РоС 1210 не передает сообщение запроса мультимедийного пакета. В этом случае этапы S109 и S110 могут быть исключены до окончания сеанса.

На фиг.5 иллюстрируется формат сообщения на основе метода PUBLISH, предназначенного для установки услуги ящика РоС по фиг.4.

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

Часть PUBLISH XML выражает параметры, ассоциированные с услугой ящика РоС, с использованием имени элемента "установки pocbox". В элементе "установки pocbox" то, следует ли использовать услугу, может быть выражено в виде двоичной цифры. Если значение "poc-box active" имеет значение "true" (истинно), может быть указано использование ящика РоС.

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

Кроме того, настоящее изобретение может запрашивать услугу РоС с ящика разделением типа сеанса/группы (один абонент с одним абонентом, предварительно организованная, чат или специальная) или специального пользователя при установке услуги ящика РоС. Это становится возможным путем дополнительного определения содержания MIME, включенного в сообщение PUBLISH. Например, могут быть сохранены только мультимедийные данные определенной группы путем обозначения элемента "типа группы" или элемента "установки pocbox". Услугой ящика РоС можно управлять только по запросу сеанса от конкретного пользователя путем обозначения адреса или идентификатора (такого, как SIP URI или TEL URI) пользователя РоС. Этот способ не отклоняется от объема настоящего изобретения, и поэтому его подробное описание здесь не будет приведено.

На фиг.6 и 7 иллюстрируется дополнительная конфигурация схемы XML, предназначенной для использования метода PUBLISH по фиг.5. В дополнение к схеме XML определены элемент "poc-settings" (установки РоС) и подробные параметры, включенные в содержание сообщения PUBLISH. Запрос на услугу выражается определением параметра каждого имени элемента как "булевский".

На фиг.8 иллюстрируется формат сообщения ответа 200 OK, предназначенного для уведомления о соединении с сеансом с использованием ящика РоС по фиг.4, в котором, когда PF передает ответ в CF, используются сервер конференции, заголовок и часть тела ответа 200 OK для уведомления о том, что используется услуга ящика РоС. Часть заголовка ответа OK представляет собой часть параметра общего сигнала SIP, и поэтому ее описание здесь не приведено. В настоящем изобретении об услуге ящика РоС уведомляют, используя сигнал ответа SIP, но в нем может использоваться содержание SDP MIME, как на фиг.8, с целью обеспечения совместимости с обычной стандартной технологией SIP. В содержании МРIP параметр "poc_box" определен в строке "а=", которая обозначает параметр формата протокола управления голосовых данных (TBCP), и его двоичное значение используется для уведомления, используется ли услуга ящика РоС (услуга ящика РоС используется, когда poc_box=1, в то время как услуга ящика РоС не используется, когда poc_box=0).

На фиг.9 подробно иллюстрируется поток сигналов, используемых для передачи сообщения, сохраненного в ящике РоС, по фиг.4. Как показано на фиг.9, когда выполняют сохранение мультимедийных данных в зависимости от выхода из сеанса, ящик РоС уведомляет клиента РоС методикой прямой рассылки (РАР PUSH/HTTP POST) (А100 и A102), и затем клиент РоС запрашивает HTTP GET (А104), как показано в блоке A. В результате обеспечивается возможность создания схемы приема сообщения.

В качестве альтернативы, как представлено в блоке B, ящик РоС уведомляет клиент РоС методикой уведомления SIP, и затем клиент РоС запрашивает HTTP GET. В соответствии с этим обеспечивается возможность схемы приема сообщения.

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

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

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

Промышленная применимость

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

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

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

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

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

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

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

6. Способ по п.4, в котором этап запроса услуги сохранения мультимедийных данных использует сообщение PUBLISH протокола инициирования сеанса (SIP).

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

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

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

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

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

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