ПОЛЬЗОВАТЕЛЬСКОЕ ОБОРУДОВАНИЕ, СПОСОБ И СИСТЕМА ДЛЯ УПРАВЛЕНИЯ ОДНОВРЕМЕННЫМ СЕАНСОМ СВЯЗИ Российский патент 2010 года по МПК H04W4/10 H04W80/10 H04M3/56 H04L29/06 

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

[1] Настоящее изобретение относится к сеансам связи на основе услуг подсистемы передачи мультимедийных сообщений на базе протоколов Интернет «IMS» и, в частности, к абонентскому оборудованию (пользовательскому оборудованию) «UE», способу и системе для управления одновременными сеансами связи, для таких услуг, как услуга многоточечной полудуплексной связи («Push-to-Talk»/«Haжми и Говори») подвижной радиотелефонной связи сотовой связи (далее «РоС» услуга).

Известный уровень техники

[2] В документе RFC 3261 рабочей группы по стандартам сети Интернет (IETF) способы работы «SIP» серверов (серверов, реализующих протокол установления сеанса связи «SIP»), например «РоС-сервера» (сервера, поддерживающего «РоС»-услугу), можно разделить, в общем, на способ «SIP-прокси» (с использованием сервера представителя) и способ двустороннего пользовательского агента «B2BUA».

[3] На фиг.1 и 2 представлены блок-схемы алгоритмов для объяснения соответственно способа «B2BUA» и способа «SIP-прокси» в соответствии с известными техническими решениями.

[4] Как показано на фиг.1, в режиме работы по способу «B2BUA» данные протокола реального времени «RTP», данные протокола управления в реальном масштабе времени «RTCP» и данные протокола управления передачей пользовательской информации «ТВСР», а также «Приоритет РоС-сеанса», которые передаются и принимаются между «РоС-клиентом» (клиентом, пользующимся «РоС» услугой) и управляющим «РоС-сервером В» (сервером, выполняющим управляющую функцию), всегда должны проходить через принимающий участие «РоС-сервер А» (сервер, выполняющий функцию участия). Аналогичным образом, как показано на фиг.2, в режиме работы «SIP-прокси» «SIP-сообщения», передаваемые и принимаемые между «РоС-клиентом» и управляющим «РоС-сервером В», всегда проходят через принимающий участие «РоС-сервер А». Однако в режиме «SIP-прокси» данные протокола реального времени «RTP», данные протокола управления в реальном масштабе времени «RTCP» и данные протокола управления передачей пользовательской информации «ТВСР» не проходят через принимающий участие «РоС-сервер А», но передаются и принимаются напрямую между «РоС-клиентом» и управляющим «РоС-сервером В».

[5] Как таковые, режим «SIP-прокси» и режим «B2BUA» отличаются друг от друга в зависимости от того, проходят ли данные протокола реального времени «RTP», данные протокола управления в реальном масштабе времени «RTCP» и данные протокола управления передачей пользовательской информации «ТВСР» через принимающий участие «РоС-сервер А». То есть, как показано на фиг.1, когда принимающий участие «РоС-сервер А» работает в режиме двустороннего пользовательского агента «B2BUA», данные протокола реального времени «RTP», данные протокола управления в реальном масштабе времени «RTCP» и данные протокола управления передачей пользовательской информации «ТВСР», которые передаются и принимаются по каналу между «РоС-клиентом» и управляющим «РоС-сервером В», всегда проходят через принимающий участие «РоС-сервер А». Однако, как показано на фиг.2, когда принимающий участие «РоС-сервер А» работает в режиме «SIP-прокси», данные протокола реального времени «RTP», данные протокола управления в реальном масштабе времени «RTCP» и данные протокола управления передачей пользовательской информации «ТВСР», передаваемые и принимаемые по каналу между «РоС-клиентом» и управляющим «РоС-сервером В», не проходят через принимающий участие «РоС-сервер А». «РоС-сервер А», работающий в режиме «SIP-прокси» в соответствии с известным техническим решением, не может и не принимает данные протокола реального времени «RTP», данные протокола управления в реальном масштабе времени «RTCP» и данные протокола управления передачей пользовательской информации «ТВСР» от «РоС-клиента» или управляющего «РоС сервера В» и, соответственно, не может управлять этими данными. Однако имеются ситуации, когда такое управление необходимо.

[6] Как известно, «РоС-сервер» может выполнять и «РоС-функцию» управления, и «РоС-функцию» участия. «РоС-функция» управления «РоС-сервера» осуществляет централизованную обработку сеанса связи с оказанием «РоС-услуги» (далее «РоС-сеанса»), включая распределение информации протокола реального времени «RTP», управление передачей пользовательской информации («Talk Burst»), совершенствование правил для участвующих в групповом сеансе, управление информацией участников и т.п. «РоС-функция» участия «РоС-сервера» обеспечивает совершенствование правил РоС-сеансов входящих вызовов и обработки РоС-сеансов для ретрансляции управляющего сообщения о передаче пользовательской информации между «РоС-клиентом» и «РоС-сервером», выполняющим «РоС-функцию» управления. «РоС-функция» участия может ретранслировать информацию протокола реального времени «RTP» по каналу между «РоС-клиентом» и «РоС-сервером», выполняющим «РоС-функцию» управления.

[7] «РоС-функция» участия «РоС-сервера» (например, «РоС-сервера А») может поддерживать (способна обеспечить) «одновременный РоС-сеанс» для «РоС-клиента». В настоящем описании «одновременный РоС-сеанс» представляет собой сеанс связи, во время которого «РоС-сервер» выполняет функцию приоритета сеанса многоточечной полудуплексной связи подвижной радиотелефонной связи сотовой связи (далее функция «Приоритет РоС-сеанса») или функцию блокировки многоточечной полудуплексной связи подвижной радиотелефонной связи сотовой связи (далее «Блокировка РоС»). Функция «Приоритет РоС-сеанса» для «РоС-сервера» предоставляет приоритет конкретному «РоС-сеансу» для «РоС-клиента», инициализировавшего или принявшего приглашения на множество «РоС-сеансов». Функция «Блокировка РоС» для «РоС-сервера» позволяет выполнять передачу мультимедийных данных, связанных только с конкретным «РоС-сеансом» для «РоС-клиента», и одновременно блокирует передачу мультимедийных данных, связанных с другими сеансами связи. Можно сказать, что таким способом при одновременном «РоС-сеансе» можно осуществлять фильтрацию определенных данных (например, множество данных протокола реального времени «RTP») с целью предоставления только одного блока данных протокола реального времени «RTP», например соответствующего заблокированного сеанса или основного сеанса. Некоторые «РоС-серверы» и «РоС-клиенты» могут поддерживать одновременный «РоС-сеанс», тогда как другие «РоС-серверы» и «РоС-клиенты» могут не поддерживать одновременный «РоС-сеанс».

