SIP多媒体服务中的删除机制

具体实施方式

本发明包括用于在SIP多媒体服务中使用的新颖的删除机制。本发明涉及用于此目的各种SIP多媒体服务环境的使用。在一个实施方式中，在网络中定义用于已删除项目的“回收站”或者类似位置，并将其与SIP统一资源标识符相关联。对在网络内部存储的消息指派唯一的标识符。如果用户期望删除消息，则他或者她请求在消息以及网络定义的回收站之间建立SIP/MSRP会话功能。当处理时，将消息传送至回收站，放置在用户的邮件存储服务器中的用户账户中。

图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”。

如上所述，可以为网络中存储的消息指派唯一消息标识符。在图1中的130处，利用标识符“13242@mailserver57.Sonera.com”(MSG1)、“13243@mailserver57.Sonera.com”(MSG2)以及“13244@mailserver57.Sonera.com”(MSG 3)示出了三个此类消息。备选地，消息可以作为文件来存储。在一个实施方式中，可以为每个消息给出文件名称、文件类型以及散列值。在图2中，利用标识符“文件1＝(文件名，文件类型，唯一散列值)”、“文件2＝(文件名，文件类型，唯一散列值)”以及“文件3＝(文件名，文件类型，唯一散列值)”示出了三个此类消息。

在图1的140处，用户确定他或者她希望删除MSG 2。此时，用户/客户端设备100向用户账户110处的消息标识符

13243@mailserver57.Sonera.com(其充当虚拟用户代理155)发送具有INVITE(邀请)请求150的SIP REFER。在Refer-to报头中，该SIP REFER请求具有基于网络的回收站地址

(RecycleBin@mailserver.sonera.com)。具有INVITE请求150的SIPREFER用于请求与基于网络的回收站120

(RecycleBin@mailserver.sonera.com)建立SIP会话。在160处，虚拟用户代理155通过“202 ACCEPT(接受)”来接受来自用户/客户端设备100的SIP REFER请求，以此来进行响应。在170处，虚拟用户代理155还发送INVITE请求来与回收站120建立SIP会话。在180处，回收站120接受此会话。在190处，以消息会话中继协议(MSRP)的形式来与虚拟用户代理155正式建立SIP会话，其中将会话描述协议(SDP)媒体属性设置为a＝SendOnly(只发)。在200处，虚拟用户代理155向用户/客户端100通知SIP会话，并且在210处，用户/客户端设备100确认此通知。在SIP/MSRP会话中，MSG 2从用户账户110发送至基于网络的回收站120，这导致MSG 2从用户账户110中消失。在消息MSG 2成功传输之后，虚拟用户代理155与回收站120之间的SIP会话结束。结果是，如220处示出，在用户邮件存储服务器中的用户账户110中仅存在MSG1和MSG 3。

在本发明的备选实施方式中，可以对用户账户110以及回收站120的功能进行配置。在此情况下，发送INVITE请求以建立SIP会话170、对此请求的确认180以及利用MSRP来建立SIP会话190不是必须的。

在图2中示出了存储为文件的消息的备选实施方式。在此实施方式中，用以将所存储或者选择的消息恢复至回收站的机制可以基于作为附录B而附加的文件传输草案，将附录B并入此申请。在此实施方式中，REFER请求可以包括待删除文件的SDP描述。

在图2的140处，用户确定他或者她希望删除MSG 2(文件2)。此时，用户/客户端设备100向用户账户110处邮件存储服务器(其充当虚拟用户代理155)发送具有INVITE请求150的SIP REFER。在Refer-to报头中，该SIP REFER请求具有基于网络的回收站地址(RecycleBin@mailserver.sonera.com)。具有INVITE请求150的SIPREFER用于请求与基于网络的回收站120

(RecycleBin@mailserver.sonera.com)建立SIP会话。在160处，虚拟用户代理155通过“202 ACCEPT”来接受来自用户/客户端设备100的SIP REFER请求，以此来进行响应。在170处，虚拟用户代理155还发送INVITE请求来与回收站120建立SIP会话。在180处，回收站120接受此会话。在190处，以消息会话中继协议(MSRP)的形式来与虚拟用户代理155正式建立SIP会话，其中将会话描述协议(SDP)媒体属性设置为a＝SendOnly(只发)。在200处，虚拟用户代理155向用户/客户端100通知SIP会话，并且在210处，用户/客户端设备100确认此通知。在SIP/MSRP会话中，文件2从用户账户110发送至基于网络的回收站120，这导致MSG 2从用户账户110中消失。在文件2(MSG 2)成功传输之后，在虚拟用户代理155以及回收站120之间的SIP会话结束。如220处示出，最终结果是：在用户邮件存储服务器中的用户账户110中仅存在MSG1(文件1)和MSG 3(文件3)。

在本发明的备选实施方式中，可以对用户账户110以及回收站120的功能进行配置。在此情况下，发送INVITE请求以建立SIP会话170、此请求的确认180以及利用MSRP建立SIP会话190不是必须的。

在图3中示出了本发明的备选实施方式。在此实施方式中，绕过虚拟用户代理而将具有INVITE请求的SIP REFER直接发送至基于网络的回收站。例如，在340中，用户确定他或者她希望删除MSG 2。此时，用户/客户端设备100向回收站120

(RecycleBin@mailserver.sonera.com)发送具有INVITE请求350的SIP REFER。具有INVITE请求350的SIP REFER用于请求在基于网络的回收站120(RecycleBin@mailserver.sonera.com)与用户账户110或者在虚拟用户代理155(如果使用)之间建立SIP会话。在360处，回收站120通过“202 ACCEPT”来接受来自用户/客户端设备100的SIP REFER请求，以此来进行响应。在370处，回收站120还发送INVITE请求来与虚拟用户代理155建立SIP会话。在380处，虚拟用户代理155接受此会话。在390处，以消息会话中继协议(MSRP)的形式来与虚拟用户代理155正式建立SIP会话，其中将会话描述协议(SDP)媒体属性设置为a＝RecvOnly(只收)。在400处，回收站120向用户/客户端100通知SIP会话，并且在410处，用户/客户端设备100确认此通知。在SIP/MSRP会话中，MSG 2从用户账户110发送至基于网络的回收站120，这导致MSG 2从用户账户110中消失。在消息MSG 2成功传输之后，在虚拟用户代理155以及回收站120之间的SIP会话结束。如420处示出，最终结果是：在用户邮件存储服务器中的用户账户110中仅存在MSG 1和MSG 3。

类似于先前的实施方式，可以对用户账户110以及回收站120的备选功能进行配置。在此情况下，发送INVITE请求以建立SIP会话370、此请求的确认380以及利用MSRP建立SIP会话390不是必须的。

在图4中示出的本发明的实施方式是图3中实施方式的备选。类似于图3，在此实施方式中，绕过虚拟用户代理而将具有INVITE请求的SIP REFER直接发送至基于网络的回收站。然而，在图4的实施方式中，用于将所存储或者选择的消息恢复至回收站的机制是基于如附录B所附加的文件传输草案。在此实施方式中，REFER请求包括待删除文件的SDP描述。

在图4中的340处，用户确定他或者她希望删除MSG 2(文件2)。此时，用户/客户端设备100向回收站120

