Механизм удаления сообщения или файла в мультимедийных службах, работающих по протоколу sip

Механизм удаления сообщения или файла в мультимедийных службах, работающих по протоколу sip

Иллюстрации

Показать все

Реферат

ОБЛАСТЬ ТЕХНИКИ

[0001] Настоящее изобретение в общем относится к службам, использующим протокол инициирования сеанса (SIP - session initiation protocol), и протоколу SIP для служб мгновенного обмена сообщениями и уведомления о присутствии (SIMPLE - SIP for instant messaging and presence leveraging extensions). В частности, настоящее изобретение относится к службам на основе SIP/SIMPLE, таким как службы мгновенного обмена сообщениями (IM - instant messaging) и службы «нажми и говори» (РоС).

ПРЕДПОСЫЛКИ ИЗОБРЕТЕНИЯ

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

[0003] Открытое сообщество производителей мобильной связи (ОМА - Open Mobile Alliance) - это комитет по стандартизации, который коллективно разрабатывает открытые стандарты для использования в индустрии мобильной связи. ОМА помогает создавать средства обеспечения работы взаимодействующих служб между разными странами, операторами и мобильными терминалами и ведет свою деятельность исходя из требований рынка. Для расширения рынка мобильных систем компании, поддерживающие Open Mobile Alliance, ведут работы для содействия быстрому и широкому развитию и вводу в действие разнообразных новых, улучшенных информационных, коммуникационных и развлекательных мобильных услуг.

[0004] В настоящее время ОМА разрабатывает услуги мгновенного обмена сообщениями, основанные на протоколах SIP, MSRP (Message Session Relay Protocol) и XCAP (Configuration Access Protocol) для языка XML (Extensible Markup Language), разработанных рабочей группой SIMPLE Комитета по инженерным вопросам Internet (IETF - International Engineering Task Force). Службы мгновенного обмена сообщениями в настоящее время реализованы при помощи некоторых частных технологий и спецификаций Wireless Village.

[0005] В настоящее время существует потребность в механизме удаления в среде мультимедийных услуг SIP. В среде http для удаления документа просто подается команда «http delete». Однако в среде SIP в настоящее время не существует соответствующего средства или определенной функции для удаления. Фактически даже расширения SIP для служб не заданы как функциональная возможность. В современных мультимедийных службах, в частности ОМА SIP/SIMPLE IM, имеются некоторые требования по хранению и поиску сообщений. Хотя существует необходимость удаления и выборочного удаления сохраненных сообщений, такой механизм еще предстоит реализовать.

СУЩНОСТЬ ИЗОБРЕТЕНИЯ

[0006] Настоящее изобретение предлагает новый механизм удаления для использования в мультимедийных службах SIP. Настоящее изобретение включает использование для этой цели различных особенностей среды мультимедийных служб SIP. В одном варианте реализации изобретения в сети предусмотрена «мусорная корзина», которая связана с унифицированным идентификатором ресурса (URI) SIP. Сообщениям, хранящимся в сети, назначены уникальные идентификаторы. Если пользователь желает удалить сообщение, он делает запрос, чтобы между сообщением и сетевой корзиной была установлена функция SIP/MSRP. После обработки сообщение с аккаунта пользователя на сервере хранения пользовательской почты перемещается в корзину.

[0007] Система и способ, соответствующие настоящему изобретению, не являются сложными и легко могут быть приняты к использованию, так как в них задействованы уже существующие инструменты, такие как метод SIP REFER, Virtual User Agent (агент виртуального пользователя) и SIP URI.

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

Краткое описание чертежей

[0009] Фиг.1 - блок-схема, показывающая работу механизма удаления для мультимедийных служб SIP в соответствии с одним вариантом осуществления настоящего изобретения.

[0010] Фиг.2 - блок-схема, показывающая работу механизма удаления для мультимедийных служб SIP для удаления выбранного сообщения в соответствии с еще одним вариантом осуществления настоящего изобретения.

[0011] Фиг.3 - блок-схема, показывающая работу механизма удаления для мультимедийных служб SIP для удаления выбранного сообщения в соответствии с еще одним вариантом осуществления настоящего изобретения.

[0012] Фиг.4 - блок-схема, показывающая работу механизма удаления для мультимедийных служб SIP для удаления группы выбранных сообщений в соответствии с вариантом осуществления настоящего изобретения.

[0013] Фиг.5 - блок-схема, показывающая работу механизма удаления для мультимедийных служб SIP для удаления группы выбранных сообщений в соответствии с вариантом осуществления настоящего изобретения.