[8] В качестве примера, предположим, что имеются «РоС-клиент» и «РоС-сервер», которые поддерживают и выполняют одновременный «РоС-сеанс». В соответствии с функцией приоритета «РоС-сеанса» «РоС-клиент» устанавливает только один «РоС-сеанс» как основной сеанс связи, а другие «РоС-сеансы» - как дополнительные сеансы связи. Предпочтительно значение приоритета такого «РоС-сеанса» передается от «РоС-клиента» на «РоС-сервер», который выполняет «РоС-функцию» участия (например, принимающий участие «РоС-сервер А»), используя сообщения «ПРИГЛАШЕНИЕ» («INVITE»), «ПОВТОРНОЕ ПРИГЛАШЕНИЕ» («RE-INVITE») или «ОБНОВЛЕНИЕ» («UPDATE»).

[9] После установки значения приоритета «РоС-сеанса» «РоС-сервер», выполняющий функцию участия («РоС-сервер А»), передает данные «РоС-клиенту» на основе установленного значения приоритета «РоС-сеанса». В частности, если один «РоС-сеанс» устанавливается как основной сеанс связи, то, когда принимаются мультимедийные данные этого основного «РоС-сеанса», в то время как «РоС-сервер» принимает мультимедийные данные дополнительных «РоС-сеансов», «РоС-клиент» под управлением «РоС-сервера А» может немедленно принять мультимедийные данные основного «РоС-сеанса» вдобавок к мультимедийным данным дополнительных «РоС-сеансов». То есть в соответствии с приоритетом сеанса связи, установленным «РоС-клиентом», «РоС-сервер А» может избирательно передавать (передавать или не передавать) мультимедийные данные, связанные с каждым «РоС-сеансом», «РоС-клиенту» в определенном приоритетном порядке.

[10] С другой стороны, в соответствии с функцией «Блокировка РоС» «РоС-клиент» устанавливает «блокировка» (должен быть блокирован) для одного из «РоС-сеансов» и, следовательно, может принимать мультимедийные данные, связанные только с этим заблокированным «РоС-сеансом», в то время как он не принимает мультимедийные данные, связанные с другими «РоС-сеансами», от «РоС-сервера А» (сервера, выполняющего функцию участия). Таким способом функция блокировки блокирует мультимедийные данные определенных «РоС-сеансов». Предпочтительно значение блокировки «РоС-сеанса» передается от «РоС-клиента» в «РоС-сервер А», используя сообщения «ПРИГЛАШЕНИЕ» («INVITE»), «ПОВТОРНОЕ ПРИГЛАШЕНИЕ» («RE-INVITE») или «ОБНОВЛЕНИЕ» («UPDATE»), и устанавливается в «РоС-сервере А». После установки значения блокировки «РоС-сеанса» «РоС-сервер А» определяет, следует ли передавать мультимедийные данные «РоС-клиенту» в зависимости от установленного значения блокировки «РоС-сеанса», и в соответствии с результатами определения избирательно передает (передает или не передает) мультимедийные данные «РоС-клиенту».

[11] Таким образом, чтобы выполнить одновременный «РоС-сеанс» (например, функцию «Приоритет РоС-сеанса», функцию «Блокировка РоС» и т.д.) для «РоС-услуги», как это показано на фиг.1, мультимедийные данные, в том числе данные протокола реального времени «RTP», данные протокола управления в реальном масштабе времени «RTCP», данные протокола управления передачей пользовательской информации «ТВСР» и т.д., должны проходить через «РоС-сервер А» (выполняющий функцию участия), когда происходит обмен данными между «РоС-клиентом» и управляющим «РоС-сервером В» (выполняющим функцию управления), поскольку «РоС-сервер А» должен управлять потоком данных в соответствии с функцией «Блокировка РоС» или функцией «Приоритет РоС-сеанса». Например, «РоС-серверу А», выполняющему «РоС-функцию» участия, необходимо принять данные протокола реального времени «RTP» (например, мультимедийные данные, такие как голосовые данные, видео и т.п.), которые были переданы для «РоС-клиента» с управляющего «РоС-сервера В», выполняющего «РоС-функцию» управления, в ходе передачи соответствующих данных, так чтобы «РоС-сервер А» мог определить, следует ли передавать принятые данные протокола реального времени «RTP» «РоС-клиенту», чтобы применить функцию «Блокировка РоС» или функцию «Приоритет РоС-сеанса».

[12] Другими словами, для осуществления одновременного «РоС-сеанса» «РоС-сервер А», выполняющий «РоС-функцию» участия, должен всегда работать в режиме «B2BUA» (но не в режиме «SIP-прокси»), так чтобы обеспечить прохождение всех мультимедийных данных через «РоС-сервер», выполняющий «РоС-функцию» участия. Однако в одновременном «РоС-сеансе» в соответствии с известным техническим решением этот «РоС-сервер» может работать или в режиме «B2BUA», или в режиме «SIP-прокси» и он не знает, поддерживает ли «РоС-клиент» одновременный «РоС-сеанс». Когда «РоС-сервер», выполняющий «РоС-функцию» участия, при предоставлении услуги одновременного «РоС-сеанса» не работает в режиме B2BUA, но работает в режиме «SIP прокси», могут возникнуть следующие проблемы.

[13] При предоставлении услуги одновременного «РоС-сеанса», если один «РоС-клиент» участвует в нескольких «РоС-сеансах», этот «РоС-клиент» устанавливает функцию «Блокировка РоС» для одного конкретного РоС-сеанса и, следовательно, может послать запрос на «РоС-сервер», выполняющий «РоС-функцию» участия, на передачу мультимедийных данных, связанных только с зафиксированным РоС-сеансом, через зафиксированный РоС-сеанс. Однако в этом случае если «РоС-сервер» работает в режиме «SIP-прокси», то мультимедийные данные, отправляемые этим «РоС-сервером», выполняющим «РоС-функцию» управления, отправляются непосредственно «РоС-клиенту» без прохождения через «РоС-сервер», выполняющий «РоС-функцию» участия. Соответственно, «РоС-сервер», выполняющий «РоС-функцию» участия, не может применять функцию «Блокировка РоС», запрошенную «РоС-клиентом». Аналогичные проблемы существуют при применении функции «Приоритет РоС-сеанса» для одновременного «РоС-сеанса».