(RecycleBin@mailserver.sonera.com)发送具有INVITE请求350的SIP REFER。具有INVITE请求350的SIP REFER用于请求与基于网络的回收站120(RecycleBin@mailserver.sonera.com)建立SIP会话。在360处，回收站120通过“202 ACCEPT”来接受来自用户/客户端设备100的SIP REFER请求，以此来进行响应。在370处，回收站120还发送INVITE请求来与虚拟用户代理155建立SIP会话。在380处，虚拟用户代理155接受此会话。在390处，以消息会话中继协议(MSRP)的形式来与虚拟用户代理155正式建立SIP会话，其中将会话描述协议(SDP)媒体属性设置为a＝RecvOnly(只收)。在400处，回收站120向用户/客户端100通知SIP会话，并且在410处，用户/客户端设备100确认此通知。在SIP/MSRP会话中，文件2(MSG2)从用户账户110发送至基于网络的回收站120，这导致文件2(MSG2)从用户账户110中消失。在文件2(MSG2)成功传输之后，在虚拟用户代理155以及回收站120之间的SIP会话结束。如420处示出，最终结果是：在用户邮件存储服务器中的用户账户110中仅存在文件1(MSG1)和文件3(MSG3)。

类似于先前的实施方式，可以对用户账户110以及回收站120的备选功能进行配置。在此情况下，发送INVITE请求以建立SIP会话370、此请求的确认380以及利用MSRP建立SIP会话390不是必须的。

在另一实施方式中，用户可以选择并删除所存储的多个消息。在此实施方式中，如图5中示出，可以将多个REFER请求发送至回收站120以删除所选择的多个消息。并入此申请中的附录A示出了多个REFER请求的一个实施方式或者实现。在图5所示的实施方式中，绕过虚拟用户代理而将具有INVITE请求的SIP多REFER直接发送至基于网络的回收站。备选地，如关于图1所示的实施方式所述，将具有INVITE的SIP多REFER发送至虚拟用户代理。

在图5中的540处，用户确定他或者她希望删除MSG 2以及MSG3。此时，用户/客户端设备100向回收站120

(RecycleBin@mailserver.sonera.com)发送包括URI列表的具有INVITE请求550的SIP多REFER，其中URI列表包含待删除的已存储消息(在此情况下是MSG 2以及MSG 3)的URI。具有INVITE请求550的SIP REFER用于请求与基于网络的回收站120(RecycleBin@mailserver.sonera.com)建立SIP会话。在570以及571处，回收站120分别针对每个待删除的消息而发送INVITE请求，以与虚拟用户代理155和156建立SIP会话。在此情况下INVITE请求570对应于MSG 2，而INVITE请求571对应于MSG 3。在580以及581处，虚拟用户代理155和156分别接受这些会话。在590处，以消息会话中继协议(MSRP)的形式来与虚拟用户代理155正式建立SIP会话，其中将会话描述协议(SDP)媒体属性设置为a＝RecvOnly(只收)，并且在591处，与虚拟用户代理156建立SIP会话。在SIP/MSRP会话中，MSG 2以及MSG 3从用户账户110发送至基于网络的回收站120，这导致MSG 2以及MSG 3从用户账户110中消失。在消息MSG 2以及MSG 3成功传输之后，在虚拟用户代理155和156以及回收站120之间的SIP会话结束。如620处示出，最终结果是在用户邮件存储服务器中的用户账户110中仅存在MSG1。

类似于先前的实施方式，也可以对用户账户110以及回收站120的功能进行配置。在此情况下，发送INVITE请求以建立SIP会话570和571、此请求的确认580和581以及利用MSRP建立SIP会话590和591不是必须的。

图6中示出的实施方式示出了当将所存储和选择的消息恢复至回收站的机制是基于如附录B所附加的文件传输草案时的删除多个消息的图示。在此实施方式中，REFER请求也包括待删除文件的SDP描述。在图6中的540处，用户确定他或者她希望删除MSG 2(文件2)以及MSG 3(文件3)。此时，针对待删除的存储消息(文件)(在此情况下是MSG 2和MSG 3)，用户/客户端设备100使用附录B中描述的语法来向回收站120(RecycleBin@mailserver.sonera.com)发送具有INVITE请求550的SIP REFER。在此情况下，针对每个待删除文件(消息)的SDP参数需要在单独的媒体行“m＝”中发送。具有INVITE请求550的SIP REFER用于请求在基于网络的回收站120(RecycleBin@mailserver.sonera.com)与用户账户110或者虚拟用户代理115(如果使用)之间建立SIP会话。在570处，回收站120发送INVITE请求以与虚拟用户代理155建立SIP会话。在580以及581处，虚拟用户代理155分别接受用于每个待删除文件的会话。在590处，以消息会话中继协议(MSRP)的形式来与虚拟用户代理155正式建立SIP会话，其中将会话描述协议(SDP)媒体属性设置为a＝RecvOnly(只收)，并且在591处，与虚拟用户代理156建立SIP会话。在SIP/MSRP会话中，文件2(MSG 2)以及文件3(MSG 3)从用户账户110发送至基于网络的回收站120，这导致MSG 2(文件2)以及MSG 3(文件3)从用户账户110中消失。在文件2(MSG 2)以及文件3(MSG 3)成功传输之后，在虚拟用户代理155以及回收站120之间的SIP会话结束。如620处示出，最终结果是：在用户邮件存储服务器中的用户账户110中仅存在文件1(MSG 1)。

类似于先前的实施方式，还可以对用户账户110以及回收站120的功能进行配置。在此情况下，发送INVITE请求以建立SIP会话570和571、此请求的确认580和581以及利用MSRP建立SIP会话590和591不是必须的。

在另一实施方式中，用户可以选择和删除所有存储的消息。在此实施方式中，如图7中所示，可以向回收站120发送REFER请求以通过引用用户邮件存储账户的SIP URI而不是单个消息或者消息的URRI列表来删除所有消息。在图7的实施方式中还示出了，绕过虚拟用户代理而将具有INVITE请求的SIP REFER消息直接发送至基于网络的回收站。备选地，如关于图1中示出的实施方式所述，可以将具有INVITE的SIP REFER发送至虚拟用户代理。

如图7中的740处所示，用户确定他或者她希望删除他或者她的邮件存储账户中的所有消息。此时，用户/客户端设备100将具有INVITE请求750的SIP REFER发送到回收站120

(RecycleBin@mailserver.sonera.com)，其中包括用户邮件存储账户的SIP URI(在此情况下是User@mailserver57.Sonera.com)。具有INVITE请求750的SIP REFER的作用是请求在基于网络的回收站120(RecycleBin@mailserver.sonera.com)以及用户账户110或者在虚拟用户账户155(如果使用)之间建立SIP会话。在760处，回收站120通过“202 ACCEPT”来接受来自用户/客户端设备100的SIPREFER请求，以此来进行响应。在770处，回收站120还发送INVITE请求以与虚拟用户代理155建立SIP会话。在780处，虚拟用户代理155接受此会话。在790处，以消息会话中继协议(MSRP)的形式来与虚拟用户代理155正式建立SIP会话，其中将会话描述协议(SDP)媒体属性设置为a＝RecvOnly(只收)。在800处，回收站120向用户/客户端100通知SIP会话，并且在810处，用户/服务器设备100确认此通知。在SIP/MSRP会话中，用户邮件存储账户中的所有消息(在此情况下是MSG 1、MSG 2以及MSG 3)从用户账户110发送至基于网络的回收站120，这导致所有消息从用户账户110中消失。在所有消息从用户邮件存储账户成功传输之后，在虚拟用户代理155以及回收站120之间的SIP会话结束。如820处示出，最终结果是：在用户邮件存储服务器中的用户账户110中不存在消息。

