专利名称：：Sip多媒体服务中的删除机制的制作方法
技术领域：
：本发明通常涉及会话发起协议(SIP)服务以及针对即时消息传送和呈现业务的利用扩展的会话发起协议(SIMPLE)服务。更具体地，本发明涉及基于SIP/SIMPLE的服务，诸如即时消息传送(IM)以及一键通(PoC)服务。
背景技术：
：本部分旨在提供在权利要求书中记载的本发明的背景或者上下文。这里的描述可以包括能够贯彻的概念、但是并非技术人员在先前必然已经构思或者贯彻。因此，除非另有指明，在本部分中描述的内容并不是对于本申请中的说明书和权利要求书的现有技术，也不因包含于本部分中而被承认为现有技术。开放移动联盟(OMA)是标准实体，其集中地开发开放标准用于在移动产业中使用。OMA有助于创建可共同操作服务支持者以便跨越国家、运营商以及移动终端运行，并且受到市场需求的驱动。为了扩展移动市场，支持开放移动联盟的公司的运行促进了各种新型、增强型移动信息、通信以及娱乐服务的快速、广泛的开发和部署。OMA当前正在基于以下协议来开发IM服务由国际工程任务组(IETF)SIMPLE工作组开发的SIP、消息会话中继协议(MSRP)以及可扩展标记语言(XML)配置访问协议(XCAP)。已经使用多种专利技术和无线村(WirelessVillage)规范而开发了即时消息发送服务。目前需要一种SIP多媒体服务环境中的删除机制。在http环境中，如果需要删除文档，则可以简单地发布"http删除，，命令。然而，目前没有针对SIP环境而定义的相应删除特征或者功能。实际上，用于8服务的SIP扩展甚至没有定义这种特征。在当前的多媒体服务中，尤其是OMASIP/SIMPLEIM,对于存储和恢复消息存在多种需求。尽管需要删除以及选择性删除已存储的消息，但是还不曾定义此类机制。
发明内容本发明包括用于在SIP多媒体服务中使用的新颖性删除机制。出于此目的，本发明涉及各种SIP多媒体服务环境特征的使用。在一个实施方式中，在网络中定义"回收站"，并且将该"回收站，，与SIP统一资源标识符相关联。存储在网络内的消息被分配有唯一的标识符。如果用户希望删除消息，则他或她请求在消息和网络定义的回收站之间建立SIP/MSRP功能。当处理时，消息离开用户的邮件存储服务器中的用户的账户传送至回收站。根据本发明的系统和方法的使用简单、方便，这是由于使用了诸如SIPREFER方法、虚拟用户代理以及SIPURI的已有的已定义工具。当结合附图时，从下文的详细说明中，本发明的这些以及其他优势和特征、以及其中的组织和操作方式将变得易见，其中在下文描绘的多个附图中，类似的元件使用了类似的附图标记。图1是示出根据本发明一个实施方式的SIP多媒体服务的删除机制的操作的流程图2是示出根据本发明另一实施方式的用于删除已选择消息的SIP多媒体服务的删除机制的操作的流程图3是示出根据本发明另一实施方式的用于删除已选择消息的SIP多媒体服务的删除机制的操作的流程图4是示出根据本发明一个实施方式的用于删除多个已选择消息的SIP多媒体服务的删除机制的操作的流程图5是示出根据本发明一个实施方式的用于删除多个已选择消息的SIP多媒体服务的删除机制的操作的流程图6是示出根据本发明一个实施方式的用于删除多个已选择消息的SIP多媒体服务的删除机制的操作的流程图7是示出根据本发明一个实施方式的用于删除用户的邮件存储账户中所有消息的SIP多媒体服务的删除机制的操作的流程图8是可以实现本发明的系统的概要视图9是可以在本发明的实现中使用的移动电话的透视图；以及图IO是图9的移动电话的电话电路的示意性表示。具体实施例方式本发明包括用于在SIP多媒体服务中使用的新颖的删除机制。本发明涉及用于此目的各种SIP多媒体服务环境的使用。在一个实施方式中，在网络中定义用于已删除项目的"回收站"或者类似位置，并将其与SIP统一资源标识符相关联。对在网络内部存储的消息指派唯一的标识符。如果用户期望删除消息，则他或者她请求在消息以及网络定义的回收站之间建立SIP/MSRP会话功能。当处理时，将消息传送至回收站，放置在用户的邮件存储服务器中的用户账户中。图1是示出根据本发明一个实施方式的SIP多媒体服务的删除机制的操作的流程图。具体地，如在此所述，图l示出了在用户/客户端设备100、邮件存储设备110中的用户账户以及回收站120之间的交互。用户账户110以及回收站120两者位于用户/客户端设备的远程。在图l示出的实施方式中，用户/客户端设备的SIPURI是"User@Sonem.com"。用户账户的SIPURI是"User@mailserver57.Sonera.com"。回4欠站的SIPURI是"RecycleBin@mailserver.sonera.com"。如上所述，可以为网络中存储的消息指派唯一消息标识符。在图1中的130处，利用标识符"13242@mailserver57.Sonera.com"(MSG1)、"13243@mailserver57.Sonera.com"(MSG2)以及"13244@mailserver57.Sonera.com"(MSG3)示出了三个此类消息。10备选地，消息可以作为文件来存储。在一个实施方式中，可以为每个消息给出文件名称、文件类型以及散列值。在图2中，利用标识符"文件1=(文件名，文件类型，唯一散列值)"、"文件2=(文件名，文件类型，唯一散列值)"以及"文件3=(文件名，文件类型，唯一散列值)"示出了三个此类消息。在图1的140处，用户确定他或者她希望删除MSG2。此时，用户/客户端设备100向用户账户110处的消息标识符13243@mailserver57.Sonera.com(其充当虚拟用户代理155)发送具有INVITE(邀请)请求150的SIPREFER。在Refer-to报头中，该SIPREFER请求具有基于网络的回收站地址(RecycleBin@mailserver.sonera.com)。具有INVITE请求150的SIPREFER用于请求与基于网络的回收站120(RecycleBin@mailserver.sonera.com)建立SIP会话。在160处,虚拟用户代理155通过"202ACCEPT(接受)"来接受来自用户/客户端设备100的SIPREFER请求，以此来进行响应。在170处，虚拟用户代理155还发送INVITE请求来与回收站120建立SIP会话。在180处，回收站120接受此会话。在190处，以消息会话中继协议(MSRP)的形式来与虚拟用户代理155正式建立SIP会话，其中将会话描述协议(SDP)媒体属性设置为a=SendOnly(只发)。在200处，虚拟用户代理155向用户/客户端IOO通知SIP会话，并且在210处，用户/客户端设备IOO确认此通知。在SIP/MSRP会话中，MSG2从用户账户IIO发送至基于网络的回收站120,这导致MSG2从用户账户110中消失。在消息MSG2成功传输之后，虚拟用户代理155与回收站120之间的SIP会话结束。结果是，如220处示出，在用户邮件存储服务器中的用户账户110中仅存在MSG1和MSG3。在本发明的备选实施方式中，可以对用户账户IIO以及回收站120的功能进行配置。在此情况下，发送INVITE请求以建立SIP会话170、对此请求的确认180以及利用MSRP来建立SIP会话190不是必须的。在图2中示出了存储为文件的消息的备选实施方式。在此实施方式中，用以将所存储或者选择的消息恢复至回收站的机制可以基于作为附录B而附加的文件传输草案，将附录B并入此申请。在此实施方式中，REFER请求可以包括待删除文件的SDP描述。在图2的140处，用户确定他或者她希望删除MSG2(文件2)。此时，用户/客户端设备100向用户账户110处邮件存储服务器(其充当虚拟用户代理155)发送具有INVITE请求150的SIPREFER。在Refer-to报头中，该SIPREFER请求具有基于网络的回收站地址(RecycleBin@mailserver.sonera.com)。具有INVITE请求150的SIPREFER用于请求与基于网络的回收站120(RecycleBin@mailserver.sonera.com)建立SIP会话。在160处,虚拟用户代理155通过"202ACCEPT"来接受来自用户/客户端设备100的SIPREFER请求，以此来进行响应。在170处，虚拟用户代理155还发送INVITE请求来与回收站120建立SIP会话。在180处，回收站120接受此会话。在190处，以消息会话中继协议(MSRP)的形式来与虛拟用户代理155正式建立SIP会话，其中将会话描述协议(SDP)媒体属性设置为a=SendOnly(只发)。在200处，虚拟用户代理155向用户/客户端IOO通知SIP会话，并且在210处，用户/客户端设备IOO确认此通知。在SIP/MSRP会话中，文件2从用户账户IIO发送至基于网络的回收站120，这导致MSG2从用户账户110中消失。在文件2(MSG2)成功传输之后，在虚拟用户代理155以及回收站120之间的SIP会话结束。如220处示出，最终结果是在用户邮件存储服务器中的用户账户110中仅存在MSG1(文件l)和MSG3(文件3)。在本发明的备选实施方式中，可以对用户账户IIO以及回收站120的功能进行配置。在此情况下，发送INVITE请求以建立SIP会话170、此请求的确认180以及利用MSRP建立SIP会话190不是必须的。在图3中示出了本发明的备选实施方式。在此实施方式中，绕过虚拟用户代理而将具有INVITE请求的SIPREFER直接发送至基于网络的回收站。例如，在340中，用户确定他或者她希望删除MSG2。此时，用户/客户端设备100向回收站120(RecycleBin@mailserver.sonera.com)发送具有INVITEifr求350的SIPREFER。具有INVITE请求350的SIPREFER用于请求在基于网络的回收站120(RecycleBin@mailserver.sonera.com)与用户账户110或者在虚拟用户代理155(如果使用)之间建立SIP会话。在360处，回收站120通过"202ACCEPT"来接受来自用户/客户端设备100的SIPREFER请求，以此来进行响应。在370处，回收站120还发送INVITE请求来与虛拟用户代理155建立SIP会话。在380处，虚拟用户代理155接受此会话。在390处，以消息会话中继协议(MSRP)的形式来与虚拟用户代理155正式建立SIP会话，其中将会话描述协议(SDP)媒体属性设置为a=RecvOnly(只收)。在400处，回收站120向用户/客户端100通知SIP会话，并且在410处，用户/客户端设备100确认此通知。在SIP/MSRP会话中，MSG2从用户账户110发送至基于网络的回收站120，这导致MSG2从用户账户IIO中消失。在消息MSG2成功传输之后，在虚拟用户代理155以及回收站120之间的SIP会话结束。如420处示出，最终结果是在用户邮件存储服务器中的用户账户110中仅存在MSG1和MSG3。类似于先前的实施方式，可以对用户账户110以及回收站120的备选功能进行配置。在此情况下，发送INVITE请求以建立SIP会话370、此请求的确认380以及利用MSRP建立SIP会话390不是必须的。在图4中示出的本发明的实施方式是图3中实施方式的备选。类似于图3，在此实施方式中，绕过虚拟用户代理而将具有INVITE请求的SIPREFER直接发送至基于网络的回收站。然而，在图4的实施方式中，用于将所存储或者选择的消息恢复至回收站的机制是基于如附录B所附加的文件传输草案。在此实施方式中，REFER请求包括待删除文件的SDP描述。在图4中的340处，用户确定他或者她希望删除MSG2(文件2)。此时，用户/客户端设备100向回收站120(RecycleBin@mailserver.sonera.com)发送具有INVITE请求350的SIPREFER。具有INVITE请求350的SIPREFER用于请求与基于网纟各的回^|文3占120(RecycleBin@mailserver.sonera.com)建立SIP会"i舌。在360处，回收站120通过"202ACCEPT，，来接受来自用户/客户端设备100的SIPREFER请求，以此来进行响应。在370处，回收站120还发送INVITE请求来与虚拟用户代理155建立SIP会话。在380处，虛拟用户代理155接受此会话。在390处，以消息会话中继协议(MSRP)的形式来与虚拟用户代理155正式建立SIP会话，其中将会话描述协议(SDP)媒体属性设置为a=RecvOnly(只收)。在400处，回收站120向用户/客户端IOO通知SIP会话，并且在410处，用户/客户端设备100确认此通知。在SIP/MSRP会话中，文件2(MSG2)从用户账户IIO发送至基于网络的回收站120，这导致文件2(MSG2)从用户账户110中消失。在文件2(MSG2)成功传输之后，在虚拟用户代理155以及回收站120之间的SIP会话结束。如420处示出，最终结果是在用户邮件存储服务器中的用户账户IIO中仅存在文件1(MSG1)和文件3(MSG3)。类似于先前的实施方式，可以对用户账户110以及回收站120的备选功能进行配置。在此情况下，发送INVITE请求以建立SIP会话370、此请求的确认380以及利用MSRP建立SIP会话390不是必须的。在另一实施方式中，用户可以选择并删除所存储的多个消息。在此实施方式中，如图5中示出，可以将多个REFER请求发送至回收站120以删除所选#^的多个消息。并入此申请中的附录A示出了多个REFER请求的一个实施方式或者实现。在图5所示的实施方式中，绕过虚拟用户代理而将具有INVITE请求的SIP多REFER直接发送至基于网络的回收站。备选地，如关于图l所示的实施方式所述，将具有INVITE的SIP多REFER发送至虚拟用户代理。在图5中的540处，用户确定他或者她希望删除MSG2以及MSG3。此时，用户/客户端设备100向回收站12014(RecycleBin@mailserver.sonera.com)发送包括URI歹'J表的具有INVITE请求550的SIP多REFER,其中URI列表包含待删除的已存储消息(在此情况下是MSG2以及MSG3)的URI。具有INVITE请求550的SIPREFER用于请求与基于网络的回收站120(RecycleBin@mailserver.sonera.com)建立SIP会话。在570以及571处，回收站120分别针对每个待删除的消息而发送INVITE请求，以与虚拟用户代理155和156建立SIP会话。在此情况下INVITE请求570对应于MSG2，而INVITE请求571对应于MSG3。在580以及581处，虚拟用户代理155和156分别接受这些会话。在590处，以消息会话中继协议(MSRP)的形式来与虛拟用户代理155正式建立SIP会话，其中将会话描述协议(SDP)媒体属性设置为a-RecvOnly(只收)，并且在591处，与虚拟用户代理156建立SIP会话。在SIP/MSRP会话中，MSG2以及MSG3从用户账户110发送至基于网络的回收站120，这导致MSG2以及MSG3从用户账户110中消失。在消息MSG2以及MSG3成功传输之后，在虚拟用户代理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处，用户确定他或者她希望删除MSG2(文件2)以及MSG3(文件3)。此时，针对待删除的存储消息(文件)(在此情况下是MSG2和MSG3),用户/客户端设备100使用附录B中描述的语法来向回收站120(RecycleBin@mailserver.sonera.com)发送具有INVITE请求550的SIPREFER。在此情况下，针对每个待15删除文件(消息)的SDP参数需要在单独的媒体行"m="中发送。具有INVITE请求550的SIPREFER用于请求在基于网络的回收站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(MSG2)以及文件3(MSG3)从用户账户IIO发送至基于网络的回收站120，这导致MSG2(文件2)以及MSG3(文件3)从用户账户IIO中消失。在文件2(MSG2)以及文件3(MSG3)成功传输之后，在虚拟用户代理155以及回收站120之间的SIP会话结束。如620处示出，最终结果是在用户邮件存储服务器中的用户账户110中仅存在文件1(MSG1)。类似于先前的实施方式，还可以对用户账户110以及回收站120的功能进行配置。在此情况下，发送INVITE请求以建立SIP会话570和571、此请求的确认580和581以及利用MSRP建立SIP会话590和591不是必须的。在另一实施方式中，用户可以选择和删除所有存储的消息。在此实施方式中，如图7中所示，可以向回收站120发送REFER请求以通过引用用户邮件存储账户的SIPURI而不是单个消息或者消息的URRI列表来删除所有消息。在图7的实施方式中还示出了，绕过虚拟用户代理而将具有INVITE请求的SIPREFER消息直4妻发送至基于网络的回收站。备选地，如关于图1中示出的实施方式所述，可以将具有INVITE的SIPREFER发送至虚拟用户代理。如图7中的740处所示，用户确定他或者她希望删除他或者她的邮件存储账户中的所有消息。此时，用户/客户端设备IOO将具有INVITE请求750的SIPREFER发送到回收站120(RecycleBin@mailserver.sonera.com)，其中包括用户邮件存储账户的SIPURI(在此情况下是User@mailserver57.Sonera.com)。具有INVITE请求750的SIPREFER的作用是请求在基于网络的回收站120(RecycleBin@mailserver.sonera.com)以及用户账户110或者在虚拟用户账户155(如果使用)之间建立SIP会话。在760处，回收站120通过"202ACCEPT"来接受来自用户/客户端设备100的SIPREFER请求，以此来进行响应。在770处，回收站120还发送INVITE请求以与虛拟用户代理155建立SIP会话。在780处，虚拟用户代理155接受此会话。在790处，以消息会话中继协议(MSRP)的形式来与虛拟用户代理155正式建立SIP会话，其中将会话描述协议(SDP)媒体属性设置为a=RecvOnly(只收)。在800处，回收站120向用户/客户端IOO通知SIP会话，并且在810处，用户/服务器设备100确认此通知。在SIP/MSRP会话中，用户邮件存储账户中的所有消息(在此情况下是MSG1、MSG2以及MSG3)从用户账户IIO发送至基于网络的回收站120，这导致所有消息从用户账户IIO中消失。在所有消息从用户邮件存储账户成功传输之后，在虚拟用户代理155以及回收站120之间的SIP会话结束。如820处示出，最终结果是在用户邮件存储服务器中的用户账户110中不存在消息。类似于先前的实施方式，还可以对用户账户110以及回收站120的功能进行配置。在此情况下，发送INVITE请求以建立SIP会话770、此请求的确认780以及利用MSRP建立SIP会话790不是必须的。图8示出了本发明可以在其中使用的系统10，包括可以通过网络进行通信的多个通信设备。系统10可以包括有线或无线网络的任意组合，其中这些网络包括但不限于移动电话网络、无线局域网(LAN)、蓝牙个人局域网、以太网LAN、令牌环LAN、广域网、互联网等。系统IO可以包括有线通信设备和无线通信设备两者。例如，图8中所示系统10包括移动电话网络11和互联网28。通往互联网28的连接可以包括但不限于远程无线连接、短程无线连接，以及各种有线连接，所述有线连接包括但不限于电话线、电缆线路、17电力线等。系统10的示例性通信设备可以包括但不限于移动电话12、组合式PDA和移动电话14、PDA16、集成消息传递设备(IMD)18、台式计算机20，以及笔记本计算机22。通信设备可以是固定的或者在由行进中的人携带时是移动的。通信设备还可以处于交通模式中，包括但不限于汽车、卡车、出租车、公共汽车、船、飞机、自行车、摩托车等。通信设备的一些或全部可以通过通往基站24的无线连接25发送和接收呼叫和消息，并且通过通往基站24的无线连接25与服务提供商进行通信。基站24可以连接至网络服务器26，该服务器26允许移动电话网络11和互联网28之间的通信。系统10可以包括附加的通信设备和不同类型的通信设备。图9和图10示出了本发明可以在其中实现的一个代表性移动电话12。然而应当理解，无意将本发明限制为一种特定类型的移动电话12或者其他电子设备。可以使用的其他类型的电子设备包括但不限于，PDA16、通信PDA以及移动电话14、IMD18、台式计算机20,以及笔记本计算机22。通信设备可以是固定的或者在由行进中的人携带时是移动的。通信设备还可以处于交通模式中，包括但不限于汽车、卡车、出租车、公共汽车、船、飞机、自行车、摩托车等。图9和图IO的移动电话12包括壳体30、液晶显示器形式的显示器32、小键盘34、麦克风36、耳机38、电池40、红外端口42、天线44、根据本发明一个实施方式的UICC形式的智能卡46、读卡器48、无线接口电路52、编解码电路54、控制器56以及存储器58。单独的电路和元件可以是本领域公知的所有类型，例如Nokia范围内的移动电话系列。出于示例目的，图8所示的系统10包括移动电话网络ll以及互联网28。对互联网28的连4妄可以包括但不限于远程无线连接、短程无线连接，以及各种有线连接，所述有线连接包括但不限于电话线、电缆线路、电力线等。在方法步骤的通常背景下对本发明进行了描述，在一个实施方式中，这些方法步骤可以通过程序产品来实现，该程序产品包括在网络环境中由计算机执行的计算机可执行指令，诸如程序代码。通常，程序模块包括例程、程序、对象、组件、数据结构等，用于执行具体任务或者实现特定的抽象数据类型。计算机可执行指令、相关数据结构和程序模块代表了用于执行此处公开的方法的步骤的程序代码的示例。这种可执行指令或者相关数据结构的特定序列代表了用于实现在这种步骤中描述的功能的对应动作的示例。本发明的软件和网络实现能够利用标准编程技术来完成，利用基于规则的逻辑或者其他逻辑来实现数据库搜索步骤、相关步骤、比较步骤和决策步骤。还应当注意的是，此处以及权利要求书中使用的词语"组件"和"模块"意在包括使用一行或者更多行软件代码的实现和/或硬件实现和/或用于接收手动输入的设备。出于示例和描述的目的，已经给出了本发明实施的前述说明。前述说明并非是穷举性的也并非要将本发明限制到所公开的确切形式，根据上述教导还可能存在各种变形和修改，或者是可能从本发明的实践中得到各种变形和修改。选择和描述这些实施方式是为了说明本发明的原理及其实际应用，以使得本领域的技术人员能够以适合于构思的特定用途来以各种实施方式和各种修改而利用本发明。附录AG.CamarilloEricssonA.NiemiM.IsomakiM.Garcia-MartinNokiaH.KhartabilTelio2005年10月21日参考会话发起协议(SIP)中的多项资源draft-itef-sipping-multiple-REFER04.txt本备忘录的状态根据BCP79的章节6，通过发布本互联网草案，每位作者表明，他或者她所了解的任何可应用专利或者其他IPR权项已经或者将要被公开，并且他或者她开始了解的任何内容将要被公开。互联网草案是互联网工程任务组(ITEF)、其领域及其工作组的工作文档。注意，其他工作组还可以将工作文档作为互联网草案来分发。互联网草案是一种草案文档，其最长有效性为六个月，并且可以在任何时间由其他文档进行更新、替换或者废除。将互联网草案作为引用材料或者将其作为"工作进程中"以外的形式进行引用，是不适当的。在http:〃www.ietf.org/ietf/lid-abstracts.txt处，可以i方问当前互联网草案的列表。在http:〃www.ietf.org/shadow.html处，可以访问互联网草案的镜SIP工作组互联网草案届满2006年4月26日像目录(ShadowDirectory)列表。本互联网草案将于2006年4月24日过期。版权声明版权(C)互联网协会(2005)摘要本文档定义了对SIPREFER方法的扩展，从而使此方法可用以将服务器引用至多个资源。这些扩展包括对于在Refer-to报头中的统一资源标识符(URI)-列表的指针以及"multiple-refer(多参考)"SIP选项标签的使用。目录1.*.......................................................................................................................................152.H.......................................................................................................................................153.操作概要...............................................................................................................................154.Multiple-referSIP选项标签...............................................................................................165.禁止REFER的隐式订阅...................................................................................................166.SIP-发布者的行为...............................................................................................................177.REFER接受者的行为.........................................................................................................188.默认URI列表格式.............................................................................................................189.^侈寸.......................................................................................................................................1910.安全性考虑事项................................................................................................................2111.IANA考虑事项.................................................................................................................2112.参考文献.............................................................................................................................2212.1标准化参考文献....................................................................................................2212.2信息性参考文献....................................................................................................22^t^"AiiJ:.....................................................................................................................................23完全版权声明.............................................................................................................................44211.介绍SIP[3]REFER方法[5]允许用户代理来请求服务器向第三方发送请求。另外，应用成员需要请求服务器来朝向一组目的地而发起事务。在一个示例中，会议的仲裁者可能希望会议服务器向一组参与者发送BYE请求。在另一示例中，相同的仲裁者可能希望会议服务器向一组参与者发送INVITE。对REFER定义一种扩展，从而可以使用REFER来将服务器参考至多个目的地。另外，我们使用在[7]中定义的REFER扩展，其禁止REFER的隐式订阅。2.术语在本文档中，词语"必须"、"不应"、"应当"、"不能"、以及"可选，，应解释为如BCP14，于适应性实现的需求级别。"不得"、"需要"、"应该"、"推荐"、"不推荐"、"可以"RFC2119[l]中所述，并且表明对定义了以下三个新术语REFER发布者(REFER-Issuer):发布REFER请求的用户代理。REFER接受者(REFER-Recipient):接收REFER请求的用户代理。REFER目标(REFER-Target):由REFER接受者生成的请求的所期望最终接受者。3.操作概要本文档定义了对SIPREFER方法[5]的扩展，其允许SIP用户代理客户端(UAC)在REFER请求中包括REFER目标的列表，并且将其22发送至服务器。服务器将针对REFER目标URI列表中的每个条目创建新的请求。使用URI列表来表示REFER的多个REFER目标。希望将服务器参卡至一组目的地的UAC(用户代理客户端)创建SIPREFER请求。Refer-to报头包括指向包括在主体部分中的URI列表的指针以及Required报头字段中的选项标签:"multiple-refer(多参考)"。此选项-标签表示需要支持在此规范中描述的功能性。当服务器接收此类请求时，其针对每个目的地创建新的请求并将其发送。本文档不提供供UAC用来找出关于具有多REFER目标的REFER请求的任何机制。此外，本文档不提供对作为SIPREFER方法一部分的隐式订阅机制的支持。保持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发布者。如在RFC3515[5]中所述，作为REFER请求所创建23的隐式订阅的结果而被发送NOTIFY请求包含"消息/sipfrag"[4]类型的主体，其描述由REFER接受者所发起的事务的状态。在REFER发布者生成具有多REFER目标的REFER的情况下，REFER发布者通常已经订阅了其他事件包，所述事件包可以提供关于针对REFER目标的事务的结果。例如，指示会议服务器来向一组参与者发送BYE请求的仲裁者通常订阅了针对该会议的会议状态事件包。对此事件包的通知将保持把会议参与者的当前列表通知给仲裁者以及其余订阅者。使用多REFER的多数应用不需要其隐式的订阅。同时，生成具有多REFER目标的REFER请求的SIPREFER发布者应当在Require报头字段中包括"norefersub"选项标签，以指示不应将关于该请求的通知发送至REFER发布者。"norefersub"SIP选项标签在[7]中定义并且禁止REFER的隐式订阅。在撰写时，不存在允许通过REFER隐式订阅来报告多个事务状态的扩展。这是本文档的动机，以便推荐使用"norefersub"选项标签。如果将来定义了此类扩展，则对其进行使用的REFER发布者可以避免使用"norefersub"选项标签并且代替地使用新的扩展。6.SIP-发布者的行为如在章节4以及章节5中所指示，创建具有多REFER目标的REFER请求的SIPREFER发布者在Require报头字段中包括"multiple-refer"以及"norefersub"。具有多REFER目标的REFER请求的Refer-to报头字段必须包括指向承载URI列表的主体部分的指针(即，内容ID统一资源定位符(URL)[2])。REFER发布者不应在URI列表中包括一次以上的任何特定URI。7.REFER接受者的行为REFER接受者遵循RFC3515中章节2.4.2的规则[5],以便确定对于REFER的响应的状态代码。如果URI列表包含URI不止一次，则REFER接受者必须按照在URI列表中仅出现一次URI那样来操作。REFER接受者使用特定于URI列表中每个URI的URI配置(scheme)的比较规则，以便确定是否存在任何出现一次以上的URLREFER接受者按照RFC3515中的规则[5]来生成朝向REFER目标的所需请求，针对URI列表中每个URI,就像其已经接收到常规(没有URI列表)REFER那样操作。8.默认URI列表格式在多REFER请求中使用的URI列表主体的默认格式是在[6]中规定的资源列表。能够生成或者接收具有多REFER目标的用户代理必须支持如在[6]中规定的这种格式，并且可以支持其他的格式。此外，可扩展标记语言(XML)配置访问协议(XCAP)资源列表文档提供了诸如以下特征层次列表，以及通过相对于XCAP根URI的参考来包括多个条目的能力(这对于在本文档中定义的多REFER服务并不需要)。由此，当使用默认资源列表文档时，生成具有多REFER目标的SIPREFER发布者应当使用平面列表(即，非层次列表)并且不应使用〈entry-ref^元素。接收到比已订阅更多信息的URI列表的REFER接受者可以丟弃所有额外的信息。图1示出了遵循资源列表文档的平面列表的示例。<xmlversion-"l0Wencoding*"UTF-8"><resource-listsxmlns="urn:ietf:params:xml:ns-resource-lists"xmlns:xsi="http:〃www.w3org/2001/XMLSchema-instance'<list><entryuri-"sip:bill@exatnplecom"/><entryuri-"sip-joeoexatnple-org"/><entryuri"wsip:ted@example,iiet"/></list:></resource-lists>图1URI列表9.示例图2示出了REFER发布者向会议中心发送多REFER请求的示例流程，其中该会议中心担任REFER接受者。REFER接受者针对每个REFER目标生成BYE请求。(在[10]中规定了如何使用REFER来从会议中去除参与者。)REFER发布者REFER接受者REFER目标lREFER目标2REFER目标3REFER202接受BYEJ4,BYE115.BYE16,200OKJ7，200OK1200KOK|1图2包含多REFER目标的REFER请求的示例流程REFER请求[1]包含包括指向消息体的指针的Refer-To报头字段，其中该消息体承载REFER目标的URI列表。REFER的Require报头字段承载"multiple-refer"以及"norefersub"选项标签。图3示出了此REFER请求的示例。资源列表文档包含REFER目标的列表以及REFER接受者生成的SIP请求。REFERsip:conf-123exatnple,coTnSIP/2.0Via:SIP/20/TCPclient.Chicago.example.comMax-Forwards:70To:*Conference123"<sip:conf-123@exaniple.com:>From:Carol<sip;carol@chicago.example.com>;tag=32331Call-ID:d432fa8化4c76e"710CSeg:2REFERContact:<sip:carol@client,Chicago.example,com:>Refer-To:<cid:cn35t8jf02example，com>Require:認ltiple-refer,norefersutoAllow:INVITE,ACK,CANCEL,OPTIONS,BYE,REFER,SUBSCRIBE,NOTIFYAllow-Events:dialogAccept:application/sdp,message/sipfragContent-Type:application/resource-lists+xmlCcmtent-Disposition:uri-listContent■Length:307Content-ID:<cn35t8jf￡}2@example.com>version-"l,D"encoding"OTF-8"><resource-listsxmlns-"urn:ietf.'params:xml:ns:resource-1ists"xnilns:xsinhttp://www,w3.org/2001/XMLSchema-instancew><entryuri-"sip:bill@exaniple.cotnmethod=BYE"/><entryuri-"sip:joe@example.orgmethod=BYE"/><entryuri-"sip:ted@exatnple*net7method=BYE"/></resouirce-lists>图3具有多REFER目标的REFER请求图4示出了REFER接受者发送至第一REFER目标的BYE请求的示例。BYEsip:bill豕example.comSIP/2.0Via:SIP/2.D/TCPconference.example,combranch-z9hG4bKhjhs8assnwnMax-Forwards:70From:"Conference123"csip:conf-123e3cample.com>,'tag==88734To:csip:t>illexample.com:>,.tag=29872Call-ID:d432fa84b4c34038s812CSecp34BYEContent-Length:0图4BYE请求2710.安全性考虑事项关于SIPURI列表服务的框架以及安全性考虑事项讨论了关于SIPURI列表服务的问题。假设接受具有多REFER目标的REFER的服务器用于URI列表服务，此类服务器的实现必须遵循[8]中的相关安全性规则。这些规则包括叩t-in列表以及客户端的强制认证以及授权。另外，服务器应当仅接受服务器理解的应用上下文内的REFER请求(例如，会议应用)。这意味着，服务器不应接受其不理解方法的REFER。这两个规则隐含的意思是，服务器不能用作其仅用作将其不理解的随机消息进行扇出操作的吸服务器。11.IANA考虑事项本文档定义了新的SIP选项标签"multiple-refer"。此选项标签应当在SIP参数注册器中进行注册。将"多refer"选项标签放置在所支持报头字段中的SIP用户代理理解包含描述多REFER目标的资源列表文档的REFER请求。2812.参考文献12.1标准化参考文献lievinson,E,,"Content-IDandMessage-IDUniformResourceIiocators，',RFC2332,AugustSparks,R.,"InternetMediaTypemessage/sipfrag",RFC3420,November2002.〖5Sparks,R.,"TheSessionInitiationProtocol(SIP)Refer(Method",RFC3515,April2003.6]Rosenberg,J.,"ExtensibleMarkupLanguage(XML)FormatsforRepresentingResourceLists",draft-ietf-sitnple-3ccap-list-usage-05(workinprogress),February2005.7〗Levin,O.,"SuppressionofSessionInitiationProtocolREFERMethodImplicitSubscription",draft-ietf-sip-refer-with-norefersub-03(workinprogress),October2005.Camarillo,G-andA.Roach,SessionInitiationProtocol(UR工)-ListServices",draftinprogress),April2005."RequirementsandFrameworkfor(SIP)UniformResourceIdentifierietf-sipping-uri-services-03(work12.2信息性参考文献Rosenberg,J.,"ASessionInitiationProtocol(SIP》EventPackageforConferenceState",draft-ietf-sipping-conference-package-12(workinprogress),July2005.提供用于在用户之间建立和管理多媒体会话的一般功能。这些会话通常包含诸如但不限于语音和视频的实时媒体流。基本上，只要在会话描述协议(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定义属性扩展和34使用转换就足够了，而MSRP本身不需要扩展并且可以以其现状进行使用。此外，可以以此方式规定所有SDP扩展，并且不支持这些扩展的端点仅需执行基本MSRP要求的实现，虽然受到某些功能性限制，但其依然可以在文件传送会话中用作被叫方。通过将MSRP用作会话内的转换协议，本文档定义了为满足关于在SIP会话内文件传送服务需求所需的使用转换以及SDP属性扩展。原则上，可以使用在此定义的SDP扩展并且由能够承载MIME对象的任何其他类似协议替换MSRP。如果需要，可以将此类规范撰写为独立的文档。在本文档中描述的机制允许往来于远程用户代理发送或者接收文件。章节3定义了本文档中使用的一些术语。章节4提供了操作概述。在章节5中定义了关于如何使用现有内容的新SDP属性和转换的详细语法和语义。章节6描述了协议操作，包括SIP、SDP以及MSRP。在章节7中给出了某些示例。2.术语在本文档中，词语"必须"、"不应"、"应当"、"不能"、以及"可选，，应解释为如BCP14,于适应性实现的需求级别。3.定义"不得"、"需要"、"应该"、"推荐，，、"不推荐"、"可以，，RFC2119[l]中所述，并且表明对出于本文档的目的，在RFC3264[6]中特别规定的定义应用回答者(answerer).提供者(offerer)另外，定义了如下术语文件发送者希望向文件接受者传送文件的端点。文件接受者希望从文件发送者接收文件的端点。文件选择器多个SDP属性的交集，导致选择零个或者更多文件。这在章节6.1中更详细地描述。4.操作概要在本文档中规定的文件传输服务使用SDPoffer/answer(提供/回答)[6]来建立将要传输文件的基于MSRP的媒体流。每个"m-"行描述用以传输单一文件的基于MSRP的媒体流。即，多文件的传输需要多个"m="行。本文档定义了允许用户代理描述待发送文件或者将要从远程用户代理接收的文件的一组SDP属性以及某些转换。这样，用户代理可以定义基于文件名称、大小、描述、散列、图标(例如，如果文件是图片)等来接受或者不接受给定的文件传输。有效的是，此机制的目标类似于SIP[15]中的内容间接机制的目标。两种机制均允许用户代理确定基于关于文件的信息来下栽或者不下载文件。然而，尽管在SIP消息[12]请求中可以使用内容间接机制来传输文件(实际文件传输机制可以是超文本传输协议(HTTP)[ll])，在文件传输协议是MSRP[10]的情况下，在由offer/answer交换建立的会话中不能使用该机制。5.对SDP的扩展在SDP[9]中定义了多个属性，其提供所需信息以描述利用MSRP的文件传输。下文是这些新属性的形式化ABNF语法[8]。该语法是基于SDP[9]文法、RFC2045[2]以及RFC2392[3]来建立的。36attributefilenane-attrfi丄etype-attrtypesubtypedisposition-attrdisposition-valuefilesize-vslueicon-attricon-valuehash-attrhash—algorithmhssh-valuefilename-attr/filetype-attr/disposition-attr/f丄lesize-attr/icon-attr/hash-attr/attributeisdefinedinsdp-new"filename:"filename-stringbyte-string,'byte-stringdefinedinsdp-new"filetype:"type'V"subtype*(";"parameter)parameterdefinedinRFC2045tokentoken"disposition:"disposition-valuetck:en"filesize:"f丄lesize-valueinteger/integerdefinedinsdp-new"icon:"icon-value=cid-url,'cid-urldefinedinRFC》392="hash:"hash—algorithmWSPhash—valuetoken/seeIANAHashAlgorithm,'sectionintheIPSEC,'registry-byte-string;byte-stringdefinedinsdp-new图1SDP扩展的语法"filename(文件名)"属性包含内容的文件名，并且其属性是字节串(在SDP[9]中规定)。"filetype(文件类型)"属性包含内容的MIME媒体类型。通常，可以在内容类型(Content-Type)报头字段(参加RFC2045[21])中表达的任何内容还可以以"filetype"属性来表示。在MIME媒体类型IANA登记中列出了可能的MIME媒体类型值。接下来可以是零个或者更多参数。在RFC2045[2]中规定了"参数，，的语法。"disposition(部署)"属性向对等端提供了文件的期望部署的建议。在邮件内容部署值的IANA登记中列出了可能的值，尽管最可能是仅仅"内联"或者"附件"的值对于文件传输应用是重要的。"filesize(文件大小)"属性以八位字节形式指示文件大小。"icon(图标)"属性可用于诸如图像的特定文件类型。允许发送者包括一个指针，该指针指向包括表示带传输文件内容的图标的体。这允许发送者包括该图标作为伴随SDP的另一主体，并且对于接受者来说，获得可以潜在传输的文件的图标。推荐的是，保持将图标限制至有意义的最小字节数。"icon，，属性包含内容ID(Content-ID)URL,这在RFC2392[3]中进行了规定。"hash(散列)"属性提供了待传输文件的散列。其目的在于以下两方面一方面，允许文件接收者通过其散列而不是通过其文件名来标识文件，通过某些带外(out-of-band)机制来使得文件接收者已经知晓文件的散列。另一方面，允许文件发送者提供待传输文件的散列，该散列可由文件接受者使用用于验证其内容或者避免已经存在的文件的不必要传输。"hash"属性包括散列的类型及其值。可能的散列类型是IPSec登记的IANA的散列算法部分中定义的那些类型。根据此规定的实现必须实现US安全散列算法1(SHAl)[4],并且可以实现其他散列算法。SDP的创建者还可以对相同的文件添加一个以上的"hash"属性(可能具有不同类型的散列)。所述值是通过向文件内容应用散列算法而生成的字节串。下文是包含在本备忘录中定义的扩展的SDP主体示例v=00-alice289C8445262890S"526INIP4host.atlanta.example.coms=c-INIP4host.atlanta.exarople.comt=00m哦ssage7654TCP/MSRP*1-Thisismylatestpicturea=5endcmlya豕accept-types:*a-path:msrp://atlanta.example,com:7654/jshA7we,.tcpa-filename:Mycoolpicture.jpga-filetype:image/jpega-disposition:inlinea-filesize:32349a=icon.dd:id2@alicepc.example.coma=hash:SHA72245fe8653ddaf371362f86d471913ee"2ce2e图2描述文件传输的SDP示例6.协议操作此部分讨论如何在offer/answer[6]交换的上下文中使用章节5中定义的参数。另外，此章节还讨论了使用MSRP的端点的行为。通常，可以根据提供者是文件发送者或者文件接收者来区分两种情况1)提供者是文件发送者，即提供者希望向回答者传送文件。回答者是文件接收者。在此情况下，SDPoffer包括"sendonly(只发)，，属性。2)提供者是文件接受者，即提供者希望从回答者获取文件。回答者是文件发送者。在此情况下，SDPoffer包含"recvonly(只收)，，属性，并且由此SDP回答包含"sendonly"属性。6.1文件选择符在本文档中规定的协议要求一种用来标识远程主机中文件的机制。引入了文件选择器的概念，该文件选择器是"hash"、"filename"、"filesize，，以及"filetype"属性的交集。根据SDP文件中的所提及属性以及根据主机中的可用文件，文件选择器可以指向零个、一个或者更多文件。在本文档中规定的文件传输机制需要文件选择器生成单一的文件选择。通常，如果"hash"属性是已知的，则"hash"属性足够生成指向零个或者一个文件的文件选择器。然而，文件选择器并非总是已知或者可用。有时，仅已知"filename"、"filesize，，或者"filetype，，属性，从而使得文件选择器可能导致产生一个以上的文件，这是不期望的情况。相反情况也是如此，如果文件选择器包含"hash"和"filename"属性，但是远程主机处的用户已经将文件重新命名，尽管存在具有所指示散列的文件，但是文件名并不匹配，由此，文件选择器将导致选择零个文件。396.2提供者的行为希望往来于回答者发送或者接收一个或者多个文件的提供者必须建立包含一个或者多个"m="行的会话的SDP[9]描述，根据MSRP[10]过程，每一行描述一个MSRP会话(并且由此，一个文件传输操作)。还必须包括MSRP[10]所需的以及指定的所有媒体行属性。对于每个待传输文件，必须存在单独的"m="行。6.2.1提供者是文件发送者如果提供者是文件发送者，则其必须向SDPoffer中添加会话或者媒体"sendonly，，属性。另外，提供者应当还添加分别指示文件的类型、大小以及散列的"filetype"、"filesize"、以及"hash"属性。当提供者创建SDPoffer时，这些属性可能不是已知的，例如，主机仍然正在处理文件。"hash"属性包含对文件接收者有价值的信息，以便指示文件是否已经可用以及不必;陂传送。提供者还可以添加进一步描述待传输文件的"filename"、"icon"以及"disposition"属性。"disposition"属性提供呈现建议，(例如文件发送者可能需要文件接收者将文件呈递为"内联"，或者将其保存为"附件")。另外，通过使用"i="媒体行，提供者可以提供人类可读的文件描述。6.2.2提供者是文件接受者如果提供者是文件接受者，则其必须创建包含会话或者媒体"recvonly"属性的SDPoffer。然后，提供者应当添加构成文件选择器("hash"、"filename""filesize，，、或者"filetype，，)的至少一个属性。在多种情况下，如果文件的散列是已知的，则该散列足够标识文件，由此提供者可以仅包括"hash"属性。然而，特别是在未知文件散列的情况下，文件名称、大小以及类型可以提供待获取文件的描述。6.2.3针对多个文件的SDPoffer希望发送或者接收一个以上文件的提供者针对每个文件生成一个"m=，，行。以此方式，按照常规SDP[10]过程，回答者可以通过将其相关联的"m=，，行的端口号设置为零来拒绝单独的文件。针对每个文件使用"m="行，这意味着使用不同MSRP会话来传输不同文件。然而，可以在单一的TCP连接上建立并运行所有这些MSRP会话，如在[IO]的章节8.1中所述。6.3回答者的行为如果回答者希望拒绝提供者提供的文件，则其按照SDP[9]过程来将与该文件相关联的"m="行的端口号设置为零。如果回答者确定接受文件，则按照常规MSRP[10]以及SDP[9]的过程进行处理。6.3.1回答者是文件接收者如果回答者是文件接收者并且确定接收文件传输，则其必须创建包含"recvonly"属性的SDP回答(参见RFC3264[6])。如果offer包含"filetype"、"filesize"或者"filename"属性，则回答者必须将其复制到确认中。这向提供者通知回答者支持此规范。如果回答者是文件接收者，则其在SDP回答中不得包括"icon"、"hash"或者"disposition"属性。如果所接收的offer包含"hash"属性，则回答者可以使用其来查看具有相同散列的本地文件是否已经可用，在此情况下，这可以表示接收到复制文件。根据回答者来确定是否接受文件传输或者不是复制文件的情况。6.3.2回答者是文件发送者如果回答者是文件发送者，则其必须首先检查所接收的SDPoffer并且计算文件选择器。文件选择器是修改SDPoffer中的相同"m="行的"filetype"、"filesize"、"filename"以及"hash"属性(如41果存在)的交集(即，上述四个属性位于SDP中的相同"m=，，行中)。文件选择器标识待发送的一个或者多个文件。如果文件选择器不能标识任何文件，则回答者必须通过将端口号设置为零来拒绝文件传输的MSRP流，(以及如果该MSRP流是SDPoffer中的唯一流，则如果应当拒绝SDP,则按照RFC3264[6]中的过程进行)。如果文件选择器指向单一文件，则回答者确定接受文件传输，回答者必须创建包含"sendonly"属性的SDP回答(按照RFC3264[6〗)。回答者应当添加包含待发送文件的散列的"散列，，属性，并且可以包括"filename"、"filetype"、"filesize"、"icon"或者"disposition"属性来进一步描述该文件。最后，如果文件选择器指向多个文件，则回答者应当拒绝文件传输的MSRP媒体流(通过将端口号设置为零而进行)。如果需要，则未来的规范可以提供适当的机制，以便允许选择多个文件或者例如通过返回匹配于文件选择器的文件列表来解决多义性问题。6.4MSRP使用在本文档中规定的文件传输服务使用"m="行来描述文件的单向传输。由此，在章节6.2以及章节6.3之后建立的每个MSRP会话仅用以传输单一文件。因此，发送者必须使用给定MSRP会话来发送在SDP提供或者回答中描述的文件。即，发送者不必通过相同的MSRP发送额外的文件。一旦完成文件传输，则文件发送者应当关闭MSRP会话，并且必须根据MSRP[10]过程针对关闭MSRP会话进行处理。7.示例7.1UAC向UAS发送文件。此会话示出了用于文件传输情况的示例流程。该示例假设使用42SIP来传递SDP交换，尽管出于简便原因只概要示出了SIP的细节。Alice(SDP提供者)希望向Bob(回答者)发送图像文件。Alice的UAC创建包含她希望向Bob发送的文件的描述的单向SDPoffer。描述还包括表示带传输文件内容的图标。在图3中示出了序列的流程。<formula>formulaseeoriginaldocumentpage43</formula>图3UAC向UAS发送文件的流程图Fl:Alice构建将要发送的文件的SDP描述，并且将其附加至寻址到Bob的SIPINVITE请求。INVITEsip:t>ob@example.comSIP/2.0To:Bob<sip:bob@example.com>From:Alice<sip:aliceSexample.com"tag=1928301774Call-工D:a84b化76e66710CSeg:1INVITEMax-ForwardsJ70Date:Fri,17Feb200613:02:03GMTContact:<sip:alice@alicepc.example.com>Content-Type:multipart/mixed,.boundary="boundary"71"Content-Length:[length]一-boumdary71Content-Type:application/sdpContent-Length:(lengthofSDP〗v=G0-alice2S3C5262890844526IN工P4al丄cepc.example,coms=c-工NIP4alicepc.examp丄e.comt=00m-message7654TCP/MSRP*1-Thisismylatestpicturea-sendonlya=accept-types:*a=path:m5rp://alicepcexample.com:7654/jshA"7we;tcpa=filename:Mycoolpicture.jpg"fiietype:image/jpega=disposition:inlinea-filesize:4096a=dcon:cid:id2@alicepc.example.comahash:SHA72245fe8653ddaf371362f86d471913ee4a2ce2e—boundary71Content-Type:image/jpegContent-Trgnsfeir-Encoding:binaryContent-ID:'<id2@slicepc.example.com>Content-:Length:[lengthofimage]...binaryJPEGimage,..—bcundary71从现在开始，出于简化原因，忽略SIP的细节。F2:Bob接收INVITE请求，检查SDPoffer并且提取图标体，检查文件大小并且确定接收文件传输。从而Bob创建了以下SDP回答44v=0o-bob289084465628S0844656IN工P4bobpc.example.coms=c=IN工P4bobpc.example.comt-00ra-message8888TCP/MSRP*a=recvonlya-accept-types*a=path:msrp://bobpc.example.com:8888/9di4ea'-tcpa-filename:Mycoolpicture.jpga=filetype:image/jpega=filesize:4096F4:Alice对Bob打开TCp连接并且创建MSRpsEND请求此SEND请求包含文件的第一块。MSRPd93kswowSENDTo-Path:msrp://bobpc.example,com:8888/9d丄4ea,'tcpFrom-Path:msrp://alicepc.example.com:"7777/iau39'.tcpMessage-ID:12339sdqwerByte-Range:1-2048/4096Content-Type:image/jpeg...firstchunkoftheJPEGimage...-------d93kswow十F5:Bob确认第一块的接收。MSRPd93kswow200OKTo-Path:msrp://alicepc,example,com:7777/iau39,'tcpFrom-Path:msrp://bobpc.example.com:8888/9di4ea/tcpByte-Range:1-2048/4096-------d93kswow$F6:Alice发送第二块以及最后一块。MSRPop2nc9aSENDTo-Path:msrp://bobpc.example.com:8888/9di4ea;tcpFrom-Path:msrp://alicepc-example.com:7777/iau39,'tcpMessage-ID:12339sdqwerByte-Range:2049-4096/4096Content-Type:image/jpeg,,.second(andlast)chunkoftheJPEGimage...-------op2nc9s$F7:Bob确认第二块的接收。MSRPop2nc9a200OKTo-Path:msrp://alicepc.example.com:7777/iau39;tcpFrom-Path:msrp://bobpc.example.com:8888/9di4ea;tcpByte-Range:2049-4096/4096-------op2nc9a$F8:Alice通过发送SIPBYE请求来终止SIP会话。F9:Bob确认BYE请求的接收并且发送200(OK)响应。7.2UAC从UAS请求文件在此示例中，Alice(SDP提供者)，希望从Bob(SDP回答者)获取文件。Alice已知Bob具有她希望下载的特定文件。她已经通过带外机制而知晓了文件的散列。散列属性足够产生指向特定文件的文件选择器。从而，Alice创建包含文件描述符的SDPoffer。Bob接收传输并且将文件发送至Alice。图IO示出了序列的流程。<table>tableseeoriginaldocumentpage46</column></row><table>图IOUAC从UAS请求文件的流程图Fl:Alice构建她希望接收的文件的nSDp描述，并且将SDPoffer附加至寻址到Bob的SIPINVITE请求。INVITEsip:bobgexample'centS丄tV厶i;To:Bob<sip:t>ob@exarople.com>From:Alice<sip:alice@example.com>;tag-1928301774Ca丄丄一工D:a84b4c76e66710CSeq:1INVITEDate:Fri,17Feb200613:02:03GMTContact:<sip:alice@alicepc.exainple.com;>Content-Type:application/sdpContent-Length:(lengthofSDPv=0o=alice28908445262890844526INIP4alicepc.example.corac=INalicepc.example.comt=0Cm-message7654TCP/MSRP*a=recvonlyaaccept-types:image/jpega=path:msrp://alicepc,example.com:7654/jshA7we,'tcpa=hash:SHA72245fe8653ddaf371362f86d471313ee4a2ce2e从现在开始，为简便起见而省略SIP细节,F2:Bob接收INVITE请求，检查SDPoffer,计算文件描述符并查找其散列值等于在SDP中所指示的文件的本地文件。Bob接收文件传输并且创建SDP回答如下o-bob2890S446562890844656INIEMbobpc.enample.comc-INIP4bobpc.example.comt-00xn-message8888TCP/MSRP*a-sendonlya=accept-types:*a-path:msrp://bobpe.example.com:8888/9di4ea/tcpa-filename:Mycoolphoto,jpga=filetype:image/jpega=filesize:2027F4:Alice对Bob打开TCP链接。然后，Bob创建包含该文件的SEND请求。MSRPd93kswowSENDTo-Path:msrp://alicepc.example.com:7777/iau39tcpFrom-Path:msrp://bobpc.example.com:888S/9di4ea/tcpMessage-ID:12339sdgwerByte-Range:1-2027/2027Content-Type:image/jpeg.，binaryJPEGimage,,.-------d93kswow$F6:Alice确认SEND请求的接收。MSRPci93kswow200OKTo—Path:msrp://bobpc.example.com:8888/9di4ea;tcpFrom-Path:msrp://alicepcexample-com:7777/iau39;tcpByte-Range:1-2027/2027-------d93kswow$F6:然后，Bob通过发送SIPBYE请求来终止SIP会话。F7:Alice确认BYE请求的接收并且发送200(OK)响应。8.安全性考虑因素待定9.IANA考虑因素待定10.感谢作者将感谢MatsStiller、NancyGreene、AdamuHanma以及Art。Leppisaari对于在本备忘录中所述初始概念的讨论。感谢PekkaKuure确认本文档的初始版本以及提供的有益意见。11.参考文献11.1标准化参考文献〔1〗Bradner,S.,"KeywordsforuseinRFCstoIndicateRequirementLevels",BCP14,RFC2119,March1997-2Freed,andNBorenstein,"MultipurposeInternetMailExtensions(MIM￡〉PartOne:FormatofInternetMessageBodies",RfC2CM5,November1996-Levinson,E.,"Content-13andMessage-IDUniformResource"Locators",艦2392,August4〗Eastlake,andP.Jones,"USSecureHashiUgcrithm1(SHAl)，，,RFC3174,September2001.Rosenberg,J.,Schulzrinne,H,,Camarillo,G,,Johnston,A.,Peterson,J,Sparks,R,,Handley,M,,andE,Schooler,"SIP;SessionInitiationProtocol",RFC3261,June2002,Crocker,D.andP，Overel丄,"AugmentedBNFforSyntax:Specifications:ABNF，，,RFC4234,October2G05*Hsndley,M,，'SDP:SessionDescriptionProtocol",draft-ietf—頻usic-sdp-new-25(workinprogress),July2005*Fielding,R.,Gettys,J*,Mogul,J',Frystyk,H*,Masinter,Leach,P*,and1\Berners-:Lee-"HypertextTransferProtocol—HTTP/l.l",RFC2616,June1999.Campbell,B,,Rosenberg,J',Schulzrinne,H.,Huitema,C.,andD.Gurle,"SessionInitiationProtocol(SIP)ExtensionforInstantMessaging",RFC3428,December2G02.Jennings,C,,"RelayExtensionsfortheMessageSessionsRelayProtocol(MSRP)",draft-ietf-simple-msrp-relays-06(workinprogress),December2005〔15〗Surger,E,,"AMechanismforContentIndirectioni_nSessionInitiationProtocol(SIP)Messages",draft-ietf-sip-ccmter丄t-indirect-mech-05(wcrkinprogress:',October2004,作者地址MiguelA.Garcia-MartinNokiaP.O.Box407NOKIAGROUP,F工M00045Finland电子邮件:miguel.an.ga;rcia@nokia.comMarkus工somakiNokiaKeilalahdentie2-4Espoo02150Finland电子由卩^f牛，markus.isoma3ci@nokia，comGon2al0CamarilloEricssonHirsalantie11Jorvas02420Finland电子由卩件:Gon2al0.CamarilloQericsson.com50SalvatoreLoretoEricssonHirsalantie11Jorvas02420FinlandSalvatore.LiOreto@ericssoncom电子邮件:完全版权声明版权(C)互联网协会(2006)本文档具有BCP78中包含的权利、许可和限制，除非在此阐明，作者拥有其全部权利。本文档以及在此包含的信息是在"现有形式，，的基础上提供，以及他/她所代表或被赞助(如果有的话)的投稿人、组织、互联网协会^使用放弃所有担保在此使^]的信息没有^犯任何权利，、或者放、弃为特定目的适用或者可销售的任何暗示担保。本IETF并不侵犯关于任何知识产权权利或者可能要求保护的其他权利的有效性以及范围，其中所述权利属于在本文档中所述方法的可；或者已经进行了独立的努力以标识任何此类权利。关于权利过程的信息可参见BCP78以及BCP79。可以从位于http:〃www.ietf.org.ipr的IETF在线IPR知识库中获取以下内容对IETF秘书处进行的IPR公开的副本、以及将有效的任何许可的保证、或者由此规范的实现者或者用户尝试获取此类所有权使用或者一般许可或者准许的尝试的结果。IETF邀请任何感兴趣方来关注可能覆盖需要实现此标准的技术的任何版权、专利或者专利应用、或者其他所有权。请将此类信息通知至ietf-ipr@ietf.org。感谢对于RFC编辑器功能的资助目前由互联网协会提供5权利要求1.一种用于在SIP多媒体环境中从用户账户删除项目的方法，包括从用户设备接收用以从所述用户账户删除所述项目的请求；在基于网络的已删除项目位置与所述用户账户之间建立SIP会话；在建立所述SIP会话之后，将所述项目从所述用户账户传送至所述基于网络的已删除项目位置；以及从所述用户账户删除所述项目。2.根据权利要求1所述的方法，其中所述请求包括SIPREFER请求。3.根据权利要求2所述的方法，其中所述SIPREFER请求在其Refer-to报头中包括所述基于网络的已删除项目位置的地址。4.根据权利要求1所述的方法，其中所述请求包括SIPMultiple-REFER请求。5.根据权利要求1所述的方法，进一步包括响应于接收到所述请求，将对所述请求的确认传送至所述用户设备。6.根据权利要求1所述的方法，其中建立所述SIP会话中，SDP方向性属性设置为a=SendOnly。7.根据权利要求1所述的方法，其中建立所述SIP会话中，SDP方向性属性设置为a=RecvOnly。8.根据权利要求1所述的方法，其中所述项目包括唯一的消息标识符，并且其中所述唯一的消息标识符包括在来自所述用户设备的所述请求中。9.根据权利要求1所述的方法，其中所述请求用以从所述用户账户删除多个项目，并且其中在来自所述用户设备的所述请求中包括所述多个项目的URI列表。10.根据权利要求1所述的方法，其中所述请求用以从所述用户账户删除所有项目，并且其中在来自所述用户账户的所述请求中包括所述用户账户的SIPURI。11.根据权利要求1所述的方法，其中所述项目存储为具有SDP描述的文件，并且其中所述文件SDP描述包括在来自所述用户设备的所述请求中。12.根据权利要求11所述的方法，其中所述请求用以从所述用户账户删除多个项目，并且其中在来自所述用户设备的所述请求中包括所述多个项目中的每个项目的文件SDP描述，每个文件的所述文件SDP描述包括在所述请求中的独立媒体行中。13.根据权利要求1所述的方法，其中所述用户设备、所述用户账户以及所述基于网络的已删除项目位置各自拥有唯一的统一资源标识符。14.根据权利要求1所述的方法，其中使用MSRP协议来将所述15.—种在计算机可读介质中实现的计算机程序产品，用于在SIP多媒体环境中从用户账户删除项目，包括用于从用户设备接收用以从所述用户账户删除所述项目的请求的计算机代码；用于在基于网络的已删除项目位置与所述用户账户之间建立SIP会话的计算机代码；所述基于网络的已删除项目位置的计算机代码；以及用于从所述用户账户删除所述项目的计算机代码。16.根据权利要求15所述的计算机程序产品，其中所述请求包括SIPREFER请求。17.根据权利要求16所述的计算机程序产品，其中所述SIPREFER请求在其Refer-to报头中包括所述基于网络的已删除项目位置的地址。18.根据权利要求15所述的计算机程序产品，其中所述请求包括SIPMultiple-REFER请求。19.根据权利要求15所述的计算机程序产品，其中建立所述SIP会话中，SDP方向性属性设置为a=SendOnly。20.根据权利要求15所述的计算机程序产品，其中建立所述SIP会话中，SDP方向性属性设置为a=RecvOnly。21.根据权利要求15所述的计算机程序产品，其中所述项目包括唯一的消息标识符，并且其中所述唯一的消息标识符包括在来自所述用户设备的所述请求中。22.根据权利要求15所述的计算机程序产品，其中所述请求用以从所述用户账户删除多个项目，并且其中在来自所述用户设备的所述请求中包括所述多个项目的URI列表。23.根据权利要求15所述的计算机程序产品，其中所述请求用以从所述用户账户删除所有项目，并且其中所述用户账户的SIPURI包括在来自所述用户账户的所述请求中。24.根据权利要求15所述的计算机程序产品，其中所述项目存储为具有SDP描述的文件，并且其中所述文件SDP描述包括在来自所述用户设备的所述请求中。25.根据权利要求23所述的计算机程序产品，其中所述请求用以从所述用户账户删除多个项目，并且其中在来自所述用户设备的所述请求中包括所述多个项目中每个项目的文件SDP描述，每个文件的所述文件SDP描述包括在所述请求中的独立媒体行中。26.根据权利要求15所述的计算机程序产品，其中所述用户设备、所述用户账户以及所述基于网络的已删除项目位置各自拥有唯一的统一资源标识符。27.根据权利要求15所述的计算机程序产品，其中使用MSRP目位置。28.—种电子设备，包括处理器；以及可通信地连接至所述处理器的存储器单元，并且所述存储器单元包括用于从用户设备接收用以从用户账户删除项目的SIP请求的计算机代码；用于在基于网络的已删除项目位置与所述用户账户之间建立SIP会话的计算机代码；送至所述基于网络的已删除项目位置的计算机代码；以及用于从所述用户账户删除所述项目的计算机代码。29.根据权利要求28所述的电子设备，其中所述请求包括SIPREFER请求。30.根据权利要求29所述的电子设备，其中所述SIPREFER请求在其Refer-to报头中包括所述基于网络的已删除项目位置的地址。31.根据权利要求28所述的电子设备，其中所述请求包括SIPMultiple-REFER请求。32.根据权利要求28所述的电子设备，其中建立所述SIP会话中，SDP方向性属性设置为a=SendOnly。33.根据权利要求28所述的电子设备，其中建立所述SIP会话中，SDP方向性属性设置为a=RecvOnly。34.根据权利要求28所述的电子设备，其中所述项目包括唯一的消息标识符，并且其中所述唯一的消息标识符包括在来自所述用户设备的所述请求中。35.根据权利要求28所述的电子设备，其中所述请求用以从所述用户账户删除多个项目，并且其中在来自所述用户设备的所述请求中包括所述多个项目的URI列表。36.根据权利要求28所述的电子设备，其中所述请求用以从所述用户账户删除所有项目，并且其中在来自所述用户设备的所述请求中包括所述用户账户的SIPURI。37.根据权利要求28所述的电子设备，其中所述项目存储为具有SDP描述的文件，并且其中所述文件SDP描述包括在来自所述用户设备的所述请求中。38.根据权利要求37所述的电子设备，其中所述请求用以从所述用户账户删除多个项目，并且其中在来自所述用户设备的所述请求中包括所述多个项目中每个项目的文件SDP描述，每个文件的所述文件SDP描述包括在所述请求中的独立媒体行中。39.根据权利要求28所述的电子设备，其中使用MSRP协议来40.—种用于在SIP多媒体环境中从用户账户删除项目的方法，包括从用户设备传送用以从所述用户账户删除所述项目的请求；响应于所述所传送的请求，在虚拟用户代理与基于网络的已删除项目位置之间建立SIP会话；在建立所述SIP会话之后，从所述用户代理向所述基于网络的已删除项目位置传送所述项目；以及从所述用户账户删除所述项目。41.根据权利要求40所述的方法，其中建立所述SIP会话中，SDP方向性属性设置为a=SendOnly。42.根据权利要求40所述的方法，其中建立所述SIP会话中，SDP方向性属性设置为a=RecvOnly。43.根据权利要求40所述的方法，其中所述请求包括SIPREFER请求，所述SIPREFER请求包括所述待删除项目的唯一标识符。44.根据权利要求40所述的方法，其中所述请求用以删除多个项目，所述请求包括包含所述待删除项目的URI列表的SIPMultiple-REFER请求。45.根据权利要求40所述的方法，其中所述请求用以删除所有项目，所述请求包括包含所述用户账户的SIPURI的SIPREFER请求。46.根据权利要求40所述的方法，其中所述项目存储为具有SDP描述的文件，并且其中所述请求包括包含所述SDP描述的REFER请求。47.根据权利要求40所述的方法，其中项目存储为具有SDP描述的文件，其中所述请求用以删除多个项目，并且其中在来自所述用户设备的所述请求中包括所述待删除项目的所述文件SDP描述，每个文件的所述文件SDP描述包括在所述请求中的独立媒体行中。48.根据权利要求40所述的方法，其中所述SIPREFER请求在其Refer-to报头中包括所述基于网络的已删除项目位置的地址。49.根据权利要求40所述的方法，其中使用MSRP协议来从所述用户账户向所述基于网络的已删除项目位置传送所述项目。50.—种用于在SIP多媒体环境中从用户账户删除项目的方法，包括从用户设备传送SIPREFER请求以从所述用户账户删除所述项目，所述SIPREFER请求在其Refer-to报头中包括基于网络的已删除项目位置的地址；响应于接收到所述SIPREFER请求，向所述用户设备传送对所述请求的确认；以及从所述用户账户删除所述项目。全文摘要一种用于在SIP多媒体环境中从用户账户删除项目的方法。当将要删除诸如即时消息的项目时，从用户设备传送SIPREFER消息以从用户账户删除该项目，其中所述消息包括用于所述项目的唯一标识符。响应于传送的请求，在虚拟代理和基于网络的已删除项目位置之间建立SIPINVITE会话。在建立SIPINVITE会话之后，项目从用户账户传送至基于网络的已删除项目位置，并且被从用户账户删除。文档编号H04L29/06GK101455050SQ200780018392公开日2009年6月10日申请日期2007年4月3日优先权日2006年4月3日发明者A·哈鲁纳,A·里普皮萨阿里申请人:诺基亚公司