[0014] Фиг.6 - блок-схема, показывающая работу механизма удаления для мультимедийных служб SIP для удаления группы выбранных сообщений в соответствии с вариантом осуществления настоящего изобретения.

[0015] Фиг.7 - блок-схема, показывающая работу механизма удаления для мультимедийных служб SIP для удаления всех сообщений с пользовательского почтового аккаунта в соответствии с вариантом осуществления настоящего изобретения.

[0016] Фиг.8 - общая схема системы, в которой может быть реализовано настоящее изобретение.

[0017] Фиг.9 - вид в перспективе мобильного телефона, который может быть использован для осуществления настоящего изобретения.

[0018] Фиг.10 - схематическое представление схем мобильного телефона, изображенного на фиг.9.

Подробное описание предпочтительных вариантов осуществления изобретения

[0019] Настоящее изобретение содержит новый механизм удаления для использования в мультимедийных службах SIP. Настоящее изобретение включает использование для этой цели различных особенностей среды мультимедийных служб SIP. В одном варианте реализации изобретения в сети предусмотрена «корзина» или подобное место для удаленных элементов, которое связано с унифицированным идентификатором ресурса (URI) SIP. Сообщениям, хранящимся в сети, назначены уникальные идентификаторы. Если пользователь желает удалить сообщение, он делает запрос, чтобы между сообщением и сетевой корзиной была установлена функция сеанса SIP/MSRP. После обработки сообщение с аккаунта пользователя на сервере хранения пользовательской почты перемещается в корзину.

[0020] Фиг.1 - блок-схема, показывающая работу механизма удаления для мультимедийных служб SIP в соответствии с одним вариантом осуществления настоящего изобретения. В частности, на фиг.1 показано описанное здесь взаимодействие между пользовательским/клиентским устройством 100, пользовательским аккаунтом в почтовом хранилище 110 и корзиной 120. И пользовательский аккаунт 110, и корзина 120 расположены удаленно от пользовательского/клиентского устройства. В варианте осуществления, показанном на фиг.1, SIP URI для пользовательского/клиентского устройства является следующим “User@Sonera.com”. SIP URI для пользовательского аккаунта - “User@mailserver57.Sonera.com”. SIP URI для корзины “RecycleBin@mailserver.sonera.com”.

[0021] Как говорилось ранее, сохраненным в сети сообщениям могут быть назначены уникальные идентификаторы сообщений. Три таких сообщения показаны на фиг.1 под номером 130 и имеют идентификаторы “13242@mailserver57.Sonera.com” (MSG 1) “13243@mailserver57.Sonera.com” (MSG 2) и “13244@mailserver57.Sonera.com” (MSG 3). В качестве альтернативы сообщения могут храниться в виде файлов. В одном варианте реализации изобретения каждое сообщение может быть снабжено именем файла, типом файла и значением хэша. Три таких сообщения показаны на фиг.2 с идентификаторами “Файл 1=(имя_файла, тип_файла, уникальное_значение_хэша)”, “Файл 2=(имя_файла, тип_файла, уникальное_значение_хэша)” и “Файл 1=(имя_файла, тип_файла, уникальное_значение_хэша)”.

[0022] На шаге 140 на фиг.1 пользователь решает, что он хочет удалить сообщение MSG 2. В это время пользовательское/клиентское устройство 100 отправляет запрос SIP REFER «INVITE» 150 на идентификатор сообщения 13243@mailserver57.Sonera.com, который служит виртуальным агентом 155 пользователя на пользовательском аккаунте 110. Запрос SIP REFER имеет в заголовке «Refer-to» адрес сетевой корзины (RecycleBin@mailserver.sonera.com). Запрос SIP REFER «INVITE» 150 служит для запроса на установление сеанса SIP с сетевой корзиной 120 (RecycleBin@mailserver.sonera.com). Виртуальный агент 155 пользователя отвечает приемом запроса SIP REFER от пользовательского/клиентского устройства 100, индицируя это сообщением “202 ACCEPT” на шаге 160. Виртуальный агент 155 пользователя также отправляет запрос INVITE для установления сеанса связи SIP с корзиной 120 на шаге 170. Корзина 120 принимает этот сеанс на шаге 180. На шаге 190 сеанс SIP официально устанавливается с виртуальным агентом 155 пользователя по Протоколу ретрансляции сообщений сеанса связи (MSRP - message session relay protocol), при этом атрибут “media” протокола SDP (протокол описания сеанса связи - session description protocol) устанавливается на a=SendOnly. На шаге 200 виртуальный агент 155 пользователя уведомляет пользователя/клиента 100 сеанса SIP, и пользовательское/клиентское устройство 100 на шаге 210 подтверждает это уведомление. В сеансе связи SIP/MSRP сообщение MSG 2 отправляется с пользовательского аккаунта 110 в сетевую корзину 120, в результате чего сообщение MSG 2 пропадает с пользовательского аккаунта 110. После удачной передачи сообщения MSG 2 сеанс SIP между виртуальным агентом 155 пользователя и корзиной 120 прекращается. Конечным результатом, показанным на шаге 220, является наличие на пользовательском аккаунте 110 на сервере хранения пользовательской почты только сообщений MSG 1 и MSG 3.

