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

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

Иллюстрации

Показать все

Реферат

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

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

ОПИСАНИЕ ПРЕДШЕСТВУЮЩЕГО УРОВНЯ ТЕХНИКИ

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

В попытке расширить использование услуг вида walkie-talkie было учреждено промышленное объединение, известное как Открытый союз по мобильной связи (www.openmobilealliance.org), с целью стандартизации применимых протоколов, которые будут допускать межсетевую взаимную работоспособность («интероперабельность») для услуг полудуплексной связи, предлагаемых по сетям сотовой радиосвязи. Услуга, установленная согласно различным стандартам, известна как полудуплексная связь поверх сотовой радиосвязи (PoC). PoC предлагает, что соответствующие речевые данные будут транспортироваться по сети доступа с коммутацией пакетов. В случае глобальной системы мобильной связи (GSM) и универсальной системы мобильной связи (UMTS) это будут обобщенные услуги пакетной радиопередачи (GPRS), или сеть абонентского доступа систем связи третьего поколения (3G). В других архитектурах сетей связи для транспортировки данных разговора будут использованы аналогичные сети доступа с коммутацией пакетов. Услуги полудуплексной связи также могут предлагаться по сетям доступа с коммутацией каналов, хотя это не является предпочтительным возможным вариантом.

Система полудуплексной связи поверх сотовой радиосвязи (PoC) обычно реализуется на сетях GSM/GPRS/3G и использует подсистему мультимедийных услуг (IMS) на основе IP-протокола, стандартизированную согласно Проекту партнерства систем связи 3-го поколения, чтобы содействовать введению расширенных услуг передачи данных в сетях сотовой радиосвязи, и в частности услуг передачи мультимедиа в реальном масштабе времени. IMS основывается на протоколе инициирования сеанса (SIP), который был определен комитетом инженерной поддержки сети Internet (IETF) для установки и управления сеансами передачи мультимедийных данных на основе протокола IP. Сервер PoC располагается в IMS или присоединяется к ней, и реализует функциональность для установки и управления PoC-сеансами.

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

Для запроса права говорить от имени пользователя, терминал (PoC-клиент) обычно посылает на контроллер (PoC-сервер) сообщение запроса. Контроллер обычно отвечает либо предоставляя, либо отклоняя запрос. Контроллер обычно ограничивает время, которое пользователю разрешается говорить, обычно, запуская таймер разрешенного разговора, когда он удовлетворяет запрос, и использует некоторый механизм, чтобы прерывать пользователя, обычно, путем посылки на пользовательский терминал сообщения отмены или, просто не пересылая пользовательские медиаданные. Пользователь, которого прервал контроллер, обычно некоторым образом штрафуется контроллером, например, путем не предоставления пользователю права говорить в течение некоторого интервала времени.

В OMA развивается следующая версия PoC-OMA (называемая в документе «PoC 2», при этом предыдущая версия называется «PoC 1»). Частью новой функциональности в PoC 2 является включение новых типов медиа, предоставляющих возможность посылки изображений, видео и т.д. в PoC-сеансах. Однако конечный пользователь или клиент может быть способен только (или выбирать, чтобы) обрабатывать поднабор из всех доступных медиа. Ввиду этого, будут иметься требования включить функциональность, предназначенную для запрещения (передачи) медиа. Нижеследующая выдержка взята из документа OMA технических требований к PoC 2 [Требования к полудуплексной связи поверх сотовой радиосвязи, проект версии 2.0-02 сентября 2005, OMA-RD-PoC-V2_0-20050902-D]: «В дополнение к тому, что определено в PoC версии 1.0, возможность запрета входящих медиа PoC является необходимой, когда принимающий пользователь PoC не желает принимать некоторые медиа в некоторый момент. Он может потребовать запрет без вмешательства в преобразование и совместное использование медиа в пределах остальной группы». Также из документа OMA технических требований к PoC 2: «PoC-клиент может поддерживать запрет отдельных входящих медиа для каждого типа медиа»; «PoC-клиент может поддерживать различные правила принятия и отклонения для каждого типа медиа»; «Инфраструктура услуги PoC должна поддерживать запрет отдельных входящих медиа PoC для каждого типа медиа»; «Инфраструктура услуги PoC должна использовать ручной режим ответа (оператора) в качестве заданного по умолчанию режима ответа для PoC-сеансов, когда медиа представляют собой видеоданные (пользователь PoC может настраивать режим ответа, как он желает)»; «Инфраструктура услуги PoC должна использовать режим автоматического ответа в качестве заданного по умолчанию режима ответа для PoC-сеансов только с типом медиа, представляющим передачу сообщениий или при добавлении передачи сообщений к реализуемому PoC-сеансу»; «Инфраструктура услуги PoC должна использовать режим ответа в соответствии с установкой режима ответа таким же образом, как указано PoC 1»; и «Инфраструктура услуги PoC должна использовать различные правила принятия и отклонения для каждого типа медиа, если настроено PoC-клиентом».