[14] Кроме того, когда и «РоС-клиент», и «РоС-сервер» поддерживают одновременный «РоС-сеанс», на пути мультимедийных данных (например, между «РоС-клиентом» и управляющим «РоС-сервером», выполняющим «РоС-функцию» управления) может существовать «РоС-сервер», выполняющий «РоС-функцию» участия и, следовательно, выполняющий функцию ретрансляции принимаемых мультимедийных данных и затем передачи принятых мультимедийных данных. Однако в соответствии с известным техническим решением «РоС-сервер», выполняющий «РоС-функцию» участия, не может распознать, поддерживает ли «РоС-клиент» одновременный «РоС-сеанс». Соответственно, «РоС-сервер», выполняющий «РоС-функцию» участия, может не знать максимальное число одновременных сеансов, поддерживаемых каждым «РоС-клиентом» и поэтому не может надлежащим образом иметь дело с настройками «РоС-сеансов», запрашиваемыми «РоС-клиентом».

[15] Кроме того, при управлении работой одновременного сеанса (или аналогичной операцией) такие же проблемы могут возникать и в IР-услугах (на основе Интернет-протокола) всех других типов (например, услугах на основе сообщений протокола установления сеанса связи «SIP»).

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

Техническая проблема

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

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

[18] Еще одной целью настоящего изобретения является предложить технологию предоставления информации по настройке поддержки одновременных сеансов с помощью «IP-сообщений» для всех «IР-услуг» (например, для услуг с использованием протокола реального времени «RTP»), таких как «VoIP» (передача голосового трафика по IP-сетям), видеотелефония, обслуживание многоточечной полудуплексной связи подвижной радиотелефонной связи сотовой связи («РТ» - Push-To), в том числе «РоС-услуги», служба передачи мультимедийных сообщений (MMS), службы коротких сообщений (SMS), мгновенных сообщений (IM), немедленных сообщений и т.д.

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

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

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

[21] В соответствии с одним аспектом настоящего изобретения указанное определенное сообщение означает сообщение протокола установления сеанса связи «SIP-сообщение», например сообщение «ПУБЛИКАЦИЯ» («PUBLISH»), сообщение «ПРИГЛАШЕНИЕ» («INVITE»), «ОБНОВЛЕНИЕ» («UPDATE»), «ПРЕДПИСАНИЕ» («REFER»), «ПАРАМЕТРЫ» («OPTIONS») и т.п.

[22] В соответствии с другим аспектом настоящего изобретения устройство управления одновременными сеансами может содержать: клиентское оборудование, предназначенное для передачи информации о поддержке одновременных сеансов от него на сервер посредством определенного сообщения; и сервер, предназначенный для определения режима работы для предоставления конкретной услуги на основе переданной информации о поддержке одновременного сеанса.

[23] В соответствии с еще одним аспектом настоящего изобретения предложено пользовательское устройство «UE», содержащее: контроллер, чтобы определять, поддерживает ли устройство пользователя одновременный сеанс связи, чтобы генерировать информацию о настройке поддержки одновременного сеанса (далее информация о настройке «SSS») в соответствии с полученным результатом и чтобы отправить информацию о настройке «SSS» в домашнюю сеть пользовательского устройства.

[24] В соответствии с еще одним аспектом настоящего изобретения предложен сервер, содержащий: контроллер, чтобы определить на основе «SIP-сообщения» - сообщения протокола установления сеанса связи «SIP» от пользовательского устройства, поддерживает ли пользовательское устройство «UE» одновременный сеанс связи, чтобы определить, поддерживает ли сервер одновременный сеанс связи, и для установки на основе полученных результатов режима работы сеанса связи сервера для одновременного сеанса связи пользовательского устройства «UE».

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

[26] В соответствии с очередным аспектом настоящего изобретения предложен способ управления одновременными сеансами, включающий в себя следующие шаги: определение пользовательским устройством «UE», поддерживает ли это пользовательское устройство «UE» одновременный сеанс связи; генерирование информации о настройке поддержки одновременных сеансов «SSS» (информация о настройке «SSS») в соответствии с полученным результатом; и отправка сообщения протокола установления сеанса связи «SIP-сообщение» в домашнюю сеть пользовательского устройства «UE».

[27] В соответствии с очередным аспектом настоящего изобретения предложен способ управления одновременными сеансами, включающий в себя следующие шаги: определение сервером на основе сообщения протокола установления сеанса связи «SIP» («SIP-сообщение») от пользовательского устройства «UE», поддерживает ли пользовательское устройство «UE» одновременный сеанс связи; определение сервером, поддерживает ли этот сервер одновременный сеанс связи; и установка на основе полученных результатов рабочего режима сеанса связи сервера для одновременного сеанса пользовательского устройства «UE».

[28] В соответствии с очередным аспектом настоящего изобретения предложен способ управления одновременными сеансами для системы, содержащей пользовательское устройство «UE» и сервер в домашней сети пользовательского устройства «UE», включающий в себя следующие шаги: передача сообщения протокола установления сеанса связи «SIP» («SIP-сообщение»), содержащего информацию о настройке пользовательской информации (информация о настройке «SSS»), связанную с пользовательским устройством «UE», от пользовательского устройства «UE» в домашнюю сеть; сохранение полученной информации о настройке SSS на сервере и установка рабочего режима сеанса связи сервера для одновременного сеанса связи пользовательского устройства «UE» частично на основе информации о настройке «SSS».

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

Описание чертежей

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

[31] На чертежах:

[32] фиг.1 иллюстрирует концепцию режима «B2BUA» в соответствии с известным техническим решением;

[33] фиг.2 иллюстрирует концепцию режима «SIP-прокси» в соответствии с известным техническим решением;

[34] фиг.3 иллюстрирует систему управления одновременными сеансами в соответствии с вариантом осуществления настоящего изобретения;

[35] фиг 4 иллюстрирует процедуру «SIP-регистрации» и публикации значения настроек «РоС-услуги», применяемую в системе фиг.3, в соответствии с вариантом осуществления настоящего изобретения;

[36] на фиг.5 представлена блок-схема, иллюстрирующая пример способа управления одновременными сеансами «РоС-услуги» в соответствии с вариантом осуществления настоящего изобретения; и

[37] на фиг.6 представлена блок-схема, иллюстрирующая другой пример способа управления одновременными сеансами «РоС-услуги» в соответствии с вариантом осуществления настоящего изобретения.

Примеры осуществления изобретения

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