[0023] В альтернативном варианте осуществления настоящего изобретения функции пользовательского аккаунта 110 и корзины 120 совмещены. В данной ситуации отправка запроса INVITE для установления сеанса SIP 170, подтверждение 180 приема этого запроса и установление 190 сеанса SIP с MSRP необязательны.

[0024] Альтернативный вариант осуществления, в котором сообщения хранятся в виде файлов, показан на фиг.2. В этом варианте механизм извлечения сохраненных или выбранных сообщений в корзину может быть основан на схеме передачи файлов согласно Приложению В, которое включено в настоящую заявку. В данном варианте запрос REFER может включать описания SDP удаляемого файла(-ов).

[0025] На шаге 140 на фиг.2 пользователь решает, что он хочет удалить сообщение MSG 2 (файл 2). В это время пользовательское/клиентское устройство 100 отправляет запрос SIP REFER «INVITE» 150 на сервер хранения почты, который служит виртуальным агентом 155 пользователя на пользовательском аккаунте 110. Запрос SIP REFER имеет в заголовке «Refer-to» адрес сетевой корзины

(RecycleBin@mailserver.sonera.com). Запрос SIP REFER «INVITE» 150 служит для запроса на установление сеанса SIP с сетевой корзиной 120 (RecycleBin@mailserver.sonera.com). Виртуальный агент 155 пользователя отвечает приемом запроса SIP REFER от пользовательского/клиентского устройства 100, индицируя это сообщением “202 ACCEPT” на шаге 160. Виртуальный агент 155 пользователя также отправляет запрос INVITE для установления сеанса связи SIP с корзиной 120 на шаге 170. Корзина 120 принимает этот сеанс на шаге 180. На шаге 190 сеанс SIP официально устанавливается с виртуальным агентом 155 пользователя по протоколу ретрансляции сообщений сеанса связи (MSRP - message session relay protocol), при этом атрибут “media” протокола SDP (протокол описания сеанса связи - session description protocol) устанавливается на a=SendOnly. На шаге 200 виртуальный агент 155 пользователя уведомляет пользователя/клиента 100 сеанса SIP, и пользовательское/клиентское устройство 100 на шаге 210 подтверждает прием этого уведомления. В сеансе связи SIP/MSRP Файл 2 отправляется с пользовательского аккаунта 110 в сетевую корзину 120, в результате чего сообщение MSG 2 пропадает с пользовательского аккаунта 110. После удачной передачи Файла 2 (MSG 2) сеанс SIP между виртуальным агентом 155 пользователя и корзиной 120 прекращается. Конечным результатом, показанным на шаге 220, является наличие на пользовательском аккаунте 110 на сервере хранения пользовательской почты только сообщений MSG 1 (Файл 1) и MSG 3 (Файл 3).

[0026] В альтернативном варианте осуществления настоящего изобретения функции пользовательского аккаунта 110 и корзины 120 совмещены. В данной ситуации отправка запроса INVITE для установления сеанса SIP 170, подтверждение 180 приема этого запроса и установление 190 сеанса SIP с MSRP необязательны.

