Область техники, к которой относится изобретение
Изобретение относится к способу и устройству для обработки приглашений на многопользовательский сеанс связи. Изобретение можно применять, хотя и не как обязательный вариант, для сеансов конференц-связи, таких как сеанс связи «нажми и говори».
Уровень техники
Услуги с использованием портативных радиостанций двусторонней связи давно стали популярными у пользователей, желающих быстро обмениваться короткими сообщениями. В известном уровне техники эти услуги предоставляются двусторонней портативной радиосвязью, использующей выделенную часть радиочастотного спектра, но которая позволяет пользователям осуществлять связь с небольшой группой заранее отобранных пользователей, которые используют аналогичные оконечные устройства и действуют в пределах относительно узкого рабочего диапазона радиосвязи. В более позднее время в Соединенных Штатах появились услуги, которые действуют как вложение в существующей инфраструктуре сотовой телефонной связи. Но эти услуги являются услугами частного характера и не дают пользователям возможность осуществлять связь между сетями разных операторов.
Для расширения использования услуг портативной двусторонней радиосвязи промышленная группа под названием «Оупен Мобайл Эллайанс» (Open Mobile Alliance) (www.openmobilealliance.org) cоздана с целью стандартизации соответствующих протоколов, с помощью которых услуги «Waklike-Talkie», предлагаемые сотовыми сетями, можно будет использовать для межсетевой связи. Услуги в соответствии с различными стандартами известны под названием «нажми и говори по сотовой связи» (РоС). РоС использует Мультимедийную Субсистему Межсетевого Протокола (IMS) для организации и управления РоС-сеансами при помощи PoC-серверов (действующих как Серверы Приложений Протокола Инициации Сеансов (SIP ASs)). Согласно PoC соответствующие речевые данные будут переноситься по сети доступа с коммутацией пакетов. В случае общеевропейской цифровой системы сотовой подвижной радиотелефонной связи-GSM или универсальной системы подвижной электросвязи-UMTS это будет сеть радиослужбы пакетной передачи данных-GPRS. В других видах сетевой архитектуры аналогичные сети доступа с коммутацией пакетов будут использоваться для переноса переговорных данных. Услуги связи «нажми и говори» могут также предоставляться по сетям с коммутацией каналов, хотя это предоставление не является предпочтительным вариантом.
Текущее состояние PoC изложено в Выпуске 1.0.
Сущность изобретения
Выпуск 1.0 PoC предусматривает функцию конференц-связи, согласно которой множество пользователей могут участвовать в общем PoC-сеансе. Пользователи, каждый из них, могут относиться к разным PoC-серверам - как в том случае, когда разные пользователи зарегистрированы в сетях разных операторов. В этом сценарии один из PoC-серверов, обычно - сервер инициирующего пользователя, назначается для выполнения функции Управления PoC, и действует как «коммутатор для конференц-связи», и управляет аудиторией (т.е. назначает участникам временные интервалы для высказывания). Прочие PoC-серверы называются Участвующими PoC-серверами.
Пользователь может установить связь с группой других пользователей по принципу «на данный случай», т.е. пользователь может выбрать из своей телефонной книжки несколько пользователей, нажать PoC-кнопку на своем оконечном устройстве, и тогда связь будет установлена со всеми пользователями, на данный момент доступными. PoC также предоставляет пользователю возможность определить группы людей (называемые согласно стандартам Архитектуры Управления Объектами «Составленной PoC-Группой»); причем данная группа и соответствующая Идентификация PoC-Группы запоминается в PoC-сервере данного пользователя в Исходной Сети. После того как группа будет определена, пользователь может инициировать PoC-сеанс с доступными членами данной группы простым отправлением ПРИГЛАШЕНИЯ, в котором указан Идентификатор Группы.
Например, PoC-Сервер принимает от пользователя запрос на подготовку Сеанса PoC-Группы на Данный Случай, и этот запрос содержит перечень приглашаемых PoC-Пользователей. Для пользовательских идентичностей (которые даны в виде унифицированного указателя информационного ресурса-URL), которые соответствуют отдельному PoC-Пользователю, PoC-Сервер может без затруднений пригласить PoC-Пользователя с помощью процедуры согласно Выпуску 1.0 PoC. Для этого ПРИГЛАШЕНИЕ направляется в PoC-сервер, определяемый как обслуживающий данного нужного пользователя; причем высылаемое ПРИГЛАШЕНИЕ содержит характерную метку «isfocus». Эта метка указывает, что отправляющий PoC-сервер является управляющим сервером данного сеанса PoC-группы. Принимающий сервер распознает эту метку, и в ответ не создает о себе представления как об управляющем сервере. Принимающий сервер лишь направляет ПРИГЛАШЕНИЕ к означенному пользователю(ям), который находится в его ведении.
Если отправленное исходным пользователем ПРИГЛАШЕНИЕ содержит идентичность (URL), соответствующую данной PoC-Группе, которой «владеет» управляющий PoC-сервер, то этот сервер просто «разобьет» эту группу и направит ПРИГЛАШЕНИЕ в PoC-сервер(ы), к которым относятся члены группы. Если исходное ПРИГЛАШЕНИЕ содержит Идентификатор PoC-Группы, которой владеет PoC-сервер, не являющийся управляющим сервером, то управляющий сервер направит это ПРИГЛАШЕНИЕ к серверу-владельцу. Именно на этом этапе возникает трудность, т.к. в этой ситуации нормы Выпуска 1.0 PoC обязуют принимающий PoC-сервер отклонить ПРИГЛАШЕНИЕ. Эта особенность предусмотрена для того, чтобы сохранить управление PoC-сеансами за PoC-серверами, которые владеют определенными группами и, тем самым, предотвратить создание нескольких управляющих PoC-серверов для одиночного PoC-сеанса.
Решение проблемы нескольких управляющих PoC-серверов может повлечь за собой необходимость согласования по определению конкретного управляющего, и необходимость увязывания нескольких PoC-серверов. Но выработка этого решения будет сложной и может привести к созданию «бесконечных» шлейфов. При этом также будет фигурировать вопрос о решении по состоянию PoC-группы, когда PoC-группа будет приглашаться на PoC-Сеанс на Данный Случай. Например, если член Составленной PoC-Группы (по той или иной причине не являющийся частью PoC-Сеанса на Данный Случай) инициирует Сеанс PoC-Группы для этой Составленной PoC-Группы, то надо ли этого члена включать в этот PoC-Сеанс Группы на Данный Случай, или надо организовать отдельный PoC-Сеанс Группы? Любая методика по урегулированию этих «конфликтов» обязательно будет сложной.
Еще одна трудность, которая может возникнуть в случае PoC-сеансов с участием заранее определенных групп, возникает, если данный пользователь принадлежит к нескольким заранее определенным и «вложенным» группам. Тогда данный пользователь будет получать несколько приглашений на один и тот же сеанс. Помимо связанных с этим неудобств, это обстоятельство будет причиной нерациональной траты сетевых ресурсов (особые затруднения будут в том случае, когда сетью доступа будет сотовая сеть).
Нужно отметить, что проблемы, аналогичные описываемым выше, возникают и в других, кроме PoC, службах IMS, например - в службах оперативного обмена сообщениями.
Согласно первому аспекту настоящего изобретения предлагается способ обработки приглашений на многопользовательский сеанс связи, использующий IP Мультимедийную Подсистему для подготовки и управления сеансом, при этом пользовательским доступом управляют два, или более, сервера пользовательского доступа в IP Мультимедийной Подсистеме; и согласно этому способу:
принимают приглашение на сеанс в первом сервере пользовательского доступа от инициирующего сеанс пользователя; причем приглашение в качестве возможного участника указывает по меньшей мере одну группу пользователей, которой владеет второй сервер пользовательского доступа;
направляют приглашение второму серверу пользовательского доступа, содержащее идентификацию упомянутой группы пользователей;
в упомянутом втором сервере пользовательского доступа разлагают идентификацию группы на совокупность идентичностей членов группы;
направляют ответ с указанием упомянутых идентичностей членов группы упомянутому первому серверу пользовательского доступа; и
упомянутым первым сервером пользовательского доступа направляют приглашение по меньшей мере некоторым членам этой группы, указанным в упомянутом ответе.
Настоящее изобретение определенно является применимым для обеспечения услуги «нажми и говори» - как, например, «нажми и говори по сотовой связи» (PoC). В этом применении упомянутые серверы пользовательского доступа являются серверами «нажми и говори», и упомянутые пользователи являются клиентами «нажми и говори». Упомянутый первый сервер пользовательского доступа действует в качестве управляющего PoC-сервера, и упомянутый второй сервер пользовательского доступа действует в качестве участвующего PoC-сервера, а не как управляющий сервер. Когда ко множеству PoC-серверов обращается управляющий PoC-сервер, то все другие серверы действуют как участвующие PoC-серверы.
Этот способ также может включать в себя этап - во втором сервере пользовательского доступа - использования заранее определенной методики, разрешающей приглашение идентифицированной группы к участию в сеансе. Если таковое разрешение не дается, то приглашение отклоняется.
Этот способ также может включать в себя этап - во втором сервере пользовательского доступа - использования заранее определенной методики, разрешающей запрашивающему пользователю приглашать идентифицированную группу к участию в сеансе. Эта заранее определенная методика может потребовать, чтобы запрашивающий пользователь был членом заранее определенной группы, и тогда он сможет давать это приглашение. Если пользователь не получает такового правомочия, то приглашение отклоняется.
Заявляемый способ может включать в себя этап - по получении ответа на первом сервере пользовательского доступа - отправления приглашений членам группы согласно заранее определенной методике. Эта заранее определенная методика может предотвращать рассылку приглашений членам группы, которые сами являются идентификацией группы. Если эта методика дозволяет рассылку приглашений членам группы, которые сами являются идентификациями группы, то эта методика может объединить некоторое число «вложенных» идентификаций группы, которые разлагают на идентичности членов.
Согласно второй особенности настоящего изобретения обеспечен сервер пользовательского доступа для использования в IP Мультимедийной Подсистеме, содержащий:
средства для приема приглашения на сеанс от инициирующего сеанс пользователя, причем это приглашение идентифицирует как возможного участника по меньшей мере одну группу пользователей, которой владеет второй сервер пользовательского доступа;
средства для рассылки приглашения во второй сервер пользовательского доступа; причем это приглашение включает в себя идентификацию упомянутой группы пользователей;
средства для приема от упомянутого второго сервера пользовательского доступа ответа, содержащего идентичности членов группы, разложенные вторым сервером пользовательского доступа из упомянутой идентификации группы; и
средства для рассылки приглашения по меньшей мере некоторым членам группы, указанным в упомянутом ответе.
В соответствии с третьей особенностью изобретения обеспечен сервер пользовательского доступа для использования в IP Мультимедийной Подсистеме, содержащий:
средства для приема от еще одного сервера пользовательского доступа приглашения, включающего в себя идентификацию группы пользователей, которой владеет принимающий сервер;
средства для разложения идентификации группы на совокупность идентичностей членов группы; и
средства для рассылки ответа, содержащего упомянутые идентичности членов группы, в упомянутый первый сервер пользовательского доступа.
Чертеж показывает поток передачи сигналов в PoC-архитектуре, относящейся к проведению PoC-тконференции.
Подробное описание
Клиент (Клиент А) услуги «нажми и говори по сотовой связи» (PoC) инициирует PoC-Сеанс Группы согласно процедуре, разработанной Архитектурой Управления Объектами PoC. PoC-Сеанс Группы может использовать Запланированный Сеанс, или этот сеанс может быть сеансом По требованию. В случае Запланированного Сеанса Клиент PoC назначает сеанс согласно Протоколу Инициации Сеансов (ПИС) своему PoC-Серверу в Исходной сети запросом ПРИГЛАШЕНИЯ (обычно: когда PoC-Клиент регистрируется в IMS). После того как SIP-сеанс будет установлен, PoC-Клиент сможет инициировать PoC-Сеанс запросом на Запланированный Сеанс и на ОБРАЩЕНИЕ к SIP. Если сеанс является сеансом По требованию, то PoC-Клиент инициирует PoC-Сеансы без предварительного назначения Запланированного сеанса, путем непосредственного запроса SIP-ПРИГЛАШЕНИЯ.
Перечень приглашаемых пользователей включается в SIP-запрос (обычно: SIP ПРИГЛАШЕНИЕ), отправляемый в Исходный PoC-сервер инициирующего пользователя. В поясняемом здесь примере перечень PoC-пользователей состоит из смеси PoC-адресов (универсальные идентификаторы ресурса) отдельных PoC-Пользователей и Идентификатор PoC-Группы Составленных PoC-Групп. Чертеж показывает поток передачи сигналов при назначении PoC-сеанса, предполагая PoC-Сеанс Группы На Данный Случай с передачей сигналов По требованию, например. Этот же принцип действует в отношении PoC-Сеанса Группы На Данный Случай с использованием передачи сигналов Запланированного Сеанса, и для Составленного PoC-Сеанса Группы с использованием передачи сигналов По требованию или передачи сигналов Запланированного Сеанса.
Этапы передачи сигналов:
1. PoC-Клиент А направляет запрос SIP ПРИГЛАШЕНИЕ в свой исходный PoC-сервер, идентифицируемый Универсальным идентификатором ресурса (обычно: клиентские «предустановленные» настройки). Запрос SIP ПРИГЛАШЕНИЕ содержит PoC-Адреса, идентифицирующие PoC-Пользователей, и два Идентификатора PoC-Группы, идентифицирующие Составленную группу, Группу Х и Группу Y.
2 и 4. PoC-Сервер А/Х1 идентифицирует запрос SIP ПРИГЛАШЕНИЕ, являющийся инициализацией PoC-Сеанса Группы На Данный Случай, и начинает рассылать приглашения по пригласительному перечню. Приглашения включают в себя характерную метку “isfocus”, указывающую, что этот PoC-Сервер А/Х1 является управляющим сервером назначаемого PoC-Сеанса Группы. Рассылка Приглашений отдельным PoC-пользователям представлена на этапе 4, на котором участвующие серверы показаны как один сервер B1-Bn.
3. Одним из принимающих устройств является PoC-Сервер Х2, который владеет Группой Х. PoC-Сервер Х2 (PoC-Сервер, ведущий Составленную PoC-Группу) обнаруживает характерную метку “isfocus” в ПРИГЛАШЕНИИ, и выполняет следующие этапы:
а) Проверяет, разрешено ли по его методике приглашать Группу Х на еще один PoC-Сеанс. Эта методика может касаться Составленной PoC-Группы, либо она может быть общей методикой PoC-услуг. В этом примере это разрешение дается.
б) Затем он управомочивает инициатора. Это можно сделать, проверив, является ли приглашающий PoC-пользователь членом Группы Х. В этом примере PoC-Пользователь является членом. Это можно сделать с помощью заголовка «P-Утвержденный-Идентификатор» или из заголовка ПРИГЛАШЕНИЯ. Либо это управомочивание может основываться на относящейся к группам методике, разработанной владельцем (например: «белый список»), или на разработанной оператором методике.
в) Он возвращает ответ SIP 3хх или SIP 4хх с перечнем членов данной PoC-группы в PoC-сервер А/Х1. На чертеже ответ SIP 300 «Множественные Варианты» направляется в PoC-Сервер А/Х1. Перечень членов может включать в себя как отдельных PoC-Пользователей, так и прочие PoC-Группы.
[Если по проверке а) данную группу нельзя пригласить еще на один PoC-сеанс, то ПРИГЛАШЕНИЕ отклоняется. Аналогично, если по проверке б) приглашающий пользователь не является членом группы, то ПРИГЛАШЕНИЕ отклоняется. Разумеется, для учета этих ситуаций можно разработать и альтернативные методики, которые будут определять соответствующие предпринимаемые действия.]
4. PoC-Сервер А/Х1 принимает перечень, и выполняет следующие действия:
а) Сверяется со своей методикой и решает пригласить совокупность PoC-Пользователей, указываемых в SIP 300. Он отклоняет идентичности группы, содержащиеся в ответе.
б) Удаляет уже приглашенных пользователей из перечня, чтобы не рассылать двойные ПРИГЛАШЕНИЯ отдельным клиентам (и группам).
в) Приглашает остальных пользователей из перечня, и в каждый адрес высылает запрос ПРИГЛАШЕНИЕ.
5 и 6. Еще одним получателем первоначального ПРИГЛАШЕНИЯ является PoC-сервер Х3, который владеет Группой Y. PoC-сервер Х3 выполняет те же проверки, которые выполняет сервер Х2, и, предполагая принятие им ПРИГЛАШЕНИЯ, возвращает ответ SIP 300 «Многие Варианты», который включает в себя всех членов Группы Y. При этом также перечень членов включает в себя и отдельных PoC-Пользователей, и другие PoC-Группы. PoC-сервер повторяет указанные выше этапы а)-г).
В этом примере управляющий PoC-сервер отклоняет дополнительные группы, означенные в ответных сообщениях, т.е. выполняет только один уровень решений по Идентификатору Группы. Это делается, чтобы исключить слишком длинные разрешающие процессы по группам и исключить возникновение потенциально бесконечных коммутаций шлейфов. Но некоторое конечное число разрешающих уровней можно допустить в зависимости от методики, выполняемой управляющим PoC-сервером.
Специалисту в данной области техники будет ясно, что в описываемом выше осуществлении возможны различные модификации в рамках объема настоящего изобретения.
Изобретение относится к способу и устройству для обработки приглашений на многопользовательский сеанс связи, в частности для сеансов конференц-связи, таких как сеанс связи «нажми и говори» (РОС). Техническим результатом является обработка приглашений на многопользовательский сеанс связи, использующий IP Мультимедийную подсистему, для организации и управления сеансом, в котором пользовательским доступом управляют два, или более, сервера пользовательского доступа. Указанный технический результат достигается тем, что принимают приглашение на сеанс в первом сервере пользовательского доступа от инициирующего сеанс пользователя; причем приглашение в качестве возможного участника указывает по меньшей мере одну группу пользователей, которой владеет второй сервер пользовательского доступа; направляют приглашение второму серверу пользовательского доступа, содержащее идентификатор группы пользователей; во втором сервере пользовательского доступа разлагают идентификатор группы на совокупность идентификаторов членов группы; направляют ответ с указанием идентификаторов членов группы первому серверу пользовательского доступа; и первый сервер пользовательского доступа направляет приглашение по меньшей мере некоторым членам этой группы, указанным в ответе. 3 н. и 7 з.п. ф-лы, 1 ил.
1. Способ обработки приглашений на многопользовательский сеанс связи, использующий IP Мультимедийную Подсистему для организации и управления сеансом, в котором пользовательским доступом управляют два или более серверов пользовательского доступа в IP Мультимедийной Подсистеме; причем способ включает в себя этапы, согласно которым:
принимают приглашение на сеанс в первом сервере пользовательского доступа от инициирующего сеанс пользователя; причем приглашение в качестве возможного участника указывает по меньшей мере одну группу пользователей, которой владеет второй сервер пользовательского доступа;
направляют приглашение второму серверу пользовательского доступа, содержащее идентификацию упомянутой группы пользователей;
во втором сервере пользовательского доступа разделяют идентификацию группы на совокупность идентификаторов членов группы;
направляют ответ с указанием идентификаторов членов группы первому серверу пользовательского доступа и направляют от первого сервера пользовательского доступа приглашение по меньшей мере некоторым членам этой группы, указанным в ответе.
2. Способ по п.1, в котором сеанс является сеансом «нажми и говори», и серверы пользовательского доступа являются серверами «нажми и говори», и пользователи являются клиентами сеанса «нажми и говори»; причем первый сервер пользовательского доступа действует в качестве управляющего сервера сеанса «нажми и говори» и второй сервер пользовательского доступа действует в качестве участвующего сервера сеанса «нажми и говори».
3. Способ по п.1 или 2, содержащий также этап, согласно которому во втором сервере пользовательского доступа используют заранее определенную политику, разрешающую приглашение идентифицированной группы к участию в сеансе.
4. Способ по п.1 или 2, содержащий также этап, согласно которому во втором сервере пользовательского доступа используют заранее определенную политику, разрешающую запрашивающему пользователю приглашать идентифицированную группу к участию в сеансе.
5. Способ по п.4, в котором заранее определенная политика требует, чтобы запрашивающий пользователь для получения решения был членом заранее определенной группы.
6. Способ по п.1, содержащий также этап, согласно которому по получении ответа первым пользовательским сервером рассылают приглашения членам группы в соответствии с заранее определенной политикой.
7. Способ по п.6, в котором упомянутая политика предотвращает рассылку приглашений тем членам группы, которые сами являются идентификаторами группы.
8. Способ по п.6, в котором упомянутая политика разрешает рассылку приглашений тем членам группы, которые сами являются идентификаторами группы, до заранее определенного числа вложенных уровней.
9. Сервер пользовательского доступа для использования в IP Мультимедийной Подсистеме, содержащий:
средство для приема приглашения на сеанс от инициирующего сеанс пользователя, причем это приглашение идентифицирует как возможного участника по меньшей мере одну группу пользователей, которой владеет второй сервер пользовательского доступа;
средство для рассылки приглашения во второй сервер пользовательского доступа; причем это приглашение включает в себя идентификатор упомянутой группы пользователей;
средство для приема от второго сервера пользовательского доступа ответа, содержащего идентификаторы членов группы, разделенные вторым сервером пользовательского доступа из идентификатора группы; и средство для рассылки приглашения по меньшей мере некоторым членам группы, указанным в ответе.
10. Сервер пользовательского доступа для использования в IP Мультимедийной Подсистеме, содержащий:
средство для приема от еще одного сервера пользовательского доступа приглашения, включающего в себя идентификатор группы пользователей, которой владеет принимающий сервер;
средство для разделения идентификатора группы на совокупность идентификаторов членов группы и средство для рассылки ответа, содержащего идентификаторы членов группы, в первый сервер пользовательского доступа.
WO 2004077796 A1, 10.09.2004 | |||
WO 2004075581 A1, 02.09.2004 | |||
US 2004249949 A1, 09.12.2004 | |||
US 2003145054 A1, 31.07.2003 | |||
WO 03069927 A1, 21.08.2003 | |||
RU 2003133294 A, 27.05.2005 | |||
Push-to-talk over Cellular (PoC), Architecture, PoC Release 2.0, Technical Specification, Architecture V2.0.8, 2004.06 | |||
OPEN MOBILE ALLIANCE, Push to Talk over Cellular |
Авторы
Даты
2010-12-20—Публикация
2005-10-13—Подача