[39] В настоящем изобретении предлагается способ управления сеансами связи клиента (или пользовательского устройства) после того, как сервер определит рабочий режим на основе информации клиента о поддержке сеансов связи в услуге на основе сеанса связи, в котором клиент поддерживает услугу одновременных сеансов и централизованный сервер управляет услугой одновременных сеансов клиента. Например, одной из услуг на основе сеанса связи может считаться «РоС-услуга». В настоящем изобретении, когда клиент регистрирует себя в сервере или запрашивает от сервера настройки сеанса связи, клиент сообщает серверу его информацию поддержки одновременных сеансов связи (также называемую здесь информацией о настройке поддержки одновременных сеансов связи), и, следовательно, сервер определяет соответствующий рабочий режим (например, режим «B2BUA» или «SIP-прокси») в соответствии с принятой информацией о настройке поддержки одновременных сеансов, так чтобы управлять параметрами сеанса связи клиента.

[40] Настоящее изобретение предназначено, чтобы полностью охватить и спланировать услуги, предназначенные для предоставления быстрого обмена данными для поставщиков услуг и потребителей. Услуги, к которым применимо настоящее изобретение, представляют собой услуги по передаче информации, в которых пользовательское устройство передает мультимедийные данные на одно или несколько других пользовательских устройств. Такими услугами могут быть все IP-услуги (например, все виды передачи данных через домен IP-пакетов), включая услуги передачи сообщений или обмена данными на основе протокола установления сеанса связи «SIP» («SIP-сообщение»), в состав которых входят, но этим список не ограничивается: «VoIP» (передача голосового трафика по IP-сетям), видеотелефония, «РТ-услуги», электронная почта, служба передачи мультимедийных сообщений (MMS), службы коротких сообщений (SMS), службы мгновенных сообщений (IM), немедленных сообщений и т.п. «РТ-услугами» могут быть услуга многоточечной полудуплексной телефонной связи «РТТ», предназначенная для передачи голосовых (аудио) данных, например «РоС-услуга», услуга многоточечной полудуплексной видеосвязи «PTV», предназначенная для передачи движущихся изображений (видео данных) и услуга многоточечной полудуплексной связи для передачи данных «PTD», предназначенная для передачи данных. Настоящее изобретение охватывает также оба вида услуг, для которых необходимо управление доступом к общим ресурсам в многосторонних Интернет-конференциях (на основе протокола управления передачей пользовательской информации «ТВСР»), и услуг, для которых такое управление (на основе протокола «ТВСР») не требуется.

[41] «РТ услуга» («push to» - услуга многоточечной полудуплексной связи), предназначенная для обеспечения быстрого обмена данными для поставщиков услуг и пользователей мобильной(ых) сети(ей), представляет собой услугу по передаче информации, при которой один клиент передает мультимедийные данные (пользовательская информация - «talk burst») другому клиенту или нескольким клиентам, с которым(и) установлен сеанс связи. «РТ-услуга» обеспечивает связь с одним получателем информации (один - с одним) или между группами получателей информации, как в сеансе групповой конференции (от одного - к нескольким), в ней для установления сеанса применяется протокол установления сеанса связи «SIP». «РТ-услуга» обычно включает в себя выбор конкретным клиентом одного или более клиентов, чтобы пригласить их на «РТ-сеанс», подключение канала связи для данного сеанса между этим конкретным клиентом, приглашающим на «РТ-сеанс», и приглашенным(и) клиентом(ами) и передача или прием данных по каналу связи между клиентами, на основе установленного сеанса связи.

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

[43] Как уже упоминалось, настоящее изобретение применимо ко всем услугам на основе протокола «IР» или услугам по передаче сообщений и обмену информацией на основе протокола установления сеанса связи «SIP». Соответственно, ниже обсуждаются система и способ управления одновременными сеансами согласно настоящему изобретению для всех таких услуг, а также в качестве примера - система и способ управления одновременными сеансами в соответствии с настоящим изобретением для «РоС-услуги».

[44] Фиг.3 иллюстрирует систему управления одновременными сеансами в соответствии с примером осуществления настоящего изобретения.

[45] Как показано на фиг.3, система управления одновременными сеансами может содержать «UE» - пользовательское устройство (или клиентское устройство) 100 (например, «РоС-клиент»), чтобы передавать информацию о поддержке одновременных сеансов для какого-либо одновременного сеанса на сервер через определенное сообщение, и сервер 300 (например, «РоС-сервер», выполняющий функцию участия), чтобы принимать информацию о поддержке одновременных сеансов от пользовательского устройства 100 через сеть или интерфейс 200, например ядро «SIP/IP». Затем сервер 300 определяет рабочий режим, в котором сервер 300 будет предоставлять услуги на основе сеанса связи в зависимости от принятой информации о поддержке одновременных сеансов связи и в зависимости от того, поддерживает ли сам сервер 300 одновременный сеанс связи. Сервер 300 хранит информацию, указывающую, поддерживает ли сам сервер 300 одновременный сеанс связи (например, одновременный «РоС-сеанс»). И пользовательское устройство 100, и сервер 300 содержат контроллер или процессор (120 или 320) и другие известные компоненты. Все компоненты системы управления одновременными сеансами связи согласно настоящему изобретению в рабочем состоянии соединены. Сеть или интерфейс 200 и сервер 300 могут формировать домашнюю сеть пользовательского устройства 100.

[46] Пользовательское устройство 100 (например, контроллер 120) передает информацию о поддержке одновременного сеанса на сервер 300 посредством включения ее в заголовок или тело «SIP-сообщения» после регистрации его информации на сервере или запроса настроек сеанса связи от сервера. В предпочтительном варианте информации о поддержке одновременных сеансов может быть присвоено как активное значение, так и неактивное значение. Предпочтительно «SIP-сообщение», содержащее информацию о поддержке одновременного сеанса связи, содержит, но этим не ограничивается весь список, запрос «ПУБЛИКАЦИЯ» («PUBLISH»), сообщение «ПРИГЛАШЕНИЕ» («INVITE»), «ОБНОВЛЕНИЕ» («UPDATE»), «ПРЕДПИСАНИЕ» («REFER»), «ПАРАМЕТРЫ» («OPTIONS») и т.п. Это известные «SIP-сообщения».

