МЕХАНИЗМ УДАЛЕНИЯ СООБЩЕНИЯ ИЛИ ФАЙЛА В МУЛЬТИМЕДИЙНЫХ СЛУЖБАХ, РАБОТАЮЩИХ ПО ПРОТОКОЛУ 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 - 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, показывает совместимость с данной спецификацией.
Агент пользователя, формирующий запрос REFER с указателем на список URI в его поле заголовка Refer-To, ОБЯЗАН включить опциональную метку “multiple-refer” в поле заголовка Require запроса REFER.
5. Запрет неявной подписки REFER
Запросы REFER с одним REFER-Адресатом неявно устанавливают подписку на событие направления. Посредством этой неявной подписки REFER-Отправитель информируется о результате транзакции с REFER-Адресатом. Как описано в документе RFC 3515 [5], запросы NOTIFY, отправленные в результате созданной запросом REFER неявной подписки, содержат тело типа “message/sipfrag” [4], которое описывает состоянии транзакции, запущенной REFER-Получателем.
В случае, когда REFER-Отправитель формирует запрос REFER с несколькими REFER-Адресатами, REFER-Отправитель обычно уже подписан на другой пакет событий, который может предоставить информацию о результате транзакций с REFER-Адресатами. Например, модератор, дающий серверу конференции инструкцию отправить запрос BYE некоторому количеству участников, обычно подписан на пакет событий состояния конференции. Уведомления этого пакета событий будут информировать модератора и подписчиков о текущем списке участников конференции.
Большая часть систем, использующих групповой запрос, не требует неявной подписки. Следовательно, REFER-Отправитель протокола SIP, формирующий запрос REFER с несколькими REFER-Адресатами, ДОЛЖЕН включить в поле заголовка Require опциональную метку “norefersub”, чтобы показать, что REFER-Отправителю не надо посылать уведомлений о запросах. Опциональная метка "norefersub" протокола SIP определена в [7] и запрещает неявную подписку.
В момент написания документа не существовало расширения, позволяющего сообщать о состоянии отдельных транзакций через неявную подписку. Это является в данном документе основанием для предложения использовать опциональную метку "norefersub". Если в будущем такое расширение будет определено, использующие его REFER-Отправители могут вместо опциональной метки "norefersub" использовать новое расширение.
6. Принцип действия REFER-Отправителей протокола SIP
Как показано в Разделе 4 и Разделе 5, REFER-Отправитель протокола SIP, который создает запрос REFER с несколькими REFER-Адресатами, включает в поле заголовка Require опциональные метки “multiple-refer” и “norefersub”.
Поле заголовка Refer-To запроса REFER с несколькими REFER-Адресатами ОБЯЗАНО содержать указатель (например, идентифицирующий контент унифицированный указатель ресурса (URL - Uniform Resource Locator) [2]), который указывает на часть тела, содержащую список URI. REFER-Отправитель НЕ ДОЛЖЕН включать в список URI какой-либо отдельный URI более одного раза.
7. Принцип действия REFER-Получателей
REFER-Получатель для определения кода состояния ответа на запрос REFER следует правилам, указанным в разделе 2.4.2 документа RFC 3515 [5].
Если список URI содержит один URI более одного раза, REFER-Получатель должен вести себя так, как будто этот URI появился в списке URI только один раз. Для определения наличия повторения какого-либо URI более одного раза REFER-Получатель использует особые правила сравнения каждого URI из списка URI.
Для формирования необходимых запросов REFER-Адресатам REFER-Получатель следует правилам, изложенным в документе RFC 2515 [5], действуя так, как будто он принял обычные (без списка URI) запросы REFER для каждого URI из списка URI.
8. Формат списка URI по умолчанию
Формат тела списка URI по умолчанию, используемый в групповом запросе REFER, является документом списка ресурсов, который определен в [6]. Агенты пользователей, имеющие возможность формировать или принимать запросы REFER с несколькими REFER-Адресатами, ОБЯЗАНЫ поддерживать данный формат, как указано в [6], и МОГУТ поддерживать другие форматы.
Тем не менее, документ списка ресурсов в протоколе ХСАР - Протоколе доступа к конфигурации (Configuration Access Protocol) языка XML (Extensible Markup Language - расширяемый язык разметки) - предоставляет дополнительные возможности, такие как иерархические списки и возможность включения записей посредством ссылки относительно корневого URI протокола ХСАР, которые не требуются службе REFER, описанной в данном документе. Поэтому при использовании документа списка ресурсов по умолчанию SIP REFER-Отправители, формирующие запросы REFER с несколькими REFER-Адресатами, ДОЛЖНЫ использовать простые списки (т.е. не иерархические) и НЕ ДОЛЖНЫ использовать элементы <entry-ref>.
REFER-Получатель, принимающий список URI, в котором информации больше, чем было только что описано, может пренебречь всей избыточной информацией.
Ниже на фиг.1 показан пример простого списка, который следует документу списка ресурсов.
<?xml version=”1.0” encoding=”UTF-8”?>
<resource-lists xmlns=”urn:ietf:params:xml:ns:resource-lists”
xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance”>
<list>
<entry uri=”sip:mailto:bill@example.com” />
<entry uri=”sip:mailto:joe@iexample.org” />
<entry uri=”sip:mailto:ted@example.net” />
</list>
</resource-lists>
Фиг.1: Список URI
9. Пример
На фиг.2 показан пример процесса, в котором REFER-Отправитель посылает групповой запрос REFER в центр конференции, служащий REFER-Получателем. REFER-Получатель формирует запрос BYE для каждого REFER-Адресата. (Как использовать запрос REFER для удаления участников из конференции, указано в [10]).
|
Фиг.2: Пример процесса или запроса REFER, содержащего несколько REFER-Адресатов
Запрос REFER (1) содержит поле заголовка Rerer-To, которое включает указатель на тело сообщения, содержащее список с URI REFER-Адресатов. Поле заголовка Require запроса REFER содержит опциональные метки “multiple-refer” и “norefersub”. На фиг.3 показан пример этого запроса REFER. Документ списка ресурсов содержит список URI REFER-Адресатов, соответствующий запросу SIP, который формирует REFER-Получатель.
REFER sip:mailto:conf-123@example.com SIP/2.0
Via: SIP/2.0/TCP http://client.chicago.example.com
; branch=z9hG4bKhjhs8ass83
Max-Forwards: 70
To: “Conference 123”<sip:mailto:conf-123@example.com>
From: Carol<sip:carol@chicago.example.com>;tag=32331 Call-ID: d432fa84b4c76e66710 CSeq: 2 REFER
Contact:<sip:mailto:carol@client.Chicago.example.com>
Refer-To:<mailto:cid:cn35t8jf02@example.com>
Require: multiple-refer, norefersub
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Allow-Events: dialog
Accept: application/sdp, message/sipfrag
Content-Type: application/resource-lists+xml
Content-Disposition: uri-list
Content-Length: 307
Content-ID: mailto:cn35t8jf02@example.com
<?xml version=”1.0” encoding=”UTF-8”?>
<resource-lists xmlns=”urn:ietf:params:xml:ns:resource-lists”
xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance”>
<list>
<entry uri=”sip:bill@example.com?method=BYE” />
<entry uri=”sip:joe@example.org?method=BYE” />
<entry uri=”sip:ted@example.net?method=BYE” />
</list>
</resource-lists>
Фиг.3: Запрос REFER с несколькими REFER-Получателями
На фиг.4 показан пример запроса BYE (3), который REFER-Получатель отправляет первому REFER-Адресату.
BYE sip:mailto:bill@example.com SIP/2.0
Via: SIP/2.0/TCP conference.example.com
;branch=z9hG4bKhjhs8assmm Max-Forwards: 70
From: “Conference 123”<sip:conf-123@example.com>;tag=88734
To:<sip:bill@example com>;tag=29872
Call-ID: d432faB4b4c34098s812
CSeq: 34 BYE
Content-Length: 0
Фиг.4: Запрос BYE
10. Соображения безопасности
В Соображениях о структуре и безопасности для служб списка URI в протоколе SIP [8] обсуждаются вопросы, связанные со службами списка URI протокола SIP. При условии, что сервер, принимающий запросы REFER с несколькими REFER-Адресатами, работает как служба списка URI, варианты реализации этого типа сервера должны соответствовать правилам безопасности, изложенным в [8]. В эти правила входит обязательная аутентификация и авторизация клиентов, а также списки разрешений.
Помимо этого серверы ДОЛЖНЫ принимать только запросы REFER в контексте задач, понимаемых сервером (например, конференц-связь). Подразумевается, что серверы НЕ ДОЛЖНЫ принимать запросы REFER для методов, которые они не понимают. Общей идеей этих двух правил является то, что серверы не используются в качестве «тупых» серверов, единственной функцией которых является распространение случайных сообщений, которых они не понимают.
11. Соображения IANA
В данном документе определена новая опциональная метка протокола SIP - “multiple-refer”. Эта опциональная метка должна быть зарегистрирована в реестре параметров протокола SIP.
Агенты пользователей SIP, которые помещают опциональную метку “multiple-refer” в поле поддерживаемого заголовка, понимают запросы REFER, которые содержат документ списка ресурсов, описывающий несколько REFER-Адресатов.
12. Ссылки
12.1. Нормативные ссылки
[1] Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels”, BCP 14, RFC 2119, March 1997.
[2] Levinson, E., “Content-ID and Message-ID Uniform Resource Locators”, RFC 2392, August 1998.
[3] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol”, RFC 3261, June 2002.
[4] Sparks, R., “Internet Media Type message/sipfrag”, RFC 3420, November 2002.
[5] Sparks, R., “The Session Initiation Protocol (SIP) Refer Method”, RFC 3515, April 2003.
[6] Rosenberg, J., “Extensible Markup Language (XML) Formats for Representing Resource Lists”, draft-ietf-simple-xcap-list-usage-05 (work in progress), February 2005.
[7] Levin, 0., “Suppression of Session Initiation Protocol REFER Method Implicit Subscription”, draft-ietf-sip-refer-with-norefersub-03 (work in progress), October 2005.
[8] Camarillo, G. and A. Roach, “Requirements and Framework for Session Initiation Protocol (SIP) Uniform Resource Identifier (URI)-List Services”, draft-ietf-sipping-uri-services-03 (work in progress), April 2005.
12.2. Информационные ссылки
[9] Rosenberg, J., “A Session Initiation Protocol (SIP) Event Package for Conference State”, draft-ietf-sipping-conference-package-12 (work in progress), July 2005.
[10] Johnston, A. and O. Levin, “Session Initiation Protocol Call Control -Conferencing for User Agents”, draft-ietf-sipping-cc-conferencing-07 (work in progress), June 2005.
Адреса авторов
Gonzalo Camarillo
Ericsson
Hirsalantie 11
Jorvas 0242C
Finland
Email: mailto:Gonzalo.Camarillo@ericsson.com
Aki Niemi Nokia
P.O. Box 321
NOKIA GROUP, FIN 00045 Finland
Email: mailto:Aki.Niemi@nokia.com
Markus Isomaki
Nokia
Itamerenkatu 11-13
Helsinki 00180
Finland
Email: mailto:Markus.lsomaki@nokia.com
Miguel A. Garcia-Martin
Nokia
P.O.Box 4 07
NOKIA GROUP, FIN 00045
Finland
Email: mailto:miguel.an.garcia@nokia.com
Hisham Khartabil
Telia
P.O. Box 1203
Oslo 0110
Norway
Email: mailto:Hisham.Khartabil@telio.no
Положение об интеллектуальной собственности
IETF не занимает никакой позиции по отношению к действительности или границам любых прав на интеллектуальную собственность или других прав, которые могут быть заявлены на принадлежность к реализации или использованию описанной в данном документе технологии или к объему, для которого может или не может действовать любая лицензия на такие права; также IETF сообщает, что не делало никаких независимых попыток выяснения любых подобных прав. Информацию о порядке действий относительно прав в документах RFC можно найти в документах ВСР 78 и ВСР 79.
Копии описаний IPR, выполненные для секретариата IETF, и любые подтверждения лицензий, необходимые для их действительности, или результат попытки получения генеральной лицензии или разрешения на использование таких прав собственности пользователями данной спецификации могут быть получены в сетевой базе данных IETF по адресу http://www.ietf.org/ipr.
IETF призывает все заинтересованные стороны сообщать о любых авторских правах, патентах или заявках на патенты или любых других правах собственности, которые могут защищать технологию, которая может потребоваться для реализации данного стандарта. Пожалуйста, отправьте информацию IETF по адресу ietf-ipr@ietf.org.
Ограничение ответственности
Данный документ и содержащаяся в нем информация предоставлены по принципу «как есть», и АВТОР, ОРГАНИЗАЦИЯ, КОТОРУЮ ОН ПРЕДСТАВЛЯЕТ ИЛИ КОТОРАЯ ЕГО СПОНСИРУЕТ (ПРИ НАЛИЧИИ ТАКОВОЙ), СООБЩЕСТВО ИНТЕРНЕТ И КОМИТЕТ ПО ИНЖЕНЕРНЫМ ВОПРОСАМ INTERNET ОТКАЗЫВАЮТСЯ ОТ ВСЕХ ГАРАНТИЙ ТОГО, ЧТО ИСПОЛЬЗУЕМАЯ ЗДЕСЬ ИНФОРМАЦИЯ НЕ НАРУШИТ НИКАКИХ ПРАВ ИЛИ ПОДРАЗУМЕВАЕМЫХ ГАРАНТИЙ ПРИГОДНОСТИ ДЛЯ РЫНКА ИЛИ СООТВЕТСТВИЯ КОНКРЕТНОМУ НАЗНАЧЕНИЮ.
Положение об авторских правах
Copyright (С) The Internet Society (2005). Данный документ подчиняется правам, лицензиям и ограничениям, содержащимся в документе ВСР 78, и за исключением указанных здесь случаев авторы сохраняют все их права.
Благодарность
Финансирование функции RFC Editor обеспечивается Сообществом Интернета.
Приложение В
|
Механизм для обеспечения возможности передачи файлов при помощи протокола инициирования сеанса связи (SIP - Session Initiation Protocol)
draft-garcia-sipping-file-transfer-mech-OO.txt
Статус этой записки
Представляя данный Интернет-проект, каждый автор заявляет, что в нем раскрыт или будет раскрыт любой известный ему применимый патент или другие патентные формулы IPR, а также будет раскрыт любой из таких документов, с которым автор ознакомится в будущем, в соответствии с Разделом 6 ВСР 79.
Интернет-проекты являются рабочими документами Комитета по инженерным вопросам Internet (IETF), его сферы деятельности и рабочих групп. Необходимо заметить, что другие группы также могут распространять рабочие документы как Интернет-проекты.
Интернет-проекты являются черновыми документами, которые действительны не более 6 месяцев и могут обновляться или заменяться другими документами в любое время. Нецелесообразно использовать Интернет-проекты в качестве ссылочного материала или цитировать их иначе, чем «работа в процессе».
Текущий список Интернет-проектов может быть получен по адресу http://www.ietf.org/ietf/lid-abstracts.txt.
Текущий список теневых каталогов Интернет-проектов может быть получен по адресу http://www.ietf.org/ietf/shadow.txt.
Срок действия данного Интернет-проекта истекает 27 августа 2006 года.
Уведомление об авторских правах
Copyright (С) The Internet Society (2006).
Реферат
В данном документе представлен механизм, обеспечивающий возможность передачи одного или более файла между двумя агентами пользователей (UA). Для сигнализации установления сеанса связи используется модель «предложение/ответ» протокола инициирования сеанса связи (SIP) и протокол описания сеанса связи (SDP). Для фактической передачи файлов между двумя конечными точками используется Протокол ретрансляции сообщений сеанса связи (MSRP - message session relay protocol).
Содержание
1. Введение
2. Терминология
3. Определения
4. Краткий обзор принципа действия
5. Расширения SDP
6. Принцип действия протокола
6.1. Селектор файлов
6.2. Принцип действия запросчика
6.2.1. Запросчик является отправителем файла
6.2.2. Запросчик является получателем файла
6.2.3. Предложение SDP для нескольких файлов
6.3. Принцип действия ответчика
6.3.1. Ответчик является получателем файла
6.3.2. Ответчик является отправителем файла
6.4. Использование MSRP
7. Примеры
7.1. UAC отправляет файл на UAS
7.2. UAC запрашивает файл у UAS
8. Соображения безопасности
9. Соображения IANA
10. Благодарности
11. Ссылки
11.1. Нормативные ссылки
11.2. Информационные ссылки
Адреса авторов
Положения об интеллектуальной собственности и авторских правах
1. Введение
Протокол инициирования сеанса связи (SIP) [5] предоставляет общие функции для установления и управления мультимедийными сеансами связи между пользователями. Эти сеансы часто содержат мультимедийные потоки в реальном времени, такие как голос и видео, но этим они не ограничиваются. По существу может поддерживаться любой тип мультимедийных компонентов, так как существует спецификация о том, как согласовывать его в рамках обмена «предложение/ответ» [6] протокола описания сеанса связи (SDP) [9].
Протокол MSRP (Message Session Relay Protocol) [10] является протоколом для обмена мгновенными сообщениями (IM - instant messages) в контексте сеанса связи. Спецификация протокола включает описание того, как его использовать с протоколами SIP и SDP. Кроме сообщений в открытом тексте, протокол MSRP имеет возможность передачи произвольного (двоичного) контента, совместимого с многоцелевыми расширениями электронной почты (MIME - Multipurpose Internet Mail Extensions) [2], такого как изображения или видеоклипы.
Существует много случаев, когда пользователи, участвующие в мультимедийном сеансе связи на основе протокола SIP, могут захотеть обмениваться файлами в контексте этого сеанса. В MSRP имеется возможность встраивать файлы в поток мгновенных сообщений в качестве объектов MIME. Также MSRP имеет и другие функции, которые полезны для передачи файлов. Фрагментирование сообщений обеспечивает возможность совместного использования одного транспортного соединения для передачи больших файлов и интерактивного обмена мгновенными сообщениями, не блокируя при этом мгновенные сообщения. Ретрансляторы MSRP [4] предоставляют механизм для обхода Преобразователя сетевых адресов (NAT - Network Address Translator). В конце концов, для гарантии сохранности и конфиденциальности передачи файлов между равноправными пользователями может использоваться Безопасный MIME (S/MIME) [7].
Однако базовый протокол MSRP не удовлетворяет всем требованиям служб передачи файлов в рамках сеансов на основе SIP, указанным в [13]. Отсутствует три основные функции:
получатель ДОЛЖЕН иметь возможность распознавать «передачу файла» в «файле, вложенном в мгновенные сообщения», что позволяет получателю рассматривать случаи независимо;
отправитель ДОЛЖЕН иметь возможность отправлять запрос на передачу файла. Получатель ДОЛЖЕН иметь возможность принимать или отклонять его. Фактическая передача ДОЛЖНА иметь место только после одобрения получателем;
отправитель ДОЛЖЕН иметь возможность передачи некоторых метаданных файла перед фактической передачи. Они ДОЛЖНЫ включать по меньшей мере тип и размер контента, а также короткое (понятное человеку) описание.
Все эти требования относятся к описанию и согласованию сеанса связи, а не к механизму фактической передачи файлов. Таким образом, естественно, что для удовлетворения этих требований достаточно определить расширения-атрибуты и условия использования SDP, хотя протокол MSRP сам по себе не требует расширений и может использоваться так, как есть. Кроме того, все расширения SDP могут быть определены таким образом, что конечный объект, который не поддерживает их, а только выполняет основные требования протокола MSRP, также сможет быть вызываемым абонентом в сеансе передачи файла, хотя и с меньшими функциональными возможностями.
Данный документ определяет расширения-атрибуты и условия использования SDP, необходимые для удовлетворения требований служб передачи файлов в рамках сеансов SIP при использовании MSRP в качестве протокола передачи в сеансе связи.
В принципе возможно использовать расширения SDP, определенные здесь, и заменить MSRP любым другим подобным протоколом, который может передавать объекты MIME. При возникновении необходимости этот тип спецификации может быть написан отдельным документом.
Механизм, описанный в этом документе, позволяет как отправлять, так и принимать файлы от удаленных агентов пользователей.
В разделе 3 определено несколько терминов, используемых в данном документе. В разделе 4 представлен обзор принципа действия. Подробный синтаксис и семантика новых атрибутов SDP и условия их использования определены в разделе 5. В разделе 6 описана работа протокола, включая SIP, SDP и MSRP. В разделе 7 дано несколько примеров.
2. Терминология
В данном документе ключевые слова «ОБЯЗАН», «НЕ ОБЯЗАН», «НЕОБХОДИМО», «ДОЛЖЕН», «НЕ ДОЛЖЕН», «РЕКОМЕНДУЕТСЯ», «НЕ РЕКОМЕНДУЕТСЯ», «МОЖЕТ» и «ПО УСМОТРЕНИЮ» должны толковаться, как описано в документе ВСР 14, RFC 2119 [1], и указывают уровень требований для соответствующих вариантов реализации.
3. Определения
В данном документе применяются следующие определения, указанные в RFC 3264 [6]:
- Ответчик
- Запросчик
Помимо этого мы даем определения следующим терминам:
Отправитель файла: Конечная точка, которая хочет передать файл получателю файла.
Получатель файла: Конечная точка, которая хочет получить файл от отправителя файла.
Селектор файлов: Сочетание нескольких атрибутов SDP, которое приводит к выбору нуля или более файлов. Более подробно это описано в разделе 6.1.
4. Краткий обзор принципа действия
Служба передачи файлов, определенная в данном документе, для установления мультимедийных потоков на основе MSRP, которые будут передавать файлы, использует «предложение/ответ» протокола SDP [6]. Каждая строка “m=” описывает мультимедийный поток на основе MSRP, используемый для передачи отдельного файла. Таким образом, для передачи нескольких файлов требуется несколько строк “m=”.
В данном документе определен набор атрибутов SDP и некоторые условия, позволяющие агенту пользователя описать отправляемый файл или файл, принимаемый от удаленного агента пользователя. Таким образом агенты пользователей могут решить, принимать или нет передачу файла, на основании имени, размера, описания, хэша, пиктограммы файла (например, если файл является изображением), и т.д.
В сущности, назначение этого механизма подобно назначению механизма непрямой адресации контента в протоколе SIP [15]. Оба механизма позволяют агенту пользователя на основании информации о файле принимать решение, скачивать файл или нет. Однако, несмотря на то что механизм непрямой адресации контента может использоваться в запросах SIP MESSAGE [12] для передачи файлов (фактическим механизмом передачи файлов будет протокол передачи гипертекстовых файлов (HTTP - Hypertext Transfer Protocol) [11]), он не может применяться в сеансе связи, установленном посредством обмена «предложение/ответ», в котором протоколом передачи файлов является MSRP [10].
5. Расширения SDP
Мы определяем некоторое количество атрибутов в протоколе SDP [9], которые предоставляют необходимую информацию для описания файла в протоколе MSRP. Далее представлен формальный синтаксис ABNF [8] этих новых атрибутов. Он является надстройкой над грамматикой SDP [9], RFC 2045 [2] и RFC 2392 [3].
attribute=filename-attr / filetype-attr /
disposition-attr / filesize-attr /
icon-attr / hash-attr
;атрибут определен в sdp-new
filename-attr=“filename:” filename-string
filename-string=byte-string;byte-string определен в sdp-new
filetype-attr=“fitetype:” type“/” subtype ∗(“;” parameter)
;parameter определен в RFC 2045
type=token
subtype=token
disposition-attr=”disposition:” disposition-value
disposition-value=token
filesize-attr=“filesize:” filesize-value
filesize-value=integer.integer определен в sdp-new
icon-attr=“icon:” icon-value
icon-value=cid-url ;cid-url определен в RFC 2392
hash-attr=“hash:” hash-algorithm WSP hash-value
hash-algorithm=token;смотри раздел IANA Hash Algorithm
;в реестре IPSEC
hash-value=byte-string;byte-string определен в sdp-new
Фиг.1: Синтаксис расширения SDP
Атрибут 'filename' содержит имя файла контента, и его значение является байтовой строкой (определено в SDP [9]).
Атрибут 'filetype' содержит тип мультимедиа контента MIME. Как правило, все, что может быть указано в поле заголовка Content-Type (см. RFC 2045 [2]), также может быть указано в атрибуте 'filetype'. Возможные значения типа мультимедиа MIME перечислены в реестре IANA для типов мультимедиа MIME. Может иметься ноль или более параметров. Синтаксис 'parameter' определен в RFC 2045 [2].
Атрибут 'disposition' предоставляет равноправным участникам сети указание на назначенное местоположение файла. Возможные значения перечислены в реестре IANA для Параметров расположения содержимого электронной почты (Mail Content Disposition Values), хотя более вероятно, что для систем передачи файлов будут значимы только значения “inline” и “attachment”.
Атрибут 'filesize' указывает размер файла в октетах.
Атрибут 'icon' может быть полезен для некоторых типов файлов, таких как изображения. Он позволяет отправителю включить указатель на тело, которое содержит значок, представляющий содержимое передаваемого файла. Это позволяет отправителю включать значок как другое тело, сопровождающее SDP, а получателю - получать значок файла, который потенциально может быть передан. Рекомендуется ограничивать значки минимальным числом байтов, обеспечивающих значимость. Атрибут 'icon' содержит Content-ID URL, который определен в RFC 2392 [3].
Атрибут 'hash' предоставляет хэш передаваемого файла. Он имеет два предназначения. С одной стороны, он позволяет получателю файла идентифицировать файл по его хэшу, а не имени файла, при условии, что получатель файла узнал хэш файла посредством какого-либо внеполосного механизма. С другой стороны, он позволяет отправителю файла предоставлять хэш передаваемого файла, который может быть использован получателем файла для проверки его содержимого или для предотвращения ненужной передачи уже имеющегося файла. Атрибут 'hash' содержит тип хэша и его значение. Возможные типы хеша определены в разделе «Алгоритм хэширования» (Algorithm) в реестре IANA реестра IPSec. Варианты, соответствующие данной спецификации, ОБЯЗАНЫ реализовывать алгоритм US Secure Hash Algorithm 1 (SHA1) [4] и могут реализовывать другие алгоритмы хэширования. Создатель SDP также МОЖЕТ добавлять в один файл более одного атрибута 'hash' (предположительно с разными типами хэша). Значение является байтовой строкой, получающейся в результате применения к содержимому файла алгоритма хэширования.
Далее представлен пример тела SDP, содержащего расширения, которые указаны в данной записке:
v=0
0=alice 2890844526 2890844526 IN IP4 http://host.atlanta.example.com
s=
c=IN IP4 http://host.atlanta.example.com
t=0 0
m=message 7654 TCP/MSRP∗
i=This is my latest picture
a=sendonly
a=accept-types:∗
a=path:msrp://atlanta.example.com:7654/jshA7we;tcp
a=filename:My cool picture.jpg
a=filetype:image/jpeg
a=disposition:inline
a=filesize:32349
a=icon-cid:mailto:id2@alicepc.example.com
a=hash:SHA 72245fe8653ddaf371362f86d471913ee4a2ce2e
Фиг.2: Пример SDP, описывающего передачу файла
6. Принцип действия протокола
В данном разделе оговорено, как использовать параметры, определенные в разделе 5, в контексте обмена «предложение/ответ» [6]. Также в этом разделе описан принцип работы конечных точек, использующих протокол MSRP.
Обычно сеанс передачи файла устанавливается, когда запросчик посылает ответчику предложение SDP. Ответчик принимает или отклоняет сеанс передачи файла и посылает запросчику ответ SDP.
В зависимости от того, является ответчик отправителем или получателем файла, можно различить два случая:
1. Запросчик является отправителем файла, т.е. запросчик хочет передать файл ответчику. Ответчик является получателем файла. В этом случае предложение SDP содержит атрибут 'sendonly', а ответ SDP соответственно содержит атрибут 'recvonly'.
2. Запросчик является получателем файла, т.е. запросчик хочет получить файл от ответчика. Ответчик является отправителем файла. В этом случае предложение SDP содержит атрибут 'recvonly', а ответ SDP соответственно содержит атрибут 'sendonly'.
6.1. Селектор файлов
Протокол, указанный в этом документе, требует механизма идентификации файла на удаленном хосте. Мы представляем концепцию селектора файлов, который является сочетанием атрибутов 'hash', 'filename', 'filesize', и 'filetype'.
Селектор файлов может указать на ноль, один или более файлов в зависимости от наличия в SDP указанных атрибутов и доступных на хосте файлов. Механизм передачи файла, который мы определяем в данном документе, требует, чтобы селектор файлов давал результатом выбор одного файла. Обычно атрибут 'hash' известен и его достаточно для создания селектора файлов, указывающего на ноль или один файл. Однако не всегда селектор файлов известен или доступен. Иногда известны только атрибуты 'filename', 'filesize' или 'filetype', и поэтому селектор файлов может приводить к выбору более одного файла, что нежелательно. Обратное тоже верно, если селектор файлов содержит атрибуты 'hash' и 'filename', но пользователь на удаленном хосте переименовал файл, так как несмотря на то, что имеется файл с указанным хэшем, имя файла не совпадает, и поэтому селектор файлов даст результатом выбор нулевого количества файлов.
6.2. Принцип действия запросчика
Запросчик, который хочет отправить или принять один или более файлов у ответчика, ОБЯЗАН составлять описание SDP [9] сеанса связи, содержащее одну или более строк “m=”, каждая из которых описывает сеанс MSRP (и, следовательно, одну операцию передачи файлов) в соответствии с процедурами MSRP [10]. Все атрибуты строки media, определенные и требуемые протоколом MSRP [10] (например, “a=path”, “a=accept-types” и т.д.), также ДОЛЖНЫ быть включены. Для каждого передаваемого файла ДОЛЖНА быть отдельная строка “m=”.
6.2.1. Запросчик является отправителем файла.
Если запросчик является отправителем файла, он ОБЯЗАН добавлять к предложению SDP атрибут 'sendonly' сеанса или среды. Помимо этого запросчик также ДОЛЖЕН добавлять атрибуты 'filetype', 'filesize' и 'hash', показывающие тип, размер и хэш файла соответственно.
Эти атрибуты могут не быть известны, когда запросчик создает предложение SDP, например, потому что хост все еще обрабатывает файл.
Атрибут 'hash' содержит ценную для получателя информацию для определения, имеется ли файл и требуется ли его передача.
Запросчик также МОЖЕТ добавлять атрибуты 'filename', 'icon' и 'disposition', дающие дополнительное описание передаваемому файлу. Атрибут 'disposition' предоставляет указание по отображению (например: отправитель файла может пожелать, чтобы получатель файла показывал файл в тексте или сохранял его как вложение). Помимо этого запросчик МОЖЕТ предоставлять понятное человеку описание файла при помощи строки media “i=”.
6.2.2. Запросчик является получателем файла.
Если запросчик является получателем файла, он ОБЯЗАН создавать предложение SDP, содержащее атрибут 'sendonly' сеанса или среды. Также запросчик ДОЛЖЕН добавлять по меньшей мере один атрибут, который представляет селектор файлов ('hash', 'filename', 'filesize' или 'filetype'). Во многих случаях, если хэш файла известен, этого достаточно для идентификации файла, и поэтому запросчик может включать только атрибут 'hash'. Однако имя, размер и тип файла могут предоставить описание получаемого файла, особенно в тех случаях, когда хэш файла неизвестен.
6.2.3. Предложение SDP для нескольких файлов.
Запросчик, который хочет отправить или принять более одного файла, формирует строку “m=” для каждого файла. Таким образом, ответчик может отклонить отдельные файлы, устанавливая номер порта связанных с ними строк “m=” на ноль, как и в обычных процедурах SDP [9].
Использование строки “m=” для каждого файла предполагает, что разные файлы передаются в разных сеансах MSRP. Тем не менее, все эти сеансы MSRP могут быть установлены для выполнения в одном соединении TCP, как описано в разделе 8.1 в [10].
6.3. Принцип действия ответчика.
Если ответчик хочет отклонить файл, предложенный запросчиком, он устанавливает номер порта строки “m=”, связанной с файлом, на ноль, как и в обычных процедурах SDP [9]. Если ответчик решает принять файл, он действует в соответствии с обычными процедурами MSRP [10] и SDP [9].
6.3.1. Ответчик является получателем файла.
Если ответчик является получателем файла и хочет принять передачу файла, он ОБЯЗАН создать ответ SDP (в соответствии с RFC 3264 [6]), содержащий атрибут 'recvonly'. Если предложение содержит атрибуты 'filetype', 'filesize' или 'filename', ответчик ОБЯЗАН копировать их в ответ. Это информирует запросчика о том, что ответчик имеет поддержку этой спецификации. Если ответчик является получателем файла, он ОБЯЗАН НЕ включать атрибуты 'icon', 'hash' или 'disposition' в ответ SDP.
Если принятое предложение содержит атрибут 'hash', ответчик может использовать его для поиска локальных файлов с таким же хэшем, что может означать прием идентичного файла. Ответчику необходимо определить, принимать передачу файла или нет, в случае повторяющегося файла.
6.3.2. Ответчик является отправителем файла.
Если ответчик является отправителем файла, он ОБЯЗАН сначала проверить полученное предложение SDP и вычислить селектор файлов. Селектор файлов является результатом сочетания атрибутов 'filetype', 'filesize', 'filename' и 'hash' (если они имеются), которое изменяет одну и ту же строку “m=” в предложении SDP (т.е. четыре указанных атрибута расположены в SDP под одной строкой “m=”). Селектор файлов идентифицирует ноль или более отправляемых файлов. Если селектор файлов не может идентифицировать ни один файл, то ответчик ОБЯЗАН отклонить поток MSRP для передачи файлов посредством установки номера порта на ноль (и, если это единственный поток в предложении SDP, то он ДОЛЖЕН отклонить SDP в соответствии с процедурами в RFC 3264 [6]).
Если селектор файлов указывает на один файл и ответчик решает принять передачу файла, то ответчик ОБЯЗАН создать ответ SDP (в соответствии с RFC 3264 [6]), содержащий атрибут 'sendonly'. Ответчик ДОЛЖЕН добавлять атрибут 'hash', содержащий хэш отправляемого файла, и МОЖЕТ включать атрибуты 'filename', 'filetype', 'filesize', 'icon' или 'disposition' для дополнительного описания файла.
В заключение, если селектор файлов указывает на несколько файлов, ответчик ДОЛЖЕН отклонить мультимедийный поток MSRP для передачи файлов (устанавливая номер порта на ноль).
При возникновении необходимости будущие спецификации могут предоставить подходящий механизм, который позволяет выбирать несколько файлов или, например, разрешать неоднозначные ситуации, выдавая список файлов, которые соответствуют селектору файлов.
6.4. Использование MSRP
Служба передачи файлов, определенная в данном документе, для описания однонаправленной передачи файла использует строки “m=”. Следовательно, каждый сеанс MSRP, установленный в соответствии с процедурами из разделов 6.2 и 6.3, используется для передачи только одного файла. Таким образом, отправители ОБЯЗАНЫ использовать данный сеанс MSRP для отправки файла, описанного в предложении или ответе SDP. То есть отправители НЕ ДОЛЖНЫ отправлять другие файлы в этом же сеансе MSRP.
После завершения передачи файла отправитель файла ДОЛЖЕН завершить сеанс MSRP и ОБЯЗАН действовать в соответствии с процедурами MSRP [10] относительно завершения сеансов MSRP.
7. Примеры.
7.1. UAC отправляет файл на UAS.
В этом разделе показан пример процесса для сценария передачи файла. В примере предполагается, что для передачи обмена SDP используется протокол SIP, хотя из соображений краткости детали SIP показаны в сжатом виде.
Элис, запросчик SDP, хочет отправить изображение Бобу (ответчику SDP). UAC Элис создает однонаправленное предложение SDP с описанием файла, который она хочет отправить Бобу. Описание также включает значок, отображающий содержимое передаваемого файла. Последовательность действий показана на фиг.3.
|
Фиг.3: Схема последовательности операций при отправке файла с UAC на UAS
F1: Элис составляет описание SDP отправляемого файла и присоединяет его к запросу SIP INVITE, адресуемому Бобу.
INVITE sip:mailto:bob@example.com SIP/2.0
То: Bob<sip:>
From: Alice<sip:alice@example.com>;tag=1928301774
Call-ID: aB4b4c76e66710
CSeq: 1 INVITE
Max-Forwards: 70
Date: Fri, 17 Feb 2006 13:02:03 GMT
Contact:<sip:mailto:alice@alicepc.example.com>
Content-Type: multipart/mixed; boundary=“boundary71”
Content-Length: [length]
--boundary71
Content-Type: application/sdp
Content-Length: [length of SDP]
v=0
o=alice 2890844526 2890844526 IN IP4 http://alicepc.example.com
s=
c=IN IP4 http://alicepc.example.com
t=0 0
m=message 7654 TCP/MSRP∗
i=This is my latest picture
a=sendcnly
a=accept-types:∗
a=path:msrp://alicepc.example.com:7654/jshA7we;tcp
a=filename:My cool picture.jpg
a=filetype: image/jpeg
a=disposition:inline
a=filesize: 4096
a=icon:cid:mailto:id2@alicepc.example.com
a=hash:SHA 72245fe8653ddaf371362f86d471913ee4a2ce2e
--boundary71
Content-Type: image/jpeg
Content-Transfer-Encoding: binary
Content-ID:<mailto:id2@alicepc.example.com>
Content-Length: [length of image]
...binary JPEG image...
--boundary71
В дальнейшем из соображений краткости мы опускаем детали SIP.
F2: Боб получает запрос INVITE, проверяет предложение SDP и извлекает тело значка, проверяет размер файла и принимает решение принять передачу файла. Таким образом, Боб создает следующий ответ SDP:
v=0
o=bob 2890844656 2890844656 IN IP4
c=IN IP4 http://bobpc.example.com
m=message 8888 TCP/MSRP∗
a=recvonly
a=accept-types:∗
a=path:msrp://bobpc.example.com:8888/9di4ea;tcp
a=filename:My cool picture.jpg
a=filetype: image/jpeg
a=filesize:4096
F4: Элис открывает соединение TCP с Бобом и создает запрос MSRP SEND. Этот запрос SEND содержит первый фрагмент файла.
MSRP d93kswow SEND
To-Path: msrp://bobpc.example.com:8888/9di4ea;tcp
From-Path: msrp://alicepc.example.com:7777/iau39;tcp
Message-ID: 12339sdqwer
Byte-Range: 1-2048/4096
Content-Type: image/jpeg
...первый фрагмент изображения JPEG...
-------d93kswow+
F5: Боб подтверждает получение первого фрагмента.
MSRP d93kswow 200 OK
To-Path: msrp://alicepc.example.com:7777/iau39;tcp
From-Path: msrp://bobpc.example.com:8888/gdi4ea;tcp
Byte-Range: 1-2048/4096
-------d93kswow$
F6: Элис отправляет второй и последний фрагмент.
MSRP op2nc9a SEND
To-Path: msrp://bobpc.example.com:8888/9di4ea;tcp
From-Path: msrp://alicepc.example.com:7777/iau39;tcp
Message-ID: 12339sdqwer
Byte-Range: 2049-4096/4096
Content-Type: image/jpeg
...второй (и последний) фрагмент изображения JPEG...
-------0p2nc9a$
F5: Боб подтверждает получение второго фрагмента.
MSRP ор2пс9а 200 ОК
To-Path: msrp: //alicepc.example.com:7777/iau39;tcp
From-Path: msrp://bobpc.example.com:8888/9di4ea;tcp
Byte-Range: 2049-4096/4096
-------op2nc9a$
F8: Элис завершает сеанс SIP отправкой запроса SIP BYE.
F9: Боб подтверждает получение запроса BYE и отправляет ответ 200 (ОК).
7.2. UAC запрашивает файл у UAS.
В этом примере Элис, запросчик SDP, хочет получить файл от Боба (ответчика SDP). Элис знает, что у Боба есть определенный файл, который она хочет скачать. Она узнала хэш файла при помощи какого-либо внеполосного механизма. Атрибута 'hash' достаточно для формирования селектора файлов, указывающего на конкретный файл. Таким образом, Элис создает предложение SDP, содержащее дескриптор файла. Боб соглашается с передачей и отправляет файл Элис. Последовательность действий показана на фиг.10.
|
Фиг.10: Схема последовательности операций при запросе файла агентом клиента пользователя (UAC) у UAS
F1: Элис составляет описание SDP файла, который она хочет получить, и присоединяет предложение SIP к запросу SIP INVITE, адресуемому Бобу.
INVITE sip:mailto:mailto:bob@example.com SIP/2.0
То: Bob<sip:>
From: Alice<sip:alice@example.com>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 1 INVITE
Max-Forwards: 70
Date: Fri, 17 Feb 2006 13:02:03 GMT
Contact:<81р:alice@licepc.ехатр1е.сот>
Content-Type: application/sdp
Content-Length: [length of SDP]
v=0
c=alice 2890844526 2890844526 IN IP4 http://alicepc.example.com
s=
c=IN IP4 http://alicepc.example.com
t=0 0
m=message 7654 TCP/MSRP∗
a=recvonly
a=accept-types: image/jpeg
a=path:msrp://alicepc.example.com:7654/jshA7we;tcp
a=hash:SHA 72245fe8653ddaf371362f86d471913ee4a2ce2e
В дальнейшем из соображений краткости мы опускаем детали SIP.
F2: Боб получает запрос INVITE, проверяет предложение SDP, вычисляет дескриптор файла и находит локальный файл, который соответствует тому, который указан в SDP. Боб соглашается с передачей файла и создает ответ SDP следующим образом:
v=0
o=bob 2890844656 2890844656 IN IP4 http://bobpc.example.com
s=
c=IN IP4 http://bobpc.example.com
m=message 8888 TCP/MSRP∗
a=sendonly
a=accept-types:∗
a=path:msrp://bobpc.example.com:8888/9di4ea;tcp
a=filename:My cool photo.jpg
a=filetype: image/jpeg
a=filesize:2027
F4: Элис открывает соединение TCP с Бобом. Затем Боб создает запрос MSRP SEND, который содержит файл.
MSRP d93kswow SEND
To-path: mssrp://alicepc.example.com:7777/iau39;tcp
From-Path: msrp://bobpc.example.com:8888/9di4ea;tcp
Message-ID: 12339sdqwer
Byte-Range: 1-2027/2027
Content-Type: image/jpeg
...binary JPEG image...
-------d93kswow$
F6: Элис подтверждает получение запроса SEND.
MSRP d93kswow 200 OK
To-Path: msrp://bobpc.example.com:8888/9di4ea;tcp
From-Path: msrp://alicepc.example.com:7777/iau39;tcp
Byte-Range: 1-2027/2027
-------d93kswow$
F6: Затем Боб завершает сеанс SIP отправкой запроса SIP BYE.
F7: Элис подтверждает получение запроса BYE и отправляет ответ 200 (ОК).
8. Соображения безопасности
Подлежит определению
9. Соображения IANA
Подлежит определению
10. Благодарности
Авторы хотят поблагодарить Mats Stille, Nancy Greene, Adamu Haruna и Arto Leppisaari за обсуждение основополагающих идей, описанных в этой записке. Спасибо Pekka Kuure за рецензирование начальных версий этого документа и предоставление полезных комментариев.
11. Ссылки
11.1. Нормативные ссылки
[1] Bradner S., “Key words for use in RFCs to Indicate Requirement Levels”, BCP 14, RFC 2119, March 1997.
[2] Freed, N. and N. Borenstein, “Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies”, RFC 2045, November 1996.
[3] Levinson, E., “Content-ID and Message-ID Uniform Resource Locator's”, RFC 2392, August 1998.
[4] Eastlake, D. and P. Jones, “US Secure Hash Algorithm 1 (SHA1)”, RFC 3174, September 2001.
[5] Rosenberg, J., Schulzrinne, H., Camarilla, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol”, RFC 3261, June 2002.
[6] Rosenberg, J. and H. Schulzrinne, “An Offer/Answer Model with Session Description Protocol (SDP)”, RFC 3264, June 2002.
[7] Ramsdell, В., “Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification”, RFC 3851, July 2 004.
[8] Crocker, D. and P. Overell, “Augmented BNF for Syntax Specifications: ABNF”, RFC 4234, October 2005.
[9] Handley, M., “SDP: Session Description Protocol”, draft-ietf-mmusic-sdp-new-25 (work in progress), July 2005.
[10] Campbell, В., “The Message Session Relay Protocol”, draft-ietf-simple-message-sessions-13 (work in progress), December 2005.
11.2. Информационные ссылки
[11] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L, Leach, P., and T. Berners-Lee, “Hypertext Transfer Protocol - HTTP/1.1”, RFC 2616, June 1999.
[12] Campbell, В., Rosenberg, J., Schulzrinne, H., Huitema, C, and D. Gurle, “Session Initiation Protocol (SIP) Extension for Instant Messaging”, RFC 3428, December 2002.
[13] Isomaki, M., “Requirements and Possible Mechanisms for File Transfer Services Within the Context of SIP Based Communication”, draft-isomaki-sipping-file-transfer-00 (work in progress), October 2005.
[14] Jennings, C, “Relay Extensions for the Message Sessions Relay Protocol (MSRP)”, draft-ietf-simple-msrp-relays-06 (work in progress), December 2005.
[15] Burger, E., “A Mechanism for Content Indirection in Session Initiation Protocol (SIP) Messages”, draft-ietf-sip-content-indirect-mech-05 (work in progress), October 2004.
Адреса авторов
Miguel A. Garcia-Martin
Nokia
P.O.Box 407
NOKIA GROUP, FIN 00045
Finland
Email: mailto:miguel.an.garcia@nokia.com
Markus Isomaki
Nokia
Keilalahdentie 2-4
Espoo 02150
Finland
Email: mailto:markus.isomaki@nokia.com
Gonzalo Camarillo
Ericsson
Hirsalantie 11
Jorvas 02420
Finland
Email: mailto:Gonzalo.Camarillo@ericsson.com
Salvatore Loreto
Ericsson
Hirsalantie 11
Jorvas 02420
Finland
Email: mailto:Salvatore.Loreto@ericsson.com
Положение об авторских правах
Copyright (С) The Internet Society (2006).
Данный документ подчиняется правам, лицензиям и ограничениям, содержащимся в документе ВСР 78, и за исключением указанных здесь случаев авторы сохраняют все их права.
Данный документ и содержащаяся в нем информация предоставлены по принципу «как есть», и АВТОР, ОРГАНИЗАЦИЯ, КОТОРУЮ ОН ПРЕДСТАВЛЯЕТ ИЛИ ЕГО СПОНСИРУЕТ (ПРИ НАЛИЧИИ ТАКОВОЙ), СООБЩЕСТВО ИНТЕРНЕТ И КОМИТЕТ ПО ИНЖЕНЕРНЫМ ВОПРОСАМ INTERNET ОТКАЗЫВАЮТСЯ ОТ ВСЕХ ГАРАНТИЙ ТОГО, ЧТО ИСПОЛЬЗУЕМАЯ ЗДЕСЬ ИНФОРМАЦИЯ НЕ НАРУШИТ НИКАКИХ ПРАВ ИЛИ ПОДРАЗУМЕВАЕМЫХ ГАРАНТИЙ ПРИГОДНОСТИ ДЛЯ РЫНКА ИЛИ СООТВЕТСТВИЯ КОНКРЕТНОМУ НАЗНАЧЕНИЮ.
Интеллектуальная собственность
IETF не занимает никакой позиции по отношению к действительности или границам любых прав на интеллектуальную собственность или других прав, которые могут быть заявлены на принадлежность к реализации или использованию описанной в данном документе технологии или к объему, для которого может или не может действовать любая лицензия на такие права; также IETF сообщает, что не делало никаких независимых попыток выяснения любых подобных прав. Информацию о порядке действий относительно прав в документах RFC можно найти в документах ВСР 78 и ВСР 79.
Копии описаний IPR, выполненные для секретариата IETF, и любые подтверждения лицензий, необходимые для их действительности, или результат попытки получения генеральной лицензии или разрешения на использование таких прав собственности пользователями данной спецификации могут быть лолучены в сетевой базе данных IETF по адресу .
IETF призывает все заинтересованные стороны сообщать о любых авторских правах, патентах или заявках на патенты, или любых других правах собственности, которые могут защищать технологию, которая может потребоваться для реализации данного стандарта. Пожалуйста, отправьте информацию IETF по адресу .
Благодарность
Финансирование функции RFC Editor обеспечивается Сообществом Интернета.
Способы и системы обработки объектных моделей документов (dom) для обработки видеоконтента
Способ и устройство для маскирования ошибок кодированных аудиоданных
Пользовательский интерфейс и соответствующие способ и устройство
Устройство и способ кодирования и воспроизведения звука
Система и способ сигнализации о доступности нескольких вариантов абонентской услуги mbms
Сегментированные метаданные и индексы для потоковых мультимедийных данных
Способ и система для межчастотного или межсистемного перевыбора соты
Представление информации на основе ориентации экрана дисплея
Способ экономии потребляемой мощности для устройств беспроводной связи
Идентификация частот и спутников глобальной навигационной спутниковой системы в стандартах данных поддержки глобальной навигационной спутниковой системы
Передача данных для мультимедийных широковещательных/многоадресных услуг
Обмен сообщениями в страничном режиме