类似于先前的实施方式，还可以对用户账户110以及回收站120的功能进行配置。在此情况下，发送INVITE请求以建立SIP会话770、此请求的确认780以及利用MSRP建立SIP会话790不是必须的。

图8示出了本发明可以在其中使用的系统10，包括可以通过网络进行通信的多个通信设备。系统10可以包括有线或无线网络的任意组合，其中这些网络包括但不限于移动电话网络、无线局域网(LAN)、蓝牙个人局域网、以太网LAN、令牌环LAN、广域网、互联网等。系统10可以包括有线通信设备和无线通信设备两者。

例如，图8中所示系统10包括移动电话网络11和互联网28。通往互联网28的连接可以包括但不限于远程无线连接、短程无线连接，以及各种有线连接，所述有线连接包括但不限于电话线、电缆线路、电力线等。

系统10的示例性通信设备可以包括但不限于移动电话12、组合式PDA和移动电话14、PDA 16、集成消息传递设备(IMD)18、台式计算机20，以及笔记本计算机22。通信设备可以是固定的或者在由行进中的人携带时是移动的。通信设备还可以处于交通模式中，包括但不限于汽车、卡车、出租车、公共汽车、船、飞机、自行车、摩托车等。通信设备的一些或全部可以通过通往基站24的无线连接25发送和接收呼叫和消息，并且通过通往基站24的无线连接25与服务提供商进行通信。基站24可以连接至网络服务器26，该服务器26允许移动电话网络11和互联网28之间的通信。系统10可以包括附加的通信设备和不同类型的通信设备。

图9和图10示出了本发明可以在其中实现的一个代表性移动电话12。然而应当理解，无意将本发明限制为一种特定类型的移动电话12或者其他电子设备。可以使用的其他类型的电子设备包括但不限于，PDA 16、通信PDA以及移动电话14、IMD 18、台式计算机20，以及笔记本计算机22。通信设备可以是固定的或者在由行进中的人携带时是移动的。通信设备还可以处于交通模式中，包括但不限于汽车、卡车、出租车、公共汽车、船、飞机、自行车、摩托车等。

图9和图10的移动电话12包括：壳体30、液晶显示器形式的显示器32、小键盘34、麦克风36、耳机38、电池40、红外端口42、天线44、根据本发明一个实施方式的UICC形式的智能卡46、读卡器48、无线接口电路52、编解码电路54、控制器56以及存储器58。单独的电路和元件可以是本领域公知的所有类型，例如Nokia范围内的移动电话系列。出于示例目的，图8所示的系统10包括移动电话网络11以及互联网28。对互联网28的连接可以包括但不限于远程无线连接、短程无线连接，以及各种有线连接，所述有线连接包括但不限于电话线、电缆线路、电力线等。

在方法步骤的通常背景下对本发明进行了描述，在一个实施方式中，这些方法步骤可以通过程序产品来实现，该程序产品包括在网络环境中由计算机执行的计算机可执行指令，诸如程序代码。通常，程序模块包括例程、程序、对象、组件、数据结构等，用于执行具体任务或者实现特定的抽象数据类型。计算机可执行指令、相关数据结构和程序模块代表了用于执行此处公开的方法的步骤的程序代码的示例。这种可执行指令或者相关数据结构的特定序列代表了用于实现在这种步骤中描述的功能的对应动作的示例。

本发明的软件和网络实现能够利用标准编程技术来完成，利用基于规则的逻辑或者其他逻辑来实现数据库搜索步骤、相关步骤、比较步骤和决策步骤。还应当注意的是，此处以及权利要求书中使用的词语“组件”和“模块”意在包括使用一行或者更多行软件代码的实现和/或硬件实现和/或用于接收手动输入的设备。

出于示例和描述的目的，已经给出了本发明实施的前述说明。前述说明并非是穷举性的也并非要将本发明限制到所公开的确切形式，根据上述教导还可能存在各种变形和修改，或者是可能从本发明的实践中得到各种变形和修改。选择和描述这些实施方式是为了说明本发明的原理及其实际应用，以使得本领域的技术人员能够以适合于构思的特定用途来以各种实施方式和各种修改而利用本发明。

附录A

SIP工作组                           G.Camarillo

互联网草案                          Ericsson

届满：2006年4月26日                 A.Niemi

                                    M.Isomaki

                                    M.Garcia-Martin

                                    Nokia

                                    H.Khartabil

                                    Telio

                                    2005年10月21日

参考会话发起协议(SIP)中的多项资源

draft-itef-sipping-multiple-REFER04.txt

本备忘录的状态

根据BCP 79的章节6，通过发布本互联网草案，每位作者表明，他或者她所了解的任何可应用专利或者其他IPR权项已经或者将要被公开，并且他或者她开始了解的任何内容将要被公开。

互联网草案是互联网工程任务组(ITEF)、其领域及其工作组的工作文档。注意，其他工作组还可以将工作文档作为互联网草案来分发。

互联网草案是一种草案文档，其最长有效性为六个月，并且可以在任何时间由其他文档进行更新、替换或者废除。将互联网草案作为引用材料或者将其作为“工作进程中”以外的形式进行引用，是不适当的。

在http://www.ietf.org/ietf/lid-abstracts.txt处，可以访问当前互联网草案的列表。

在http://www.ietf.org/shadow.html处，可以访问互联网草案的镜像目录(Shadow Directory)列表。

本互联网草案将于2006年4月24日过期。

版权声明

版权(C)互联网协会(2005)

摘要

本文档定义了对SIP REFER方法的扩展，从而使此方法可用以将服务器引用至多个资源。这些扩展包括对于在Refer-to报头中的统一资源标识符(URI)-列表的指针以及“multiple-refer(多参考)”SIP选项标签的使用。

目录

1.介绍.......................................................................................................................................15

2.术语.......................................................................................................................................15

3.操作概要...................................................................................................................................15

4.Multiple-refer SIP选项标签..............................................................................................................16

5.禁止REFER的隐式订阅........................................................................................................................16

6.SIP-发布者的行为...........................................................................................................................17

7.REFER接受者的行为..........................................................................................................................18

8.默认URI列表格式............................................................................................................................18

9.示例.......................................................................................................................................19

10.安全性考虑事项............................................................................................................................21

11.IANA考虑事项..............................................................................................................................21

12.参考文献..................................................................................................................................22

  12.1 标准化参考文献........................................................................................................................22

  12.2 信息性参考文献........................................................................................................................22

作者地址.....................................................................................................................................23

完全版权声明.................................................................................................................................44

1.介绍

SIP[3]REFER方法[5]允许用户代理来请求服务器向第三方发送请求。另外，应用成员需要请求服务器来朝向一组目的地而发起事务。在一个示例中，会议的仲裁者可能希望会议服务器向一组参与者发送BYE请求。在另一示例中，相同的仲裁者可能希望会议服务器向一组参与者发送INVITE。

对REFER定义一种扩展，从而可以使用REFER来将服务器参考至多个目的地。另外，我们使用在[7]中定义的REFER扩展，其禁止REFER的隐式订阅。

2.术语

在本文档中，词语“必须”、“不得”、“需要”、“应该”、“不应”、“应当”、“不能”、“推荐”、“不推荐”、“可以”以及“可选”应解释为如BCP 14，RFC 2119[1]中所述，并且表明对于适应性实现的需求级别。

定义了以下三个新术语：