[0027] На фиг.3 показан альтернативный вариант осуществления настоящего изобретения. В данном варианте запрос SIP REFER «INVITE» отправляется непосредственно в сетевую корзину, обходя виртуального агента пользователя. Например, на шаге 340 на фиг.3 пользователь решает, что он хочет удалить сообщение MSG 2. В это время пользовательское/клиентское устройство 100 отправляет запрос SIP REFER «INVITE» 350 корзине 120 (RecycleBin@mailserver.sonera.com). Запрос SIP REFER «INVITE» 350 служит для запроса на установление сеанса SIP между сетевой корзиной 120 (RecycleBin@mailserver.sonera.com) и пользовательским аккаунтом 110 или виртуальным агентом 155 пользователя, если он используется. Корзина 120 отвечает приемом запроса SIP REFER от пользовательского/клиентского устройства 100, индицируя это сообщением “202 ACCEPT” на шаге 360. Корзина 120 также отправляет запрос INVITE для установления сеанса связи SIP с виртуальным агентом 155 пользователя на шаге 370. Виртуальный агент 155 пользователя принимает этот сеанс на шаге 380. На шаге 390 сеанс SIP официально устанавливается с виртуальным агентом 155 пользователя по протоколу ретрансляции сообщений сеанса связи (MSRP - message session relay protocol), при этом атрибут “media” протокола SDP (протокол описания сеанса связи - session description protocol) устанавливается на a=RecvOnly. На шаге 400 корзина 120 уведомляет пользователя/клиента 100 сеанса SIP, и пользовательское/клиентское устройство 100 на шаге 410 подтверждает прием этого уведомления. В сеансе связи SIP/MSRP сообщение MSG 2 отправляется с пользовательского аккаунта 110 в сетевую корзину 120, в результате чего сообщение MSG 2 пропадает с пользовательского аккаунта 110. После удачной передачи сообщения MSG 2 сеанс SIP между виртуальным агентом 155 пользователя и корзиной 120 прекращается. Конечным результатом, показанным на шаге 420, является наличие на пользовательском аккаунтэ 110 на сервере хранения пользовательской почты только сообщений MSG 1 и MSG 3.

[0028] Подобно вышеуказанным вариантам осуществления настоящего изобретения, в качестве альтернативы функции пользовательского аккаунта 110 и корзины 120 могут быть совмещены. В данной ситуации отправка запроса INVITE для установления сеанса SIP 370, подтверждение 380 приема этого запроса и установление 390 сеанса SIP с MSRP необязательны.

[0029] Вариант осуществления настоящего изобретения, изображенный на фиг.4, является альтернативой варианту на фиг.3. Подобно фиг.3, в данном варианте запрос SIP REFER «INVITE» отправляется непосредственно в сетевую корзину, обходя виртуального агента пользователя. Однако в варианте на фиг.4 механизм извлечения сохраненных или выбранных сообщений в корзину может быть основан на схеме передачи файлов, описанной в Приложении В. В данном варианте запрос REFER включает описания SDP удаляемого файла(-ов).

[0030] На шаге 340 на фиг.4 пользователь решает, что он хочет удалить сообщение MSG 2 (Файл 2). В это время пользовательское/клиентское устройство 100 отправляет запрос SIP REFER «INVITE» 350 корзине 120 (RecycleBin@mailserver.sonera.com). Запрос SIP REFER «INVITE» 350 служит для запроса на установление сеанса SIP с сетевой корзиной 120 (RecycleBin@mailserver.sonera.com). Корзина 120 отвечает приемом запроса SIP REFER от пользовательского/клиентского устройства 100, индицируя это сообщением “202 ACCEPT” на шаге 360. Корзина 120 также отправляет запрос INVITE для установления сеанса связи SIP с виртуальным агентом 155 пользователя на шаге 370. Виртуальный агент 155 пользователя принимает этот сеанс на шаге 380. На шаге 390 сеанс SIP официально устанавливается с виртуальным агентом 155 пользователя по протоколу ретрансляции сообщений сеанса связи (MSRP -message session relay protocol), при этом атрибут “media” протокола SDP (протокол описания сеанса связи - session description protocol) устанавливается на a=RecvOnly. На шаге 400 корзина 120 уведомляет пользователя/клиента 100 сеанса SIP, и пользовательское/клиентское устройство 100 на шаге 410 подтверждает прием этого уведомления. В сеансе связи SIP/MSRP Файл 2 (MSG 2) отправляется с пользовательского аккаунта 110 в сетевую корзину 120, в результате чего Файл 2 (MSG 2) пропадает с пользовательского аккаунта 110. После удачной передачи Файла 2 (MSG 2) сеанс SIP между виртуальным агентом 155 пользователя и корзиной 120 прекращается. Конечным результатом, показанным на шаге 420, является наличие на пользовательском аккаунте 110 на сервере хранения пользовательской почты только Файла 1 (MSG 1) и Файла 3 (MSG 3).

[0031] Подобно вышеуказанным вариантам осуществления настоящего изобретения, в качестве альтернативы функции пользовательского аккаунта 110 и корзины 120 могут быть совмещены. В данной ситуации отправка запроса INVITE для установления сеанса SIP 370, подтверждение 380 приема этого запроса и установление 390 сеанса SIP с MSRP необязательны.