[47] На фиг.4 показана процедура «SIP» регистрации и публикации значения настроек «РоС-услуги», применяемая в системе, показанной на фиг.3, и особенности системы, показанной на фиг.3, при применении изобретения к «РТ-услуге» или «РТ-системе» (например, «РоС-услуге»/«РоС-системе»). Например, «РТ-система» фиг.4 содержит пользовательское устройство «РоС-клиент» 10, ядро «SIP/IP» 20 и «РоС-сервер» (выполняющий «РоС-функцию» участия), все в рабочем состоянии соединенные друг с другом. Ядро «SIP/IP» 20 и сервер 30 формируют домашнюю сеть клиентского устройства 10. Компоненты 10, 20 и 30 фиг.4 являются примерами соответственно пользовательского устройства 100, сети 200 и сервера 300 фиг.3.

[48] Как показано на фиг.4, в соответствии с настоящим изобретением «РоС-клиент» 10 запрашивает от ядра «SIP/1P» 20, например «IMS» - подсистема передачи мультимедийных сообщений на базе протоколов Интернет, регистрацию его информации через сообщение «РЕГИСТРАЦИЯ» («REGISTER»), чтобы принимать «РоС-услугу», и ядро «SIP/lP» 20 отправляет сообщение 200 «В Норме» («ОК») «РоС-клиенту» 10, чтобы предоставить регистрацию.

[49] Здесь, если «РоС-клиент» 10 поддерживает одновременный «РоС-сеанс», РоС-клиент 10 должен сообщить домашней «РоС-сети» свою информацию «SSS» о поддержке одновременных «РоС-сеансов» (также называемую здесь информацией о настройке «SSS»). Предпочтительно информация «SSS» может быть активного или неактивного типа (иметь соответствующее значение). Для активного типа установлены значения «ВЕРНО» или «НЕВЕРНО» («1» или «0»). Информация «SSS» показывает, поддерживает ли «РоС-клиент» 10 одновременный «РоС-сеанс», являющийся сеансом связи, который поддерживает «РоС-функцию» приоритета сеанса связи или «РоС-функцию» блокировки. Например, если информация «SSS» указывает на активный тип (т.е значение «ВЕРНО» или «1»), это означает, что «РоС-клиент» 10 поддерживает одновременный «РоС-сеанс», тогда как если информация «SSS» указывает на неактивный тип (т.е значение «НЕВЕРНО» или «0»), это означает, что «РоС-клиент» 10 не поддерживает одновременный «РоС-сеанс».

[50] От «РоС-клиента» 10 информация о поддержке одновременных сеансов «SSS» отправляется на ядро «SIP/IP» 20 вместе с информацией о возможностях и информацией о предпочтениях «РоС-пользователя» с помощью сообщения запроса «ПУБЛИКАЦИЯ» («PUBLISH»). Предпочтительно информация «SSS» передается в заголовке или теле «SIP-сообщения», например запроса «ПУБЛИКАЦИЯ» («PUBLISH»). Затем сообщение запроса «ПУБЛИКАЦИЯ» («PUBLISH») (или «SIP-сообщение») передается из ядра «SIP/IP» 20 на «РоС-сервер» 30. Если домашняя «РоС-сеть» поддерживает одновременный «РоС-сеанс», «РоС-сервер» 30 в домашней «РоС-сети» должен хранить информацию «SSS», предоставляемую от «РоС-клиента» 10 через ядро «SIP/IP» 20. Здесь «РоС-сервер» 30 является сервером, выполняющим «РоС-функцию» участия, например домашним «РоС-сервером» «РоС-клиента» 10.

[51] Таким образом, «РоС-сервер» 30 отправляет сообщение 200 «В НОРМЕ» («ОК») на ядро «SIP/IP» 20 и после этого сохраняет в нем принятую информацию «SSS» вместе с информацией о возможностях и информацией о предпочтениях «РоС-пользователя». Как вариант, «РоС-сервер» 30 может сохранить информацию «SSS» и затем (или одновременно) отправить сообщение 200 «В НОРМЕ» («ОК») в ответ на сообщение «ПУБЛИКАЦИЯ» («PUBLISH»).

[52] «РоС-клиент» 10, если необходимо, при получении сообщения 200 «В НОРМЕ» («ОК») от ядра «SIP/IP» 20 выполняет процедуру настройки «РоС-сеанса».

[53] Таким способом, как показано на фиг.4, «РоС-сервер» 30 может принимать от «РоС-клиента» 10 информацию о поддержке одновременного сеанса связи «SSS» «РоС-клиента» 10 посредством «SIP-сообщения», например сообщения «ПУБЛИКАЦИЯ» («PUBLISH»). После приема информации о поддержке одновременного сеанса связи «SSS» «РоС-сервер» 30 может эффективно выполнять управление соответствующими одновременными «РоС-сеансами» в соответствии с принятой информацией о поддержке одновременных сеансов «SSS».

[54] Фиг.5 иллюстрирует способ управления одновременными сеансами для «РоС-сервера» в соответствии с примером осуществления настоящего изобретения. Этот способ применяется в системах, показанных на фиг.3 или 4, или может применяться в других подходящих системах или устройствах. Например, для выполнения шагов способа могут использоваться контроллеры 120 и 320 или 12 и 32.

[55] Как показано на фиг.5, в «IMS» - подсистеме передачи мультимедийных сообщений на базе протоколов Интернет «РоС-клиент» (например, «РоС-клиент» 10) регистрирует свою информацию в домашней «РоС-сети», чтобы принимать «РоС-услугу» (S10). То есть «РоС-клиент» регистрирует свою информацию в ядре «SIP/IP» (например, ядре «SIP/IP» 20), таком как подсистема «IMS», используя сообщение «РЕГИСТРАЦИЯ» («REGISTER»). Информация «SSS» (информация о настройке «SSS») «РоС-клиента» также передается от «РоС-клиента» «РоС-серверу» для выполнения «РоС-функции» участия (например, серверу 30) через ядро «SIP/IP», используя сообщение «ПУБЛИКАЦИЯ» («PUBLISH»).

[56] То есть, если «РоС-клиент» поддерживает одновременный «РоС-сеанс», «РоС-клиент» уведомляет домашнюю «РоС-сеть» об информации «SSS» о поддержке одновременного «РоС-сеанса», которая показывает, что «РоС-клиент» поддерживает одновременный «РоС-сеанс». Информация «SSS» отправляется вместе со значением настройки «РоС-услуги», например информацией о возможностях и информацией о предпочтениях «РоС-пользователя», посредством «SIP-сообщения», например сообщения «ПУБЛИКАЦИЯ» («PUBLISH»), и может иметь значение активного типа или неактивного типа. Информация о поддержке одновременного сеанса «SSS» также передается с помощью включения ее в заголовок или тело «SIP-сообщения».