REFER发布者(REFER-Issuer)：发布REFER请求的用户代理。

REFER接受者(REFER-Recipient)：接收REFER请求的用户代理。

REFER目标(REFER-Target)：由REFER接受者生成的请求的所期望最终接受者。

3.操作概要

本文档定义了对SIP REFER方法[5]的扩展，其允许SIP用户代理客户端(UAC)在REFER请求中包括REFER目标的列表，并且将其发送至服务器。服务器将针对REFER目标URI列表中的每个条目创建新的请求。

使用URI列表来表示REFER的多个REFER目标。希望将服务器参卡至一组目的地的UAC(用户代理客户端)创建SIP REFER请求。Refer-to报头包括指向包括在主体部分中的URI列表的指针以及Required报头字段中的选项标签：“multiple-refer(多参考)”。此选项-标签表示需要支持在此规范中描述的功能性。

当服务器接收此类请求时，其针对每个目的地创建新的请求并将其发送。

本文档不提供供UAC用来找出关于具有多REFER目标的REFER请求的任何机制。此外，本文档不提供对作为SIP REFER方法一部分的隐式订阅机制的支持。保持UAC了解REFER结果的方式是服务特定的。例如，发送REFER请求以邀请一组参与者参与会议的UAC可能发现，参与者通过订阅会议状态事件而成功加入会议[9]。

4.Multiple-referSIP选项标签

我们针对Required以及Supported报头字段定义了新的SIP选项：“multiple--refer”。

用户代理在Supported报头中包括“multiple-refer”选项标签表示与此规范相一致。

生成REFER的用户代理(其中，该REFER具有指向其Refer-to报头字段中的URI列表的指针)在REFER的Require报头字段中必须包括“multiple-refer”选项标签。

5.禁止REFER的隐式订阅

具有单一REFER目标的REFER隐式地建立对REFER事件的订阅。通过此隐式订阅，将关于朝向REFER目标的事务结果通知给REFER发布者。如在RFC 3515[5]中所述，作为REFER请求所创建的隐式订阅的结果而被发送NOTIFY请求包含“消息/sipfrag”[4]类型的主体，其描述由REFER接受者所发起的事务的状态。

在REFER发布者生成具有多REFER目标的REFER的情况下，REFER发布者通常已经订阅了其他事件包，所述事件包可以提供关于针对REFER目标的事务的结果。例如，指示会议服务器来向一组参与者发送BYE请求的仲裁者通常订阅了针对该会议的会议状态事件包。对此事件包的通知将保持把会议参与者的当前列表通知给仲裁者以及其余订阅者。

使用多REFER的多数应用不需要其隐式的订阅。同时，生成具有多REFER目标的REFER请求的SIP REFER发布者应当在Require报头字段中包括“norefersub”选项标签，以指示不应将关于该请求的通知发送至REFER发布者。“norefersub”SIP选项标签在[7]中定义并且禁止REFER的隐式订阅。

在撰写时，不存在允许通过REFER隐式订阅来报告多个事务状态的扩展。这是本文档的动机，以便推荐使用“norefersub”选项标签。如果将来定义了此类扩展，则对其进行使用的REFER发布者可以避免使用“norefersub”选项标签并且代替地使用新的扩展。

6.SIP-发布者的行为

如在章节4以及章节5中所指示，创建具有多REFER目标的REFER请求的SIP REFER发布者在Require报头字段中包括“multiple-refer”以及“norefersub”。

具有多REFER目标的REFER请求的Refer-to报头字段必须包括指向承载URI列表的主体部分的指针(即，内容ID统一资源定位符(URL)[2])。REFER发布者不应在URI列表中包括一次以上的任何特定URI。

7.REFER接受者的行为

REFER接受者遵循RFC 3515中章节2.4.2的规则[5]，以便确定对于REFER的响应的状态代码。

如果URI列表包含URI不止一次，则REFER接受者必须按照在URI列表中仅出现一次URI那样来操作。REFER接受者使用特定于URI列表中每个URI的URI配置(scheme)的比较规则，以便确定是否存在任何出现一次以上的URI。

REFER接受者按照RFC 3515中的规则[5]来生成朝向REFER目标的所需请求，针对URI列表中每个URI，就像其已经接收到常规(没有URI列表)REFER那样操作。

8.默认URI列表格式

在多REFER请求中使用的URI列表主体的默认格式是在[6]中规定的资源列表。能够生成或者接收具有多REFER目标的用户代理必须支持如在[6]中规定的这种格式，并且可以支持其他的格式。

此外，可扩展标记语言(XML)配置访问协议(XCAP)资源列表文档提供了诸如以下特征：层次列表，以及通过相对于XCAP根URI的参考来包括多个条目的能力(这对于在本文档中定义的多REFER服务并不需要)。由此，当使用默认资源列表文档时，生成具有多REFER目标的SIP REFER发布者应当使用平面列表(即，非层次列表)并且不应使用<entry-ref>元素。

接收到比已订阅更多信息的URI列表的REFER接受者可以丢弃所有额外的信息。

图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:bill@example.com＂/>

    <entry uri＝＂sip:joe@example.org＂/>

    <entry uri＝＂sip:ted@example.net＂/>

 </list>

</resource-lists>

图1URI列表

9.示例

图2示出了REFER发布者向会议中心发送多REFER请求的示例流程，其中该会议中心担任REFER接受者。REFER接受者针对每个REFER目标生成BYE请求。(在[10]中规定了如何使用REFER来从会议中去除参与者。)

图2包含多REFER目标的REFER请求的示例流程

REFER请求[1]包含包括指向消息体的指针的Refer-To报头字段，其中该消息体承载REFER目标的URI列表。REFER的Require报头字段承载“multiple-refer”以及“norefersub”选项标签。图3示出了此REFER请求的示例。资源列表文档包含REFER目标的列表以及REFER接受者生成的SIP请求。

REFER sip:conf-123@example.com SIP/2.0

Via:SIP/2.0/TCP client.chicago.example.com

      ；branch＝z9hG4bKhjhs8ass83

Max-Forwards:70

To:＂Conference123＂<sip:conf-123@example.com>

From:Carol<sip:carol@chicago.example.com>；tag＝32331

Call-ID:d432fa84b4c76e66710

CSeq:2REFER

Contact:<sip:carol@client.chicago.example.com>

Refer-To:<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:<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示出了REFER接受者发送至第一REFER目标的BYE请求[3]的示例。

BYE sip: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:d432fa84b4c34098s812

CSeq:34 BYE

Content-Length:0

图4BYE请求

10.安全性考虑事项

关于SIP URI列表服务的框架以及安全性考虑事项讨论了关于SIP URI列表服务的问题。假设接受具有多REFER目标的REFER的服务器用于URI列表服务，此类服务器的实现必须遵循[8]中的相关安全性规则。这些规则包括opt-in列表以及客户端的强制认证以及授权。

另外，服务器应当仅接受服务器理解的应用上下文内的REFER请求(例如，会议应用)。这意味着，服务器不应接受其不理解方法的REFER。这两个规则隐含的意思是，服务器不能用作其仅用作将其不理解的随机消息进行扇出操作的哑服务器。

11.IANA考虑事项

本文档定义了新的SIP选项标签“multiple-refer”。此选项标签应当在SIP参数注册器中进行注册。

将“多refer”选项标签放置在所支持报头字段中的SIP用户代理理解包含描述多REFER目标的资源列表文档的REFER请求。

12.参考文献