[0032] В другом варианте осуществления изобретения пользователем может быть выбрана и удалена группа сохраненных сообщений. В данном варианте, показанном на фиг.5, корзине 120 может быть отправлен групповой запрос Multiple-REFER для удаления группы выбранных сообщений - см. Приложение А, которое включено в данную заявку и показывает один из вариантов реализации группового запроса Multiple-REFER. В варианте, изображенном на фиг.5, запрос SIP Multiple-REFER «INVITE» отправляется непосредственно в сетевую корзину, обходя виртуального агента пользователя. В качестве альтернативы запрос SIP Multiple-REFER «INVITE» может быть отправлен виртуальному агенту пользователя, как было описано относительно варианта, показанного на фиг.1.

[0033] На шаге 540 на фиг.5 пользователь решает, что он хочет удалить сообщения MSG 2 и MSG 3. В это время пользовательское/клиентское устройство 100 отправляет корзине 120 (RecycleBin@mailserver.sonera.com) запрос SIP Multiple-REFER «INVITE» 550, включающий список URI, который содержит URI удаляемых сохраненных сообщений (в данной ситуации, MSG 2 и MSG 3). Запрос SIP Multiple-REFER «INVITE» 550 служит для запроса на установление сеансов SIP с сетевой корзиной 120 (RecycleBin@mailserver.sonera.com). Корзина 120 отправляет запросы INVITE для установления сеансов SIP с виртуальными агентами 155 и 156 пользователей на этапах 570 и 571 соответственно, один сеанс для каждого удаляемого сообщения. В данном случае запрос INVITE 570 соответствует MSG 2, а запрос INVITE 571 соответствует MSG 3. Виртуальные агенты 155 и 156 пользователей принимают эти сеансы связи на этапах 580 и 581 соответственно. На шаге 590 сеанс SIP официально устанавливается с виртуальным агентом 155 пользователя по Протоколу ретрансляции сообщений сеанса связи (MSRP - message session relay protocol), при этом атрибут “media” протокола SDP (протокол описания сеанса связи - session description protocol) устанавливается на a=RecvOnly, и на шаге 591 сеанс SIP устанавливается с виртуальным агентом 156 пользователя. В сеансах связи SIP/MSRP сообщения MSG 2 и MSG 3 отправляются с пользовательского аккаунта 110 в сетевую корзину 120, в результате чего сообщения MSG 2 и MSG 3 пропадают с пользовательского аккаунта 110. После удачной передачи сообщений MSG 2 и MSG 3 сеанс SIP между виртуальными агентами 155 и 156 пользователей и корзиной 120 прекращается. Конечным результатом, показанным на шаге 620, является наличие на пользовательском аккаунте 110 на сервере хранения пользовательской почты только сообщения MSG 1.

[0034] Подобно рассмотренным выше вариантам осуществления настоящего изобретения, в качестве альтернативы функции пользовательского аккаунта 110 и корзины 120 также могут быть совмещены. В данной ситуации отправка запросов INVITE для установления сеансов SIP 570 и 571, подтверждение 580 и 581 приема этих запросов и установление 590 и 591 сеанса SIP с MSRP необязательны.

[0035] Вариант, изображенный на фиг.6, показывает механизм группового удаления сообщений, когда механизм извлечения сохраненных или выбранных сообщений в корзину основан на схеме передачи файлов, описанной в Приложении В. В данном варианте запрос REFER также включает описания SDP удаляемых файлов. На шаге 540 на фиг.6 пользователь решает, что он хочет удалить сообщения MSG 2 (Файл 2) и MSG 3 (Файл 3). В это время пользовательское/клиентское устройство 100 отправляет корзине 120 (RecycleBin@mailserver.sonera.com) запрос SIP REFER «INVITE» 550, используя синтаксис, описанный в Приложении В для удаляемых сохраненных сообщений (файлов) (в данной ситуации MSG 2 и MSG 3). В этом случае параметры SDP для каждого удаляемого файла (сообщения) должны отправляться в отдельной строке media “m=”. Запрос SIP REFER «INVITE» 550 служит для запроса на установление сеансов SIP между сетевой корзиной 120 () и пользовательским аккаунтом 110 или виртуальным агентом 155 пользователя, если он используется. Корзина 120 отправляет запросы INVITE для установления сеансов связи SIP с виртуальным агентом 155 пользователя на шаге 570. Виртуальный агент 155 пользователя принимает сеанс связи для каждого удаляемого файла на этапах 580 и 581 соответственно. На шаге 590 сеанс SIP официально устанавливается с виртуальным агентом 155 пользователя по Протоколу ретрансляции сообщений сеанса связи (MSRP - message session relay protocol), при этом атрибут “media” протокола SDP (протокол описания сеанса связи - session description protocol) устанавливается на a=RecvOnly, и на шаге 591 сеанс SIP устанавливается с виртуальным агентом 156 пользователя. В сеансах связи SIP/MSRP Файл 2 (MSG 2) и Файл 3 (MSG 3) отправляются с пользовательского аккаунта 110 в сетевую корзину 120, в результате чего Файл 2 (MSG 2) и Файл 3 (MSG 3) пропадают с пользовательского аккаунта 110. После удачной передачи Файла 2 (MSG 2) и Файла 3 (MSG 3) сеансы SIP между виртуальным агентом 155 пользователя и корзиной 120 прекращаются. Конечным результатом, показанным на шаге 620, является наличие на пользовательском аккаунте 110 на сервере хранения пользовательской почты только Файла 1 (MSG 1).

