专利名称：用于无线网络的多媒体传送的制作方法
用于无线网络的多媒体传送
背景技术：
3GPP (第三代合作伙伴计划，wwwJGPP.org)是为第三代(3G ) 移动系统提出技术规范和建议的合作成果。这些建议之一，IP多媒体子 系统(网际协议多媒体子系统或IMS),迅速得到许多人的认可，原因 在于用于IP多媒体的非官方标准服务于3G平台。
IMS的关键特征之一是把会话启动协议(SIP)用于呼叫控制和信 令功能。SIP属于来自因特网工程任务组(IETF)的RFC标准(RFC 3261 ) ， IETF是负责管理和开发被广泛接受的用于改造因特网的技术规 范的组织。SIP也用于促进将多媒体文件(例如视频剪辑)从一个移动 设备传送到另 一个接收装备，例如另 一个终端用户的移动设备。
为了传送视频剪辑，设置在发送者的手机内的SIP代理常常用于发 送视频剪辑。例如，如果发送者想要将视频剪辑发送给指定接收方，首 先将该视频剪辑装载到用户的手机的存储区域中。使用SIP协议，然后 其中的SIP代理使用由发送者提供的接收方的身份来将该视频剪辑发送 到接收方。
考虑这样的情形，其中用户希望将相同的视频剪辑发送到一组接收 方(一对多)而不是单个接收方(一对一)。再次地，将该视频剪辑装 载到用户的手机的存储区域中。用户指定每个接收方的身份，并且用户 的手机中的SIP代理依次将视频剪辑发送到接收方。
尽管基于SIP的方法实现了视频剪辑的一对多传送，但是存在许多
缺点。例如，尽管许多现代手机提供指定地址列表的能力，但是该列表
典型地用于快速拨号。更具体而言，目前的地址列表不能被SIP代理用
于将视频剪辑发送到地址列表中的成员。相反，发送者必须手动地指定 每个接收方。
作为另一个例子，由于视频剪辑被每次一个地发送给接收方，因此 在发送者的手机和网络其余部分之间的带宽要求是相当大的。例如，如
果用户希望将5兆字节的视频剪辑发送给4个接收方，则大约有相当于 20兆字节的视频数据将被从发送者的移动设备传送。由于无线终端链路 带宽(即，移动设备和到网络其余部分的网关之间的带宽)常常极其有
限且是昂贵的，所以这样的方法对资源极其有限的网络资源强加了高带 宽要求。该限制严重制约了当前方法的可伸缩性。
作为又一个例子，用于多媒体数据的 一对多传送的当前方法可以导 致许多接收方在视频传送会话开始之后的数分钟甚至数小时之后才收 到视频剪辑。例如，如果指定接收方是接收视频剪辑的队列中的第10 个接收方，则该指定接收方在开始接收视频剪辑之前可能必须等待发送 者的手机中的客户应用程序完成将视频剪辑发送到前面的九个接收 方。对于一些实时或近实时视频流使用情形，当前方法是不能令人满意 的，原因在于对位于队列的末尾或靠近队列末尾的接收方而言时延将会 过长。
发明内容
在一个实施例中，本发明涉及一种用于将多媒体文件从一个用户的 移动设备传送到与另 一个用户相关联的用户装备的方法。所述方法包括 把邀请从所述用户的移动设备发送到所述用户装备以请求多媒体文件 的传送。所述方法还包括在所述用户的移动设备和所述装备之间设置承 载数据信道以便于多媒体文件的传送，所述传送被配置成使用消息会话
中继协议(MSRP)实现。所述方法进一步包括使用MSRP和承载数据 信道来传送多媒体文件。
在另 一实施例中，本发明涉及一种用于将多媒体文件从一个用户的 移动设备传送到与一个组的多个组成员相关联的多个用户装备的方 法。所述方法包括从服务器获得組成员资格信息，所述组成员资格信息 与所述多个组成员有关。所述方法还包括使用所述组成员资格信息将多 媒体文件从应用服务器发送到所述多个组成员的至少 一个子集。
在另 一实施例中，本发明涉及一种用于将多媒体文件从一个用户的 移动设备传送到与 一个组的多个组成员相关联的多个用户装备的方 法。所述方法包括将包括多媒体文件且指定组接收方的SIP(会话启动 协议)消息发送到CSCF (呼叫会话控制功能)。所述方法还包括将包 括多媒体文件且指定组接收方的SIP消息转发到应用服务器。所述方法 另外包括从服务器获得组成员资格信息，所述组成员资格信息与所述多 个组成员有关。所述方法进一步包括使用所述组成员资格信息，使用SIP 将多媒体文件从应用服务器发送到所述多个组成员的至少一个子集。
在另 一 实施例中，本发明涉及一种包括程序存储介质的制造物品，
所述介质具有包含在其中的计算机可读代码，所述计算机可读代码被配 置成将多媒体文件从一个用户的移动设备传送到与一个组的多个组成 员相关联的多个用户装备。所述介质包括用于从服务器获得组成员资格 信息的计算机可读代码，所述组成员资格信息与所述多个组成员有关。 所述介质还包括用于使用所述组成员资格信息将多媒体文件从应用服 务器发送到所述多个组成员的至少一个子集的计算机可读代码。
下面将在本发明的具体描述中结合附图更详细地描述本发明的这 些和其他特征。
在附图的图中以举例而非限制的方式示出了本发明，其中相似的附
图标记表示同样的元件，其中
图1是示出当手机用户设置一个组时发生的消息流的示例性流程图。
图2是示出在用户注册期间在用户的移动设备和各种网络部件之间
交换的消息的示例性流程图。
图3示出当用户预订接收组存在数据时所涉及的示例性消息。
图4A根据本发明的一个实施例示出在使用MSRP将视频剪辑从用
户的移动设备发送到接收方的视频接收装备的过程中所涉及的步骤。 图4B根据本发明的一个实施例示出了显示当用户1希望使用
MSRP承载信道将视频剪辑传送到用户2时交换的消息的示例性流程图。
图5A根据本发明的 一个实施例示出使用应用服务器实现一对多视 频传送的步骤。
图5B根据本发明的一个实施例更详细地示出一旦AS接收到从用 户1转发的SIP邀请消息就使用应用服务器完成一对多视频传送的步骤。
图5C根据本发明的一个实施例示出了显示当用户l希望使用应用 服务器将视频剪辑传送到指定组的多个成员时交换的消息的示例性流程图。
图6A根据本发明的一个实施例示出使用SIP消息将视频剪辑发送 到一个组中的多个组成员的步骤。
图6B根据本发明的一个实施例示出了显示当用户l希望使用应用
服务器将视频剪辑传送到指定组的多个成员时交换的消息的示例性流 程图。
图7根据本发明的一个实施例示出了显示当用户1希望使用应用服 务器将视频剪辑传送到指定组的多个成员时交换的消息的示例性流程图。
具体实施例方式
现在将参考如附图中所示的本发明的几个实施例来详细地描述本 发明。在以下描述中，阐述了许多具体细节以便提供对本发明的透彻理 解。然而对本领域技术人员将会很明显的是，可以在没有这些具体细节 中的一些或全部的情况下实施本发明。在其他实例中，为了不会不必要 地使本发明变得晦涩难懂，就没有详细地描述公知的过程步骤和/或结 构。
在下文中描述了包括方法和技术的各种实施例。应当牢记本发明还 涵盖包括计算机可读介质的制造物品，所述计算机可读介质存储着用于 实现本发明的技术的实施例的计算机可读指令。所述计算机可读介质可 以包括例如半导体、磁、光磁、光或用于存储计算机可读代码的计算机 可读介质的其他形式。此外，本发明还涵盖着装置，例如专用和/或可编 程电路，例如用以执行与本发明的实施例有关的任务。这样的装置的例 子包括被适当编程的专用计算设备和/或通用计算机并且可以包括计算的组合。
根据本发明的实施例，用户可以指定待发送到公共或私有组的多媒 体文件，例如视频剪辑，并且由网络中的应用服务器处理对一对多视频 传送的请求，由此减少对发送者的移动设备方的带宽要求。在以下公开 中，参考视频剪辑和视频数据的传送。然而，做这样的参考是为了通过 讨i仑一致的例子和/或应用来简化对本发明的理解。本发明的实施例可应 用于任何类型的数据文件的传送，尤其是包括视频、音频和其他类型的 数字数据的多媒体文件的传送。
本发明的实施例包括这样的技术，所述技术用于查明组成员的存在 状态以便可以为存在的(例如登录的)那些组成员按优先顺序排列视频 剪辑。当发送者请求发送视频剪辑时可以不向不存在的那些组成员提供 视频剪辑的拷贝，或者在一个实施例中，可以在以后的时间从应用服务
器向那些组成员提供视频剪辑的拷贝。
视频剪辑可以由应用服务器使用SIP来发送给每个接收方。本发明 的实施例进一步包括使用使应用服务器和接收方之间的视频传送过程
更加高效的协议。这些协议包括MSRP (消息会话中继协议)、RTP (实
时传输协议)等。
可以参考以下的图和讨i仑来更好地理解本发明的实施例的特征和
优点。图1-3示出当用户用组列表管理服务器(GLMS)创建一个组并 且随后向一个组(无论是由该用户还是由其他用户创建的组)预订被告 知组数据的变化和被告知组成员的存在状态时发生的示例性流程。图1 -3是常规的并且在这里被讨论以便帮助读者理解包括本发明的实施例
知的，因此在这里将不对其进行详细说明。
图1是示出当蜂窝电话用户建立 一个组时发生的消息流的示例性流 程图。在该例子中，用户的移动装备(图1中的UE或用户装备)利用 消息101中的HTTP命令Put (放)，HTTP PUT ( group.xml)以便指示 GLMS才艮据文件group.xml创建一个组。文件group.xml与/>共组(即可 以被建立所述组的用户以外的用户看到和/或管理的组)有关并且包含组 成员的联系数据。应当注意名称"group (组)"仅仅是例子；所述组和 xml文件可以具有任何合适的名称。当在这里使用时，术语用户移动装 备或移动设备包括能够利用用于数据传输的无线介质的任何移动设备 (例如蜂窝电话、个人数字助理、掌上电脑、膝上型电脑等)。
在消息102中，如果用户没有被授权建立列表或者如果用户没有用 GLMS正确地鉴别自己，则GLMS可以以HTTP错误代码401做为响应。 下一对消息102和103显示这样的情况，其中用户被正确鉴别并且被授 权去使用HTTP put命令用GLMS创建一个组(消息103)。在这种情 况下，GLMS接受命令和文件group.xml以创建被请求的组。GLMS以 所创建的HTTP消息201作为响应(消息104)。
下一对消息(105和106)示出用户可以请求GLMS用不同名称创 建另 一个组(即，消息105中的friend.xml)，并且当组friend.xml被成 功创建时GLMS响应(在消息106中创建的HTTP 201 )。在该例子中， 文件friend.xml与私有组(即，只有建立所述组的用户才能看到的组) 有关。
步骤110和消息111 - 118示出在用户随后登录时在用户和GLMS 之间交换的步骤和消息。步骤110是注册步骤，该注册步骤发生在用户 的蜂窝电话被打开之时。在图2中更详细地解释了注册步骤110。消息 111代表用于从GLMS获得组数据的消息，所述组数据与先前根据文件 fhend.xml创建的私有组有关。 一旦组数据被成功传送到移动设备， GLMS就以消息112 (HTTP 200 OK)进行确认。消息113和114是用 于检索与先前根据文件group.xml创建的公共组有关的组数据的类似消 息对。
在消息115中，用户请求(通过消息SIP预订(group.xml))他希 望预订组成员数据的改变，并且这样的请求由GLMS经由HTTP消息200 OK确认(消息116)。如果根据文件group.xml创建的公共组的成员资 格数据随后有变化(例如成员之一改变了他的电子信箱地址)，则GLMS (经由消息117 SIP通知)通知该用户。该通知消息由移动设备在消息 118 (例如HTTP200 OK)中确认。
图2是示出在用户注册期间在用户的移动设备和各种网络部件之间 交换的消息的示例性流程图。用户的移动设备发送请求注册消息201 (SIP注册(sip:userl@hp.com))以向网络注册用户的移动设备。在 这种情况下，该请求被询问CSCF接收。众所周知，CSCF可以具有多 个部分，包括询问CSCF、代理CSCF和服务CSCF。
询问CSCF然后使用由用户的移动设备提供的数据解析用户的域。 利用其自身的代理，服务CSCF然后联系与所述用户的域相关联的归属 用户服务器(HSS )以(经由请求Diameter MAR或多媒体-鉴别-请求的 消息202 )请求鉴别令牌。HSS然后检索鉴别向量(步骤250 )并且(经 由消息203， Diameter多媒体-鉴另'卜应答或MAA)将鉴别向量返回到服 务CSCF。
由于用户的移动设备还必须向网络注册，因此CSCF将经由消息204 向用户的移动设备通知(401未授权的RAND AUTN ):用户当前未被 授权并且CSCF希望从用户的移动设备接收鉴别令牌以便将它们与从 HSS接收的鉴别向量进行比较。在消息205中，用户的移动设备以被请 求的鉴别令牌响应(SIP注册RES )。
CSCF然后在步骤260中比较从HSS接收的鉴别令牌与从用户的移 动设备接收的鉴别令牌以鉴别用户的移动设备。如果比较是成功的，那
么CSCF在消息206中将Diameter SAR (服务器分配请求)发送到HSS 以请求存储服务CSCF的名称。
HSS将服务CSCF存储在用户的简档中(方框270 )并且在消息207 中以更新的用户简档响应。用户简档包括关于用户的帐户的信息，例如 用户的公共URI，预订的服务，用户的帐户是否被禁止，和服务触发器 信息(例如当SIP预订消息的事件标题被设置为存在时的存在服务触发 器)。在这时，注册完成并且CSCF在消息208中向请求用户的移动设 备确认注册任务的完成(200 OK)。
如果用户的简档包括对存在服务器(PS)的预订(在步骤280中查 明)，则CSCF然后在消息209中将SIP注册消息转发到存在服务器 (PS ) 。 PS然后在流程210中以发送给CSCF的确认做出响应并且记录 用户的有效性。这允许存在服务器将与用户的移动设备有关的存在数据 提供给其他用户。
图3示出当用户预订接收组存在数据时涉及的示例性消息。在这种 情况下，由于组group@hp.com是公共组，因此预订用户可以是任何用 户，而未必是创建所述组的用户。方框330包括消息301 - 304,所述消 息被交换以使用户能够预订组存在。在消息301中，用户的移动设备将 SIP预订(group@hp.com)发送到CSCF询问部分，并且事件标题设置 为存在。所述请求指示用户希望预订接收由URI(统一资源标识符) group@hp.com识别的组中的成员的存在信息。CSCF在消息302中将所 述请求转发到存在服务器(PS)。
由于在本例子中请求用户是所述组的最初所有者，因此PS将允许 用户预订(消息303 ),这经由CSCF被发送到用户(消息304)。
在这时，PS可以获得组成员信息并且可以预订接收组信息的变化 (方框320,包括消息310-321 )。首先，PS获得成员资格列表。该成 员资格列表驻留于GLMS,在那里用户最初提交成员列表(如结合图1 所述的那样)。因而，PS将SIP预订(group@hp.com)发送到CSCF (消息310)，然后CSCF将所述请求转发到GLMS(消息311 ) 。 GLMS 确认收到所述请求，所述请求经由GLMS被发送回PS (消息312和 313 )。随后，GLMS经由CSCF将group@hp.com的成员资格列表发送 到PS(使用SIP通知消息314和315，所述消息可以被多次发送以便传 送所有成员的数据)。 一旦成员资格信息被接收，PS就以200 OK消息 确认，所述消息经由CSCF被转发到GLMS (消息316和317)。
一旦PS具有了成员资格信息，它就能够将与成员有关的存在数据 发送到预订用户的移动设备。因而，PS将与group@hp.com的成员有关 的存在数据发送到预订用户的移动设备(经由SIP通知消息318和 319,所述消息可以被多次发送以覆盖所有成员)。存在数据的接收是 由用户的移动设备经由200 OK消息320和321而确认的，所述消息经 由CSCF被发送到PS。消息318-321可以被重复，原因在于成员资格 信息可以变化一次以上直到预订期满或预订被取消为止。
图4A根据本发明的一个实施例示出在使用MSRP将视频剪辑从用 户的移动设备发送到接收方的视频接收装备(它可以是另一移动设备、 个人信息管理器、膝上型电脑或能够接收视频的任何计算设备)中涉及 的步骤。在步骤402中，用户1 (例如希望发送视频的一方)通过将邀 请消息从用户1的移动设备发送到用户2的UE (用户装备)来邀请用 户2 (例如接收视频的一方)接收视频剪辑。在步骤404中，建立MSRP 承载信道以便于在不必在网络中的中间节点(例如多个CSCF跳、应用 服务器等)中引起处理开销的情况下将视频数据从用户1传送到用户 2。 一旦MSRP承载信道被建立，视频数据就在该MSRP承载信道上被 直接从用户1发送到用户2 (步骤406)。 一旦视频剪辑被完全传送， MSRP承载信道就被关闭(步骤408)。
图4B根据本发明的一个实施例示出了显示当用户1 (被示为图4B 中的UE1或用户装备1 )希望使用MSRP承载信道将视频剪辑传送到用 户2 (被示为图4B中的UE2或用户装备2)时交换的消息的示例性流 程图。在消息451中，用户1的移动设备使用MSRP承载数据信道将SIP 邀请(user2@hp.com msrp)发送到CSCF以邀请用户2接收视频剪辑。 CSCF经由消息452 ( 100尝试)确认接收到该请求，所述消息指示 CSCF处于在把该请求转发到用户2的过程中。
在将视频剪辑转发到用户2的UE之前，CSCF检查(方框480 )用 户2的服务状态以查明是否适合将视频剪辑转发到用户2。例如，用户2 对网络服务可能欠费，并且他的帐户可能已经被暂时禁止，从而导致用 户2无资格使用网络来接收视频剪辑。作为另一个例子，用户2有可能 在他的简档中表明用户2并不希望从用户l或从任何人接收任何视频 剪辑。如果认为用户2不能接收视频剪辑，则可以通知用户1并且终止会话。
在另一方面，如果用户2有资格接收视频剪辑，则CSCF将来自用 户1的请求(SIP邀请(user2@hp.com msrp ))转发到用户2的UE (消 息453 )。用户2的UE通过将消息454 ( 100尝试)发送到CSCF来确 认接收到该请求。
在这时，用户2的UE将试图建立(方框490 ) MSRP承载数据信 道以便于视频传送。使用常规的TCP和MSRP建立程序(箭头A、箭头 B和箭头C) , MSRP承载数据信道被建立在用户1的移动设备和用户2 的UE之间。
一旦MSRP数据信道被建立，用户2就将200 OK消息发送到用户 1,其中所述消息通过CSCF被中继(消息457和458) 。 Ok消息的接 收由用户1的移动设备确认，所述消息经由CSCF被发送到用户2的UE (ACK消息459和460 )。
在这时，MSRP承载数据信道被创建并且视频传送可以开始(箭头 D和E)。在消息461中，使用MSRP将视频数据从用户1的移动设备 发送到用户2的UE (通过MSRP发送消息)。用户2的UE使用消息 462进行确认(MSRPOK)。应该注意到，视频数据的传送是使用用户 1的移动设备和用户2的UE之间的直接通道来实现的。为传送所有视 频数据，该传送可能涉及MSRP发送和MSRPOK消息的多次循环。
一旦视频剪辑传送完成，用户1的移动设备通知用户2的UE:它 正在终止连接。因而用户1的移动设备将SIP结束消息463发送到用户 2的UE。用户2的UE使用消息200 OK进行确认(在消息464中)。 在这时，视频剪辑被传送了并且MSRP承载数据信道被终止。
图5 A根据本发明的 一个实施例示出使用应用服务器实现一对多视 频传送的步骤。用户1将SIP邀请消息发送到CSCF ( 502 )。如果SIP 邀请消息指示接收方是单个接收方(504),则CSCF将例如使用在图 4A和4B中讨论的MSRP承载数据信道技术或者如随后在这里将结合图 6A和6B所描述的通过将视频剪辑附加到SIP消息中来启动l对l视频 传送过程(506 )。在另一方面，如果SIP邀请消息指示接收方是一个 组(504)，则CSCF将把SIP邀请消息路由到应用服务器(AS)以使 AS能够将视频剪辑发送到组成员(508 )。
图5B根据本发明的一个实施例更详细地示出这样的步骤 一旦AS 接收到从用户1转发的SIP邀请消息就使用应用服务器实现一对多视频
传送。在利用AS进行一对多视频传送之前，视频剪辑首先被装载到AS 上(530 )。在这种情况下，用户1 (发送视频的一方)可以以图4A和 4B中所描述的方式使用例如基于MSRP的方法来执行视频剪辑到应用 服务器(AS)的初始传送，从而用AS代替用户2。如果视频剪辑相当 短，则初始传送也可以使用SIP消息来执行，随后在这里将结合图6A 和6B对此进行描述。
一旦到AS的初始一见频传送完成，AS可以开始执行一对多传送。在 步骤532中，AS从GLMS获得成员资格列表。在步骤534中，AS然后 用PS检查组成员的存在状态。对于存在的成员，AS使用例如MSRP承 载数据信道技术或者使用SIP消息技术(如果视频剪辑相当短的话)将 视频剪辑发送(536 )到接收方成员。
图5C根据本发明的一个实施例示出了显示当用户1希望使用应用 服务器将视频剪辑(它例如可能是大视频剪辑)传送到指定组的多个成 员时交换的消息的示例性流程图。用户1将像图4B中那样把视频剪辑 发送到应用服务器，从而用AS代替UE2。在图5C的例子中，视频剪 辑通过MSRP承载数据信道被从AS发送到组成员。然而，也可以使用 其他视频传送技术来代替MSRP,不过效率的程度会有所不同。
经由消息501 (HTTP GET ( group.xml) ) , AS首先获得由用户1
在发送视频的请求中指定的组的成员资格列表。在该例子中，组是 group@hp.com,它被保持在GLMS处的group.xml列表中。GLMS以消 息502响应，从而将组成员提供给AS。
在查明组成员的存在状态过程中涉及到消息503 - 506。因而AS将 SIP预订(group@hp.com期满=0)发送(503 )到PS,以请求 group@hp.com的成员的存在状态。可选参数"期满=0"将预订消息的 定时器设置为零以表明AS仅仅对一次获得的存在状态感兴趣而对被 告知存在状态以后是否改变不感兴趣。然而，也可以不设置定时器或者 将定时器设置为某些其他值以使AS能够被告知存在状态变化。例如， AS可能希望在以后的时间当成员的存在状态从"不存在"变为"存在" 时发送视频剪辑。在方框320中描述了 PS组列表说明。
PS以消息200 OK来确认预订消息(504 ) 。 PS然后获得组的成员 的存在数据并且将存在状态发送到AS。对于用户2，PS经由消息SIP通 知(user2@hp.com)发送(505 )存在状态。用户2的SIP通知消息的 接收用消息200 OK(消息506 )确认。对于该组的用户3,用户4..用户 N，可以重复消息505和506。
在方框510中，AS使用MSRP承载数据信道将视频剪辑的拷贝从 AS发送到存在的成员。在方框510中涉及的消息基本上与结合图4A和 4B讨论的消息相同，从而用AS代替图4A和4B的用户1。视频剪辑被 逐一地从AS发送。然而，所述发送可以通过AS的多个通信端口^皮并 行地执行或者可以被顺序地发送。通过使用AS来执行到多个接收方的 实际视频传送，对发送者的移动设备的带宽要求相对于现有技术被相当 大程度地减小。此外，该方法是高度可伸缩的，原因在于多个应用服务 器可以用于处理到大量的接收方的视频传送和/或处理涉及大视频剪辑 的^L频传送。
图6A根据本发明的一个实施例示出使用SIP消息将视频剪辑发送 到一个组中的多个组成员的步骤。由于SIP消息常常用于发送IM(即时 消息)文本，因此该技术很适合发送短视频剪辑。在步骤602中，用户 发送包括视频剪辑的SIP消息，指定组URI作为接收方。在步骤604中， SIP消息(包括视频剪辑)被CSCF转发到应用服务器(AS) 。 CSCF 根据设置在用户筒档中的触发器将SIP消息转发到AS,例如组URI未 被识别而URI包含目的地为AS的域名(也称为公共服务标识符或PSI 查找表)。
在步骤606中，AS从GLMS获得成员信息。该成员信息使AS随后 能够将视频剪辑的拷贝转发到该组的成员。在步骤608中，AS获得组 成员的存在状态。在步骤610中，AS将包括视频剪辑的SIP消息逐一地 (或并行地或串行地)发送到组成员。
图6B根据本发明的一个实施例示出当用户1希望使用应用服务器 将视频剪辑传送到指定组的多个成员时交换的消息的示例性流程图。在 图6B的例子中，视频剪辑经由SIP消息被从AS发送到组成员。经由消 息651，与用户l(发送者)相关联的移动设备将SIP消息(group@hp.com +视频剪辑)发送到CSCF。该SIP消息包括视频剪辑并且指定 group@hp.com作为接收方。CSCF并不识别组URI并且使用组URI的 域名而进行了 PSI查找表。在消息652中，CSCF将包括视频剪辑的SIP 消息转发到AS以使AS能够将视频剪辑的拷贝转发到组成员。SIP消息 的接收由AS经由消息653 (200 OK)向CSCF确认。
经由消息654 (HTTP GET ( group.xml) ) ， AS首先获得由用户1 在发送视频的SIP请求中指定的组的成员资格列表。在该例子中，组是 group@hp.com,它被保持在GLMS处的group.xml列表中。GLMS以消 息655响应，将组成员提供给AS。在该时间期间，CSCF经由消息656 (200 OK)向用户1确认接收到SIP消息。
在查明组成员的存在状态的过程中涉及消息657 - 660。因而，AS 将SIP预订(group@hp.com期满=0)发送(657 )到PS，以请求 group@hp.com的成员的存在状态。可选参数"期满=0"将预订消息的 定时器设置为零以表明AS仅仅对一次获得的存在状态感兴趣而对被 告知存在状态以后是否改变不感兴趣。然而，也有可能不设置定时器或 者将定时器设置为某些其他值以使AS能够被告知存在状态变化。在方 框320中描述了组列表预订。
PS以消息200 OK来确认预订消息(658 ) 。 PS然后获得组的成员 的存在数据并且将存在状态发送到AS。对于用户2,PS经由消息SIP通 知(user2@hp.com)发送(659 )存在状态。用户2的SIP通知消息的 接收用消息200 OK(消息660)确认。对于该组的用户3，用户4..用户 N,可以重复消息659和660。
在方框670中，AS使用SIP消息将视频剪辑从AS发送到存在的成 员。因而，经由消息661， AS将包括视频剪辑的SIP消息与指定接收方 数据(SIP消息(group@hp.com +视频剪辑))一起发送到CSCF, CSCF
有助于将视频剪辑转发到指定接收方。
在方框680中，CSCF执行对指定接收方(在该例子中的用户2)的 服务控制。在执行服务控制过程中，CSCF检查用户2的服务状态以查 明是否适合将视频剪辑转发到用户2。例如，用户2对网络服务可能欠 费，并且他的帐户可能已经被暂时禁止，从而导致用户2无资格使用网 络来接收视频剪辑。作为另一个例子，用户2可以在他的简档中表明 用户2并不希望从用户1或从任何人接收任何视频剪辑。如果认为用户 2不能接收视频剪辑，则可以通知用户1并且终止会话。
在另一方面，如果用户2有资格接收视频剪辑，则CSCF将来自用 户1的请求(SIP消息(group@hp.com +视频剪辑))转发到用户2 的UE (消息662)。用户2的UE经由将消息663 (200 OK)发送到CSCF来确认接收到视频剪辑。CSCF继而经由消息664 ( 200 OK)通知 AS:视频剪辑已经被转发到用户2。
图7根据本发明的一个实施例示出了显示当用户1希望使用应用服 务器将视频剪辑传送到指定组的多个成员时交换的消息的示例性流程 图。在图7的例子中，使用实时传输协议(RTP)而不是MSRP (如图 5C中所执行的那样)来将视频剪辑从AS发送到组成员。除了 AS和每 个接收方之间的视频传送采用RTP而不是MSRP之外，图7的消息与 图5的消息基本上相同。因而，AS使用RTP (图7中的附图标记A和 B)将视频剪辑传送到每个接收方的UE,而不是MSRP通信信道(图 5C中的附图标记D和E)。
尽管在此根据几个实施例对本发明进行了描述，但是仍存在落入本 发明的范围内的变化、排列和等效替换。如上所述，尽管为了便于理解 所述例子始终涉及视频剪辑的发送，但是本发明的实施例也适用于其他 类型的多媒体数据。此外，还存在着许多实现本发明的装置的替代性方 式。因此后附权利要求旨在被理解成包括落入本发明的真实精神和范围 内的所有这样的变化，排列和等效替换。
权利要求
1.一种用于将多媒体文件从一个用户的移动设备(UE1)传送到与另一个用户相关联的用户装备(UE2)的方法，所述方法包括把邀请从所述用户的移动设备(UE1)发送(402)到所述用户装备(UE2)以请求所述多媒体文件的传送；在所述用户的移动设备和所述装备之间建立(404)承载数据信道以便于所述多媒体文件的所述传送，所述传送被配置成使用消息会话中继协议(MSRP)来实现；和使用所述MSRP和所述承载数据信道来传送(406)所述多媒体文件。
2. 根据权利要求1所述的方法，其中所述多媒体文件是视频文件 (402)。
3. 根据权利要求1所述的方法，其中使用SIP (会话启动协议)来 执行所述邀请(451/453 )。
4. 根据权利要求1所述的方法，其中所述发送所述邀请包括通过 呼叫会话控制功能(CSCF)设施来发送所述邀请。
5. 根据权利要求1所述的方法，其中所述建立包括使用HTTP (超 文本传输协议)命令来进行建立。
6. 根据权利要求1所述的方法，其中所述用户的移动设备是蜂窝 电话。
7. 根据权利要求1所述的方法，其中所述用户的移动设备是便携 式计算设备。
8. 根据权利要求1所述的方法，其中所述用户的移动设备是个人 信息管理器(PIM)设备。
全文摘要
本发明公开了一种用于将多媒体文件从一个用户的移动设备(UE1)传送到与另一个用户相关联的用户装备(UET)的方法。所述方法包括把邀请从所述用户的移动设备发送(402)到所述用户装备以请求多媒体文件的传送。所述方法还包括在所述用户的移动设备和所述装备之间建立(404)承载数据信道以便于多媒体文件的传送，所述传送被配置成使用消息会话中继协议(MSRP)或实时传输协议(RTP)来实现。所述方法进一步包括使用MSRP或RTP和承载数据信道来传送(406)多媒体文件。
文档编号H04L29/06GK101199185SQ200680021439
公开日2008年6月11日 申请日期2006年4月3日 优先权日2005年4月14日
发明者J·亨里克森, S·林 申请人:惠普开发有限公司