12.1 标准化参考文献

[1]Bradner，S.，＂Key words for use in RFCs to Indicate RequirementLevels＂，BCP14，RFC 2119，March 1997.

[2]Levinson，E.，＂Content-ID and Message-ID Uniform ResourceLocators＂，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)ReferMethod＂，RFC 3515，April 2003.

[6]Rosenberg，J.，＂Extensible Markup Language(XML)Formats forRepresenting Resource Lists＂，draft-ietf-simple-xcap-list-usage-05(work in progress)，February 2005.

[7]Levin，O.，＂Suppression of Session Initiation Protocol REFERMethod Implicit Subscription＂，

draft-ietf-sip-refer-with-norefersub-03(work in progress)，October 2005.

[8]Camarillo，G.and A.Roach，＂Requirements and Framework forSession Initiation Protocol(SIP)Uniform Resource Identifier(URI)-List Services＂，draft-ietf-sipping-uri-services-03(workin progress)，April 2005.

12.2 信息性参考文献

[9]Rosenberg，J.，＂A Session Initiation Protocol(SIP)EventPackage for Conference State＂，draft-ietf-sipping-conference-package-12(work in progress)，July 2005.

[10]Johnston，A.and O.Levin，＂Session Initiation Protocol CallControl-Conferencing for User Agents＂，draft-ietf-sipping-cc-conferencing-07(work in progress)，June 2005.

作者地址

Gonzalo Camarillo

Ericsson

Hirsalantie 11

Jorvas 02420

Finland

电子邮件：Gonzalo.Camarillo@ericsson.com

Aki Niemi

Nokia

P.O.Box 321

NOKIA GROUP，FIN 00045

Finland

电子邮件：Aki.Niemi@nokia.com

Markus Isomaki

Nokia

Itamerenkatu 11-13

Helsinki 00180

Finland

电子邮件：Markus.Isomaki@nokia.com

Miguel A.Garcia-Martin

Nokia

P.O.Box 407

NOKIA GROUP，FIN 00045

Finland

电子邮件：miguel.an.garcia@nokia.com

Hisham Khartabil

Telio

P.O.Box 1203

Oslo 0110

Norway

电子邮件：Hisham.Khartabil@telio.no

知识产权声明

本IETF并不侵犯关于任何知识产权权利或者可能要求保护的其他权利的有效性以及范围，其中所述权利属于在本文档中所述方法的实现或者使用、或者扩展至在此类权利下可用或者不可用的任何许可；或者已经进行了独立的努力以标识任何此类权利。关于权利过程的信息可参见BCP 78以及BCP 79。

可以从位于http://www.ietf.org.ipr的IETF在线IPR知识库中获取以下内容：对IETF秘书处进行的IPR公开的副本、以及将有效的任何许可的保证、或者由此规范的实现者或者用户尝试获取此类所有权使用或者一般许可或者准许的尝试的结果。

IETF邀请任何感兴趣方来关注可能覆盖需要实现此标准的技术的任何版权、专利或者专利应用、或者其他所有权。请将此类信息通知至ietf-ipr@ietf.org。

有效性免责声明

本文档以及在此包含的信息是在“现有形式”的基础上提供，以及他/她所代表或被赞助(如果有的话)的投稿人、组织、互联网协会以及互联网工程任务组以明示或者暗示的方式对于包括但不限于以下使用放弃所有担保：在此使用的信息没有侵犯任何权利，或者放弃为特定目的适用或者可销售的任何暗示担保。

版权声明

版权(C)互联网协会(2005)。除非在此阐明，本文档具有在BCP 78中包含的权利、许可以及限制，作者保留他们的所有权利。

感谢

对于RFC编辑器功能的资助目前由互联网协会提供。

附录B

SIP工作组                               M.Garcia-Martin

互联网草案                              M.Isomaki

                                        Nokia

届满：2006年8月27日                     G.Camarillo

                                        S.Loreto

                                        Ericsson

                                        2006年2月23日

支持具有会话发起协议(SIP)的文件传输的机制

draft-garcia-sipping-file-transfer-mech-00.txt

本备忘录的状态

根据BCP 79的章节6，通过发布本互联网草案，每位作者表明，他或者她所了解的任何可应用专利或者其他IPR权项已经或者将要被公开，并且他或者她开始了解的任何内容将要被公开。

互联网草案是互联网工程任务组(ITEF)、其领域及其工作组的工作文档。注意，其他工作组还可以将工作文档作为互联网草案来分发。

互联网草案是一种草案文档，其最长有效性为六个月，并且可以在任何时间由其他文档进行更新、替换或者废除。将互联网草案作为引用材料或者将其作为“工作进程中”以外的形式进行引用，是不适当的。

在http://www.ietf.org/ietf/lid-abstracts.txt处，可以访问当前互联网草案的列表。

在http://www.ietf.org/shadow.html处，可以访问互联网草案的镜像目录(Shadow Directory)列表。

本互联网草案将于2006年8月27日过期。

版权声明

版权(C)互联网协会(2006)

摘要

