RU2414099C2 - Установление "рт-сеанса связи" с использованием "рт-блока" - Google Patents

Установление "рт-сеанса связи" с использованием "рт-блока" Download PDF

Info

Publication number
RU2414099C2
RU2414099C2 RU2008131819/09A RU2008131819A RU2414099C2 RU 2414099 C2 RU2414099 C2 RU 2414099C2 RU 2008131819/09 A RU2008131819/09 A RU 2008131819/09A RU 2008131819 A RU2008131819 A RU 2008131819A RU 2414099 C2 RU2414099 C2 RU 2414099C2
Authority
RU
Russia
Prior art keywords
box
sip
client
message
server
Prior art date
Application number
RU2008131819/09A
Other languages
English (en)
Other versions
RU2008131819A (ru
Inventor
Канн-Сок ХО (KR)
Канн-Сок ХО
Сон-Му СОН (KR)
Сон-Му СОН
Чжэ-Сын СОН (KR)
Чжэ-Сын СОН
Original Assignee
Эл Джи Электроникс Инк.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Эл Джи Электроникс Инк. filed Critical Эл Джи Электроникс Инк.
Publication of RU2008131819A publication Critical patent/RU2008131819A/ru
Application granted granted Critical
Publication of RU2414099C2 publication Critical patent/RU2414099C2/ru

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00Data switching networks
    • H04L12/66Arrangements for connecting between networks having differing types of switching systems, e.g. gateways
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/40Support for services or applications
    • H04L65/4061Push-to services, e.g. push-to-talk or push-to-video
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00Data switching networks
    • H04L12/28Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066Session management
    • H04L65/1101Session protocols
    • H04L65/1104Session initiation protocol [SIP]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W76/00Connection management
    • H04W76/40Connection management for selective distribution or broadcast
    • H04W76/45Connection management for selective distribution or broadcast for Push-to-Talk [PTT] or Push-to-Talk over cellular [PoC] services
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/10Architectures or entities
    • H04L65/1016IP multimedia subsystem [IMS]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W4/00Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/06Selective distribution of broadcast services, e.g. multimedia broadcast multicast service [MBMS]; Services to user groups; One-way selective calling services
    • H04W4/10Push-to-Talk [PTT] or Push-On-Call services

Abstract

Изобретение относится к системам связи и, в частности, к способу и терминалу для установления сеанса многоточечной полудуплексной связи (РТ-сеанс) (Push to "Нажми, чтобы…") в услуге на основе протокола установления сеанса связи (SIP). Техническим результатом является создание способа использования услуги (РТ-ящика), когда конкретный терминал не способен выполнить регистрацию или не зарегистрирован в Ядре SIP/IP (информационной системе IMS) и параметры настройки услуги многоточечной полудуплексной связи (РТ-услуга) не могут быть переданы на сервер РТ-услуги (РТ-сервер) из-за отключения питания терминала. Указанный технический результат достигается тем, что осуществляют прием РТ-сервером из терминала клиента, поддерживающего РТ-услугу (РТ-терминал), приглашающего сообщения протокола SIP, чтобы инициировать сеанс связи, для, как минимум, одного из целевых РТ-терминалов; направление РТ-сервером сообщения с запросом серверу РТ XDMS (сервер РТ-услуги связи с управлением базой данных на основе расширяемого языка разметки (XML)), для того, чтобы проверить набор правил критериев доступа к РТ-ящику; прием РТ-сервером от сервера «РТ XDMS» ответного сообщения в ответ на сообщение с запросом; при этом ответное сообщение содержит набор правил критериев доступа к РТ-ящику для, по крайней мере, одного целевого РТ-терминала. 10 з.п ф-лы, 11 ил.

Description

Сущность изобретения
Техническое решение
[1] Настоящее изобретение относится к услуге на основе сеанса связи и к способу и терминалу для установления сеанса многоточечной полудуплексной связи - «РТ-сеанс» (Push to = "Нажми, чтобы…") в услуге на основе протокола установления сеанса связи «SIP», что позволяет конкретному терминалу использовать услугу «РТ-блока» - «почтового ящика» полудуплексной связи, далее «РТ-ящик», под управлением сервера для услуги «РТ», далее «РТ-сервер».
[2] В беспроводной связи протокол установления сеанса связи «SIP» означает протокол сигнализации, который определяет процедуру, в которой терминалы, желающие установить связь, идентифицируют друг друга и находят свое местоположение и устанавливают, отменяют или изменяют мультимедийные сеансы связи между собой. Услуги, основанные на протоколе установления сеанса связи «SIP (т.е. услуги на основе «SIP»), имеют структуру типа «запрос/ответ» для управления генерированием, изменением и завершением мультимедийных сеансов связи. Кроме того, обслуживание на основе протокола установления сеанса связи «SIP» предоставляет услуги с использованием унифицированного указателя ресурса «URL» протокола «SIP», который аналогичен адресу электронной почты безотносительно к «IP-адресам» (адресам Интернет-протокола), что позволяет идентифицировать каждого пользователя.
[3] Услуга многоточечной полудуплексной связи, далее «РТ-услуга» ("Нажми, и"), может быть одной из услуг в сеансе связи на основе протокола установления сеанса связи «SIP». «РТ-услуга» предназначена для обеспечения быстрого соединения между поставщиками услуг (провайдерами) и пользователями подвижной связи. Кроме того, «РТ-услуга» является услугой полудуплексной связи, т.е. услугой связи, в которой один клиент передает мультимедийные данные (например, речевой пакет или мультимедийный пакет) одному или нескольким другим клиентам, с которыми был установлен сеанс связи. «РТ-услуга» может быть в основном «РоС-услугой» (услугой «push to talk over cellular» - «нажмите и говорите через сеть сотовой связи»), предназначенной для обслуживания вызовов с передачей речевых данных, «PTV-услугой» (push to view - «нажмите и смотрите»), предназначенной для передачи движущегося изображения (видеоданных), или «PTD-услугой» (push to data - «нажмите и передавайте данные»), предназначенной для передачи данных.
[4] «РТ-услуга» может предоставлять определенному клиентскому терминалу связь с одним собеседником (один с одним/«1-с-1») или между группами собеседников, как в групповом чате (один со многими), и может для установления сеанса связи использовать протокол установления сеанса связи «SIP».
[5] Обычно услуга «РТ-ящика» может относиться к услуге, аналогичной голосовому почтовому ящику в услуге подвижной связи.
[6] На Фиг.1 представлена блок-схема прохождения сигналов, иллюстрирующая способ использования услуги «РТ-ящика».
[7] На Фиг.1 «РТ-клиент А» (клиент, пользующийся «РТ-услугой») может быть любым конкретным терминалом (или абонентским устройством «UE», пользующимся «РТ-услугой»), под которым понимается устройство (объект) для обработки сообщений протокола установления сеанса связи «SIP». Все сообщения, показанные на Фиг.1, являются также сообщениями на основе протокола «SIP».
[8] Для использования услуги «РТ-ящика» должны быть выполнены несколько предварительных условий, а именно конкретный терминал должен быть зарегистрирован в ядре, поддерживающем протокол «SIP»/«IP» (протокол установления сеанса связи «SIP» / Интернет-протокол «IP»), далее «Ядро SIP/IP», а в «РТ-сервере» (сервере, поддерживающем «РТ-услугу») должны быть получены и/или реализованы параметры настройки «РТ-услуги».
[9] Как показано на Фиг.1, «РТ-клиент А» 15 может зарегистрироваться в «Ядре SIP/IP A» 20 (например, 3GPP IMS или 3GPP2 MMD), используя сообщение протокола установления сеанса связи, далее «SIP-сообщение», «REGISTER» (ЗАРЕГИСТРИРОВАТЬ) (S1). «Ядро SIP/IP A» 20 может передать «РТ-клиенту А» 15 «SIP-сообщение» с подтверждением - «SIP 200 OK» с целью проинформировать его о том, что «РТ-клиент А» 15 успешно зарегистрирован в «Ядре SIP/IP A» 20 (S2).
[10] «РТ-клиент А» 15 может передать установленные значения, требуемые для «РТ-услуги» (т.е. параметры настройки «РТ-услуги»), «РТ-серверу А» 30 через «Ядро SIP/IP A» 20, используя «SIP-сообщение» «PUBLISH» («ПУБЛИКАЦИЯ»). Здесь параметры настройки «РТ-услуги» могут включать, например, режим ответа, флаг ограничения (запрета) входящего сеанса связи, флаг ограничения (запрета) мгновенного персонального предупреждения, флаг одновременной поддержки и т.п. (S3 и S4). Настройка «РТ-услуги» может быть отправлена путем включения ее в тело или в поле «SIP-сообщения» «PUBLISH».
[11] «РТ-сервер А» 30 может сохранить у себя параметры настройки «РТ-услуги» (S5). «РТ-сервер А» 30 может также информировать «РТ-клиента А» 15, используя «SIP-сообщение» с подтверждением «SIP 200 OK» о том, что параметры настройки «РТ-услуги» были успешно сохранены (S6 и S7). Здесь на шагах S6 и S7 сообщение «SIP 200 OK» может быть отправлено «РТ-сервером А» 30 «РТ-клиенту А» 15 через «Ядро SIP/IP A» 20.
[12] Вышеупомянутые шаги S1 и S2 могут рассматриваться как процесс «регистрации», а шаги S3-S7 могут рассматриваться как «настройка «РТ-услуги»».
[13] Однако в этом случае конкретный терминал (т.е. «РТ-клиент А» 15 на Фиг.1) может использовать услугу «РТ-ящика» только после полного выполнения процесса регистрации и передачи параметров настройки «РТ-услуги» на «РТ-сервер».
[14] Для устранения этих недостатков необходим способ использования услуги «РТ-ящика» даже тогда, когда конкретный терминал не способен выполнить регистрацию «Ядра SIP/IP» и параметры настройки «РТ-услуги» не могут быть переданы на «РТ-сервер» из-за неожиданного отключения питания конкретного терминала, или также в случае, когда конкретный терминал находится в состоянии, когда этот терминал не зарегистрирован в «Ядре SIP/IP» (информационной системе «IMS»).
[15] Один из аспектов настоящего изобретения включает понимание авторами изобретения недостатков, описанных выше. Основываясь на этом понимании, можно добиться улучшения установления «РТ» сеанса связи «РТ-услуги» на основе протокола «SIP» с целью использования услуги «РТ-ящика». Определенные особенности, которые могут быть частью способа и терминала для установления «РТ» сеанса связи «РТ-услуги» на основе протокола «SIP», не будут описываться слишком подробно просто для предотвращения усложнения понимания характеристик настоящего изобретения. Однако такие дополнительные особенности могут также быть частью способа установления «РТ» сеанса связи для услуги сеанса связи на основе протокола «SIP» с целью использования услуги «РТ-ящика», что должно быть понятно специалистам в данной области техники.
[16] Таким образом, в одном из вариантов осуществления настоящего изобретения предлагаются способ и терминал для установления «РТ» сеанса связи «РТ-услуги» на основе протокола установления сеанса связи «SIP» с целью использования услуги «РТ-ящика» даже тогда, когда конкретный терминал (или абонентское устройство «РТ-услуги») не зарегистрирован в «Ядре SIP/IP» и «РТ-сервер» не получил параметров настройки «РТ-услуги» из конкретного терминала.
[17] В другом варианте осуществления настоящего изобретения предлагается способ установления «РТ» сеанса связи, включающий в себя: прием от первого клиента сообщения с приглашением к сеансу связи, по крайней мере, для одного или нескольких целевых терминалов; проверку из определенного объекта (устройства) информации об условиях доступа к «РТ-ящику», относящейся к одному или нескольким целевым терминалам; и передачу сообщения с приглашением к сеансу связи в «РТ-ящик», если в информации об условиях доступа к «РТ-ящику» удовлетворяются условия доступа к «РТ-ящику» целевых клиентов.
[18] Здесь способ установления «РТ» сеанса связи может дополнительно включать в себя: прием из «РТ-ящика» ответного сообщения на приглашение к сеансу связи; и передачу первому клиенту ответного сообщения на приглашение к сеансу связи.
[19] В другом варианте осуществления настоящего изобретения способ установления «РТ» сеанса связи может включать в себя: передачу вторым клиентом сообщения с приглашением к сеансу связи для приглашения первого клиента; проверку «Ядром SIP/IP» информации об условиях доступа к «РТ-ящику», относящейся к первому клиенту; и использование вторым клиентом «РТ-ящика» в соответствии с заданным состоянием (настройкой) в проверенной информации об условиях доступа к «РТ-ящику».
[20] В еще одном варианте осуществления настоящего изобретения способ установления «РТ» сеанса связи может включать в себя: сохранение конкретным клиентом информации об условиях доступа к «РТ-ящику» в определенном объекте из первого сообщения; и передачу этим определенным объектом второго сообщения в ответ на первое сообщение конкретному клиенту.
[21] В еще одном варианте осуществления настоящего изобретения способ установления «РТ» сеанса связи может включать в себя способ использования «РТ-ящика», посредством которого первый клиент проверяет конкретные данные, хранящиеся в «РТ-ящике», который может включать в себя: обращение первого клиента к «РТ-ящику» через «РТ-сервер», используя «SIP-сообщение» «PUBLISH» («ПУБЛИКАЦИЯ»); передачу «РТ-ящиком» первому клиенту «SIP-сообщения» (сообщения протокола установления сеанса связи «SIP»), включающего конкретную информацию; и передачу первым клиентом «SIP-сообщения» «PUBLISH» («ПУБЛИКАЦИЯ») с использованием конкретной информации для проверки конкретных данных, хранящихся в «РТ-ящике».
[22] Предлагается также терминал, который может передать сообщение с приглашением к сеансу связи в, как минимум, один или несколько целевых терминалов, может принять сообщение с приглашением к сеансу связи из «РТ-ящика» на основе информации об условиях доступа к «РТ-ящику», относящейся к целевым терминалам, и может принимать конкретные данные из «РТ-ящика» путем установления сеанса связи с «РТ-ящиком».
[23] На Фиг.1 показана блок-схема прохождения сигналов, иллюстрирующая способ использования услуг «РТ-ящика».
[24] На Фиг.2 показана блок-схема прохождения сигнала, иллюстрирующая процедуру сохранения информации об условиях доступа к «РТ-ящику» в «РТ-сервере» с управлением базой данных на основе расширяемого языка разметки «XML», далее «РТ XDM-сервер», в «РТ-системе».
[25] На Фиг.3 показана блок-схема прохождения сигналов, иллюстрирующая способ использования «РТ-ящика», в случае, когда прямая передача «РТ-ящиком» информации об условиях доступа к ящику «РТ», хранящейся в «РТ XDM-сервере» системы «РТ», установлена на «истина» («true»).
[26] На Фиг.4 показана блок-схема прохождения сигналов, иллюстрирующая способ использования «РТ-ящика», в случае, когда прямая передача «РТ-ящиком» информации об условиях доступа к «РТ-ящику», хранящейся в «РТ XDM-сервере» системы «РТ», установлена на «ложь» («false»).
[27] На Фиг.5 показана блок-схема прохождения сигналов, иллюстрирующая процедуру сохранения информации об условиях доступа к «РТ-ящику» в «РТ-ящике» системы «РТ».
[28] На Фиг.6 показана блок-схема прохождения сигналов, иллюстрирующая способ использования «РТ-ящика», в случае, когда прямая передача «РТ-ящиком» информации об условиях доступа к «РТ-ящику», хранящейся в «РТ-ящике» системы «РТ», установлена на «истина» («true»).
[29] На Фиг.7 показана блок-схема прохождения сигналов, иллюстрирующая способ использования «РТ-ящика», в случае, когда прямая передача «РТ-ящиком» информации об условиях доступа к «РТ-ящику», хранящейся в «РТ-ящике» системы «РТ», установлена на «ложь» («false»).
[30] На Фиг.8 показана блок-схема прохождения сигналов, иллюстрирующая процедуру сохранения информации об условиях доступа к «РТ-ящику» в домашнем сервере абонентских данных (HSS) «Ядра SIP/IP» в системе «РТ».
[31] На Фиг.9 показана блок-схема прохождения сигналов, иллюстрирующая способ использования «РТ-ящика», в случае, когда прямая передача «РТ-ящиком» информации об условиях доступа к «РТ-ящику», хранящейся в «Ядре SIP/IP» системы «РТ», установлена на «истина» («true»).
[32] На Фиг.10 показана блок-схема прохождения сигналов, иллюстрирующая способ использования «РТ-ящика», в случае, когда прямая передача «РТ-ящиком» информации об условиях доступа к «РТ-ящику», хранящейся в «Ядре SIP/IP» системы «РТ», установлена на «ложь» («false»).
[33] На Фиг.11 показана блок-схема прохождения сигналов, иллюстрирующая процедуру уведомления «РТ-ящика».
[34] Далее будет приведено описание конструкции и операций согласно предпочтительным вариантам осуществления настоящего изобретения со ссылками на прилагаемые чертежи.
[35] В настоящем описании изобретения в случае, когда партнерский (целевой) терминал (или абонентское устройство, пользующееся «РТ-услугой») не был зарегистрирован в «Ядре SIP/IP» (т.е. находится в состоянии не зарегистрирован в «Ядре SIP/IP») и «РТ-сервер» не принимал сообщение «Настройка «РТ-услуги» из партнерского терминала, применяется следующее, а именно: во-первых, партнерский терминал может хранить информацию, относящуюся к использованию «РТ-ящика» (т.е. информацию об условиях доступа к «РТ-ящику»), в определенном объекте (например, в «РТ XDM-сервере», «РТ-ящике» или «Ядре SIP/IP»); во-вторых, конкретный терминал запрашивает информацию об условиях доступа к «РТ-ящику», относящуюся к партнерскому терминалу, когда партнерский терминал приглашается этим конкретным терминалом к сеансу связи «РТ»; в-третьих, этот определенный терминал может хранить данные (например, речевой пакет или мультимедийный пакет) в «РТ-ящике» в соответствии с настройкой в информации об условиях доступа к «РТ-ящику» для партнерского терминала; и, в-четвертых, этот определенный терминал может проверить хранящиеся данные, чтобы таким образом использовать услугу «РТ-ящика».
[36] В настоящем изобретении предлагаются или рекомендуются предпочтительные варианты осуществления изобретения с первого по четвертый. Варианты осуществления настоящего изобретения с первого по третий различаются тем, какой объект (модуль) определенного «РТ-клиента» будет использоваться для хранения информации об условиях доступа к «РТ-ящику» с целью использования «РТ-ящика». Четвертый вариант осуществления настоящего изобретения может проиллюстрировать, что конкретный терминал проверяет отдельные данные, сохраненные в «РТ-ящике» партнерским терминалом.
[37] Варианты осуществления настоящего изобретения с первого по третий могут быть пояснены или рассмотрены следующим образом.
[38] Первый вариант осуществления настоящего изобретения может иллюстрировать случай, когда информация об условиях доступа к «РТ-ящику», относящаяся к конкретному «РТ-клиенту», хранится в «РТ-сервере» с управлением базой данных на основе расширяемого языка разметки «XML», (т.е. в сервере, называемом «РТ XDMS» или «РТ XDM-сервер»). Второй вариант осуществления настоящего изобретения может иллюстрировать случай, когда информация об условиях доступа к «РТ-ящику», относящаяся к конкретному «РТ-клиенту», хранится в «РТ-ящике». Третий вариант осуществления настоящего изобретения может иллюстрировать случай, когда информация об условиях доступа к «РТ-ящику», относящаяся к конкретному «РТ-клиенту», хранится в «Ядре SIP/IP» (конкретно, в домашнем сервере абонентских данных «HSS»).
[39] В вариантах осуществления настоящего изобретения с первого по третий предполагается, что «РТ-клиент В» не зарегистрирован в «Ядре SIP/IP» и «РТ-сервер» не принимал «настройку РТ-услуги». В этом случае можно говорить, что терминал «РТ-клиента В» может находиться в состоянии - не зарегистрирован в «Ядре SIP/IP», если настройка «РТ-услуги» еще не была принята от этого «РТ-клиента» или если «РТ-клиент» не выполнил регистрацию в информационной управляющей системе «IMS» (т.е. в «Ядре SIP/IP»).
[40] Далее первый вариант осуществления настоящего изобретения будет описан со ссылками на Фиг.2-4.
[41] На Фиг.2 показана блок-схема прохождения сигналов, иллюстрирующая процедуру сохранения информации об условиях доступа к «РТ-ящику» в «РТ-сервере» с управлением базой данных на основе расширяемого языка разметки «XML», («РТ XDMS») в системе многоточечной полудуплексной связи «РТ» в соответствии с первым вариантом осуществления настоящего изобретения.
[42] Как показано на Фиг.2, система, поддерживающая «РТ-услугу», может включать «XDM-клиента В» 10 (объект, поддерживающий управление базой данных на основе расширяемого языка разметки «XML»), включенного в устройство абонента «РТ-услуги» с целью обработки сообщений, относящихся к протоколу передачи гипертекста «HTTP», «Ядро SIP/IP» 20, «РТ-сервер» 30, «РТ XDM-сервер» 40 (сервер с управлением базой данных на языке «XML»), который может управлять документами на языке «XML» для «РТ-услуги», и «РТ-ящик» 50, который может хранить речевые данные (т.е. речевой пакет) и мультимедийные данные (т.е. мультимедийный пакет) для «РТ-услуги».
[43] Документы на языке «XML», управляемые «РТ XDM-сервером» 40, означают документы в формате «XML», относящиеся к правилам обращения к пользователю, например, относящиеся к таким «РТ-услугам», как группы «РТ» и правила авторизации.
[44] Как показано на Фиг.2, «XDM-клиент В» 10 может передать информацию об условиях доступа к «РТ-ящику» в «РТ XDM-сервер» 40 (S21). И информация об условиях доступа к «РТ-ящику» может быть передана от «XDM-клиента В» 10 в «РТ XDM-сервер» путем включения в тело сообщения «HTTP PUT». Здесь информация об условиях доступа к «РТ-ящику» может включать определенную информацию, требуемую для указания того, надо ли соединить (дать право доступа) третье абонентское устройство «РТ-услуги» с «РТ-ящиком», когда третье абонентское устройство «РТ-услуги» приглашает абонентское устройство «РТ-услуги» (или терминал, пользующийся «РТ-услугой») к сеансу связи «РТ» при условии, что это абонентское устройство «РТ-услуги» не зарегистрировано в «Ядре SIP/IP» 20 (например, в состоянии отключения напряжения питания абонентского устройства «РТ-услуги»). Для простоты пояснения указанная информация может называться «прямой передачей «РТ-ящиком». Если эта информация установлена на соединение третьего абонентского устройства «РТ-услуги» с «РТ-ящиком», когда абонентское устройство «РТ-услуги» не зарегистрировано в «Ядре SIP/IP» 20, то она может называться «прямая передача ящиком РТ [истина] («true»)», а в противоположном случае она может называться "прямая передача ящиком РТ [ложь] («false»)». Здесь незарегистрированное состояние абонентского устройства «РТ-услуги» в «Ядре SIP/IP» 20 может указывать на то, что «РТ-сервер» 30 не принял настройку «РТ-услуги» из этого абонентского устройства «РТ-услуги».
[45] Кроме того, информация об условиях доступа к ящику РТ может дополнительно включать информацию для идентификации того, является ли абонентское устройство «РТ-услуги» терминалом (т.е. абонентским устройством «РТ-услуги»), способным обеспечить использование услуги «РТ-ящика». Для упрощения объяснений указанная информация может называться «поддержка «РТ-ящика»». Если абонентское устройство «РТ-услуги» является терминалом, способным обеспечить использование услуги «РТ-ящика», то информация, указывающая данную способность терминала, может называться «поддержка «РТ-ящика» [истина] («true»)». С другой стороны, если абонентское устройство «РТ-услуги» является терминалом, неспособным обеспечить использование услуги «РТ-ящика», то информация, обозначающая данную способность терминала, может называться «поддержка «РТ-ящика» [ложь] («false»)». При этом настоящее изобретение может быть реализовано только путем использования информации «прямая передача «РТ-ящиком» [истина/ложь]", а не путем использования информации «поддержка «РТ-ящика»». Это обусловлено тем, что информация «прямая передача «РТ-ящиком» [истина/ложь]» является таким типом информации, который доступен только тогда, когда информация «поддержка «РТ-ящика»» имеет значение «истина». Иными словами, если терминал, используемый пользователем «РТ-услуги» (т.е. «РТ-клиент» пользователя), не поддерживает услугу «РТ-ящика» (т.е. в случае, когда «поддержка «РТ-ящика» [ложь]»), «РТ-клиент» не может передать настройку «РТ-услуги», используя информацию «прямая передача «РТ-ящиком»». Поэтому также «РТ-серверу» не требуется идентифицировать, то ли клиент «РТ-услуги» не поддерживает услугу «РТ-ящика», то ли пользователь «РТ» не желает отправить сообщение в «РТ-ящик» путем маршрутизации своего сеанса связи «РТ».
[46] С другой стороны, указанная информация, а именно «прямая передача «РТ-ящиком» [истина/ложь]» и «поддержка «РТ-ящика» [истина/ложь]», может быть параметрами или элементами, включенными в тело сообщения «HTTP PUT».
[47] «РТ XDM-сервер» 40 может хранить информацию об условиях доступа к «РТ-ящику», относящуюся к «XDM клиенту В» 10, включенную в сообщение «HTTP PUT». «РТ XDM-сервер» 40 может затем произвести прямую передачу сообщения с подтверждением «HTTP 200 OK» «XDM-клиенту В» 10, включенному в состав абонентского устройства «В» «РТ-услуги» (S20). Сообщение «HTTP 200 OK» может быть сообщением для индикации того, что информация об условиях доступа к «РТ-ящику» была успешно сохранена в «РТ XDM-сервере» 40. Информация об условиях доступа к «РТ-ящику», хранящаяся в «РТ XDM-сервере» 40, не может быть удалена, даже если «XDM-клиент В» 10 выходит из «РТ-системы» или отключается абонентское устройство «РТ-услуги». То есть, первоначально заданная информация об условиях доступа к «РТ-ящику» хранится в «РТ XDM-сервере» 40 до тех пор, пока «XDM-клиент В» 10 не изменит информацию об условиях доступа к «РТ-ящику».
[48] На Фиг.3 показана блок-схема прохождения сигналов, иллюстрирующая способ использования «РТ-ящика», в случае, когда прямая передача «РТ-ящиком» информации об условиях доступа к «РТ-ящику», хранящейся в «РТ XDM-сервере» системы «РТ», установлена на «истина» («true»).
[49] Как показано на Фиг.3, в дополнение к структуре «РТ-системы», показанной на Фиг.2, «РТ-система» может дополнительно включать в себя «РТ-клиента А» 15 и «РТ-клиента В» 11. Здесь «РТ-клиенты», которые встроены в абонентское устройство «РТ-услуги», означают средства для обработки сигналов, относящихся к маршрутизации. Таким образом, «РТ-клиент А» 15 может передать и принять сообщение протокола установления сеанса связи «SIP» через «Ядро SIP/IP» 20. «РТ-сервер» 30 может быть непосредственно соединен с «РТ XDM-сервером» 40 через интерфейс, именуемый интерфейсом «ХСАР» (например, интерфейс «HTTP»).
[50] Далее будут рассмотрены со ссылками на Фиг.3 операции в соответствии с первым вариантом осуществления настоящего изобретения.
[51] Для того чтобы пригласить «РТ-клиента В» 11 к сеансу связи «РТ», «РТ-клиент А» 15 может передать сообщение с приглашением «SIP INVITE» (которое является сообщением с приглашением к сеансу связи, отправленным путем указания адреса «РТ-клиента В» 11). Сообщение с приглашением «SIP INVITE» может быть передано (направлено) на «РТ-сервер» 30 «РТ-клиента В» 11 через «Ядро SIP/IP» 20 (S31).
[52] «РТ-сервер» 30 может принять сообщение с приглашением «SIP INVITE» (т.е. сообщение с приглашением к сеансу связи) и может проверить, была ли принята настройка «РТ-услуги» от «РТ-клиента В» 11, который является адресатом сообщения. То есть, поскольку «РТ-клиент В» 11 находится, например, в отключенном состоянии (т.е. вышел из системы) или в незарегистрированном состоянии, «РТ-сервер» 30 может убедиться, что «РТ-клиент В» 11 не может в данный момент ответить на приглашение к сеансу связи «РТ» для «РТ-клиента В» 11.
[53] Таким образом, «РТ-сервер» 30 может затребовать (или запросить) у «РТ XDM-сервера» 40 информацию об условиях доступа к «РТ-ящику», относящуюся к «РТ-клиенту В» 11, посредством сообщения «HTTP GET» (S32). «РТ XDM-сервер» 40 может передать «РТ-серверу» 30 ранее сохраненную информацию об условиях доступа к «РТ-ящику» (т.е. параметр «Прямая передача «РТ-ящиком» [истина]») для «РТ-клиента В» 11 посредством сообщения с подтверждением «HTTP 200 OK» (т.е. ответного сообщения на приглашение к сеансу связи) (S33).
[54] «РТ-сервер» 30 может проверить услугу «РТ-ящика», которую «РТ-клиент В» 11 хочет использовать, на основе информации об условиях доступа к «РТ-ящику» (т.е. параметра «Прямая передача «РТ-ящиком» [истина]») для «РТ-клиента В» 11. То есть, поскольку параметр (т.е. «Прямая передача «РТ-ящиком»») был установлен (или включен) в информацию об условиях доступа к «РТ-ящику» для «РТ-клиента В» 11, то «РТ-сервер» 30 может определить, что абонентское устройство «РТ-услуги», включающее «РТ-клиента В» 11, является терминалом, который способен использовать услугу «РТ-ящика». Кроме того, поскольку параметр «Прямая передача «РТ-ящиком»» в информации об условиях доступа к «РТ-ящику» для «РТ-клиента В» 11 был установлен на «истина», то «РТ-сервер» 30 может определить, что «РТ-клиент В» 11 был настроен на использование «РТ-ящика», даже в том случае, если «РТ-сервер» 30 не принимал настройку «РТ-услуги» от «РТ-клиента В» 11.
[55] Таким образом, на основе информации об условиях доступа к «РТ-ящику» (т.е. параметра «Прямая передача «РТ-ящиком» [истина]»), которая была установлена на Фиг.2, «РТ-сервер»30 может передать сообщение с приглашением «SIP INVITE» для приглашения «РТ-ящика» 50 «РТ-клиента В 11, так что «РТ-клиент А» 15 может сохранить речевой пакет (тип речевого почтового сообщения) или мультимедийный пакет (тип мультимедийного сообщения, такого как текст, видео и т.п.) в «РТ-ящике» 50 (S34). Сообщение с приглашением «SIP INVITE», которое адресуется «РТ-ящику» 50, пересылается из «РТ-сервера» 30 в «РТ-ящик» 50 «РТ-клиента В» 11 через «Ядро SIP/IP» 20 (S34).
[56] «РТ-ящик» 50 может передать сообщение с подтверждением «SIP 200 OK», подтверждающее прием приглашения «РТ-сервером» 30 (т.е. шага, соответствующего S34), «РТ-серверу» 30 через «Ядро SIP/IP» (S35). Затем «РТ-сервер» 30 может переслать сообщение с подтверждением «SIP 200 OK» «PT-клиенту А» 15 через «Ядро SIP/IP» 20 (S3 6). Здесь сообщение с подтверждением «SIP 200 OK» на шаге S35 может включать так называемый «индикатор РТ». «Индикатор РТ» может означать индикатор или параметр для формирования ответа «РТ-ящика» 50 «РТ-клиента В» 11 относительно приглашения к сеансу связи «РТ» от «РТ-клиента А» 15. «Индикатор РТ» может быть отправлен вместе с сообщением с подтверждением «SIP 200 OK» или путем включения в сообщение с подтверждением «SIP 200 OK». Кроме того, «индикатор РТ» может быть отправлен либо «РТ-сервером» 30, либо «РТ-ящиком» 50.
[57] «РТ-клиент А» 15 может сохранить в «РТ-ящике» 50 речевой пакет или мультимедийный пакет «РТ-клиента В» 11, который он может пожелать иметь (оставить), или же и речевой, и мультимедийный пакеты (S37).
[58] На Фиг.4 показана блок-схема прохождения сигналов, иллюстрирующая способ использования «РТ-ящик» в случае, когда параметр «Прямая передача ящиком РТ» информации об условиях доступа к «РТ-ящику», хранящейся в «РТ XDM-сервере» системы «РТ», установлен на «ложь» («false»).
[59] Как показано на Фиг.4, процесс (S31), в котором «РТ-клиент А» 15 может передать сообщение с приглашением «SIP INVITE» «РТ-клиенту В» 11, и процессы (S32 и S33), связанные с сообщением HTTP, являются такими же, как на Фиг.3. Поэтому объяснение их не повторяется, и далее будут рассматриваться только различия между вариантом осуществления на Фиг.4 и вариантом осуществления на Фиг.3.
[60] «РТ-сервер» 30 может проверить услугу «РТ-ящика», которую «РТ-клиент В» хочет использовать, на основе информации об условиях доступа к «РТ-ящику» 50 (т.е. на основе параметра «Прямая передача ящиком РТ [ложь] («false»)»), относящейся к «РТ-клиенту В» 11. То есть, поскольку данный параметр (т.е. «Прямая передача ящиком РТ») был установлен (или включен) в информацию об условиях доступа к «РТ-ящику» для «РТ-клиента В» 11, то «РТ-сервер» 30 может определить, что абонентское устройство «РТ-услуги», включающее «РТ-клиента В» 11, является терминалом, который способен обеспечить использование услуги «РТ-ящика». Однако, поскольку параметр «Прямая передача ящиком РТ» информации об условиях доступа к «РТ-ящику» для «РТ-клиента В» 11 был установлен на «ложь», то «РТ-сервер» 30 может определить, что «РТ-клиент В» 11 был настроен так, чтобы не использовать «РТ-ящик», хотя «РТ-сервер» 30 не принимал настройку «РТ-услуги» от «РТ-клиента В» 11.
[61] Следовательно, на основе информации об условиях доступа к «РТ-ящику» (т.е. параметра «Прямая передача ящиком РТ [ложь]"), которая была установлена на Фиг.2, «РТ-сервер» 30 может передать «РТ-клиенту А» 15 сообщение об отказе в отношении приглашения к сеансу связи (например, сообщение «SIP 4xx», сообщение «SIP 480 "временно недоступен"» и т.п.), так что «РТ-клиент А» 15 может не сохранять речевой пакет или мультимедийный пакет в «РТ-ящике» 50 «РТ-клиента В» 11. Сообщение об отказе «SIP 4xx» может быть передано «РТ-клиенту А» 15 через «Ядро SIP/IP» 20 (S36'').
[62] Как было указано выше применительно к первому варианту осуществления настоящего изобретения, проиллюстрированному на Фиг.2-4, приглашение «РТ-клиентом А» 15 к сеансу связи «РТ» может быть включено в «РТ-ящик» 50 только тогда, когда информация об условиях доступа к ящику РТ настроена так, как на Фиг.2, а именно, когда параметр «Прямая передача ящиком РТ» установлен на "истина". В этом случае приглашающий (т.е. «РТ-клиент А» 15) может сохранить речевой пакет или мультимедийный пакет, или оба пакета в «РТ-ящике» 50.
[63] Далее будет рассмотрен второй вариант осуществления настоящего изобретения со ссылками на Фиг.5-7. Однако части, перекрывающиеся с первым вариантом осуществления настоящего изобретения, могут быть понятны из описания, представленного со ссылками на Фиг.2-4, а второй вариант осуществления настоящего изобретения будет поясняться на основе отличий от первого варианта осуществления настоящего изобретения. Поэтому одинаковые операции и свойства на Фиг.5-7 и на Фиг.2-4 обозначаются одинаковыми справочными номерами.
[64] На Фиг.5 показана блок-схема прохождения сигналов, иллюстрирующая процедуру сохранения информации об условиях доступа к «РТ-ящику» в «РТ-ящике» «РТ-системы».
[65] По сравнению с Фиг.2 во втором варианте осуществления настоящего изобретения, проиллюстрированном на Фиг.5, информация об условиях доступа к «РТ-ящику», относящаяся к «РТ-клиенту В», может храниться в «РТ-ящике» 50 иначе, чем в «РТ XDM-сервере» 40. Сообщение «HTTP PUT» может быть адресовано «РТ-ящику» 50, а сообщение с подтверждением «HTTP 200 OK» может быть отправлено «РТ-ящиком» 50 (S21 и S22).
[66] На Фиг.6 показана блок-схема прохождения сигналов, иллюстрирующая способ использования «РТ-ящика» в случае, когда параметр «Прямая передача ящиком РТ» информации об условиях доступа к «РТ-ящику», хранящейся в «РТ-ящике» системы «РТ», установлен на «истина».
[67] Как показано на Фиг.6, «РТ-сервер» 30 может принять сообщение с приглашением «SIP INVITE» (шаг S31), с целью проверить, что настройка «РТ-услуги» не была принята от «РТ-клиента В» 11, который является адресатом сообщения. То есть, «РТ-сервер» 30 может проверить, что«РТ-клиент В» 11 не может в настоящий момент ответить на приглашение к сеансу связи «РТ».
[68] Здесь, в отличие от первого варианта осуществления изобретения на Фиг.3, в котором «РТ-сервер» 30 посредством сообщения «HTTP GET» затребует (или запрашивает) у «РТ XDM-сервера» 40 информацию об условиях доступа к «РТ-ящику» для «РТ-клиента В» 11, второй вариант осуществления согласно Фиг.6 показывает, что «РТ-сервер» 30 может передать сообщение с приглашением «SIP INVITE» в «РТ-ящик» 50 через «Ядро SIP/IP» 20 (S32). Затем «РТ-ящик» 50 может передать ранее сохраненную информацию об условиях доступа к «РТ-ящику» (т.е. параметр «Прямая передача ящиком РТ 10 [истина]») для «РТ-клиента В» 11 на «РТ-сервер» 30 посредством сообщения с подтверждением «SIP 200 OK» (S35). При сравнении первого варианта осуществления изобретения на Фиг.3 и варианта осуществления изобретения согласно Фиг.6 видно, что в отличие от первого варианта осуществления изобретения на Фиг.3, в котором шаги S32 и S33 выполняются с использованием сообщения HTTP, соответствующие шаги S32 и S35 во втором варианте осуществления на Фиг.6 могут быть выполнены с использованием сообщения протокола «SIP». Кроме того, второй вариант осуществления согласно Фиг.6 не требует выполнения шага S34. Более того, некоторые шаги (т.е. S35-S37) на Фиг.6 одинаковы с соответствующими шагами (т.е. S35-S37) на Фиг.3.
[69] На Фиг.7 показана блок-схема прохождения сигналов, иллюстрирующая способ использования «РТ-ящика» в случае, когда параметр «Прямая передача ящиком РТ» информации об условиях доступа к «РТ-ящику», хранящейся в «РТ-ящике» системы «РТ», установлен на «ложь».
[70] Как показано на Фиг.7, ряд шагов (S31'-S33'), начиная от сообщения с приглашением «SIP INVITE», одинаков с шагами, указанными на Фиг.6.
[71] Далее будут рассмотрены различия между вторым вариантом осуществления согласно Фиг.7 и первым вариантом осуществления согласно Фиг.4.
[72] «РТ-ящик» 50 может проверить услугу «РТ-ящика», которую хочет использовать «РТ-клиент В» 11, на основе информации об условиях доступа к «РТ-ящику» (то есть параметра «Прямая передача ящиком РТ [ложь]») для «РТ-клиента В» 11. Соответственно, на основе информации об условиях доступа к «РТ-ящику» (т.е. параметра «Прямая передача ящиком РТ [ложь]»), настроенной на Фиг.5, «РТ-ящик» 50 может передать сообщение об отказе «SIP 4хх» (т.е. сообщение «РТ-сервера» 30 «SIP 480 "Временно недоступен"»), информирующее об отказе от приглашения (т.е. данный процесс соответствует шагу S34) «РТ-серверу» 30 через «Ядро SIP/IP» 20 (S35'). «РТ-сервер» 30 затем может переслать сообщение об отказе «SIP 4хх» «РТ-клиенту А» 15 через «Ядро SIP/IP» 20 (S36').
[73] При сравнении второго варианта осуществления изобретения согласно Фиг.7 с первым вариантом осуществления изобретения согласно Фиг.4 видно, что второй вариант осуществления согласно Фиг.7 отличается от первого варианта осуществления изобретения на Фиг.4 тем, что сообщение от отказе «SIP 4хх» передается из «РТ-ящика» 50 на «РТ-сервер» 30 через «Ядро SIP/IP» 20 (S35'), а затем сообщение об отказе «SIP 4xx» пересылается из «РТ-сервера» 50 «РТ-клиенту А» 15 через «Ядро SIP/IP» 20 (S36').
[74] Далее будет рассмотрен третий вариант осуществления настоящего изобретения со ссылками на Фиг.8-10. Однако части, перекрывающиеся с первым вариантом осуществления настоящего изобретения, могут быть понятны из описания, представленного со ссылками на Фиг.2-4, а части, перекрывающиеся со вторым вариантом осуществления настоящего изобретения, могут быть понятны из описания, представленного со ссылками на Фиг.5-7, так что третий вариант осуществления настоящего изобретения будет рассматриваться на основе отличий от первого и второго вариантов осуществления настоящего изобретения. Поэтому одинаковые операции и особенности на Фиг.8-10 и на Фиг.2-4, 5-7 обозначаются одинаковыми ссылочными номерами.
[75] На Фиг.8 показана блок-схема прохождения сигналов, иллюстрирующая процедуру сохранения информации об условиях доступа к «РТ-ящику» в домашнем сервере абонентских данных (HSS) «Ядра SIP/IP» в системе «РТ».
[76] По сравнению с Фиг.2 в третьем варианте осуществления настоящего изобретения, проиллюстрированном на Фиг.8, информация об условиях доступа к «РТ-ящику» для «РТ-клиента В» 10 может храниться в «Ядре SIP/IP» 20, в частности в домашнем сервере абонентских данных (HSS) «Ядра SIP/IP» 20, а не в «РТ XDM-сервере» 40 (или в «РТ-ящике» 50 в случае второго варианта осуществления изобретения согласно Фиг.5). Таким образом, сообщение «HTTP PUT» может быть адресовано домашнему серверу абонентских данных (HSS) «Ядра SIP/IP» 20, а сообщение с подтверждением «HTTP 200 OK» может быть отправлено «Ядром SIP/IP» 20 (S21 и S22).
[77] На Фиг.9 показана блок-схема прохождения сигналов, иллюстрирующая способ использования «РТ-ящика», в случае, когда параметр «Прямая передача ящиком РТ» информации об условиях доступа к «РТ-ящику», хранящейся в «Ядре SIP/ IP» системы «РТ», установлен на «истина».
[78] Как показано на Фиг.9, для приглашения «РТ-клиента В» 11 к сеансу связи «РТ», «РТ-клиент А» 15 может передать сообщение с приглашением «SIP INVITE» «РТ-клиенту В» 11 (S31).
[79] «Ядро SIP/IP» 20 может принять сообщение с приглашением «SIP INVITE» (S31) и может проверить информацию об условиях доступа к «РТ-ящику», относящуюся к «РТ-клиенту В» 11, которая хранится в домашнем сервере абонентских данных (HSS). В этом случае на Фиг.8 «Ядро SIP/IP» 20 может проверить, что информация об условиях доступа к «РТ-ящику» для «РТ-клиента В» 11, была сохранена, а именно параметр «Прямая передача ящиком РТ» был установлен на «истина». Следовательно, «Ядро SIP/IP» 20 может передать сообщение с приглашением «SIP INVITE» на «РТ-сервер» 30, даже если «РТ-клиент В» 11 не был зарегистрирован в «Ядре SIP/IP» 20 (S32). Сообщение с приглашением «SIP INVITE» (шаг S32) может включать конкретную информацию, указывающую, что «РТ-клиент А» 15 должен быть подсоединен к «РТ-ящику» 50 «РТ-клиента В» 11.
[80] Более того, показанный на Фиг.9 ряд шагов (т.е. S32-S37) из ряда сообщений протокола «SIP» одинаков с соответствующими шагами, проиллюстрированными на Фиг.6 (то есть шаги S32-S37 на Фиг.6).
[81] На Фиг.10 показана блок-схема прохождения сигналов, иллюстрирующая способ использования «РТ-ящика», в случае, когда параметр «Прямая передача ящиком РТ» информации об условиях доступа к ящику РТ, хранящейся в «Ядре SIP/IP» системы «РТ», установлен на «ложь».
[82] Как показано на Фиг.10, для приглашения «РТ-клиента В» 11 к сеансу связи «РТ», «РТ-клиент А» 15 может передать сообщение с приглашением «SIP INVITE» «РТ-клиенту В» 11 (S31). «Ядро SIP/IP» 20 может принять сообщение с приглашением «SIP INVITE» (шаг S31) с целью проверить информацию об условиях доступа к «РТ-ящику» «РТ-клиента В» 11, хранящуюся в домашнем сервере абонентских данных (HSS). В этом случае «Ядро SIP/IP» 20 может проверить настройку информации об условиях доступа к «РТ-ящику» для «РТ-клиента В» 11, сохраненную в домашнем сервере абонентских данных (HSS) (т.е. не был ли параметр «Прямая передача ящиком РТ» установлен на «ложь» («false»)).
[83] На основе этой настройки информации об условиях доступа к «РТ-ящику» «РТ-клиента В» 11, если «РТ-клиент В» 11 еще не был зарегистрирован в «Ядре SIP/IP» 20 (т.е. находится в незарегистрированном состоянии в «Ядре SIP/IP» 20), «Ядро SIP/IP» 20 может определить, что приглашающий (т.е. «РТ-клиент А» 15) не будет соединен с «РТ-ящиком» 50 «РТ-клиента В» 11. Соответственно, «ядро SIP/IP» 20 может отправить «РТ-клиенту А» 15 сообщение с отказом «SIP 4хх» (т.е. сообщение «SIP 480 "Временно недоступен"») (S36').
[84] Как было указано выше, в вариантах осуществления этого изобретения с первого по третий была проиллюстрирована информация об условиях доступа к «РТ-ящику», включающая параметры (т.е. параметры «Поддержка ящика РТ» и «Прямая передача ящиком РТ»). Однако варианты осуществления изобретения с первого по третий могут быть распространены на случай, когда информация об условиях доступа к «РТ-ящику» включает только параметр «Прямая передача ящиком РТ» без параметра «Поддержка ящика РТ». Они могут быть применимы, даже если параметр «Поддержка ящика РТ» установлен на любое из значений "истина" или "ложь", при этом заданное состояние (настройка) информации об условиях доступа к «РТ-ящику» определяется в соответствии с настройкой параметра «Прямая передача ящиком РТ». То есть, если параметр «Прямая передача ящиком РТ» установлен на "истина", то «РТ-клиент А» 15 может использовать услугу «РТ-ящика». С другой стороны, если параметр «Прямая передача ящиком РТ» установлен на "ложь", то «РТ-клиент А» 15 не может использовать услугу «РТ-ящика».
[85] На Фиг.11 показана блок-схема прохождения сигналов, иллюстрирующая процедуру уведомления «РТ-ящика» в соответствии с четвертым вариантом осуществления настоящего изобретения.
[86] На Фиг.11 показана процедура, когда речевой пакет или мультимедийный пакет (или оба пакета), которые «РТ-клиент А» 15 сохранил в «РТ-ящике» 50 «РТ-клиента В» 11 в вариантах осуществления настоящего изобретения с первого по третий, проверяются «РТ-клиентом В» 11.
[87] Как показано на Фиг.11, после того, как «РТ-клиент В» 11, находящийся в незарегистрированном в «Ядре SIP/IP» 20 состоянии (не показанном на Фиг.11), регистрируется в «Ядре SIP/IP» 20, «РТ-клиент В» 11 может передать настройку «РТ-услуги» на «РТ-сервер» 30, используя сообщение о публикации «SIP PUBLISH» (S111). To есть, посредством шага S111 «РТ-сервер» 30 может определить, что «РТ-клиент В» 11 доступен для использования «РТ-услуги» (т.е. находится в доступном для «РТ-услуги» состоянии). Таким образом, «РТ-сервер» 30 может передать сообщение с подтверждением «SIP 200 OK» «РТ-клиенту В» 11 (S112). Здесь сообщение с подтверждением «SIP 200 OK» может означать успешный прием сообщения «SIP PUBLISH» на шаге S111.
[88] «РТ-сервер» 30 может передать сообщение «SIP PUBLISH» в «РТ-ящик» 50 «РТ-клиента В» 11 с целью информирования о том, что «РТ-клиент В» 11 в настоящий момент находится в доступном для «РТ-услуги» состоянии (т.е. «РТ-клиент В» 11 зарегистрирован и выполнил настройку «РТ-услуги» на Фиг.11) (S113). «РТ-ящик» 50 затем может передать сообщение с подтверждением «SIP 200 OK», информирующее об успешном приеме сообщения «SIP PUBLISH» на шаге S113, на «РТ-сервер» 30 (S114).
[89] Если имеется сохраненный для «РТ-клиента В» 11 речевой пакет или мультимедийный пакет, то «РТ-ящик» 50 может передать «SIP-сообщение» (например, сообщение «SIP MESSAGE METHOD» (СПОСОБ SIP-СООБЩЕНИЯ)), которое включает определенную информацию для разрешенного «РТ-клиента В» 11, чтобы проверить речевой пакет или мультимедийный пакет (или оба пакета), сохраненные «РТ-клиентом А» 15 (на Фиг.11 не показан) (S115). Здесь определенная информация может включать адрес «РТ-ящика» (например, унифицированный указатель ресурса «URL» ящика «РТ»), адрес позиции внутри «РТ-ящика», по которому сохранены соответствующие речевой или мультимедийный пакет (или оба пакета) (например, унифицированный указатель ресурса «URL» речевого пакета и/или унифицированный указатель ресурса «URL» мультимедийного пакета), и т.п.
[90] «РТ-клиент В» 11 может принять «SIP-сообщение» шага S115, а затем может передать сообщение с подтверждением «SIP 200 OK» в «РТ-ящик» 50 с целью проинформировать об успешном приеме этого «SIP-сообщения» (S116).
[91] «РТ-клиент В» 11 может передать сообщение с приглашением «SIP INVITE» в «РТ-ящик» 50 для того, чтобы подсоединиться к «РТ-ящику» 50, используя определенную информацию, включенную в «SIP-сообщение» (шаг S115), при этом эта определенная информация указывает адрес «РТ-ящика» и адрес позиции внутри «РТ-ящика», по которому хранятся речевой пакет или мультимедийный пакет (или они оба) (S117). В ответ на сообщение с приглашением «SIP INVITE» из шага S117 «РТ-ящик» 50 может передать сообщение с подтверждением «SIP 200 OK» «РТ-клиенту В» 11 с целью информирования об успешном приеме сообщения с приглашением «SIP INVITE» (S118).
[92] «РТ-ящик» 50 может отправить «РТ-клиенту В» 11 речевой пакет или мультимедийный пакет (или оба пакета), сохраненные для «РТ-клиента В» 11(S119).
[93] Как было описано ранее, настоящее изобретение может предложить способ и систему, которые даже в случае, если целевой «РТ-клиент» (например, «РТ-клиент В») не зарегистрирован в «Ядре SIP/IP» и «РТ-сервер» не принимал от целевого «РТ-клиента» «Настройку услуги РТ», позволяют конкретному «РТ-клиенту» (например, «РТ-клиенту А») использовать «РТ-ящик». Конкретно, настоящее изобретение предлагает способ и терминал для установления «РТ-сеанса» связи, дающие возможность конкретному терминалу (или абонентскому устройству «РТ-услуги») использовать услугу «РТ-ящика» даже в состоянии, когда конкретный терминал не зарегистрирован в «Ядре SIP/IP», а «РТ-сервер» пока не принял настройку «РТ-услуги», при этом в случае, когда партнерский терминал (или абонентское устройство «РТ-услуги») не зарегистрирован в «Ядре SIP/IP» (т.е. находится в незарегистрированном в «Ядре SIP/IP» состоянии) и «РТ-сервер» не принимал «настройку услуги РТ» от партнерского терминала, применяется следующее, а именно, во-первых, партнерский терминал сохраняет информацию, относящуюся к использованию «РТ-ящика» (т.е. информацию об условиях доступа к «РТ-ящику») в конкретном объекте (например, «РТ-сервере» с управлением базой данных на основе расширяемого языка разметки «XML» - «РТ XDM-сервер», «РТ-ящике» или «Ядре SIP/IP»), во-вторых, когда определенный терминал приглашает этот партнерский терминал к «РТ-сеансу» связи, он запрашивает информацию об условиях доступа к «РТ-ящику», относящуюся к партнерскому терминалу, в-третьих, этот определенный терминал сохраняет данные (например, речевой пакет или мультимедийный пакет) в «РТ-ящике» в соответствии с настройкой информации об условиях доступа к «РТ-ящику» партнерского терминала, в-четвертых, этот определенный терминал проверяет сохраненные данные, используя таким образом услугу «РТ-ящика».
[94]
[95] Кроме того, настоящее изобретение может быть реализовано так, что целевой «РТ-клиент» может быть подсоединен к «РТ-ящику» для получения речевого или мультимедийного пакета (или обоих пакетов), которые хранятся в «РТ-ящике» для целевого «РТ-клиента».
[96] Можно сказать, что настоящее изобретение может предложить способ управления услугой сеанса многоточечной полудуплексной связи - «РТ-сеанс» (Push to = Нажми, чтобы…») с обеспечением быстрого соединения в системе беспроводной связи, поддерживающей протокол установления сеанса связи «SIP», причем данный способ включает в себя: прием из терминала приглашающего сообщения протокола установления сеанса связи «SIP» с целью установления сеанса связи для, как минимум, одного из нескольких целевых терминалов; проверку, была ли принята настройка «РТ-услуги» от каждого из целевых терминалов; проверку информации об условиях доступа к «РТ-ящику», связанной с одним или несколькими определенными целевыми терминалами, если настройка «РТ-услуги» не была принята от этих, одного или нескольких, определенных целевых терминалов; определение, надо ли переслать в «РТ-ящик» приглашающее сообщение протокола установления сеанса связи «SIP», или же надо передать на терминал сообщение об отказе, на основе проверки информации об условиях доступа к «РТ-ящику»; передачу индикатора «РТ» на терминал, где индикатор «РТ» представляет собой ответ на приглашающее сообщения протокола установления сеанса связи «SIP» из «РТ-ящика» в отношении приглашающего сообщения протокола установления сеанса связи «SIP» от терминала; и передачу, как минимум, одного речевого пакета и мультимедийного пакета в «РТ-ящик», если терминал принимает ответ на приглашающее сообщение протокола установления сеанса связи «SIP»; при этом шаг определения дополнительно содержит: пересылку приглашающего сообщения протокола установления сеанса связи «SIP» в «РТ-ящик», когда информация об условиях доступа к ящику РТ установлена на безусловную маршрутизацию ящика РТ; сообщение об отказе представляет собой сообщение «SIP 480» («Временно недоступен»); информация об условиях доступа к «РТ-ящику» предварительно сохраняется в определенном объекте сети, как минимум, одним из множества терминалов; информация об условиях доступа к «РТ-ящику» извлекается из этого определенного объекта сети; при этом указанный определенный объект является, как минимум, одним из следующих: «Ядро SIP/IP», сервер с управлением базой данных на основе расширяемого языка разметки «XML» - «РТ XDM-сервер» и «РТ-ящик»; и ответом на приглашающее сообщение протокола установления сеанса связи «SIP» является сообщение с подтверждением «SIP 200 OK».
[97] Можно сказать, что настоящее изобретение может предложить способ управления услугой сеанса многоточечной полудуплексной связи - «РТ-сеанс» (Push to = "Нажми, чтобы…») с обеспечением быстрого соединения в системе беспроводной связи, поддерживающей протокол установления сеанса связи «SIP», причем данный способ включает в себя: передачу сообщения с приглашением к сеансу связи в один или несколько целевых терминалов; и прием ответного сообщения на приглашение к сеансу связи от «РТ-ящика», когда информация об условиях доступа к «РТ-ящику», связанная с одним или несколькими незарегистрированными целевыми терминалами, установлена на безусловную маршрутизацию «РТ-ящика»; при этом данное сообщение с ответом на приглашение к сеансу связи включает адрес «РТ-ящика»; при этом информация об условиях доступа к «РТ-ящику» ранее сохранена в определенном объекте одним или несколькими целевыми терминалами; причем определенный объект является, как минимум, одним из следующих: «Ядро SIP/IP», сервер с управлением базой данных на основе расширяемого языка разметки «XML» - «РТ XDM-сервер» и «РТ-ящик»; сообщение с ответом на приглашение к сеансу связи является сообщением об отказе, когда информация об условиях доступа к «РТ-ящику» не установлена на безусловную маршрутизацию «РТ-ящика»; причем сообщение об отказе представляет собой сообщение «SIP 480» («Временно недоступен»); информация об условиях доступа к «РТ-ящику» извлекается из определенного объекта сети, а определенный объект является, как минимум, одним из следующих: «Ядро SIP/IP», сервер с управлением базой данных на основе расширяемого языка разметки «XML» - «РТ XDM-сервер» и «РТ-ящик»; один или несколько незарегистрированных целевых терминалов являются неподсоединенными терминалами подсистемы передачи мультимедийных данных по IP-сетям (подсистемы IMS); один или несколько незарегистрированных целевых терминалов являются терминалами, для которых сервер не получал от них настройку «РТ-услуги».
[98] Можно сказать, что настоящее изобретение может предложить способ управления услугой сеанса многоточечной полудуплексной связи - «РТ-сеанс» (Push to = "Нажми, чтобы…») с обеспечением быстрого соединения в системе беспроводной связи, поддерживающей протокол установления сеанса связи «SIP», причем данный способ включает в себя: передачу сообщения «SIP PUBLISH» в «РТ-ящик» через «РТ-сервер»; прием из «РТ-ящика» «SIP-сообщения», которое включает определенную информацию; передачу в «РТ-ящик», используя данную конкретную информацию, приглашающего сообщения протокола установления сеанса связи «SIP» с целью проверки определенных данных, хранящихся в «РТ-ящике»; передачу в «РТ-ящик» сообщения с подтверждением «SIP 200 OK» в ответ на принятое «SIP-сообщение»; прием сообщения с подтверждением «SIP 200 OK» из «РТ-яшика» в ответ на переданное приглашающее сообщение протокола установления сеанса связи «SIP»; и прием из «РТ-ящика» определенных данных, хранящихся в этом «РТ-ящике»; при этом шаг передачи сообщения «SIP PUBLISH» дополнительно включает в себя: передачу сообщения «SIP PUBLISH» на «РТ-сервер» и прием сообщения с подтверждением «SIP 200 OK» из этого «РТ-сервера» в ответ на сообщение «SIP PUBLISH», причем «РТ-сервер» передает сообщение «SIP PUBLISH» в «РТ-ящик», а затем принимает сообщение с подтверждением «SIP 200 OK» из «РТ-ящика» в ответ на сообщение «SIP PUBLISH»; при этом определенные данные представляют собой речевой пакет (ТВ) и/или мультимедийный пакет (MB); и определенная информация включает адрес определенных данных, хранящихся в «РТ-ящике».
[99] Настоящее изобретение может предложить способ управления услугой сеанса многоточечной полудуплексной связи - «РТ-сеанс» (Push to = "Нажми, чтобы…») с обеспечением быстрого соединения в системе беспроводной связи, поддерживающей протокол установления сеанса связи «SIP», причем данный способ включает в себя: прием приглашающего сообщения протокола установления сеанса связи «SIP» с целью инициирования сеанса связи для, как минимум, одного из нескольких целевых терминалов; проверку каждой настройки «РТ-услуги» для каждого целевого терминала соответственно; передачу приглашающего сообщения протокола установления сеанса связи «SIP» в «РТ-ящик», если настройка «РТ-услуги» не была принята от одного или нескольких отдельных целевых терминалов; прием ответного сообщения на приглашающее сообщение протокола установления сеанса связи «SIP» из «РТ-ящика», причем ответное сообщение на приглашающее сообщение протокола установления сеанса связи «SIP» включает информацию об условиях доступа к «РТ-ящику» для одного или нескольких определенных целевых терминалов; и выполнение обмена данными посредством подключения к сеансу связи с «РТ-ящиком», когда информация об условиях доступа к «РТ-ящику» установлена на безусловную маршрутизацию «РТ-ящика».
[100] Кроме того, настоящее изобретение может предложить способ управления услугой сеанса многоточечной полудуплексной связи - «РТ-сеанс» (Push to = "Нажми, чтобы…») с обеспечением быстрого соединения в системе беспроводной связи, поддерживающей протокол установления сеанса связи «SIP», причем данный способ включает в себя: прием запроса от клиента на инициацию сеанса связи для, как минимум, одного из множества целевых клиентов; проверку информации о доступе к объекту хранения для одного или нескольких незарегистрированных целевых клиентов или для, как минимум, одного недоступного целевого терминала; определение того, надо ли переслать этот запрос в объект хранения или же надо передать клиенту сообщение об отказе в соответствии с шагом проверки; прием ответа на запрос, который был отправлен объекту хранения на шаге определения; и выполнение обмена данными посредством соединения на время сеанса связи с объектом хранения, когда информация о доступе к объекту хранения установлена на безусловную переадресацию объекта хранения; при этом объект хранения хранит данные сеанса; и один или несколько незарегистрированных целевых клиентов представляют собой терминалы, для которых сервер не получал от них настройку «РТ-услуги».
[101] Иллюстративные способы, рассмотренные выше, могут быть реализованы программными средствами, аппаратными средствами или их комбинацией. Например, иллюстративные способы или, как минимум, некоторые их процедуры могут храниться в запоминающем устройстве (например, во встроенной памяти подвижного терминала, во флэш-памяти, на жестком диске и т.п.) и могут быть реализованы в виде встроенных программ, команд, инструкций и т.п., являющихся часть программного обеспечения, которые могут выполняться процессорами (например, микропроцессором подвижного терминала, контроллером и т.п.).
[102] Вышеупомянутые клиентские (абонентские) терминалы могут включать приемо-передающий модуль, выходной блок (например, дисплей, устройство вывода звука и т.п.), входной блок (например, микрофон, клавишный блок ввода и т.п.), модуль фотоаппарата, а также другие схемы управления или компоненты. Кроме того, сервер может включать сетевой интерфейс, запоминающее устройство, процессор, а также другие сетевые объекты.
[103] Кроме того, рассмотренные в настоящем особенности и аспекты можно также использовать во многих системах беспроводной связи, использующих мобильные устройства, такие как карманные и портативные компьютеры, оснащенные функциями беспроводной связи. Кроме того, использование определенных терминов для описания настоящего изобретения не должно ограничивать области действия настоящего изобретения системами беспроводной связи определенного типа, такими как универсальная система мобильной связи «UMTS». Настоящее изобретение также применимо к другим системам беспроводной связи, использующим различные беспроводные интерфейсы и/или физические уровни, например TDMA (множественный доступ с временным разделением), CDMA (множественный доступ с кодовым разделением каналов), FDMA (множественный доступ с частотным разделением), WCDMA (широкополосный множественный доступ с разделением каналов), OFDM, EV-DO, Mobile Wi-Max, Wi-Bro и т.д.
[104] Следует также понимать, что вышеупомянутые примеры вариантов осуществления настоящего изобретения не ограничиваются никакими деталями вышеприведенного описания, если это не оговорено особо, и должны толковаться в широком смысле. Поэтому любые конструктивные и/или функциональные изменения и модификации, которые находятся в рамках и пределах формулы изобретения или эквивалентны указанным рамкам и пределам, должны считаться охваченными пунктами формулы изобретения.

Claims (11)

1. Способ управления услугой сеанса полудуплексной связи (РТ-Push to = "Нажми, чтобы…"), далее «РТ-сеанс», в системе беспроводной связи, поддерживающей протокол установления сеанса связи «SIP», включающий в себя:
прием «РТ-сервером» (сервер, поддерживающий услугу многоточечной полудуплексной связи ««РТ-услуга») из терминала клиента, поддерживающего «РТ-услугу», далее «РТ-терминал» клиента, приглашающего сообщения протокола установления сеанса связи «SIP», чтобы инициировать сеанс связи, для как минимум одного из целевых «РТ-терминалов»;
направление указанным «РТ-сервером» сообщения с запросом серверу «РТ XDMS» (сервер, поддерживающий услугу многоточечной полудуплексной связи с управлением базой данных на основе расширяемого языка разметки «XML») для того, чтобы проверить набор правил критериев доступа к «РТ-ящику»;
прием «РТ-сервером» от сервера «РТ XDMS» ответного сообщения в ответ на сообщение с запросом;
при этом ответное сообщение содержит набор правил критериев доступа к «РТ-ящику» для, по крайней мере, одного целевого «РТ-терминала»;
при этом набор правил критериев доступа к «РТ-ящику» представляет собой или первое условие (Прямая передача «РТ-ящику» - «ложь»), или второе условие (Прямая передача «РТ-ящику» - «истина»);
при этом первое условие означает не направлять приглашающее сообщение протокола установления сеанса связи «SIP» в «РТ-ящик», по крайней мере, одного из целевых «РТ-терминалов», если этот «РТ-терминал» клиента не зарегистрирован, а второе условие означает направить приглашающее сообщение протокола установления сеанса связи «SIP» в «РТ-ящик», по крайней мере, одного из целевых «РТ-терминалов», если этот «РТ-терминал» клиента не зарегистрирован;
направление «РТ-сервером» сообщения об отказе «РТ-терминалу» клиента или передачу «РТ-сервером» приглашающего сообщения протокола установления сеанса связи «SIP» в «РТ-ящик» на основе набора правил критериев доступа к «РТ-ящику», по крайней мере, одного из целевых «РТ-терминалов».
2. Способ по п.1, в котором сообщение об отказе направляется «РТ-терминалу» клиента, если принятое ответное сообщение содержит первое условие набора правил критериев доступа к «РТ-ящику».
3. Способ по п.1, в котором приглашающее сообщение протокола установления сеанса связи «SIP» передается в «РТ-ящик», если принятое ответное сообщение содержит второе условие набора правил критериев доступа к «РТ-ящику».
4. Способ по п.1, в котором «РТ-терминал» клиента не регистрируется, если «РТ-терминал» клиента не выполнил регистрацию в подсистеме передачи мультимедийных данных по IP-сетям (IMS).
5. Способ по п.1, в котором сообщение об отказе представляет собой сообщение «SIP 4xx» или сообщение «SIP 480 "Временно недоступен"».
6. Способ по п.1, дополнительно включающий в себя прием от«РТ-ящика» сообщения с подтверждением «SIP 200 ОК» в ответ на переданное приглашающее сообщение протокола установления сеанса связи «SIP» и передачу сообщения с подтверждением «SIP 200 ОК» «РТ-терминалу» клиента, чтобы инициировать сеанс связи между этим «РТ-терминалом» клиента и «РТ-ящиком».
7. Способ по п.1, дополнительно включающий в себя прием от «РТ-терминала» клиента, по крайней мере, одного из следующего: речевого пакета или мультимедийного пакета, и пересылку в «РТ-ящик» принятого, по крайней мере, одного из следующего: речевого пакета или мультимедийного пакета.
8. Способ по п.1, в котором набор правил критериев доступа к «РТ-ящику» от, по крайней мере, одного из нескольких целевых терминалов сохраняют в объекте сети.
9. Способ по п.8, в котором набор правил критериев доступа к «РТ-ящику» извлекают из указанного объекта сети.
10. Способ по п.9, в котором указанный объект сети представляет собой одно из следующего: ядро, поддерживающее протокол установления сеанса связи «SIP» / Интернет-протокол «IР» («Ядро SIP/IP»), сервер «РТ XDMS» и «РТ-ящик».
11. Способ по п.1, в котором «РТ-терминал» клиента не регистрируется, если настройки «РТ-услуги» от «РТ-терминала» клиента не были приняты, по крайней мере, одним из целевых «РТ-терминалов».
RU2008131819/09A 2006-01-12 2007-01-12 Установление "рт-сеанса связи" с использованием "рт-блока" RU2414099C2 (ru)

Applications Claiming Priority (5)

Application Number Priority Date Filing Date Title
US75821106P 2006-01-12 2006-01-12
US60/758,211 2006-01-12
US79737606P 2006-05-04 2006-05-04
US60/797,376 2006-05-04
KR10-2006-0089322 2006-09-14

Publications (2)

Publication Number Publication Date
RU2008131819A RU2008131819A (ru) 2010-02-20
RU2414099C2 true RU2414099C2 (ru) 2011-03-10

Family

ID=38500428

Family Applications (1)

Application Number Title Priority Date Filing Date
RU2008131819/09A RU2414099C2 (ru) 2006-01-12 2007-01-12 Установление "рт-сеанса связи" с использованием "рт-блока"

Country Status (8)

Country Link
US (1) US20070184867A1 (ru)
EP (1) EP1972117A4 (ru)
JP (1) JP2009522915A (ru)
KR (1) KR101002572B1 (ru)
BR (1) BRPI0706489A2 (ru)
CA (1) CA2635349A1 (ru)
RU (1) RU2414099C2 (ru)
WO (1) WO2007081170A1 (ru)

Families Citing this family (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR100761276B1 (ko) * 2005-04-11 2007-09-28 엘지전자 주식회사 PoC서비스를 위한 Simultaneous 세션제어방법 및 장치
KR100992625B1 (ko) 2006-05-04 2010-11-05 엘지전자 주식회사 PT Box 이용을 위한 PT 세션 설정 방법 및 단말
KR101431826B1 (ko) 2007-03-29 2014-08-25 삼성전자주식회사 프레젼스 소스로부터 프레젼스 정보를 직접 요청하기 위한시스템 및 방법
KR20090019665A (ko) * 2007-08-21 2009-02-25 삼성전자주식회사 구독자의 선호도를 참조하여 sip을 기반으로 하는이벤트 통지를 제어하는 시스템 및 방법
KR101524311B1 (ko) * 2008-11-27 2015-05-29 삼성전자주식회사 통신 시스템에서 그룹 메시징 세션 생성 방법 및 그 시스템
CN102474421A (zh) * 2009-07-10 2012-05-23 瑞典爱立信有限公司 按键通话服务的群组处理

Family Cites Families (17)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7522931B2 (en) * 1998-06-05 2009-04-21 Netnumber, Inc. Method and apparatus for accessing a network computer to establish a push-to-talk session
US6615236B2 (en) 1999-11-08 2003-09-02 Worldcom, Inc. SIP-based feature control
US6999783B2 (en) * 2001-11-01 2006-02-14 Nokia Corporation Method for creating a dynamic talk group
US7634568B2 (en) * 2002-02-07 2009-12-15 Sprint Spectrum L.P. Method and system for facilitating services in a communication network through data-publication by a signaling server
US7552204B2 (en) * 2002-05-15 2009-06-23 Microsoft Corporation Method and system for supporting the communication of presence information among computing devices of a network
US7050792B2 (en) * 2002-12-20 2006-05-23 Avaya Technology Corp. Voice message notification and retrieval via mobile client devices in a communication system
US9451422B2 (en) * 2003-03-17 2016-09-20 Nokia Technologies Oy Method, system and network device for routing a message to a temporarily unavailable network user
US20040249949A1 (en) * 2003-03-27 2004-12-09 Christophe Gourraud Voice and multimedia distribution using Push-To-Talk (PTT) subscribers' group
KR100552521B1 (ko) 2004-01-29 2006-02-14 삼성전자주식회사 브이 오 아이피 시스템에서의 음성 메시징 서비스 방법 및그 장치
US7280502B2 (en) * 2004-04-13 2007-10-09 Research In Motion Limited Method for a session initiation protocol push-to-talk terminal to indicate answer operating mode to an internet protocol push-to-talk network server
US20060045043A1 (en) * 2004-08-31 2006-03-02 Crocker Ronald T Method and apparatus for facilitating PTT session initiation and service interaction using an IP-based protocol
FI20041169A0 (fi) * 2004-09-08 2004-09-08 Nokia Corp Ryhmäpalveluiden ryhmätiedot
US7324505B2 (en) * 2004-12-24 2008-01-29 Christopher Hoover Sustained VOIP call logs using PoC contact lists
US8010142B2 (en) * 2005-01-31 2011-08-30 Motorola Solutions, Inc. Method and apparatus for including a recording device in a push-to-talk over cellular communication session
KR101061373B1 (ko) * 2005-04-11 2011-09-02 삼성전자주식회사 푸쉬투토크 오버 셀룰러 망의 미디어 저장 서비스 수행 방법과 PoC 서버 및 PoC 클라이언트
US7801494B2 (en) * 2005-05-27 2010-09-21 Motorola Mobility, Inc. Method for PoC server to handle PoC caller preferences
FI20055514A0 (fi) * 2005-09-27 2005-09-27 Nokia Corp Ryhmäviestintä viestintäjärjestelmässä

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
ROSENBERG J. et al. Guidelines for Usage of the Session Initiation Protocol (SIP) Caller Preferences Extension; draft-ietf-sipping-callerprefs-usecases-05.txt, IETF STANDARD-WORKING-DRAFT, INTERNET ENGINEERING TASK FORCE, №5, 05.10.2005. Push-to-talk over Cellular (PoC), Architecture, PoC Release 2.0, Technical Specification, Architecture V2.0.8, 2004-06. ГОЛЬДШТЕЙН Б.C. и др. Протокол SIP. Справочник по телекоммуникационным протоколам, BHV-Санкт-Петербург. - СПб.: 2005. *
ОМА РоС Control Plane, Candidate Version 1.0-05 Aug 2005, OMA-TS-PoC-ControlPlane-V1_0-20050805-C, найдено в Интернет на http://www.openmobilealliance.org/Technical/release_program/PoC_archive.aspx#v1_0-20050805-C. *

Also Published As

Publication number Publication date
RU2008131819A (ru) 2010-02-20
WO2007081170A1 (en) 2007-07-19
JP2009522915A (ja) 2009-06-11
US20070184867A1 (en) 2007-08-09
CA2635349A1 (en) 2007-07-19
BRPI0706489A2 (pt) 2011-03-29
KR20070075249A (ko) 2007-07-18
EP1972117A4 (en) 2009-11-04
KR101002572B1 (ko) 2010-12-17
EP1972117A1 (en) 2008-09-24

Similar Documents

Publication Publication Date Title
US9860074B2 (en) Group communication
KR101458634B1 (ko) 사전 설정 세션을 관리하기 위한 방법 및 이를 구현하기위한 PoC 시스템과 PoC 단말
US9264467B2 (en) Method, user equipment, and system for opening an ad-hoc PoC session in a PoC system
RU2347321C1 (ru) СПОСОБ И СИСТЕМА ДЛЯ ОБРАБОТКИ РоС-ВЫЗОВОВ НА ОСНОВЕ РЕЖИМА ОТВЕТА СИСТЕМЫ СВЯЗИ С ПЕРЕКЛЮЧЕНИЕМ МЕЖДУ ПРИЕМОМ И ПЕРЕДАЧЕЙ ПОВЕРХ СОТОВОЙ СВЯЗИ
US8054843B2 (en) Method for securing privacy in automatic answer mode of push-to service
RU2477014C2 (ru) Способ группового оповещения в службе обмена сообщениями на основе протокола инициации сеанса связи "sip"
JP5456006B2 (ja) マルチメディア通話サービスを遂行するためのマルチメディアセッション開設及び管理のためのサーバ
US20060014556A1 (en) Method and apparatus for processing call in PTT over cellular (PoC) system
KR101183328B1 (ko) PoC 세션에서 발언권 관리 규칙 전달과 적용 방법 및이를 구현하기 위한 시스템
US7730127B2 (en) Method, system and apparatus for video sharing
RU2414099C2 (ru) Установление "рт-сеанса связи" с использованием "рт-блока"
US9049263B2 (en) Method and terminal for establishing PT session in order to use PT box
US9350695B2 (en) Method for transferring and storing CPM service message and service thereof
US20070026883A1 (en) System and method for re-invitation to push-to-talk over cellular group session
WO2008125057A1 (fr) Procédé et système de communication avec un abonné supportant divers services de messagerie
US8700706B2 (en) Method for determining active communication sessions and communication session information server
KR100889867B1 (ko) Sip기반의 통신 서비스에서의 세션초대 예약장치 및방법
KR101322990B1 (ko) Pt 서비스의 자동 응답 모드에서의 프라이버시 확보 방법
WO2007083876A1 (en) Session invitation reservation method in sip based communication service
KR20070118025A (ko) 미디어 타입별 서로 다른 응답 모드를 가진 PoC 세션개시 방법 및 시스템

Legal Events

Date Code Title Description
MM4A The patent is invalid due to non-payment of fees

Effective date: 20140113