[0036] Подобно рассмотренным выше вариантам осуществления настоящего изобретения, в качестве альтернативы функции пользовательского аккаунта 110 и корзины 120 также могут быть совмещены. В данной ситуации отправка запросов INVITE для установления сеансов SIP 570 и 571, подтверждение 580 и 581 приема этих запросов и установление 590 и 591 сеанса SIP с MSRP необязательны.

[0037] В еще одном варианте осуществления изобретения пользователем могут быть выбраны и удалены все сохраненные сообщения. В данном варианте, показанном на фиг.7, корзине 120 может быть отправлен запрос REFER для удаления всех сообщений, что выполняется посредством отсылки идентификатора SIP URI пользовательского почтового аккаунта вместо отдельного сообщения или списка URI сообщений. Опять же, в варианте на фиг.7 запрос SIP REFER «INVITE» отправляется непосредственно в сетевую корзину, обходя виртуального агента пользователя. В качестве альтернативы запрос SIP REFER «INVITE» может быть отправлен виртуальному агенту пользователя, как было описано относительно варианта, показанного на фиг.1.

[0038] На шаге 740 на фиг.7 пользователь решает, что он хочет удалить все сообщения с его почтового аккаунта. В это время пользовательское/клиентское устройство 100 отправляет корзине 120 (RecycleBin@mailserver.sonera.com) запрос SIP REFER «INVITE» 750, включающий SIP URI пользовательского почтового аккаунта (в данной ситуации User@mailserver57.Sonera.com). Запрос SIP REFER «INVITE» 750 служит для запроса на установление сеанса SIP между сетевой корзиной 120 (RecycleBin@mailserver.sonera.com) и пользовательским аккаунтом 110 или виртуальным агентом 155 пользователя, если он используется. Корзина 120 отвечает приемом запроса SIP REFER от пользовательского/клиентского устройства 100, индицируя это сообщением “202 ACCEPT” на шаге 760. Корзина 120 также отправляет запрос INVITE для установления сеанса связи SIP с виртуальным агентом 155 пользователя на шаге 770. Виртуальный агент 155 пользователя принимает этот сеанс на шаге 780. На шаге 790 сеанс SIP официально устанавливается с виртуальным агентом 155 пользователя по Протоколу ретрансляции сообщений сеанса связи (MSRP -message session relay protocol), при этом атрибут “media” протокола SDP (протокол описания сеанса связи - session description protocol) устанавливается на a=RecvOnly. На шаге 800 корзина 120 уведомляет пользователя/клиента 100 сеанса SIP, и пользовательское/клиентское устройство 100 на шаге 810 подтверждает прием этого уведомления. В сеансах связи SIP/MSRP все сообщения, хранящиеся на пользовательском почтовом аккаунте (в данном случае MSG 1, MSG 2 и MSG 3), отправляются с пользовательского аккаунта 110 в сетевую корзину 120, в результате чего все сообщения пропадают с пользовательского аккаунта 110. После удачной передачи всех сообщений с пользовательского почтового аккаунта сеанс SIP между виртуальным агентом 155 пользователя и корзиной 120 прекращается. Конечным результатом, показанным на шаге 820, является отсутствие сообщений на пользовательском аккаунте 110 на сервере хранения пользовательской почты.

[0039] Подобно рассмотренным выше вариантам осуществления настоящего изобретения, в качестве альтернативы функции пользовательского аккаунта 110 и корзины 120 также могут быть совмещены. В данной ситуации отправка запросов INVITE для установления сеанса SIP 770, подтверждения 780 приема запроса и установление 790 сеанса SIP с MSRP необязательны.

[0040] На фиг.8 показана система 10, в которой может быть использовано настоящее изобретение, включающая разнообразные устройства связи, которые могут обмениваться информацией по сети. Система 10 может содержать любое сочетание проводных или беспроводных сетей, в том числе мобильную телефонную сеть, беспроводную локальную сеть (LAN), персональную сеть Bluetooth, Ethernet LAN, локальную сеть Token Ring («маркерное кольцо»), глобальную сеть (WAN), Интернет и т.д., но не ограничена этими сетями. Система 10 может включать и проводные, и беспроводные устройства связи.