本文档提供了一种用于支持在两个用户代理(UA)之间传送一个或者多个文件的机制。SIP以及会话描述协议(SDP提供/回答模型用以信令发送会话的建立。消息会话中继协议(MSRP)用以在两个断点之间实际传送文件。

目录

1.介绍........................................................................................................................................27

2.术语........................................................................................................................................28

3.定义........................................................................................................................................28

4.操作概要....................................................................................................................................29

5.对SDP的扩展.................................................................................................................................29

6.协议操作....................................................................................................................................32

  6.1 文件选择符..............................................................................................................................32

  6.2 提供者的行为............................................................................................................................33

   6.2.1 提供者是文件发送者...................................................................................................................33

   6.2.2 提供者是文件接受者...................................................................................................................33

   6.2.3 针对多个文件的SDP offer.............................................................................................................34

  6.3 回答者的行为............................................................................................................................34

   6.3.1 回答者是文件接收者...................................................................................................................34

   6.3.2 回答者是文件发送者...................................................................................................................34

  6.4 MSRP使用................................................................................................................................35

7.示例........................................................................................................................................35

  7.1 UAC向UAS发送文件。......................................................................................................................35

  7.2 UAC从UAS请求文件........................................................................................................................39

8.安全性考虑因素..............................................................................................................................41

9.IANA考虑因素................................................................................................................................41

10.感谢.......................................................................................................................................41

11.参考文献...................................................................................................................................42

  11.1标准化参考文献..........................................................................................................................42

  11.2信息性参考文献..........................................................................................................................42

作者地址......................................................................................................................................43

完全版权声明..................................................................................................................................44

1.介绍

会话发起协议(SIP)[5]提供用于在用户之间建立和管理多媒体会话的一般功能。这些会话通常包含诸如但不限于语音和视频的实时媒体流。基本上，只要在会话描述协议(SDP)[9]提供/回答交换[9]中存在如何进行协商的规范，便可以支持任何媒体成分类型。

消息会话中继协议(MSRP)[10]是用于在会话的上下文中传送即时消息(IM)的协议。该协议规范包括如何将其与SIP和SDP一起使用的描述。除了纯文本消息，MSRP能够承载任意(二进制)多用途网际邮件扩展(MIME)[2]兼容的内容，诸如图像或者视频片段。

存在很多这样的情况，基于SIP多媒体会话中所涉及的用户将在会话的上下文内部交换文件。通过MSRP，可以将文件作为MIME对象来嵌入即时消息流的内部。MSRP还具有适用于文件传送的其他特征。在不阻塞IM的情况下，消息块(chunk)支持对大文件的传送以及交互性IM交换之间的相同传输链接的共享。MSRP中继[14]提供了一种用于网络地址转换器(NAT)的机制。最后，安全MIME(S/MIME)[7]可以用于确保在对等端之间传送的完整性以及可信性。

然而，基本的MSRP没有方便地满足在基于SIP会话内的文件传送服务的[13]中表达的全部需求。主要缺少以下三个特征：

·接受者必须能够区别“附加至IM的文件”以及“文件传送”，并允许接受者针对这些情况进行不同处理。

·对于发送者，必须能够发送文件传送的请求。对于接受者，必须能够接收或者拒绝该请求。必须仅在由接受者接受后进行实际传送。

·对于发送者，必须能够在实际传送之前传递关于文件的某些元信息。这必须至少包括内容类型和大小、以及简短(人类可读的)描述。

所有这些需求是关于会话描述和协商，而不是关于实际文件传送机制。由此，显然，为了满足上述需求，针对SDP定义属性扩展和使用转换就足够了，而MSRP本身不需要扩展并且可以以其现状进行使用。此外，可以以此方式规定所有SDP扩展，并且不支持这些扩展的端点仅需执行基本MSRP要求的实现，虽然受到某些功能性限制，但其依然可以在文件传送会话中用作被叫方。

通过将MSRP用作会话内的转换协议，本文档定义了为满足关于在SIP会话内文件传送服务需求所需的使用转换以及SDP属性扩展。

原则上，可以使用在此定义的SDP扩展并且由能够承载MIME对象的任何其他类似协议替换MSRP。如果需要，可以将此类规范撰写为独立的文档。

在本文档中描述的机制允许往来于远程用户代理发送或者接收文件。

章节3定义了本文档中使用的一些术语。章节4提供了操作概述。在章节5中定义了关于如何使用现有内容的新SDP属性和转换的详细语法和语义。章节6描述了协议操作，包括SIP、SDP以及MSRP。在章节7中给出了某些示例。

2.术语

在本文档中，词语“必须”、“不得”、“需要”、“应该”、“不应”、“应当”、“不能”、“推荐”、“不推荐”、“可以”以及“可选”应解释为如BCP 14，RFC 2119[1]中所述，并且表明对于适应性实现的需求级别。

3.定义

出于本文档的目的，在RFC 3264[6]中特别规定的定义应用：

·回答者(answerer)

·提供者(offerer)

另外，定义了如下术语：

文件发送者：希望向文件接受者传送文件的端点。

文件接受者：希望从文件发送者接收文件的端点。

文件选择器：多个SDP属性的交集，导致选择零个或者更多文件。这在章节6.1中更详细地描述。

4.操作概要

在本文档中规定的文件传输服务使用SDP offer/answer(提供/回答)[6]来建立将要传输文件的基于MSRP的媒体流。每个“m＝”行描述用以传输单一文件的基于MSRP的媒体流。即，多文件的传输需要多个“m＝”行。

本文档定义了允许用户代理描述待发送文件或者将要从远程用户代理接收的文件的一组SDP属性以及某些转换。这样，用户代理可以定义基于文件名称、大小、描述、散列、图标(例如，如果文件是图片)等来接受或者不接受给定的文件传输。

有效的是，此机制的目标类似于SIP[15]中的内容间接机制的目标。两种机制均允许用户代理确定基于关于文件的信息来下载或者不下载文件。然而，尽管在SIP消息[12]请求中可以使用内容间接机制来传输文件(实际文件传输机制可以是超文本传输协议(HTTP)[11])，在文件传输协议是MSRP[10]的情况下，在由offer/answer交换建立的会话中不能使用该机制。

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

                       ；attribute is defined in sdp-new

filename-attr        ＝＂filename:＂filename-string

filename-string      ＝byte-string      ；byte-string defined in sdp-new

filetype-attr        ＝＂filetype:＂type＂/＂subtype＊(＂；＂parameter)

                              ；parameter defined in RFC 2045

type                 ＝token

subtype              ＝token

disposition-attr     ＝＂disposition:＂disposition-value

disposition-value    ＝token

filesize-attr        ＝＂filesize:＂filesize-value

filesize-value       ＝integer          ；integer defined in sdp-new

lcon-attr            ＝＂icon:＂icon-value

icon-value           ＝cid-url           ；cid-url defined in RFC 2392

hash-attr            ＝＂hash:＂hash-algorithm WSP hash-value

hash-algorithm       ＝token            ；see IANA Hash Algorithm

                                        ；section in the IPSEC

                                        ；registry

hash-value           ＝byte-string      ；byte-string defined in sdp-new

图1SDP扩展的语法

“filename(文件名)”属性包含内容的文件名，并且其属性是字节串(在SDP[9]中规定)。

“filetype(文件类型)”属性包含内容的MIME媒体类型。通常，可以在内容类型(Content-Type)报头字段(参加RFC2045[21])中表达的任何内容还可以以“filetype”属性来表示。在MIME媒体类型IANA登记中列出了可能的MIME媒体类型值。接下来可以是零个或者更多参数。在RFC 2045[2]中规定了“参数”的语法。

“disposition(部署)”属性向对等端提供了文件的期望部署的建议。在邮件内容部署值的IANA登记中列出了可能的值，尽管最可能是：仅仅“内联”或者“附件”的值对于文件传输应用是重要的。

“filesize(文件大小)”属性以八位字节形式指示文件大小。

“icon(图标)”属性可用于诸如图像的特定文件类型。允许发送者包括一个指针，该指针指向包括表示带传输文件内容的图标的主体。这允许发送者包括该图标作为伴随SDP的另一主体，并且对于接受者来说，获得可以潜在传输的文件的图标。推荐的是，保持将图标限制至有意义的最小字节数。“icon”属性包含内容ID(Content-ID)URL，这在RFC 2392[3]中进行了规定。

“hash(散列)”属性提供了待传输文件的散列。其目的在于以下两方面：一方面，允许文件接收者通过其散列而不是通过其文件名来标识文件，通过某些带外(out-of-band)机制来使得文件接收者已经知晓文件的散列。另一方面，允许文件发送者提供待传输文件的散列，该散列可由文件接受者使用用于验证其内容或者避免已经存在的文件的不必要传输。“hash”属性包括散列的类型及其值。可能的散列类型是IPSec登记的IANA的散列算法部分中定义的那些类型。根据此规定的实现必须实现US安全散列算法1(SHA1)[4]，并且可以实现其他散列算法。SDP的创建者还可以对相同的文件添加一个以上的“hash”属性(可能具有不同类型的散列)。所述值是通过向文件内容应用散列算法而生成的字节串。

下文是包含在本备忘录中定义的扩展的SDP主体示例：

v＝0

o＝alice 2890844526 2890844526 IN IP4 host.atlanta.example.com

s＝

c＝IN IP4 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:id2@alicepc.example.com

a＝hash:SHA 72245fe8653ddaf371362f86d471913ee4a2ce2e

图2描述文件传输的SDP示例

6.协议操作

此部分讨论如何在offer/answer[6]交换的上下文中使用章节5中定义的参数。另外，此章节还讨论了使用MSRP的端点的行为。

通常，可以根据提供者是文件发送者或者文件接收者来区分两种情况：

1)提供者是文件发送者，即提供者希望向回答者传送文件。回答者是文件接收者。在此情况下，SDP offer包括“sendonly(只发)”属性。

