Способ и устройство для услуги "нажми и говори"
Иллюстрации
Показать всеИзобретение относится к беспроводной связи, и в частности к услуге "нажми и говори" (РТТ), услугой "нажми и говори" может быть услуга сотовой связи "нажми и говори" (РоС). Техническим результатом является обеспечение услуги "нажми и говори", в котором для терминала требуется минимальный уровень, чтобы распределять контент среды для другого терминала, участвующего в сеансе связи "нажми и говори". Указанный технический результат достигается тем, что единственное сообщение с запросом минимального уровня посылается от клиента (А) РоС в сервер (S) РоС и относится по меньшей мере к двум различным типам контента среды. Сообщение с запросом минимального уровня указывает, по меньшей мере для одного из типов среды, как и/или степень, до которой разрешение или отклонение запроса, относящегося к этому типу среды, воздействует и/или зависит от запроса, относящегося по меньшей мере к одному другому типу среды. Например, сообщение с запросом минимального уровня может указывать, по меньшей мере для одного из типов среды, что если запрос, относящийся к этому типу среды, отклонен, тогда запрос, относящийся к какому-либо другому типу среды, также должен быть отклонен, то есть что требуется этот тип среды. Также могут использоваться и обрабатываться совместно множество сообщений с запросами минимального уровня. 9 н. и 18 з.п. ф-лы, 4 ил.
Реферат
Область техники, к которой относится изобретение
Изобретение относится к способу и устройству, предназначенным для использования в услуге "нажми и говори" (PIT), например в так называемой услуге сотовой связи "нажми и говори".
Уровень техники
Услуги типа портативной дуплексной радиосвязи долго были популярными среди тех пользователей, которые желали быстро осуществлять связь друг с другом посредством коротких сообщений. Традиционно такие услуги обеспечивались двусторонними портативными радиостанциями, которые используют выделенную часть спектра радиочастот, но которые только дают возможность пользователям связываться с небольшой группой предварительно выбранных пользователей, использующих аналогичные терминалы и находящихся в пределах досягаемости относительно короткого рабочего диапазона этих радиостанций. В последнее время в Соединенных Штатах Америки были введены услуги, которые совмещали передачу прямых и обратных пакетов на существующей телефонной инфраструктуре сотовой связи. Однако эти услуги были частными по своей природе и не обеспечивали пользователям возможность осуществлять связь между сетями различных операторов.
В попытке расширить использование услуг типа портативной дуплексной радиосвязи с целью стандартизации соответствующих протоколов, которые предоставят межсетевое удобство и простоту использования для услуг портативной дуплексной радиосвязи, предлагаемых через сотовые сети связи, была основана промышленная группа, известная как открытое сообщество производителей мобильной связи (ОМА) (www.openinobilealliance.org). Услуга, установленная по различным стандартам, известна как "нажми и говори" через сотовую связь (РоС). РоС предлагает, чтобы ассоциированные речевые данные транспортировались через сеть доступа с пакетной коммутацией. В случае GSM (глобальная система мобильной связи) и UMTS (универсальная система мобильной электросвязи), это будет система пакетной радиосвязи общего пользования (GPRS) или сеть доступа 3G. В других сетевых архитектурах аналогичные сети доступа с пакетной коммутацией могут использоваться для передачи данных разговора. Услуги "нажми и говори" можно также предлагать через сети доступа с коммутацией каналов, хотя это не является предпочтительным вариантом выбора.
Система сотовой связи (услуги "нажми и говори") (РоС) обычно реализуется в сетях GSM/GPRS/3G и тех, которые используют мультимедийную IP-подсистему (подсистема протокола межсетевого взаимодействия, IMS), стандартизированную Проектом партнерства 3-го поколения с целью облегчения введения усовершенствованных услуг передачи данных в сотовых сетях связи, в частности услуг передачи мультимедийных данных в реальном масштабе времени. IMS полагается на протокол инициирования сеанса связи (SIP), который был определен целевой группой инженерной поддержки Internet (IETF) для установления и управления сеансами связи мультимедиа на основе IP. Сервер РоС размещен в пределах IMS или подключен к ней и реализует функциональные возможности для установления и управления сеансами связи РоС.
Существующие системы сотовой связи (услуги "нажми и говори") и проведения телефонных конференций обычно используют механизм управления, чтобы предоставлять одному из пользователей право на разговор, в то время как для других пользователей, находящихся на связи, в таком праве отказывают и они находятся в режиме прослушивания. Такой механизм управления обычно упоминается как управление разрешением на передачу, арбитраж говорящей стороны, управление пакетными сигналами разговора и т.д. Например, сообщество производителей мобильной связи в настоящее время продолжает работать над техническими требованиями системы сотовой связи (услуги "нажми и говори") (РоС), которая включает в себя протокол управления пакетными сигналами разговора (ТВСР).
Чтобы запросить право на разговор от имени пользователя, терминал (клиент РоС) обычно посылает сообщение с запросом контроллеру (сервер РоС). Контроллер обычно отвечает на запрос либо допуском, либо отказом. Контроллер обычно ограничивает время, в течение которого пользователю разрешается говорить, обычно запуская таймер разрешенного разговора, когда он допускает запрос, и использует некоторое устройство для прерывания пользователя, обычно посылая сообщение с отменой полномочий в терминал пользователя или просто не отправляя мультимедийных данных пользователя. Пользователь, который прерывается контроллером, обычно штрафуется контроллером некоторым способом, например посредством отказа пользователю в праве на разговор в течение некоторого промежутка времени.
Следующая версия ОМА РоС (называемая в данном документе "РоС 2", тогда как предыдущая версия называется "РоС 1") развивается в ОМА. Часть запланированных функциональных возможностей должна включать в себя новые типы мультимедийных данных, такие как изображения, видео и т.д., которые могут быть совместно использованы в пределах сеанса связи РоС. Каждые мультимедийные данные должны иметь свое собственное управление разрешением на передачу. Нижеследующий фрагмент представляет собой извлечение из документа технических требований ОМА РоС 2 [OMA-RD-РоС-V2_0-20050902-D Push to Talk Over Cellular 2 Requirements, Draft Version 2.0 - 02. September 2005] (Технические требования услуги сотовой связи "нажми и говори" 2, проектная версия 2.0 - 02 сентября 2005 года): "Если сеанс связи включает в себя потоки видеоданных (и пакетный сигнал разговора), инфраструктура РоС ДОЛЖНА поддерживать возможность конфигурировать предпочтительный режим потокового видео у клиента РоС. Эта конфигурация может быть выполнена также: (а) благодаря ограничениям клиента РоС (например, клиента РоС 1), сконфигурированным поставщиком услуг; или (b) сконфигурированным пользователем". Также из документа технических требований ОМА РоС 2: "Режимы отправки потоков видеоданных вместе с речевыми данными представляют собой: (i) режим единственного источника и речевые данные РоС, и видеоданные РоС исходят от одного и того же участника в сеансе связи РоС в масштабе времени, близком к реальному времени; и (ii) режим множества источников: речевые данные РоС отправляются от одного участника, а видеоданные РоС отправляются от другого участника в одном и том же сеансе связи РоС". Также из документа технических требований ОМА РоС 2: "Если управление пакетными сигналами мультимедийных данных является применимым для этого типа мультимедийных данных, элементы сети РоС ДОЛЖНЫ поддерживать возможность независимого управления пакетными сигналами мультимедийных данных для любых мультимедийных данных в сеансе связи РоС. Управление пакетными сигналами мультимедийных данных ДОЛЖНО БЫТЬ применимым ко всем типам аналоговых мультимедийных данных и ДОЛЖНО БЫТЬ применимым к дискретным типам мультимедийных данных, включенным в сеанс связи РоС. Отметим: дискретные типы мультимедийных данных должны использовать управление пакетными сигналами мультимедийных данных, только если это необходимо для прикладной программы, использующей устройство разблокирования РоС". Также из документа технических требований ОМА РоС 2: "Если управление пакетными сигналами мультимедийных данных применимо для этого типа мультимедийных данных, элементы сети РоС должны поддерживать возможность единого управления пакетными сигналами мультимедийных данных для многочисленных мультимедийных данных в сеансе связи РоС".
РоС 1 имеет только монолитное управление разрешением на передачу только для одного типа мультимедийных данных: для пакетного сигнала разговора. РоС 2 расширяет управление мультимедийными данными так, чтобы включать в себя другие типы мультимедийных данных, такие как видеоданные. Технические требования РоС 2 устанавливают, что существует необходимость в устройстве, которое синхронизирует разрешение на передачу для различных мультимедийных данных так, чтобы пользователь мог посылать пакетный сигнал разговора и поток видеоданных в одно и то же время, так же как напротив, когда один пользователь посылает пакетный сигнал разговора, в то время как другой посылает поток видеоданных.
Один возможный подход к реализации управления пакетными сигналами множества мультимедийных данных иллюстрируется на фиг.1 прилагаемых чертежей, которая показывает клиента РоС PC во взаимодействии с сервером РоС PS. На этапе Р1 запрос на пакетный сигнал разговора для речевых мультимедийных данных посылается от клиента РоС PC на сервер РоС PS. На этапе Р2 запрос на пакетный сигнал разговора для потока видеоданных посылается от клиента РоС PC в сервер РоС PS. На этапе Р3 запрос на пакетный сигнал разговора для речевых данных отклоняется или удовлетворяется с помощью сообщения, посылаемого от сервера РоС PS клиенту РоС PC. На этапе Р4 запрос на пакетный сигнал разговора для видеоданных отклоняется или удовлетворяется с помощью сообщения, посылаемого от сервера РоС PS клиенту РоС PC.
Однако подход, иллюстрируемый на фиг.1, не идеален, поскольку разрешения на передачу не скоординированы, и может оказаться, что пользователь не будет заинтересован в случае, когда допускается только один из типов мультимедийных данных.
Другая проблема, связанная с существующим решением в ОМА РоС 1, состоит в том, что когда кому-то предоставляется право посылать пакетный сигнал разговора, сервер РоС ожидает, что пакетный сигнал разговора будет послан от клиента РоС, который послал запрос на пакетный сигнал разговора из условия, что сервер РоС будет отвергать любой пакетный сигнал разговора, посланный от любого другого клиента РоС.
При введении возможности посылать изображения, видеоданные или любой другой контент мультимедийных данных клиент РоС может запрашивать разрешение на передачу для одного типа мультимедийных данных от имени другого клиента РоС. Например, если запрашивающий клиент РоС желает говорить, в то время как другой клиент РоС желает предоставить изображение, между звуковыми данными и изображением требуется координация разрешения на передачу.
Желательно обратиться к вышеупомянутым проблемам.
Документ US 2005/0124365 раскрывает способ для управления разрешением на передачу в системе РТТ, в котором мобильная станция может передавать сообщение или сообщения с запросом разрешения на передачу и запрашивать множество разрешений на передачу.
Документ US 2004/0190489 раскрывает способ управления мультимедийным сеансом связи, который включает в себя прием запроса на установление сеанса связи, включающего в себя множество типов мультимедийных данных.
Сущность изобретения
Согласно первому аспекту настоящего изобретения предусматривается способ, предназначенный для использования в услуге "нажми и говори", в котором для терминала требуется разрешение на передачу, чтобы распределять контент мультимедийных данных для другого терминала, участвующего в сеансе связи "нажми и говори", который содержит отправку сообщения с запросом разрешения на передачу, относящегося по меньшей мере к двум различным типам контента мультимедийных данных, отличающийся тем, что сообщение с запросом разрешения на передачу указывает, по меньшей мере, для одного из типов мультимедийных данных, как и/или степень, до которой разрешение или отклонение запроса, относящегося к этому типу мультимедийных данных, воздействует и/или зависит от запроса, относящегося по меньшей мере к одному другому типу мультимедийных данных.
Сообщение с запросом разрешения на передачу может указывать, по меньшей мере для одного из типов мультимедийных данных, как и/или степень, до которой разрешение или отклонение запроса, относящегося к этому типу мультимедийных данных, воздействует и/или зависит от разрешения или отклонения запроса, относящегося по меньшей мере к одному другому типу мультимедийных данных.
Сообщение с запросом разрешения на передачу может указывать, по меньшей мере для одного из типов мультимедийных данных, что если запрос, относящийся к этому типу мультимедийных данных, отклоняется, тогда запрос, относящийся к какому-либо другому типу мультимедийных данных, также должен быть отклонен.
Сообщение с запросом разрешения на передачу может указывать, по меньшей мере для одного из типов мультимедийных данных, что разрешение или отклонение запроса, относящегося к этому типу мультимедийных данных, не должно воздействовать на разрешение или отклонение запроса, относящегося к какому-либо другому типу мультимедийных данных.
Сообщение с запросом разрешения на передачу может указывать, по меньшей мере для одного из типов мультимедийных данных, что запрос, относящийся к этому типу мультимедийных данных, должен быть разрешен, только если запрос, относящийся по меньшей мере к одному другому определенному типу мультимедийных данных, разрешен.
Сообщение с запросом разрешения на передачу может указывать, по меньшей мере для одного из типов мультимедийных данных, что запрос, относящийся к этому типу мультимедийных данных, должен быть разрешен или отклонен в той же самой степени, в которой разрешен или отклонен запрос, относящийся по меньшей мере к одному другому определенному типу мультимедийных данных.
Сообщение с запросом разрешения на передачу может указывать, по меньшей мере для одного из типов мультимедийных данных, как и/или степень, до которой разрешение или отклонение запроса, относящегося к этому типу мультимедийных данных, зависит по меньшей мере от одного определенного воздействующего фактора, такого как количество участников, которые примут этот тип мультимедийных данных, или оцениваемая скорость передачи данных для этого типа мультимедийных данных.
Сообщение с запросом разрешения на передачу может указывать, для каждого из типов мультимедийных данных, какой терминал указан для предоставления этого типа мультимедийных данных через разрешение на передачу, что должно быть дано разрешение на запрос, относящийся к этому типу мультимедийных данных.
Сообщение с запросом разрешения на передачу может указывать, по меньшей мере для одного из типов мультимедийных данных, что для терминала, отличающегося от того, который послал сообщение с запросом разрешения на передачу, определенного для того, чтобы предоставлять этот тип мультимедийных данных через разрешение на передачу, должно быть дано разрешение на запрос, относящийся к этому типу мультимедийных данных.
Способ может содержать обработку сообщения с запросом разрешения на передачу, чтобы определять, для каждого из по меньшей мере двух типов мультимедийных данных, разрешить или отклонить запрос, относящийся к этому типу мультимедийных данных.
Способ может содержать, по меньшей мере для каждого типа мультимедийных данных, относящегося к тому типу, для которого запрос был разрешен, отправку сообщения в результате этого в терминал, определенный для того, чтобы предоставлять этот тип мультимедийных данных.
Способ может содержать отправку сообщения в терминал, который послал сообщение с запросом разрешения на передачу, чтобы указать, для каждого типа мультимедийных данных, разрешен ли или отклонен запрос, относящийся к этому типу мультимедийных данных.
Способ может содержать отправку единственного такого сообщения в этот или каждый терминал, если требуется.
Способ может содержать обработку сообщения с запросом разрешения на передачу, чтобы определять, для каждого из по меньшей мере двух типов мультимедийных данных, разрешить или отклонить запрос, относящийся к этому типу мультимедийных данных.
Способ может содержать разрешение сообщения с запросом разрешения на передачу, которое будет варьироваться на основе этого определения, с различной комбинацией типов мультимедийных данных и ассоциированных состояний, перед окончательным удовлетворением или отклонением запроса, относящегося к каждому типу мультимедийных данных.
Услуга "нажми и говори" может быть услугой сотовой связи (услуга "нажми и говори").
Услуга "нажми и говори" может быть услугой проведения телефонных конференций.
Способ может содержать отправку единственного такого сообщения с запросом разрешения на передачу. Или он может содержать отправку множества сообщений с запросами, где каждое сообщение из этого множества относится по меньшей мере к одному из типов мультимедийных данных, причем это множество сообщений с запросами подлежит совместному рассмотрению.
Согласно второму аспекту настоящего изобретения предусматривается устройство, предназначенное для использования в услуге "нажми и говори", в котором для терминала требуется разрешение на передачу, чтобы распределять контент мультимедийных данных для другого терминала, участвующего в сеансе услуги "нажми и говори", которое содержит средство для отправки сообщения с запросом разрешения на передачу, относящегося по меньшей мере к двум различным типам контента мультимедийных данных, отличающееся тем, что сообщение с запросом разрешения на передачу указывает, по меньшей мере для одного из этих типов мультимедийных данных, как и/или степень, до которой разрешение или отклонение запроса, относящегося к этому типу мультимедийных данных, воздействует и/или зависит от запроса, относящегося по меньшей мере к одному другому типу мультимедийных данных.
Согласно третьему аспекту настоящего изобретения предусматривается способ, предназначенный для использования в услуге "нажми и говори", в котором для терминала требуется разрешение на передачу, чтобы распределять контент мультимедийных данных для другого терминала, участвующего в сеансе услуги "нажми и говори", который содержит прием и обработку сообщения с запросом разрешения на передачу, относящегося по меньшей мере к двум различным типам контента мультимедийных данных, отличающийся тем, что сообщение с запросом разрешения на передачу указывает, по меньшей мере для одного из типов контента мультимедийных данных, как и/или степень, до которой разрешение или отклонение запроса, относящегося к этому типу мультимедийных данных, воздействует и/или зависит от запроса, относящегося по меньшей мере к одному другому типу мультимедийных данных.
Согласно четвертому аспекту настоящего изобретения предусматривается устройство, предназначенное для использования в услуге "нажми и говори", в котором для терминала требуется разрешение на передачу, чтобы распределять контент мультимедийных данных для другого терминала, участвующего в сеансе услуги "нажми и говори", который содержит средство для приема и обработки сообщения с запросом разрешения на передачу, относящегося по меньшей мере к двум различным типам контента мультимедийных данных, отличающееся тем, что сообщение с запросом разрешения на передачу указывает, по меньшей мере для одного из типов мультимедийных данных, как и/или степень, до которой разрешение или отклонение запроса, относящегося к этому типу мультимедийных данных, воздействует и/или зависит от запроса, относящегося по меньшей мере к одному другому типу мультимедийных данных.
Согласно пятому аспекту настоящего изобретения предусматривается способ, предназначенный для использования в услуге "нажми и говори", в котором для терминала требуется разрешение на передачу, чтобы распределять контент мультимедийных данных для другого терминала, участвующего в сеансе услуги "нажми и говори", который содержит отправку сообщения с запросом разрешения на передачу, относящегося по меньшей мере к двум различным типам контента мультимедийных данных, отличающийся тем, что сообщение с запросом разрешения на передачу указывает, для каждого из типов мультимедийных данных, для которого терминал определен для предоставления этого типа мультимедийных данных через разрешение на передачу, что должно быть дано разрешение на запрос, относящийся к этому типу мультимедийных данных.
Согласно шестому аспекту настоящего изобретения предусмотрено устройство, предназначенное для использования в услуге "нажми и говори", в котором для терминала требуется разрешение на передачу, чтобы распределять контент мультимедийных данных для другого терминала, участвующего в сеансе услуги "нажми и говори", которое содержит средство для отправки сообщения с запросом разрешения на передачу, относящегося по меньшей мере к двум различным типам контента мультимедийных данных, отличающееся тем, что сообщение с запросом разрешения на передачу указывает, для каждого из типов мультимедийных данных, для которого терминал обозначен для предоставления этого типа мультимедийных данных через разрешение на передачу, что должно быть дано разрешение на запрос, относящийся к этому типу мультимедийных данных.
Согласно седьмому аспекту настоящего изобретения предусмотрен способ, предназначенный для использования в услуге "нажми и говори", в котором для терминала требуется разрешение на передачу, чтобы распределять контент мультимедийных данных для другого терминала, участвующего в сеансе услуги "нажми и говори", который содержит прием и обработку сообщения с запросом разрешения на передачу, относящегося по меньшей мере к двум различным типам контента мультимедийных данных, отличающийся тем, что сообщение с запросом разрешения на передачу указывает, для каждого из типов мультимедийных данных, для которого терминал определен для предоставления этого типа мультимедийных данных через разрешение на передачу, что должно быть дано разрешение на запрос, относящийся к этому типу мультимедийных данных.
Согласно восьмому аспекту настоящего изобретения предусмотрено устройство, предназначенное для использования в услуге "нажми и говори", в котором для терминала требуется разрешение на передачу, чтобы распределять контент мультимедийных данных для другого терминала, участвующего в сеансе услуги "нажми и говори", который содержит средство для приема и обработки сообщения с запросом разрешения на передачу, относящегося по меньшей мере к двум различным типам контента мультимедийных данных, отличающееся тем, что сообщение с запросом разрешения на передачу указывает, для каждого из типов мультимедийных данных, для которого терминал обозначен для обеспечения этого типа мультимедийных данных через разрешение на передачу, что должно быть дано разрешение на запрос, относящийся к этому типу мультимедийных данных.
Согласно девятому аспекту настоящего изобретения предусмотрена рабочая программа, которая, при выполнении на устройстве, заставляет устройство выполнять способ согласно первому, третьему, пятому или седьмому аспекту настоящего изобретения.
Рабочая программа может находится на носителе данных. Носитель данных может быть средой передачи. Носитель данных может быть носителем хранения.
Вариант осуществления настоящего изобретения обеспечивает прямой способ запроса разрешения на передачу для нескольких независимых разрешений на передачу мультимедийных данных в одно и то же время и от имени другого клиента РоС. Вариант осуществления настоящего изобретения также обеспечивает средство для координирования типов мультимедийных данных в запросе. Вариант осуществления настоящего изобретения обеспечивает возможность запрашивать множество разрешений на передачу мультимедийных данных в единственном запросе и запрашивать разрешение на передачу от имени другого устройства (например, другого клиента РоС).
Краткое описание чертежей
Фиг.1, обсуждавшаяся выше, схематично иллюстрирует один возможный подход к реализации управления множеством пакетных сигналов мультимедийных данных, включающий в себя клиента РоС и сервер РоС;
фиг.2 - графическое представление обмена сообщениями, иллюстрирующее обмен сообщениями в варианте осуществления настоящего изобретения между клиентом РоС и сервером РоС в одном возможном сценарии;
фиг.3 - графическое представление обмена сообщениями, иллюстрирующее обмен сообщениями в варианте осуществления настоящего изобретения между двумя клиентами РоС и сервером РоС в другом возможном сценарии;
фиг.4 - блок-схема, схематично иллюстрирующая компоненты клиента РоС и сервера РоС в варианте осуществления настоящего изобретения.
Подробное описание предпочтительных вариантов осуществления изобретения
Согласно одному варианту осуществления настоящего изобретения, чтобы запросить разрешение послать один или больше типов мультимедийных данных, используется единственное сообщение с запросом, другими словами, используется единственное сообщение с запросом для запрашивания множества разрешений на передачу.
Для каждого типа мультимедийных данных может быть указание относительно того, требуется ли этот тип мультимедийных данных или он просто является предпочтительным. Если тип мультимедийных данных является предпочтительным и сервер РоС не может предоставить разрешение послать этот тип мультимедийных данных, то запрос можно удовлетворить каким бы то ни было образом (для других типов мультимедийных данных). Если тип мультимедийных данных требуется, а сервер РоС не может предоставить разрешение послать этот тип мультимедийных данных, то сервер РоС может дать отказ на запрос, даже если доступны некоторые из других типов мультимедийных данных.
Также можно предоставлять указание того, какой участвующий терминал будет посылать конкретный тип мультимедийных данных, делая возможным запрашивать разрешение посылать мультимедийные данные от имени другого устройства, например от другого клиента РоС. Если запрос удовлетворяется и если другое устройство, отличающееся от того клиента РоС, который запрашивал разрешение на передачу, является источником для конкретного типа мультимедийных данных, то сервер РоС может послать сообщение этому другому устройству, чтобы информировать его о разрешении, предоставляемом для этого типа мультимедийных данных.
Вариант осуществления настоящего изобретения теперь будет описан более подробно со ссылкой на фиг.2, 3 и 4. Фиг.2 является графическим представлением обмена сообщениями, иллюстрирующим обмен сообщениями между клиентом А РоС и сервером S РоС в одном возможном сценарии, в то время как фиг.3 является графическим представлением обмена сообщениями, иллюстрирующим обмен сообщениями между клиентами А и В РоС и сервером S РоС в другом возможном сценарии. Фиг.4 представляет собой блок-схему, схематично иллюстрирующую части клиента А РоС и сервера S РоС. Клиент А РоС содержит производящий запрос участок А1 и посылающий запрос участок A3; эти части работают под общим управлением участка А5 администрирования. Сервер S РоС содержит принимающий запрос участок S1, обрабатывающий запрос участок S3 и отвечающий на запрос участок S5; эти компоненты работают под общим управлением участка S7 администрирования.
В первом сценарии, как иллюстрируется на фиг.2, клиент А РоС запрашивает разрешение послать как речевой контент мультимедийных данных, так и видеоконтент мультимедийных данных через разрешение на передачу. В этом сценарии клиент А РоС определяет, что запрашиваются оба типа мультимедийных данных; другими словами, если оба типа мультимедийных данных не могут быть удовлетворены в одно и то же время, то сервер S РоС должен отказать в запросе, относящемся к обоим типам мультимедийных данных, даже если разрешение на передачу для одного из этих типов мультимедийных данных доступно.
На этапе 1 посылающий запрос участок A3 клиента А РоС посылает сообщение с запросом разрешения на передачу, относящегося к обоим типам контента мультимедийных данных, к видеоданным и речевым данным. Сообщение с запросом разрешения на передачу указывает, как и/или степень, до которой разрешение или отклонение запроса, относящегося к одному из типов мультимедийных данных, должны воздействовать на разрешение или отклонение запроса, относящегося к другому типу мультимедийных данных. Сообщение с запросом подготавливается производящим запрос участком А1.
В этом примере сообщение с запросом указывает, что если запрос, относящийся к типу видеомультимедийных данных, отклоняется, то тогда должен быть запрос для речевого типа мультимедийных данных, и наоборот. Другими словами, запрашиваются оба.
Информация может альтернативно выражать информацию в том смысле, что запрос, относящийся к речевому типу мультимедийных данных, должен быть разрешен, только если разрешен запрос, относящийся к типу видеомультимедийных данных.
Или информация может указывать, что запрос, относящийся к типу видеомультимедийных данных, должен быть разрешен или отклонен в той же самой степени, в которой разрешен или отклонен запрос, относящийся к речевому типу мультимедийных данных, то есть что он должен рассматриваться как группа или набор, который должен быть разрешен или отклонен совместно, независимо от разрешения или отклонения любых других типов мультимедийных данных, представленных в этом сообщении с запросом.
Сообщение с запросом разрешения на передачу также может указывать, по меньшей мере для одного из типов мультимедийных данных, как и/или степень, до которой разрешение или отклонение запроса, относящегося к этому типу мультимедийных данных, зависит по меньшей мере от одного определенного влияющего фактора. Влияющим фактором может быть, например, количество участников, которые могут принимать этот тип мультимедийных данных, так что запрос должен быть разрешен, только если он будет распределен участникам, превышающим определенное количество. Или влияющий фактор может относиться к оцениваемой скорости передачи данных для этого типа мультимедийных данных, так что запрос должен быть разрешен, только если передача будет достаточно быстрой.
Способ выражения этой информации, такой как взаимозависимость между типами мультимедийных данных, представленными в сообщении с запросом, и состояния, требуемые для разрешения или отклонения, является неважным. Способ выражения этой информации может быть очевиден специалистам в данной области техники.
Вслед за получением сообщения с запросом на принимающем запрос участке S1 сервера S РоС сообщение с запросом направляется на обрабатывающий запрос участок S3 так, чтобы информация в запросе могла быть извлечена и интерпретирована, и так, чтобы можно было принять решение относительно того, можно ли допустить запрос или запретить и до какой степени.
Из сообщения в этом примере определяется, что клиентом А РоС запрашиваются как речевые типы мультимедийных данных, так и тип видеомультимедийных данных. Также определяется, что разрешение на передачу для речевых данных является незанятым и разрешение на передачу для видеоданных является незанятым, так что возможно удовлетворить этот запрос относительно и речевых типов мультимедийных данных, и типов видеомультимедийных данных.
Поэтому на этапе 2 отвечающий на запрос участок S5 посылает сообщение обратно клиенту А РоС, чтобы указать, что разрешение на передачу удовлетворяется и для речевых данных, и для видеоданных.
В альтернативном сценарии с помощью обрабатывающего запрос участка S3 можно определить, что оба типа мультимедийных данных - и речевой, и тот, который требует разрешения, - запрашиваются клиентом А РоС (как для предыдущего сценария), но также и то, что разрешение на передачу для речевых данных или разрешение на передачу для видеоданных является занятым. Поэтому невозможно удовлетворить запрос, относящийся и к речевым типам мультимедийных данных, и к типам видеомультимедийных данных, и на этапе 2 отвечающий на запрос участок S5 может послать сообщение обратно клиенту А РоС, чтобы указать, что разрешение на передачу отклоняется и для речевых данных, и для видеоданных (или общее сообщение об отклонении).
Хотя в описанном выше варианте осуществления сервер S РоС дает разрешение или отклонение запроса, относящегося к каждому типу мультимедийных данных, и затем посылает сообщение обратно клиенту А РоС, чтобы указать его решение, также возможно, что сервер S РоС вместо этого посылает первоначально ответ обратно клиенту А РоС, чтобы указать, какие типы мультимедийных данных являются доступными, а какие типы мультимедийных данных являются недоступными (однако без удовлетворения или отклонения какого-либо из этих запросов). Это дает клиенту А РоС вариант выбора, чтобы подтвердить первоначальный запрос (например, если определенный или все типы мультимедийных данных являются доступными) или изменить запрос на другую комбинацию типов мультимедийных данных и ассоциированных состояний. Подтверждение от клиента А РоС может быть явным или неявным (например, предполагаемым подтверждением после прохождения предварительно определенного времени без явного подтверждения).
В другом сценарии, как иллюстрируется на фиг.3, клиент А РоС снова запрашивает разрешение послать и контент речевых мультимедийных данных, и контент видеомультимедийных данных через разрешение на передачу. В этом сценарии клиент А РоС определяет, что требуется речевой тип мультимедийных данных, в то время как тип видеомультимедийных данных просто является дополнительным или предпочтительным. Другими словами, если речевой тип мультимедийных данных нельзя предоставить, то сервер S РоС должен отказать в запросе, относящемся к обоим типам мультимедийных данных, даже если разрешение на передачу для типа видеомультимедийных данных является доступным. С другой стороны, если нельзя предоставить тип видеомультимедийных данных, то сервер S РоС должен все еще давать возможность для запроса, относящегося к речевому типу мультимедийных данных, если это возможно.
В этом сценарии клиент А РоС также запрашивает разрешение на передачу для видеоданных от имени клиента В РоС так, что если разрешение на передачу для видеоданных удовлетворяется, тогда клиент В РоС должен обеспечивать видеоконтент через предоставленное разрешение на передачу.
На этапе 1 посылающий запрос участок A3 клиента А РоС посылает сообщение с запросом разрешения на передачу, относящегося к обоим типам контента мультимедийных данных, к видеоданным и речевым данным. Сообщение с запросом указывает, что требуются речевые данные и что видеоданные являются просто дополнительными. Сообщение с запросом также указывает, что клиент В РоС определен, чтобы предусмотреть тип видеомультимедийных данных через разрешение на передачу, для которого должно быть дано разрешение на запрос, относящийся к типу видеомультимедийных данных (сообщение с запросом может либо явно указывать, что клиенту А РоС, который определен для того, чтобы обеспечивать речевой тип мультимедийных данных через разрешение на передачу, должно быть дано разрешение на запрос, относящийся к речевому типу мультимедийных данных, либо это можно делать неявно в отсутствие явного указания, поскольку клиент А РоС является отправителем сообщения с запросом). Сообщение с запросом подготавливается производящим запрос участком Al.
Вслед за получением сообщения с запросом на принимающем запрос участке S1 сервера S РоС сообщение с запросом направляется на обрабатывающий запрос участок S3 так, чтобы информация в запросе могла быть извлечена и интерпретирована, и так, чтобы могло быть принято решение относительно того, можно ли дать разрешение или отклонение на этот запрос и до какой степени.
Из сообщения в этом примере определяется, что требуется речевой тип мультимедийных данных и что клиент А РоС является тем, кто будет их предоставлять. Также определяется, что тип видеомультимедийных данных является дополнительным и что клиент В РоС является тем, кто будет их предоставлять. Дополнительно определяется, что разрешение на передачу для речевых данных является незанятым и разрешение на передачу для видеоданных является незанятым, так что возможно удовлетворить запрос, относящийся и к речевому типу мультимедийных данных, и к типу видеомультимедийных данных.
Поэтому на этапе 2.1 отвечающий на запрос участок S5 посылает сообщение обратно клиенту А РоС, чтобы указать, что разрешение на передачу для речевых данных удовлетворяется, а на этапе 2.2 сообщение посылается клиенту В РоС, чтобы указать, что разрешение на передачу для видеоданных удовлетворяется.
В альтернативном сценарии, с помощью обрабатывающего запрос участка S3 можно определить, что разре