PoC 1 не содержит функциональности для запрета медиа; это является новой предложенной функциональностью в PoC 2. PoC 2 обогатит коммуникацию новыми типами медиа, такими как видео, передача текстовых сообщений и т.д, в PoC-сеансе по сравнению с PoC 1, где возможен только аудио/речевой пакет. Сеанс по PoC 2 может использовать, например, аудио/речевые пакеты параллельно с видео. С точки зрения конечного пользователя могут быть ситуации, в которых он/она желает ограничить различные медиа, которые используются в PoC-сеансе. Например, пользователь может пожелать принять только аудио/речевой пакет, а не видео. Причины для этого могут включать в себя нахождение в среде или условии, где видео не является подходящим для использования, или возможно в области ограниченной полосы частот, или наличие истощения аккумуляторной батареи и понимание, что отображение видео может потребовать очень большого потребления мощности. Именно получатель (то есть, завершающий пользователь PoC-вызова) выбирает «запретить» медиа, предлагаемые в сеансе вызывающего пользователя, а не отправитель, который выбирает «не посылать» некоторые типы медиа.

PoC (и IMS в целом) разделяется на плоскость управления, где используется сигнализация по SIP, и плоскость среды передачи, где полезная нагрузка (речевые, видеоданные и т.д.) транспортируется с использованием различных протоколов, таких как RTP (транспортный протокол реального времени), MSRP (транспортный протокол пересылки сообщений) и т.д. При установке параметров PoC-сеанса (или любого другого сеанса SIP), информация о том, какие типы медиа будут использоваться для этого сеанса, транспортируется в протоколе (SDP) описания сеанса для мультимедийных сеансов [документ RFC 2327], который является частью сообщения SIP. Это используется, чтобы синхронизировать потоки медиа от отправителя и получателя. Отправитель посылает информацию о каждом типе медиа, который он желает использовать в сеансе, и получатель представит в ответе все или поднабор предлагаемых медиа.

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

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

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

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

В-третьих, в PoC имеется функциональная возможность для автоматического ответа, где на PoC-сеанс автоматически отвечают, и пользователь не отвечает явным образом, чтобы ускорить установку сеанса и для удобства. Для видеоданных в PoC 2 предложено никогда не использовать автоматический ответ по причинам конфиденциальности. Это подразумевает, что каждый сеанс, содержащий видео, будет требовать ручного ответа от пользователя, даже если он не желает иметь дело с видео. Примером является, когда получатель установил AutoAnswer=TRUE (Автоматический ответ=ИСТИННО) и VideoMedia=FALSE (Видеоданные=ЛОЖНО); если получатель с этими установочными параметрами получает приглашение к PoC-сеансу, содержащему и аудио, и видео, функциональная возможность автоответа не может использоваться, поскольку медиа «видео» в сеансе подразумевает, что автоответ блокирован.

Желательно направить усилия на один или несколько вышеупомянутых вопросов.

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

КРАТКОЕ ОПИСАНИЕ СУЩНОСТИ ИЗОБРЕТЕНИЯ

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

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

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

Способ может содержать установку сеанса, на основании типов медиа, подтвержденных в ответном сообщении в качестве приемлемых.

Ответное сообщение может быть сообщением 200 «OK» (успешно) протокола инициирования сеанса.

Способ может содержать прием, по меньшей мере, некоторой информации от первого терминала в сообщении Publish (публиковать) протокола инициирования сеанса прежде приема сообщения приглашения.