2)提供者是文件接受者，即提供者希望从回答者获取文件。回答者是文件发送者。在此情况下，SDP offer包含“recvonly(只收)”属性，并且由此SDP回答包含“sendonly”属性。

6.1 文件选择符

在本文档中规定的协议要求一种用来标识远程主机中文件的机制。引入了文件选择器的概念，该文件选择器是“hash”、“filename”、“filesize”以及“filetype”属性的交集。

根据SDP文件中的所提及属性以及根据主机中的可用文件，文件选择器可以指向零个、一个或者更多文件。在本文档中规定的文件传输机制需要文件选择器生成单一的文件选择。通常，如果“hash”属性是已知的，则“hash”属性足够生成指向零个或者一个文件的文件选择器。然而，文件选择器并非总是已知或者可用。有时，仅已知“filename”、“filesize”或者“filetype”属性，从而使得文件选择器可能导致产生一个以上的文件，这是不期望的情况。相反情况也是如此，如果文件选择器包含“hash”和“filename”属性，但是远程主机处的用户已经将文件重新命名，尽管存在具有所指示散列的文件，但是文件名并不匹配，由此，文件选择器将导致选择零个文件。

6.2 提供者的行为

希望往来于回答者发送或者接收一个或者多个文件的提供者必须建立包含一个或者多个“m＝”行的会话的SDP[9]描述，根据MSRP[10]过程，每一行描述一个MSRP会话(并且由此，一个文件传输操作)。还必须包括MSRP[10]所需的以及指定的所有媒体行属性。对于每个待传输文件，必须存在单独的“m＝”行。

6.2.1 提供者是文件发送者

如果提供者是文件发送者，则其必须向SDP offer中添加会话或者媒体“sendonly”属性。另外，提供者应当还添加分别指示文件的类型、大小以及散列的“filetype”、“filesize”、以及“hash”属性。

当提供者创建SDP offer时，这些属性可能不是已知的，例如，主机仍然正在处理文件。

“hash”属性包含对文件接收者有价值的信息，以便指示文件是否已经可用以及不必被传送。

提供者还可以添加进一步描述待传输文件的“filename”、“icon”以及“disposition”属性。“disposition”属性提供呈现建议，(例如：文件发送者可能需要文件接收者将文件呈递为“内联”，或者将其保存为“附件”)。另外，通过使用“i＝”媒体行，提供者可以提供人类可读的文件描述。

6.2.2 提供者是文件接受者

如果提供者是文件接受者，则其必须创建包含会话或者媒体“recvonly”属性的SDP offer。然后，提供者应当添加构成文件选择器(“hash”、“filename”“filesize”、或者“filetype”)的至少一个属性。在多种情况下，如果文件的散列是已知的，则该散列足够标识文件，由此提供者可以仅包括“hash”属性。然而，特别是在未知文件散列的情况下，文件名称、大小以及类型可以提供待获取文件的描述。

6.2.3 针对多个文件的SDP offer

希望发送或者接收一个以上文件的提供者针对每个文件生成一个“m＝”行。以此方式，按照常规SDP[10]过程，回答者可以通过将其相关联的“m＝”行的端口号设置为零来拒绝单独的文件。

针对每个文件使用“m＝”行，这意味着使用不同MSRP会话来传输不同文件。然而，可以在单一的TCP连接上建立并运行所有这些MSRP会话，如在[10]的章节8.1中所述。

6.3 回答者的行为

如果回答者希望拒绝提供者提供的文件，则其按照SDP[9]过程来将与该文件相关联的“m＝”行的端口号设置为零。如果回答者确定接受文件，则按照常规MSRP[10]以及SDP[9]的过程进行处理。

6.3.1 回答者是文件接收者

如果回答者是文件接收者并且确定接收文件传输，则其必须创建包含“recvonly”属性的SDP回答(参见RFC 3264[6])。如果offer包含“filetype”、“filesize”或者“filename”属性，则回答者必须将其复制到确认中。这向提供者通知：回答者支持此规范。如果回答者是文件接收者，则其在SDP回答中不得包括“icon”、“hash”或者“disposition”属性。

如果所接收的offer包含“hash”属性，则回答者可以使用其来查看具有相同散列的本地文件是否已经可用，在此情况下，这可以表示接收到复制文件。根据回答者来确定是否接受文件传输或者不是复制文件的情况。

6.3.2 回答者是文件发送者

如果回答者是文件发送者，则其必须首先检查所接收的SDP offer并且计算文件选择器。文件选择器是修改SDP offer中的相同“m＝”行的“filetype”、“filesize”、“filename”以及“hash”属性(如果存在)的交集(即，上述四个属性位于SDP中的相同“m＝”行中)。文件选择器标识待发送的一个或者多个文件。如果文件选择器不能标识任何文件，则回答者必须通过将端口号设置为零来拒绝文件传输的MSRP流，(以及如果该MSRP流是SDP offer中的唯一流，则如果应当拒绝SDP，则按照RFC3264[6]中的过程进行)。

如果文件选择器指向单一文件，则回答者确定接受文件传输，回答者必须创建包含“sendonly”属性的SDP回答(按照RFC3264[6])。回答者应当添加包含待发送文件的散列的“散列”属性，并且可以包括“filename”、“filetype”、“filesize”、“icon”或者“disposition”属性来进一步描述该文件。

最后，如果文件选择器指向多个文件，则回答者应当拒绝文件传输的MSRP媒体流(通过将端口号设置为零而进行)。

如果需要，则未来的规范可以提供适当的机制，以便允许选择多个文件或者例如通过返回匹配于文件选择器的文件列表来解决多义性问题。

6.4 MSRP使用

在本文档中规定的文件传输服务使用“m＝”行来描述文件的单向传输。由此，在章节6.2以及章节6.3之后建立的每个MSRP会话仅用以传输单一文件。因此，发送者必须使用给定MSRP会话来发送在SDP提供或者回答中描述的文件。即，发送者不必通过相同的MSRP发送额外的文件。

一旦完成文件传输，则文件发送者应当关闭MSRP会话，并且必须根据MSRP[10]过程针对关闭MSRP会话进行处理。

7.示例

7.1 UAC向UAS发送文件。

此会话示出了用于文件传输情况的示例流程。该示例假设使用SIP来传递SDP交换，尽管出于简便原因只概要示出了SIP的细节。

Alice(SDP提供者)希望向Bob(回答者)发送图像文件。Alice的UAC创建包含她希望向Bob发送的文件的描述的单向SDP offer。描述还包括表示带传输文件内容的图标。在图3中示出了序列的流程。

图3UAC向UAS发送文件的流程图

F1：Alice构建将要发送的文件的SDP描述，并且将其附加至寻址到Bob的SIP INVITE请求。

INVITE sip:bob@example.com SIP/2.0

To:Bob<sip:bob@example.com>

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

Cont act:<sip:ali ce@ali cepc.example.com>

Content-Type:multipart/mixed；boundary＝＂boundary71＂

Content-Length:[length]

--boundary 71

Content-Type:application/sdp

Content-Length:[length of SDP]

v＝0

o＝alice 2890844526 2890844526 IN IP4 alicepc.example.com

s＝

c＝IN IP4 alicepc.example.com

t＝0 0

m＝message 7654 TCP/MSRP＊

i＝This is my latest picture

a＝sendonly

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:id2@alicepc.example.com

a＝hash:SHA 72245fe8653ddaf371362f86d471913ee4a2ce2e

