Сущность изобретения
Техническое решение
[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] Следует также понимать, что вышеупомянутые примеры вариантов осуществления настоящего изобретения не ограничиваются никакими деталями вышеприведенного описания, если это не оговорено особо, и должны толковаться в широком смысле. Поэтому любые конструктивные и/или функциональные изменения и модификации, которые находятся в рамках и пределах формулы изобретения или эквивалентны указанным рамкам и пределам, должны считаться охваченными пунктами формулы изобретения.
Изобретение относится к системам связи и, в частности, к способу и терминалу для установления сеанса многоточечной полудуплексной связи (РТ-сеанс) (Push to "Нажми, чтобы…") в услуге на основе протокола установления сеанса связи (SIP). Техническим результатом является создание способа использования услуги (РТ-ящика), когда конкретный терминал не способен выполнить регистрацию или не зарегистрирован в Ядре SIP/IP (информационной системе IMS) и параметры настройки услуги многоточечной полудуплексной связи (РТ-услуга) не могут быть переданы на сервер РТ-услуги (РТ-сервер) из-за отключения питания терминала. Указанный технический результат достигается тем, что осуществляют прием РТ-сервером из терминала клиента, поддерживающего РТ-услугу (РТ-терминал), приглашающего сообщения протокола SIP, чтобы инициировать сеанс связи, для, как минимум, одного из целевых РТ-терминалов; направление РТ-сервером сообщения с запросом серверу РТ XDMS (сервер РТ-услуги связи с управлением базой данных на основе расширяемого языка разметки (XML)), для того, чтобы проверить набор правил критериев доступа к РТ-ящику; прием РТ-сервером от сервера «РТ XDMS» ответного сообщения в ответ на сообщение с запросом; при этом ответное сообщение содержит набор правил критериев доступа к РТ-ящику для, по крайней мере, одного целевого РТ-терминала. 10 з.п ф-лы, 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, в котором «РТ-терминал» клиента не регистрируется, если настройки «РТ-услуги» от «РТ-терминала» клиента не были приняты, по крайней мере, одним из целевых «РТ-терминалов».
ОМА РоС 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 | |||
WO 2005101697 A1, 27.10.2005 | |||
WO 2005057895 A1, 23.06.2005 | |||
WO 2004077796 A1, 10.09.2004 | |||
US 2005180407 A1, 18.08.2005 | |||
US 2004219940 |
Авторы
Даты
2011-03-10—Публикация
2007-01-12—Подача