Способ может содержать подтверждение сообщения Publish с помощью сообщения 200 «OK» протокола инициирования сеанса.

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

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

Одна характеристика, по меньшей мере, из одной заранее заданной характеристики первого терминала может относиться к типу, соответствующему услуге вида полудуплексной связи, которая является действующей.

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

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

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

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

Сообщение приглашения может быть сообщением Invite протокола инициирования сеанса.

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

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

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

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

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

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

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

На основании этого, вариант осуществления настоящего изобретения получит пользу от одного или нескольких из: (a) сокращения пакетов сигнализации, поскольку удаляются параметры нежелательных медиа; (b) сокращения ненужного трафика сигналов управления получателю, если запрещены все типы медиа для конкретного сеанса; (c) более простой реализации клиента, поскольку клиент не должен согласовывать установочные параметры запрета с тем, как параметры медиа обрабатываются в сигнализации управления; и (d) обеспечения решения конкретных проблем PoC, таких как сеансы вместе с сеансами PoC 1 и PoC 2, а также особого случая автоответа и запрета медиа типа «видео», как предварительно описано.

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

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

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

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

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

Вариант осуществления настоящего изобретения теперь будет описан более подробно со ссылкой на фиг.1 и 2. На фиг.1 показана схема обмена сообщениями, иллюстрирующая обмен сообщениями между PoC-клиентами А и B и PoC-сервером S в этом варианте осуществления. На фиг.2 показана блок-схема, схематично иллюстрирующая составляющие PoC-сервера S, а также взаимодействия между внешним сервером ES, PoC-клиентами А и B, и PoC-сервером S. PoC-сервер S содержит блок S1 приема приглашения, блок S3 обработки приглашения, блок S5 пересылки приглашения, и блок S7 администратора предпочтений типов медиа. Эти составляющие PoC-сервера S работают под общим управлением блока S9 управления, который также ведет все функции обработки и взаимодействия, не выполняемые блоками S1, S3, S5 и S7.

На этапе 1 PoC-клиент А информирует блок S7 администратора предпочтений типов медиа в составе PoC-сервера S о типах медиа, которые он не желает или не может принять. Это может быть на той основе, что PoC-клиент физически не может оперировать этим типом медиа постоянно или временно, или что пользователь не желает принимать этот тип медиа, или по любой другой причине. В качестве альтернативы PoC-клиент А может информировать PoC-сервер S о типах медиа, которые он примет, или комбинацию вышеупомянутого. В этом варианте осуществления это достигается с использованием сообщения PUBLISH протокола SIP, которое описано более полно ниже. Блок S7 администратора предпочтений типов медиа хранит эту информацию для последующей ссылки.

На этапе 2 PoC-сервер S подтверждает запрос. В этом варианте осуществления это достигается с помощью SIP-сообщения 200 OK.

На этапе 3 PoC-клиент В указывает свое намерение установить PoC-сеанс с PoC-клиентом А, в то же время указывая типы медиа, которые желает использовать в PoC-сеансе. В этом варианте осуществления это достигается путем посылки SIP-сообщения INVITE с наличием перечня типов медиа, предназначенных для использования в PoC-сеансе, включаемых в «PARAMETERS SDP» (параметры SDP) в сообщение INVITE протокола SIP. Например, он может указать «речевые пакеты», видеоклип, изображение и так далее. Оно (сообщение) принимается в PoC-сервере S посредством блока S1 приема приглашения.

На этапе 4 PoC-сервер S отвечает с помощью подтверждения RINGING (посылка вызова) протокола SIP.

На этапе 5 SIP-сообщение INVITE пересылается на PoC-клиент А посредством блока S5 пересылки приглашения в составе PoC-сервере S. Однако перед выполнением этого, блок S3 обработки приглашения пересматривает перечень элементов медиа в SIP-сообщении INVITE, и удаляет все параметры SDP, которые указывают типы медиа, которые клиент А не будет принимать. Это пересмотр выполняется с использованием информации из блока S7 администратора предпочтений типов медиа.