[0041] Например, система 10, показанная на фиг.8, содержит мобильную телефонную сеть 11 и Интернет 28. Возможности подключения к Интернету 28 могут включать, но не ограничиваются, средства беспроводной связи дальнего действия, средства беспроводной связи ближнего действия и различные проводные средства связи, включая, но не ограничиваясь этим, телефонные линии, кабельные линии, линии электропитания и т.п.

[0042] Примеры устройств связи в системе 10 могут включать, но не ограничиваются этим, мобильный телефон 12, сочетание PDA (персональный цифровой помощник - personal digital assistant) и мобильного телефона 14, PDA 16, встроенное устройство для обмена сообщениями 18 (IMD - integrated messaging device), настольный компьютер 20 и ноутбук 22. Устройства связи могут быть стационарными или мобильными, когда их носят перемещающиеся лица. Также устройства связи могут быть расположены в транспортном средстве, включая, но не ограничиваясь этим, легковой автомобиль, грузовик, такси, автобус, катер, самолет, велосипед, мотоцикл и т.д. Некоторые или все устройства связи могут совершать и принимать звонки, отправлять и получать сообщения и осуществлять связь с провайдерами услуг через беспроводную связь 25 с базовой станцией 24. Базовая станция 24 может быть подключена к сетевому серверу 26, обеспечивающему связь между мобильной телефонной сетью 11 и Интернетом 28. Система 10 может включать дополнительные устройства связи и устройства связи других типов.

[0043] На фиг.9 и 10 показан образец мобильного телефона 12, в котором может быть реализовано настоящее изобретение. Однако необходимо понимать, что настоящее изобретение не должно ограничиваться определенным типом мобильного телефона 12 или другого электронного устройства. Другие типы электронных устройств, которые могут быть использованы, включают, но не ограничиваются этим, PDA 16, сочетание PDA и мобильного телефона 14, мобильный телефрн 14, IMD 18, настольный компьютер 20 и ноутбук 22. Устройства связи могут быть стационарными или мобильными, когда их носят перемещающиеся лица. Также устройства связи могут быть расположены в транспортном средстве, включая, но не ограничиваясь этим, легковой автомобиль, грузовик, такси, автобус, катер, самолет, велосипед, мотоцикл и т.д.

[0044] Мобильный телефон 12 на фиг.9 и 10 содержит корпус 30, экран 32 в виде жидкокристаллического дисплея, клавиатуру 34, микрофон 36, наушники 38, батарею 40, инфракрасный порт 42, антенну 44, смарт-карту 46 в форме UICC в соответствии с вариантом осуществления изобретения, устройство 48 считывания карт, схему 52 радиоинтерфейса, схему кодека 54, контроллер 56 и память 58. Типы отдельных схем и элементов хорошо известны в технике, например в линейке мобильных телефонов Nokia. Например, система 10, показанная на фиг.8, содержит мобильную телефонную сеть 11 и Интернет 28. Возможности подключения к Интернету 28 могут включать, но не ограничиваются этим, средства беспроводной связи дальнего действия, средства беспроводной связи ближнего действия и различные проводные средства связи, включая, но не ограничиваясь этим, телефонные линии, кабельные линии, линии электропитания и т.п.

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

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

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

Приложение А

Рабочая группа по SIP	G. Camarillo
Интернет-проект документа	Ericsson
Срок действия: 24 апреля 2006 г.	A. Niemi
	M. Isomaki
	М.Garcia-Martin
	Nokia
	Н. Khartabil
	Telio
	21 октября 2005 г.

Указание на несколько ресурсов в протоколе инициирования сеанса связи (SIP - Session Initiation Protocol)

draft-ietf-sipping-multiple-refer-04.txt

Статус этой записки

Представляя данный Интернет-проект, каждый автор заявляет, что в нем раскрыт или будет раскрыт любой известный ему применимый патент или другие патентные формулы IPR, а также будет раскрыт любой из таких документов, с которым автор ознакомится в будущем, в соответствии с Разделом 6 ВСР 79.

Интернет-проекты язляются рабочими документами Комитета по инженерным вопросам Internet (IETF), его сферы деятельности и рабочих групп. Необходимо заметить, что другие группы также могут распространять рабочие документы как Интернет-проекты.

Интернет-проекты являются черновыми документами, которые действительны не более 6 месяцев и могут обновляться или заменяться другими документами в любое время. Нецелесообразно использовать Интернет-проекты в качестве ссылочного материала или цитировать их иначе, чем «работа в процессе».