[57] В таблице 1 приведен пример информации о поддержке одновременных сеансов «SSS», передаваемой «РоС-клиентом» через тело «SIP-сообщения». Здесь если значение параметра «client_ss_supported», указывающего информацию «SSS», имеет значение «ВЕРНО» («true»), это показывает, что «РоС-клиент» поддерживает одновременный «РоС-сеанс», а если значение «НЕВЕРНО» («false») - это показывает, что РоС-клиент не поддерживает одновременный «РоС-сеанс». Возможны и другие примеры.

[58] [Таблица 1]

[59]

ТЕЛО XML ММ   С= <?xml version='1.0' encoding='UTF-8'?>       <poc-settings xmlns='urn:oma:params ”xml'ns”poc”poc-settings' xmlns:xsi=http://www. http://w3.org/2001/XMLSchema-instance'' xsi:schemaLocation='urn:oma:params:xml:ns:poc:poc-settings'> <isb-settings> <incoming-session-barring active='false'>   </isb-settings>   <am-settings>   <answer-mode>automatic</answer-mode>   </am-settings>   <ipab-settings>   <incoming-prsonal-alert-barring active='false'/>   </ipab-settings>   <client-ss-settings>   <client_ss_supported>true</client_ss_supported>   </client-ss-settings>   </poc-settings>

[60] Соответственно, если домашний «РоС-клиент» поддерживает одновременный «РоС-сеанс», «РоС-сервер», выполняющий «РоС-функцию» участия в домашней «РоС-сети», сохраняет информацию о возможностях, информацию о предпочтениях «РоС-пользователя» и информацию «SSS», поставляемую «РоС-клиентом».

[61] После сохранения на РоС-сервере (например, сервере, выполняющем функцию «РоС-участия») информации о возможностях, информации о предпочтениях «РоС-пользователя» и информации о поддержке одновременного сеанса «SSS» (например, если «РоС-клиент» принимает сообщение 200 «В НОРМЕ» («ОК») через ядро «SIP/IP», как показано на фиг.4) «РоС-клиент» отправляет сообщение «ПРИГЛАШЕНИЕ» («INVITE») на «РоС-сервер», чтобы запросить настройку «РоС-сеанса» (S11). Здесь «РоС-сервер» может сохранить информацию «SSS» перед тем, как он передаст, или после того, как он передал сообщение 200 «В НОРМЕ» («ОК»).

[62] После приема сообщения «ПРИГЛАШЕНИЕ» («INVITE») от «РоС-клиента» «РоС-сервер» проверяет, имеет ли информация «SSS», например параметр «client_ss_supported», передаваемая «РоС-клиентом» с помощью сообщения «ПУБЛИКАЦИЯ» («PUBLISH»), значение активного состояния (т.е. «ВЕРНО») (S12), и далее на основе информации «SSS» определяет, поддерживает ли «РоС-клиент» одновременный «РоС-сеанс», на основе информации «SSS».

[63] Если значение параметра «client_ss_supported» (информация «SSS») представляет собой значение «ВЕРНО» (т.е. активен), «РоС-сервер», выполняющий «РоС-функцию» участия, определяет, что «РоС-клиент», отправивший сообщение «ПРИГЛАШЕНИЕ» («INVITE»), поддерживает одновременный «РоС-сеанс». «РоС-сервер» также проверяет, поддерживает ли сам «РоС-сервер» одновременный «РоС-сеанс», например, путем проверки ранее сохраненной информации. Если он определяет, что «РоС-клиент» и РоС-сервер» поддерживают этот одновременный «РоС-сеанс», «РоС-сервер», выполняющий «РоС-функцию» участия, принимает решение работать в режиме «B2BUA» (S13), так что «РоС-сервер» может управлять потоком данных, как это необходимо для одновременного «РоС-сеанса». То есть в этом случае «РоС-сервер» работает всегда в режиме «B2BUSA» независимо от образа действий оператора.

[64] С другой стороны, если значение параметра «client_ss_supported» представляет собой значение «НЕВЕРНО» (или неактивное состояние), «РоС-сервер», выполняющий «РоС-функцию» участия, определяет, что «РоС-клиент», отправивший сообщение «ПРИГЛАШЕНИЕ» («INVITE»), не поддерживает одновременный «РоС-сеанс» и, следовательно, работает в режиме «B2BUA» или «SIP-прокси» в зависимости от образа действий оператора (S14). Как правило, в этом случае «РоС-сервер» работает в режиме «SIP-прокси». Если определяется, что «РоС-клиент» поддерживает одновременный «РоС-сеанс», но «РоС-сервер» не поддерживает одновременный «РоС-сеанс», то выполняется шаг S14.

[65] После выполнения шага S13, чтобы обработать запрос настроек «РоС-сеанса» от «РоС-клиента», «РоС-сервер», выполняющий «РоС-функцию» участия, может определить, превышает ли число сеансов связи, в которых участвует «РоС-клиент», отправивший сообщение «ПРИГЛАШЕНИЕ» («INVITE»), максимально допустимое количество одновременных «РоС-сеансов» (S15). Максимально допустимое число одновременно доступных «РоС-сеансов» может быть применено к каждому «РоС-клиенту».

[66] В другом способе «РоС-сервер», выполняющий «РоС-функцию» участия, может применять максимальное количество одновременных сеансов связи, которое назначается на основе класса абонента, чтобы определить, превышает ли число сеансов, в которых участвует «РоС-клиент», отправивший сообщение «ПРИГЛАШЕНИЕ» («INVITE»), максимальное допустимое количество одновременных «РоС-сеансов».

[67] Если число сеансов, в которых принимает участие «РоС-клиент», не превышает максимально допустимое число одновременных «РоС-сеансов», «РоС-сервер» выполняет настройку «РоС-сеанса» (S16). В ином случае «РоС-сервер» прекращает настройку «РоС-сеанса» (S17) и затем уведомляет «РоС-клиента» об этой информации. Здесь значение, указывающее максимальное допустимое количество одновременных «РоС-сеансов», может быть предварительно выделено «РоС-серверу».

[68] Вдобавок, вместо этих ограничений, «РоС-сервер», выполняющий «РоС-функцию» участия, может считать, что «РоС-клиент» не поддерживает одновременные «РоС-сеансы», если значение «client_ss_supported» не включено в тело «SIP сообщения», а именно в тело «XML МIМЕ», тогда как «РоС-сервер» может считать, что «РоС-клиент» поддерживает одновременный сеанс, если параметр «client_ss_supported» имеет значение «ВЕРНО».