На этапе 6 PoC-клиент А подтверждает и осуществляет принятие сеанса с помощью SIP-сообщения 200 OK. Это сообщение также содержит параметры SDP, и поскольку PoC-клиент А не будет иметь принятой какой-либо информации о типах медиа, которыми он не желает оперировать, эти параметры никогда не будут возвращены на PoC-сервер S и PoC-клиент B.

На этапе 7 подтверждение 200 OK пересылается на PoC-клиент B.

На этапе 8 PoC-клиент В устанавливает PoC-сеанс, использующий только медиа, которые PoC-клиент А подтвердил.

На этапе 9 согласованные типы медиа передаются от PoC-клиента B на PoC-клиент А.

В качестве альтернативы этапам 1 и 2, или в дополнение к этим этапам, является возможным, что PoC-сервер S принимает информацию, относящуюся к предпочтениям типов медиа для PoC-клиента А, в некотором заранее заданном формате от внешнего сервера ES либо заранее, либо по запросу. Например, информация может быть задана в виде документа на языке XML (расширяемом языке разметки гипертекста), хранимого в PoC XDMS (сервер управления XML-документами). Это разрешит более гибкое использование запрета использования медиа, причем запрет может быть указан для каждого из отдельных пользователей. По существу, информация укажет для одного или каждого типа из одного или нескольких типов медиа в каких условиях, если вообще имеются, PoC-клиент А примет этот тип медиа в сеансе полудуплексной связи. Это может быть выражено условно или безусловно. Например, информация может указывать, что PoC-клиент А будет принимать видео от PoC-клиента B, но не от PoC-клиента С. Он может принимать изображения от Joe Bloggs, но не от John Smith. Он может принимать голосовые данные от любого PoC-клиента или пользователя. Он может принять некоторые типы медиа только для приглашений сеанса, принимаемых в некоторые моменты времени суток. Будут очевидными многие другие такие правила. Конкретное может применяться к одиночному типу медиа, или ко многим типам медиа, и так далее. (По меньшей мере, частично такая гибкость также может быть реализована, используя ранее изложенный метод PUBLISH протокола SIP.)

В отличие от вышеописанного варианта осуществления настоящего изобретения, альтернативным решением этой проблемы (не заключающим в себе настоящее изобретение) было бы такое, когда PoC-сервер S не извлекает на этапе 3 информацию (SDP) медиа относительно нежелательных типов медиа, причем блокировка медиа взамен выполняется только в плоскости среды передачи (этап 8). Однако такое альтернативное решение было бы неэффективным по сравнению с вариантом осуществления по настоящему изобретению, потому что: (a) будет необходимо, чтобы сигнализация SIP несла дополнительную информацию SDP, которая никогда не будет использоваться; она может быть минимальной в некоторых случаях, но будет зависеть от типа медиа; (b) PoC-клиенту А потребовалось бы иметь полные сведения о типах медиа, которые он не может обрабатывать с тем, чтобы не «запутываться» при приеме дополнительной информации медиа; и (c) передача на этапе 8 медиа, которые в любом случае не могут быть обработаны PoC-клиентом А, является неэкономной, особенно для большого объема медиа, передаваемого по радиосвязи.

Теперь более полно будет описано, как PoC-клиент А публикует на PoC-сервер S подробности его установочных параметров запрета передачи медиа (этапы 1 и 2 выше). Вариант осуществления настоящего изобретения предлагает, чтобы PoC-клиент А использовал сообщение PUBLISH протокола SIP для информирования PoC-сервера S о типах медиа, которые он хотел бы запретить. Один способ состоял бы в том, чтобы выразить запрет в терминах медиа, которые поддерживаются, причем остальные рассматриваются запрещенными. Вариант осуществления настоящего изобретения может быть основан либо на явном способе запрещения, где запрещенные медиа выражены явно, либо на неявном способе запрещения, когда медиа, которые не являются запрещенными, выражены в сообщении PUBLISH протокола SIP (или подобном), либо на комбинации.

Во-первых, PoC-клиент А создает сообщение PUBLISH протокола SIP, содержащее основную часть SDP вместе с информацией запрещения. Запрещенные типы медиа либо выражены явно в виде перечня запрещенных медиа, либо неявно в виде перечня незапрещенных медиа, либо комбинацией.

Во-вторых, сообщение PUBLISH протокола SIP посылается на пользовательский PoC-сервер S.