Текущий список Интернет-проектов может быть получен по адресу http.//www.ietf.org/ietf/lid-abstracts.txt.

Текущий список теневых каталогов Интернет-проектов может быть получен по адресу http://www.ietf.org/ietf/shadow.txt.

Срок действия данного Интернет-проекта истекает 24 апреля 2006 года.

Уведомление об авторских правах Copyright (С) The Internet Society (2005)

Реферат

Данный документ определяет расширения метода REFER протокола инициирования сеанса связи (SIP), предназначенные для того, чтобы этот метод мог быть использован для направления сервера на множественные ресурсы. Эти расширения включают использование указателей на списки унифицированных идентификаторов ресурса (URI) в поле заголовка Refer-To и опциональную метку SIP “multiple-refer” (групповая ссылка).

Содержание

1. Введение

2. Терминология

3. Краткий обзор принципа действия

4. Опциональная метка SIP "multiple-refer"

5. Запрет неявной подписки REFER

6. Принцип действия REFER-Отправителей протокола SIP

7. Принцип действия REFER-Получателей

8. Формат списка URI по умолчанию

9. Пример

10. Соображения безопасности

11. Соображения IANA

12. Ссылки

12.1 Нормативные ссылки

12.2 Информационные ссылки

Адреса авторов

Положения об интеллектуальной собственности и авторских правах

1. Введение

Метод REFER [3] протокола SIP [3] позволяет агенту пользователя совершать запрос серверу на отправку запроса третьей стороне. Однако ряду систем требуется делать запрос серверу для запуска транзакций с некоторым количеством адресатов. В одном примере модератор конференции может захотеть, чтобы сервер конференции отправил запросы BYE группе участников. В другом примере этот же модератор конференции может захотеть, чтобы сервер конференции отправил запросы INVITE некоторому количеству новых участников.

Мы определяем расширение REFER, такое, чтобы запрос REFER мог быть использован для направления серверов на несколько адресатов. Помимо этого мы используем расширение REFER, оговоренное в [7], которое запрещает неявную подписку REFER.

2. Терминология

В данном документе ключевые слова «ОБЯЗАН», «НЕ ОБЯЗАН», «НЕОБХОДИМО», «ДОЛЖЕН», «НЕ ДОЛЖЕН», «РЕКОМЕНДУЕТСЯ», «НЕ РЕКОМЕНДУЕТСЯ», «МОЖЕТ» и «ПО УСМОТРЕНИЮ» должны толковаться, как описано в документе ВСР 14, RFC 2119 [1], и указывают уровень требований для соответствующих вариантов реализации.

Мы даем определения следующим трем новым терминам:

REFER-Отправитель: агент пользователя, подающий запрос REFER.

REFER-Получатель: агент пользователя, принимающий запрос REFER.

REFER-Адресат: заданный конечный получатель запроса, генерируемый REFER-Получателем.

3. Краткий обзор принципа действия

Данный документ определяет расширение метода REFER протокола SIP [5], который позволяет Клиенту агента пользователя (UAC - User Agent Client) включать в запрос REFER список REFER-Адресатов и отправлять его на сервер. Сервер создаст новый запрос для каждой записи в списке URI REFER-Адресатов.

Мы представляем несколько REFER-Адресатов запроса REFER при использовании списка URI. UAC (Клиент агента пользователя), который хочет направить сервер на некоторое количество адресатов, формирует запрос SIP REFER. Заголовок Refer-To содержит указатель на список URI, который включен в тело, и опциональную метку “multiple-refer” в поле заголовка Required. Эта опциональная метка указывает на необходимость поддержки функций, описанных в данной спецификации.

Когда сервер получает такой запрос, он создает новые запросы для каждого адресата и отправляет их.

Этот документ не предоставляет какого-либо механизма для UAC (клиентов агентов пользователей) для определения результатов запроса REFER с несколькими REFER-Адресатами. Также он не предоставляет поддержки механизма неявной подписки, который является частью метода SIP REFER. Способ, которым UAC получают информацию о результатах запроса REFER, индивидуален для конкретной службы. Например, UAC, отправляющий запрос REFER для INVITE (приглашения) в конференцию некоторого количества участников, может определять, какие участники успешно присоединились к конференции, посредством подписки на события состояния конференции [9].

4. Опциональная метка SIP “multiple-refer”

Мы определяем новую опциональную метку SIP для полей заголовков Require и Supported: “multiple-refer”.

Агент пользователя, зключающий опциональную метку “multiple-refer” в заголовок Supported, показывает совместимость с данной спецификацией.

Агент пользователя, формирующий за