[69] Фиг.6 иллюстрирует другой пример способа управления одновременными сеансами для «РоС-сервера» в соответствии с настоящим изобретением. Этот способ применяется в системе, показанной на фиг.3 или 4, и может применяться в других подходящих системах или устройствах.

Например, для выполнения шагов способа могут использоваться контроллеры 120 и 320 или 12 и 32.

[70] В примере фиг.6 «РоС-клиент» отправляет информацию о поддержке одновременных сеансов «SSS», в которой не используется сообщение «ПУБЛИКАЦИЯ» («PUBLISH»), но используется сообщение «ПРИГЛАШЕНИЕ» («INVITE»).

[71] Как показано на фиг.6, когда «РоС-клиент» отправляет сообщение «ПРИГЛАШЕНИЕ» («INVITE») на «РоС-сервер», выполняющий «РоС-функцию» участия, этот «РоС-клиент» отправляет информацию «SSS» (информацию о настройке «SSS») на «РоС-сервер» посредством включения ее в заголовок или тело сообщения «ПРИГЛАШЕНИЕ» («INVITE») (S20). В таблице 2, приведенной ниже, показан пример информации «SSS», содержащейся в теле «SIP-сообщения», в частности, протокола описания сеанса связи «SDP», при передаче данных от «РоС-клиента» на «РоС-сервер».

[72] То есть «РоС-клиент» устанавливает значение параметра «client_ss_supported» (информация «SSS») равным логической единице (т.е. «client_ss_supported=1») и включает данную информацию «SSS» в параметр протокола описания сеанса связи «SDP» (а). Если для параметра «client_ss_supported» устанавливается значение «0», это указывает на то, что «РоС-клиент» не поддерживает одновременный «РоС-сеанс».

[73] [Таблица 2]

[74]

SDP-ПАРАМЕТРЫ   С= IN IP6 57777::eee:fff:aaa:bbb m= audio 57787 RTP/AVP 97 А= rtpmap:97 AMR А= rtcp:57000 m= application 57790 udp TBCP А= fmtp:TBCP quening=l;tb_priority=2   timestamp=1;client_ss_supported=1

[75] После приема от РоС-клиента сообщения «ПРИГЛАШЕНИЕ» («INVITE»), содержащего информацию «SSS», «РоС-сервер», выполняющий «РоС-функцию» участия, проверяет, логическое значение параметра «client_ss_supported», содержащееся в сообщении «ПРИГЛАШЕНИЕ» («INVITE»), представляет собой значение «1» или «0» (S21), и, соответственно, определяет, поддерживает ли «РоС-клиент» одновременный «РоС-сеанс».

[76] То есть если логическое значение параметра «client_ss_supported» равно «1» (активное состояние), то «РоС-сервер» определяет, что «РоС-клиент», отправивший сообщение «ПРИГЛАШЕНИЕ» («INVITE»), поддерживает одновременный «РоС-сеанс», и проверяет, поддерживает ли сам «РоС-сервер» одновременный «РоС-сеанс». Если и «РоС-клиент», и «РоС-сервер» поддерживают одновременный «РоС-сеанс», «РоС-сервер», выполняющий функцию участия, принимает решение работать в режиме «B2BUA» (S22).

[77] Если логическое значение параметра «client_ss_supported» равно «0» (неактивное состояние), «РоС-сервер», выполняющий «РоС-функцию» участия, определяет, что «РоС-клиент», отправивший сообщение «ПРИГЛАШЕНИЕ» («INVITE»), не поддерживает одновременный «РоС-сеанс», и работает в режиме «B2BUA» или «SIP-прокси» в зависимости от образа действия оператора (S23). Если сам «РоС-сервер» не поддерживает одновременный «РоС-сеанс» (даже если «РоС-клиент» может поддерживать), выполняется шаг S23.

[78] После выполнения шага S22 «РоС-сервер», выполняющий «РоС-функцию» участия, может использовать максимальное допустимое число одновременных сеансов связи, которое обычно может быть применено ко всем «РоС-клиентам», чтобы определить, превышает ли число сеансов, используемых «РоС-клиентом», отправившим сообщение «ПРИГЛАШЕНИЕ» («INVITE»), максимально допустимое число одновременных «РоС-сеансов» (S24).

[79] В соответствии с другим способом «РоС-сервер», выполняющий РоС-функцию участия, может применять максимальное число одновременных сеансов связи, назначенных в зависимости от класса абонента, чтобы определить, превышает ли число одновременных сеансов, используемых «РоС-клиентом», отправившим сообщение «ПРИГЛАШЕНИЕ» («INVITE»), максимально допустимое число одновременных «РоС-сеансов».

[80] Если число сеансов, используемых «РоС-клиентом», не превышает максимально допустимое число одновременных «РоС-сеансов», «РоС-сервер» выполняет настройку «РоС-сеанса» (S25). В ином случае «РоС-сервер» прекращает запрошенную настройку «РоС-сеанса» (S26) и затем уведомляет «РоС-клиента» об этой информации. Шаги S22-26 идентичны или подобны соответственно шагам S13-S17 на фиг.5.

[81] Кроме того, в примере на фиг.6 настоящего изобретения «РоС-сервер», выполняющий «РоС-функцию» участия, может считать, что «РоС-клиент» не поддерживает одновременный «РоС-сеанс», если значение «client_ss_supported» не включено в тело «SIP-сообщения», например в параметр протокола описания сеанса связи «SDP». Если логическое значение «client_ss_supported» равно «1» (активен), «РоС-сервер», выполняющий «РоС-функцию» участия, может рассматривать, что «РоС-клиент» поддерживает одновременный РоС-сеанс.

[82] В соответствии с настоящим изобретением, когда способы, показанные на фиг.4-6, применяются ко всей системе услуг на основе протокола «IР», показанной на фиг.3, соответствующие пользовательское устройство «UE» или клиентское устройство и сервер в системе услуг на основе протокола «IР» соответствуют соответственно «РоС-клиенту» и «РоС-серверу», выполняющему «РоС-функцию» участия на фиг.4-6, при этом пользовательское устройство или клиентское устройство отправляет сообщение (например, «SIP-сообщение»), содержащее информацию (информацию о настройке «SSS»), указывающую, поддерживает ли пользовательское устройство или клиентское устройство услугу одновременных «РоС-сеансов». В этом отношении фраза «информация о настройке SSS» в настоящем изобретении не ограничена информацией о настройке поддержки одновременных «РоС-сеансов», но содержит информацию о настройке поддержки одновременных РоС-сеансов, применимую к любой услуге на основе протокола «IР». То есть настоящее изобретение равным образом и полностью может использоваться, охватывать или применяться к таким услугам, как «VoIP» (передача голосового трафика по IP-сетям), видеотелефония, «РТ-услуги», электронная почта, служба передачи мультимедийных сообщений (MMS), служба коротких сообщений (SMS), служба мгновенных сообщений (IM), немедленных сообщений и т.п.