--boundary71

Content-Type:image/jpeg

Content-Transfer-Encoding:binary

Content-ID:<id2@alicepc.example.com>

Content-Length:[length of image]

...binary JPEG image...

--boundary 71

从现在开始，出于简化原因，忽略SIP的细节。

F2：Bob接收INVITE请求，检查SDP offer并且提取图标体，检查文件大小并且确定接收文件传输。从而Bob创建了以下SDP回答：

v＝0

o＝bob 2890844656 2890844656 IN IP4 bobpc.example.com

s＝

c＝IN IP4  bobpc.example.com

t＝0 0

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：Alice对Bob打开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

...first chunk of the JPEG image...

-------d93kswow+

F5：Bob确认第一块的接收。

MSRP d93kswow 200OK

To-Path:msrp://ali cepc.example.com:7777/iau39；t cp

From-Path:msrp://bobpc.example.com:8888/9di4ea；tcp

Byte-Range:1-2048/4096

-------d93kswow$

F6：Alice发送第二块以及最后一块。

MSRP op2nc9a SEND

To-Path:msrp://bobpc.example.com:8888/9di4ea；tcp

From-Path:msrp://alicepc.example.com:7777/i au39；tcp

Message-ID:12339sdqwer

Byte-Range:2049-4096/4096

Content-Type:image/jpeg

...second(andlast)chunkof the JPEG image...

-------op2nc9a$

F7：Bob确认第二块的接收。

MSRP op2nc9a 200 OK

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：Alice通过发送SIP BYE请求来终止SIP会话。

F9：Bob确认BYE请求的接收并且发送200(OK)响应。

7.2 UAC从UAS请求文件

在此示例中，Alice(SDP提供者)，希望从Bob(SDP回答者)获取文件。Alice已知Bob具有她希望下载的特定文件。她已经通过带外机制而知晓了文件的散列。散列属性足够产生指向特定文件的文件选择器。从而，Alice创建包含文件描述符的SDP ofier。Bob接收传输并且将文件发送至Alice。图10示出了序列的流程。

图10UAC从UAS请求文件的流程图

Fl：Alice构建她希望接收的文件的n SDP描述，并且将SDP offer

附加至寻址到Bob的SIP INVITE请求。

INVITE sip:bob@example.com SIP/2.0

To:Bob<sip:bob@example.com>

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:<sip:alice@alicepc.example.com>

Content-Type:application/sdp

Content-Length:[length of SDP]

v＝0

o＝alice 2890844526 2890844526IN IP4 alicepc.example.com

s＝

c＝IN IP4 alicepc.example.com

t＝0 0

m＝message 7654 TCP/MSRP＊

a＝recvonly

a＝accept-types:i mage/jpeg

a＝path:msrp://alicepc.example.com:7654/j shA7we；tcp

a＝hash:SHA 72245fe8653ddaf371362f86d471913ee4a2ce2e

从现在开始，为简便起见而省略SIP细节。

F2：Bob接收INVITE请求，检查SDP offer，计算文件描述符并查找其散列值等于在SDP中所指示的文件的本地文件。Bob接收文件传输并且创建SDP回答如下：

v＝0

o＝bob 2890844656 2890844656IN IP4 bobpc.example.com

s＝

c＝IN IP4 bobpc.example.com

t＝00

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：Alice对Bob打开TCP链接。然后，Bob创建包含该文件的SEND请求。

MSRP d93kswow SEND

To-Path:msrp://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：Alice确认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：然后，Bob通过发送SIP BYE请求来终止SIP会话。

F7：Alice确认BYE请求的接收并且发送200(OK)响应。

8.安全性考虑因素

待定

9.IANA考虑因素

待定

10.感谢

作者将感谢Mats Stiller、Nancy Greene、Adamu Haruna以及ArtoLeppisaari对于在本备忘录中所述初始概念的讨论。感谢Pekka Kuure确认本文档的初始版本以及提供的有益意见。

11.参考文献

11.1 标准化参考文献

[1]Bradner，S.，＂Key words for use in RFCs to Indicate RequirementLevels＂，BCP 14，RFC 2119，March 1997.

[2]Freed，N.and N.Borenstein，＂Multipurpose Internet MailExtensions(MIME)Part One:Format of Internet Message Bodies＂，RFC 2045，November 1996.

[3]Levinson，E.，＂Content-ID and Message-ID Uniform ResourceLocators＂，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.，Camarillo，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 withSession Description Protocol(SDP)＂，RFC 3264，June 2002.

[7]Ramsdell，B.，＂Secure/Multipurpose Internet Mail Extensions(S/MIME)Version 3.1 Message Specification＂，RFC 3851，July 2004.

[8]Crocker，D.and P.Overell，＂Augmented BNF for SyntaxSpecifications: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，B.，＂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，B.，Rosenberg，J.，Schul zrinne，H.，Huitema，C.，andD.Gurle，＂Session Initiation Protocol(SIP)Extension forInstant Messaging＂，RFC 3428，December 2002.

[13]Isomaki，M.，＂Requirements and Possible Mechanisms for FileTransfer Services Within the Context of SIP BasedCommunication＂，draft-isomaki-sipping-file-transfer-00(work inprogress)，October 2005.

[14]Jennings，C.，＂Relay Extensions for the Message Sessions RelayProtoccl(MSRP)＂，draft-ietf-simple-msrp-relays-06(work inprogress)，December 2005.

[15]Burger，E.，＂A Mechanism for ContentIndirection in SessionInitiation 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

电子邮件：miguel.an.garcia@nokia.com

Markus Isomaki

Nokia

Keilalahdentie 2-4

Espoo 02150

Finland

电子邮件：markus.isomaki@nokia.com

Gonzalo Camarillo

Ericsson

Hirsalantie 11

Jorvas 02420

Finland

电子邮件：Gonzalo.Camarillo@ericsson.com

Salvatore Loreto

Ericsson

Hirsalantie 11

Jorvas 02420

Finland

电子邮件：Salvatore.Loreto@ericsson.com

完全版权声明

版权(C)互联网协会(2006)

本文档具有BCP78中包含的权利、许可和限制，除非在此阐明，作者拥有其全部权利。

本文档以及在此包含的信息是在“现有形式”的基础上提供，以及他/她所代表或被赞助(如果有的话)的投稿人、组织、互联网协会以及互联网工程任务组以明示或者暗示的方式对于包括但不限于以下使用放弃所有担保：在此使用的信息没有侵犯任何权利，或者放弃为特定目的适用或者可销售的任何暗示担保。

本IETF并不侵犯关于任何知识产权权利或者可能要求保护的其他权利的有效性以及范围，其中所述权利属于在本文档中所述方法的实现或者使用、或者扩展至在此类权利下可用或者不可用的任何许可；或者已经进行了独立的努力以标识任何此类权利。关于权利过程的信息可参见BCP 78以及BCP 79。

可以从位于http://www.ietf.org.ipr的IETF在线IPR知识库中获取以下内容：对IETF秘书处进行的IPR公开的副本、以及将有效的任何许可的保证、或者由此规范的实现者或者用户尝试获取此类所有权使用或者一般许可或者准许的尝试的结果。

IETF邀请任何感兴趣方来关注可能覆盖需要实现此标准的技术的任何版权、专利或者专利应用、或者其他所有权。请将此类信息通知至ietf-ipr@ietf.org。

感谢

对于RFC编辑器功能的资助目前由互联网协会提供