В-третьих, PoC-сервер S возвращает подтверждение 200 OK, если принимает сообщение, и хранит информацию запрета передачи для использования в реагировании на входящие сеансы для этого пользователя.

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

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

Теперь будут представлены дополнительные подробности установки сеанса, когда оконечная сторона использует запрет медиа.

PoC-сервер S на завершающей стороне PoC-сеанса называется функцией (PF) участия. PF действует на основании пользовательских установочных параметров завершающей стороны, чтобы запрещать или допускать различные типы медиа, используемые в сеансе PoC.

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

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

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

Хотя вариант осуществления настоящего изобретения описан выше относительно PoC, понятно, что изобретение не ограничивается PoC. Термин услуга «полудуплексной связи», используется в документе, чтобы обозначать услуги вида «переносной радиостанции». Они являются услугами, которые дают возможность двум или нескольким пользователям соединяться вместе быстро для обмена речевыми пакетами. Услуги полудуплексной связи отличаются от обычных речевых вызовов в том, что эти услуги дают возможность только одному лицу говорить в данный момент времени. Чтобы разговаривать, пользователи должны иметь управление ресурсом передачи «правом голоса». Управление обычно осуществляют согласно тому, что некоторый пользователь отпускает кнопку ведения разговора, чтобы освободить управление ресурсом передачи, и другой пользователь нажимает кнопку ведения разговора, чтобы получить управление ресурсом передачи. Должно быть понято, что термин «полудуплексная связь», используемый в прилагаемой формуле изобретения, не предназначен, чтобы подразумевать использование какого-либо конкретного протокола.

Также должно быть понято, что объем настоящего изобретения не ограничивается передачей разговорных или речевых данных в сеансе разговора, и прилагаемая формула изобретения должна толковаться охватывающей передачу данных любого типа в сеансе передачи данных, включающем в себя, но не ограниченном речевыми данными. Как таковая терминология, такая как «запрос передачи речевого пакета» и «речевой пакет» не должны интерпретироваться в качестве ограниченных только разговорными, то есть речевыми данными, но используется для согласованности с терминологией PoC 1; такие фразы могут включать в рамках их смысла передачу данных любого типа. В PoC 2 может использоваться другая терминология для понятий, которые непосредственно соответствуют таковым в PoC 1; например, взамен могут использоваться фразы «запрос передачи пакета медиа» и «пакет медиа».

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

1. Способ связи в системе полудуплексной связи поверх сотовой радиосвязи (РоС), содержащий:прием сообщения от второго терминала (Клиент В), приглашающего первый терминал (Клиент А) установить сеанс РоС;направление (5) сообщения на первый терминал (Клиент А), если надлежит, отличающийся тем, чтополученное сообщение содержит перечень типов медиа, которые второй терминал (Клиент В) может посылать на первый терминал (Клиент А) в течение сеанса РоС;дополнительно отличающийся тем, что содержитприем (1) информации предпочтений типов медиа, указывающей для одного или каждого типа, по меньшей мере, из одного типа медиа в каком условии, если имеется, первый терминал (Клиент А) будет принимать этот тип медиа в сеансе РоС;пересмотр перечня с ссылкой на информацию предпочтений типов медиа, чтобы он не включал какие-либо типы медиа, которые первый терминал (Клиент А) не будет принимать от второго терминала (Клиент В), иэтап пересылки, пересылку (5) на первый терминал (Клиент А) сообщения с пересмотренным перечнем, если надлежит;при этом по меньшей мере некоторая из информации получена (1) от первого терминала в сообщении PUBLISH(публиковать) протокола инициирования сеанса; ипри этом по меньшей мере некоторая информация получена от внешнего РоС XML сервера управления документами (ES) в форме документа на языке разметки гипертекста (XML).

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

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

4. Способ по п.3, содержащий установку сеанса на основании типов медиа, подтвержденных в ответном сообщении в качестве приемлемых.

5. Способ по п.3, в котором ответное сообщение является сообщением 200 OK протокола инициирования сеанса.

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

7. Способ по п.6, содержащий подтверждение сообщения PUBLISH с помощью сообщения 200 OK протокола инициирования сеанса.

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

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

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

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

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