[83] В соответствии с настоящим изобретением пользовательским устройством или клиентским устройством может быть мобильный терминал, но не ограничивается им. Например, пользовательским устройством или клиентским устройством (например, «РТ-клиентом» или «РоС-клиентом») могут быть, но этим список не ограничивается, мобильный телефон (мобильная станция) для сетей GSM или тому подобное устройство, «PDA» («карманный» компьютер), мобильные терминалы различного типа, подключенные через беспроводную локальную сеть (WLAN) или другую сеть и т.д.

[84] Способ (способы) по настоящему изобретению может быть частично реализован с помощью существующих компьютерных языков программирования. Такая компьютерная программа (программы) может быть сохранена в портативной или в памяти другого типа или в запоминающих устройствах, таких как жесткий диск, ОЗУ, ПЗУ, ППЗУ и т.д., связанных с одним или более компьютерами и устройствами на базе компьютеров, такими как сервер 300 и/или пользовательское устройство и клиентское устройство 100. В альтернативном варианте такая компьютерная программа (программы) может сохраняться в различных носителях записи, таких как USB-устройства, магнитные диски, оптические диски, магнитооптические диски и т.д. Такая компьютерная программа (программы) может быть в форме сигнала, распространяющегося через сети Интернет, экстранет, интранет или другие сети, и доставляться в устройство назначения (например, сервер 300, или пользовательское устройство, или клиентское устройство 100) для сохранения и использования. Компьютерные программы могут считываться с использованием известных компьютеров или устройств на основе компьютеров.

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

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

Изобретение относится к сеансам связи на основе услуг подсистемы передачи мультимедийных сообщений на базе протоколов Интернет «IMS» и, в частности, к системе для управления одновременными сеансами связи, для таких услуг, как услуга многоточечной полудуплексной связи («Push-to-Таlk»/«Нажми и Говори») подвижной радиотелефонной связи сотовой связи («РоС» услуга). Техническим результатом является повышение эффективности определения максимального числа одновременных сеансов, поддерживаемых каждым «РоС-клиентом», и обеспечение надлежащих настроек «РоС-сеансов», запрашиваемых «РоС-клиентом». Указанный технический результат достигается тем, что система связи включает пользовательское оборудование «UE», чтобы передать сообщение протокола установления сеанса связи - «SIP-сообщение», включающее информацию о настройке поддержки одновременных сеансов связи «SSS», связанную с пользовательским устройством «UE», в домашнюю сеть, включающую в себя сервер; и указанный сервер, чтобы хранить в нем информацию о настройке поддержки одновременных сеансов связи «SSS» и чтобы устанавливать режим работы сеанса связи сервера для одновременного сеанса связи пользовательского устройства «UE» на основе, частично, информации о настройке поддержки одновременных сеансов связи «SSS». 3 н. и 8 з.п. ф-лы, 6 ил.

1. Способ обработки данных, поступающих по линии связи, на основе сеансов связи, выполняемый мобильным терминалом, содержащий:
передачу сообщения серверу сети, чтобы информировать, поддерживает ли этот мобильный терминал одновременные РТ-сеансы связи (полудуплексная радиотелефонная связь - Push-to); и
прием от сети ответа с подтверждением приема указанного сообщения, информирующего, поддерживает ли этот терминал одновременные РТ-сеансы связи,
при этом указанное сообщение дает возможность сети определить, работать ли в режиме двустороннего пользовательского агента «B2BUA» или в режиме «SIP-прокси» (протокол инициации сеанса связи с использованием посредника),
при этом указанное сообщение представляет собой сообщение публикации «PUBLISH», и
причем указанное сообщение включает в себя значение, установленное как активное, для указания, что мобильный терминал поддерживает одновременные РТ-сеансы связи, или значение установленное как не активное, для указания, что терминал не поддерживает одновременные РТ-сеансы связи.

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

3. Способ по п.1, дополнительно содержащий выполнение с сетью одного или нескольких РТ-сеансов связи в соответствии с режимом двустороннего пользовательского агента «B2BUA», если оба и мобильный терминал, и сеть поддерживают одновременные РТ-сеансы связи.

4. Мобильный терминал для обработки данных, поступающих по линии связи, на основе сеансов связи, содержащий: контроллер, чтобы управлять связью на основе сеансов связи с сетью; передающее устройство, работающее совместно с указанным контроллером, чтобы передавать серверу сети сообщение, чтобы сообщить поддерживает ли этот мобильный терминал одновременные РТ-сеансы связи (полудуплексная радиотелефонная связь - Push-to), и принимающее устройство, работающее совместно с указанным контроллером, чтобы принять от сети ответ с подтверждением приема этого сообщения, информирующего, поддерживает ли терминал одновременные РТ-сеансы связи, при этом указанное сообщение дает сети возможность определить, работать ли в режиме двустороннего пользовательского агента «B2BUA» или в режиме «SIP-прокси» (протокол инициации сеанса связи с использованием посредника), при этом указанное сообщение представляет собой сообщение публикации «PUBLISH», и причем указанное сообщение публикации «PUBLISH» включает в себя установку значения - активное для указания, что мобильный терминал поддерживает одновременные РТ-сеансы связи, или установку значения - не активное для указания, что терминал не поддерживает одновременные РТ-сеансы связи.

5. Мобильный терминал по п.4, в котором значение, установленное как активное, указывает, что мобильный терминал может обрабатывать одновременно больше, чем один РТ-сеанс связи, а значение, установленное как не активное, указывает, что терминал не может обрабатывать одновременно более чем один РТ-сеанс связи.

6. Мобильный терминал по п.4, в котором указанное передающее устройство дополнительно взаимодействует с указанным управляющим устройством для выполнения с сетью одного или нескольких РТ-сеансов связи в соответствии с режимом двустороннего пользовательского агента «B2BUA», если оба и мобильный терминал, и сеть поддерживают одновременные РТ-сеансы связи.

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

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

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

10. Способ по п.7, в котором сервер и мобильный терминал передают сообщения друг другу, используя, по крайней мере, один из протоколов:
транспортный протокол реального времени «RTP», протокол управления в реальном масштабе времени «RTCP» и протокол управления передачей пользовательской информации «ТВСР».

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