专利名称：用于联网通信设备的媒体客户端体系结构的制作方法
用于联网通信设备的媒体客户端体系结构背景技术蜂窝式电话网络最初被开发以便主要提供经由线路交换网络的 话音服务。尽管线路交换网络仍然被广泛使用，然而目前趋势趋向 于分组交换网络，其不仅提供话音服务而且提供高速分组数据服 务，用于使移动用户能够在网络上沖浪、读取电子邮件、下载视频 和音频文件并且完成因特网用户可以在固定网络上所做的许多其它 事情。然而，实时的多媒体在移动式网络中仍然存在问题，这是因 为大部分分组数据服务由最佳效果网络提供，所述网络缺少实时多 媒体服务所需要的服务质量保证。由于缺乏标准化，网络操作者常 常还限于只提供他们的设备销售商所支持的那些I P服务。缺乏标准 化还使网络操作者难于从第三方开发者购买捆绑的服务。IP多媒体子系统(IMS)被开发来提供通用、标准化的体系结构 和标准化接口以便在移动式联网环境中提供IP服务。IMS网络不取决 于访问技术并且实际上与任何分組交换网络相互操作，所述分组交 换网络包括UMTS、 cdma2000、 GPRS和EDGE网络。IMS4吏用会话启动协 议(SIP)作为服务控制协议，所述会话启动协议(SIP)使操作者 能够同时提供多个应用。IMS标准会加速在移动终端上采用IP服务， 使用户能够使用移动终端上的单个客户端来经由语音、视频或文本 通信。尽管IMS向移动用户承诺更丰富的体验，然而网络操作者对投资 用于实现IMS的设备很犹豫，直到存在足够量的具有IMS能力的订户 以便使投资值得进行。目前使用的大部分蜂窝式电话缺乏IMS能力， 因此用于IMS服务的潜在订户池相对较小。把IMS能力扩展到缺乏固 有IMS能力的传统移动终端可能会向网络操作者提供更宽阔的市场 并且鼓励投资IMS技术和装备。发明内容本发明涉及一种以网络为中心的媒体客户端，用于向移动终端用 户提供SIP和/或IMS能力。媒体客户端可以包括在移动终端内，或者 可以位于移动式网络中并且由所述移动终端远程访问。远程访问能力使IMS服务能够被提供给原本缺乏IMS能力的传统移动终端。媒体客户端包括经由第一网络接口与多媒体应用通信的用户代理、经由第二网络接口与所述用户代理通信的信令代理以及经由第 三网络接口与所述用户代理通信的媒体代理。网络接口使得能够进 行本地和/或远程访问。用户代理向多媒体应用提供高级应用接口 ， 用于把所述多媒体应用与基础网络协议的细节相隔离。媒体客户端 还可以包括JAVA应用接口 。信令代理在用户代理的指导下操作并且 执行为建立、修改以及终止通信会话所必须的信令任务以用于媒体 转送。媒体代理在用户代理的控制下操作并且执行媒体操作，诸如 管理媒体连接并且把媒体路由到适当的再现设备。用户代理、信令 代理和媒体代理可以一同位于网络内或者可以分布在网络组件之 间。本发明还适用于固定联网通信设备，诸如DVD和CD播放器、数字 录像机、摄像机、数字式静物摄影机、扫描器、家庭立体声系统、 电视系统和计算机，以便能够经由通信网络在联网通信设备之间进 行媒体会话。本发明还可以用来远程控制联网通信设备。
图l是其中可以使用本发明的媒体客户端的无线通信网络的功能 框图。图2是用于图示移动通信网络中IP多媒体子系统(IMS )的基本组 件的框图。图3图示了依照本发明的媒体客户端的体系结构。 图4图示了用于实现媒体客户端的各种方法。 图5是用于图示SIP登记过程的呼叫流程图。 图6是用于图示MSRP会话的呼叫流程图。 图7是用于图示RTP会话的呼叫流程图。 图8图示了具有JAVA应用接口的媒体客户端的候选实施例。 图9和10图示了依照本发明的媒体内容的选择性路由。 图11图示了其中使用本发明来在视频服务器和远程视频播放器 之间建立媒体会话的应用。
图12图示了其中使用本发明来远程控制DVD播放器并且把媒体从 远程DVD播放器流送到移动通信设备的应用。
具体实施方式
图1图示了其中可以使用本发明的移动通信网络10。虽然在移动 通信网络10的范围内描述本发明，然而那些本领域技术人员应当理通信::这里所用，术语联网通信设备包括能够经由诸:因特网之类的网络通信的任何设备。移动通信网络10包括无线电访问网络(RAN) 20、核心网络(CN) 30以及IP多媒体子系统(IMS) 40。 RAN 20支持经由空气接口与移动 终端100无线电通信。移动终端100是如这里所使用术语的联网通信 设备。移动通信网络10典型情况下包括一个以上的RAN 20,不过在 图l中只示出了一个。CN 30提供了到因特网12或其它分组数据网络 (PDN )的连接以用于诸如网络浏览和电子邮件之类的分组交换业 务，并且可以提供到公用交换电话网络(PSTN) 14和/或综合业务数 字网络(ISDN) 16的连接以用于诸如语音和传真通信业务之类的线 路交换服务。CN 30例如可以包括通用分组无线服务(GPRS)网络、 cdma2000网络或UMTS网络。CN 30包括用于与IMS 40互连的访问网关 32。访问网关32可以包括用于GPRS网络的GPRS网关服务节点(GGSN ) 或用于cdma2000网络的分组数据服务节点(PDSN ) 。 IMS 40向移动 终端100提供了独立于访问、基于IP的多媒体服务，并且支持各种IP 服务，包括经由IP的语音(VoIP)、视频和音频流送、电子邮件、 网络浏览、召开视频会议、即时消息发送、出席及其它服务。IMS 40使用开放界面和独立于访问的会话控制协议(SCP),诸 如会话启动协议(SIP)，以便支持多媒体应用。对话描述协议(SDP) 用于媒体协商。在IETF RFC 2327和3264中描述了SDP。 SIP是用于在 一个或多个参与者之间建立、修改以及终止通信会话的会话控制协 议。这些会话例如可以包括因特网多媒体会议、因特网电话呼叫以 及多媒体分送。在IETF文档RFC 3261中描述了SIP。虽然如这里所描 述的本发明优选实施例使用SIP，然而那些本领域技术人员应当理解 本发明也可以使用其它SCP。与SIP相比另一公知的协议是H. 323。 SIP
的细节对本发明来说并非是实质上的，但是下面给出了所述SIP的简要概述以便在上下文中更好地评估本发明。SIP是使用基于ASCII的信令消息来在两个或多个参与者之间建 立通信会话的信令协议。用户由这里被称作为SIP地址的唯一地址来 标识。用户使用他们所分配的SIP地址来向登记者服务器进行登记。 登记者服务器按要求向位置服务器提供此地址。当用户发起呼叫时，SIP请求被发送到SIP服务器(代理服务器或 重定向服务器)。所述请求在消息首部中包括呼叫方地址和被叫方 地址。如果代理服务器接收SIP请求，那么它把所述SIP请求转送到 被呼叫方。被呼叫方可以是另一用户或可以是用户家庭网络中的应 用服务器。被呼叫方对代理服务器作出响应，所述代理服务器随后 把所述响应转送到呼叫方。呼叫方确i人所述响应，然后在所述呼叫 方和被呼叫方之间建立会话。使用在IETF RFC中所描述的实时转送 协议(RTP)或在IETF RFC中所描述的消息会话中继协议(MSRP )以 便在呼叫方和被呼叫方之间进行通信。如果重定向服务器接收SIP请求，那么所述重定向服务器联系位 置服务器以便确定通向被呼叫方的路径，继而向呼叫方发送该信 息。呼叫方确认接收信息继而向在重定向信息中所标识的服务器(其 可以是代理服务器的被呼叫方)重新发送SIP请求。当SIP请求到达 -故呼叫方时，被呼叫方作出响应并且呼叫方确^人该响应。然后通信 使用RTP或MSRP开始。只使用SIP来处理与呼叫控制和会话管理相关 的信令消息。如上所述，SIP使移动通信网络10内的应用能够建立通信会话。 所述应用可以位于IMS 40的移动终端100或应用月l务器中。另外，所 述应用可以位于不同的网络10中。图2图示了IMS 40的基本元件及其与CN 30的关系。IMS 40包括一 个或多个呼叫状态控制功能(CSCF) 42、媒体网关控制功能(MGCF) 44、媒体网关(MGW) 46、传输信令网关(T-SGW) 48和家庭订户服 务器(HSS) 50，其借助IP网络互连。IMS 40可以进一步包括用于向 移动终端100提供多媒体服务的应用服务器52。 CSCF 42作为SIP服务 器起作用以便处理用于建立、修改和终止通信会话的会话控制信 令。由CSCF 42所执行的功能包括呼叫控制、地址转换、认证、能力 协商以及订户简档管理。HSS 50与CSCF 42对接以便提供关于订户当 前位置的信息和订阅信息。应用服务器50向移动终端100提供了多媒 体服务或其它IP服务。MGCF 44、 MGW 46和T-SGW 48支持与诸如PSTN 或ISDN之类的外部网络交互工作。MGCF 44控制一个或多个MGW 46， 所述MGW 46管理在外部网络和IMS 40之间的连接。MGCF 44配置MGW 46 并且把SIP消息转换为不同的格式，诸如ISDN用户部分(ISUP)消息。 MGCF 44把所转换的消息转送到T-SGW 48，所述T-SGW 48把IMS 40对 接到诸如SS7网络之类的外部信令网络。T-SGW 48包括用于把IP消息 转换为SS7并且反之亦然的协议转换器。IMS 40可以包括附加元件， 所述元件在图2中未被示出并且对于理解本发明来说并不重要。本发明向移动终端100提供了在图3中所示出的媒体客户端200以 便向所述移动终端100提供SIP和IMS能力。媒体客户端200可以与移 动通信网络10中的IMS 40通信以便向移动终端100提供IP服务。另 外，媒体客户端200可以经由诸如因特网之类的通信网络直接与其它 网络设备通信。可以提供的服务例子包括经由蜂窝的按键通话 (PoC)、出席和即时消息发送(IM)、视频和音频流送、经由IP的 语音、召开视频会议、交互式游戏、空白板和内容共享。媒体客户 端200与用户应用150通信并且提供用于使所述用户应用150与基础 网络协议的细节隔离的高级应用接口 。媒体连接被用户应用150视为 简单的数据流，a/k/a管道，其可以利用简单的打开、关闭、读取和 写入命令来操纵。图3图示了媒体客户端200的基本体系结构。媒体客户端200包括 用户代理(UA) 202、信令代理(SA) 204和媒体代理(MA ) 206。 UA 202与用户应用150通信并且把应用命令转换为适当的信令和媒体操 作。SA 204和MA 206在UA 202的控制和指导下操作。UA 202对连接 管理具有全面控制，并且把信令和媒体管理任务分别委托给SA 204 和MA 206。在所图示的实施例中，SA 204实现SIP和SDP协议来处理 信令任务。SA 204使用经由IP的UDP来传输消息。也可以使用诸如 H. 323之类的其它会话控制协议。信令任务包括建立、修改以及撤下 通信会话，协商会话参数，询问远程设备以便确定容量以及存在检 测。MA 206实现消息会话中继协议(MSRP)和实时传输协议(RTP ) 并且包括一个或多个媒体播放器来处理并向媒体再现设备输出媒 体。MA 206管理媒体连接，依照媒体类型和用户设置来路由媒体， 并且调用媒体播放器以便按要求处理媒体。MA 206使用经由IP的TCP 和/或UDP来传输RTP和MSRP消息。在一些实现方式中，可以取单片方法，把UA 202、 SA 204和MA206 一起集成到单个应用中。在图3所示出的实施例中，在UA 202、 SA204 和MA 206之间的网络接口 208、 210和212使得能够进行这样的实现方 式，其中UA 202、 SA 204和MA 206可以是在移动通信网络IO内分布 的独立应用。接口 208、 210、 212可以使用TCP套接字连接或其它类 型的网络接口，用于使UA 202、 SA 204和/或MA 206能够远离于用户 应用150。分布式处理方法与单片方法相比具有几个优点。媒体客户端200 可以位于IMS 40或其它IP网络中的网络服务器中，并且由移动终端 IOO例如使用远程登录来远程访问以便打开套接字连接。从而，可以 向本来没有IMS能力的移动终端100提供IMS服务。分离UA 202、 SA 204 和MA 206使这些元件能够在网络10内分布，使得所述UA 202、 SA 204 和MA 206可以位于所述网络10内的不同位置。通过在具有低带宽或 高等待时间的网络中定位媒体客户端200，可以实现改进的性能，这 是因为媒体客户端200的高级API减少了经由空气接口的信令量。此 外，用于产生大部分信令的SA 204和MA 206可以更加接近地位于网 络主干线路附近。分离SA 204和MA 206还允许优化的独立媒体(例 如，TV)和控制(例如，遥控)设备的实现方式。图4图示了媒体客户端200的一些可能配置。在图4中，NCD A和NCD B已经跨过通信网络建立了多媒体通信会话。NCD A包括完全功能的 媒体客户端200，其与NCD IOO中的用户应用150通信。NCD B原本缺 乏IMS能力并且使用位于网络10内的远程媒体客户端200的服务。在 这种情况下，位于NCD B中的用户应用150可以经由例如远程登录之 类的TCP套接字连接与位于网络服务器中的媒体客户端200通信。网 络中的媒体客户端200向NCD B提供与位于NCD A的媒体客户端200相 同的功能。用于远程访问媒体客户端200的能力可以把IMS服务扩展 到传统移动终端，所述移动终端随后向网络操作者提供为使值得投 资IMS技术所必须的临界质量。NCD C包括UA 202,用于与联网通信 设备100中的用户应用通信并且与位于网络中的SA 204和MA 206通 媒体客户端200被实现为在诸如PC或移动终端100之类的主机设 备上运行的过程。主机设备包括其中存储用于实现本发明的代码的 存储器，用于执行所述代码的一个或多个微处理器以及用于提供网 络访问的通信接口。 UA 202、 SA 204和MA 206可以位于不同的主枳i 中。在它启动之后，媒体客户端200在例如端口 3500之类的指定端口 上打开服务器套接字，以便在UA 202和用户应用150之间通信。希望 与媒体客户端200通信的任何用户应用150可以在相同的端口上打开 客户端套接字。可以在配置文件中指定用于在UA 202和用户应用150 之间通信的端口。可以打开不同的端口以4更在UA 202和SA 204之间 或在所述UA 202和MA 206之间通信。在一个示例性实施例中，媒体客户端200使用基于文本的接口协 议(UA API)以便在用户应用150和所述媒体客户端200之间通信。到TCP套接字的文本串。IMS协议使用两种类型的消息来用于通信-请 求和响应。用户应用150典型情况下向UA 202发送请求以便发起事 务，不过UA 202还可以向所述用户应用150发送请求。请求典型情况 下具有被间隔分开的参数。UA 202典型情况下响应于请求来向客户 端发送响应。存在两种响应，临时的和最终的。临时响应不会结束 由相应请求所发起的事务。最终响应终止所述事务。在UA 202和SA 204之间的应用接口 ( SA API)和在所述UA 202 和MA 206之间的应用接口 (MA API)还与UA API类似地使用基于文 本的接口协议。来自UA 202要求SA 204或MA 206动作的请求开始在 所述UA 202和SA 204或MA 206之间的事务。附录A中的表1提供了UA API的示例性请求和响应。附录B中的表2提供了SA API的示例性请求 和响应。附录C中的表3提供了MA API的示例性请求和响应。UA API中的主要请求是REGISTER请求、CALL请求、MSG请求、 ACCEPT请求、HANG-UP请求、SUBSCRIBE请求、NOTIFY事件和PUBLISH 请求。REGISTER请求、SUBSCRIBE请求、NOTIFY请求和PUBLISH请求 对应于标准的SIP请求，但是向用户应用150提供了高级抽象。记者登记。典型的REGISTER请求采用 "register aol.com"或 "registermsn.com: 5050"的形式。响应于REGISTER请求，UA 202 命令SA 204执行SIP登记。在向SIP登记者登记之后，SA 204向UA202 发送用于表明登记尝试的状态的消息，例如成功或失败。如果登记 成功，那么示例性的REGISTER响应是"register 200: OK"，并且如 果所述登记未成功，那么响应为"register lxx: failed"。下面更 详细描述的图5图示了用于登记过程的信号流。CALL请求由用户应用150发送给UA 202以便与远程设备连接。使 用CALL请求来发起RTP或MSRP会话。CALL请求包括用于标识被呼叫方 和呼叫类型的信息，诸如用户ID、别名或完全合格的(fully qualified)网络地址。如果涉及代理，那么CALL请求可以指定,皮呼 叫方的用户ID。如果不涉及代理，那么CALL请求可以给出要连接的 远程主机的完全合格的地址和端口 。呼叫类型例如可以包括mime类 型和子类型，例如视频/h263或音频amr。 CALL请求典型情况下采取"call alice video/h263 ，， 或 "call alice@ims.net: 5060 video/h263，，或"call 10. 0. 0， 1: 5060 video/h263"的形式。可以 在单个CALL请求中包括一个以上的呼叫类型。根据CALL请求的结 果，UA 202发送用于表明CALL请求的结果或状态的CALL响应。如果 成功建立连接，那么示例性的CALL响应是"call connected (呼叫 连接)，，，或者如果所述连接未成功，那么响应为"call failed (呼 叫失败)"。CALL响应可以选择性地包括用于提供附加信息的状态 代码，诸如用于表明为什么调用请求不成功的错误代码。如果连接 成功，那么用户应用150可以开始经由RTP或MSRP连接来发送并接收媒体和/或消息。在向内呼叫的情况下，CALL请求还可以由UA 202发送到用户应用 150。在这种情况下，CALL请求包括用于标识呼叫方而不是被呼叫方 的信息。否则，CALL请求是相同的。用于标识呼叫方的信息可以包 括被呼叫方的用户ID或远程主机的完全合格地址。当CALL请求被从 UA 202发送到用户应用150时，所述用户应用150不会发送CALL响应。 作为替代，用户应用150发送用于终止CALL请求的ACCEPT请求。接受或拒绝向,内呼叫:lcCEPT"^J包括用于i明UA 202应当接受或 拒绝呼叫的命令以及选择性地包括用于表明例如为什么拒绝呼叫的
代码。如果在CALL请求中指定一个以上的呼叫类型，那么用户应用 150可以接受其中一个子集并拒绝其余的。为了接受少于所有指定的 呼叫类型，用户应用包括ACCEPT请求中所接受呼叫类型的列表。UA 202应当接受那些列出的并且拒绝其余的项。如果在ACCEPT请求中没 有指定呼叫类型，那么UA 202默认时可以接受在CALL请求中所指定 的所有呼叫类型。典型的ACCEPT请求采用"accept yes (接受)" 的形式来接受呼叫或者"accept no (不接受)"的形式来拒绝所述 呼叫。如果接受少于全部指定的呼叫类型，那么ACCEPT请求具有"accept OK audio/amr"的形式，其指定所接受的呼叫类型。根据是否成功进行连接，UA 202向用户应用150发送ACCEPT响 应。ACCEPT响应包括用于表明是否成功进行连接的状态消息以及选 择性地还包括状态代码。典型的ACCEPT响应具有"accept OK"或"accept Failed: lxx，，的形式。息。MSG请,求包括用^标识其中将发送消息的呼叫的呼叫;D或会话 ID、消息长度、消息类型和消息数据。对于文本消息来说，MSG请求 具有 "msg xxx nnn text/plain\n this is the text"的形式，其 中xxx是呼叫ID或会话ID并且nnn只是文本的长度(不包括换行或首 部)。换行字符使消息类型与消息数据分离。使用MSG请求发送的文 本消息的例子是"msg 111 5 text/plain\n hello"。对于二进制 数据来说，MSG请求具有"msg xxx匪mime/type\n，，的形式，其 中xxx是呼叫ID并且nnn是数据緩冲器的长度。二进制信息的例子是 "msg 111 43 image/jpg\n31290759.. . 93285" 。 UA 202向用户应 用150发送MSG响应以便表明MSG请求的成功递送或故障。如果消息被 成功递送，那么示例性的MSG响应形式为"MSG OK"，并且如果所迷 消息未被成功递送，那么示例性的MSG响应形式为"MSG Failed: lxx，，。使用HANGUP请求来终止连接。HANGUP请求由用户应用150发送给 媒体客户端200或反之亦然。HANGUP请求可以包括单个术语"挂机" 或者单个字母"h"以及被分配给正结束的呼叫的呼叫ID。示例性的 HANGUP请求的形式为"hangup xxx"，其中xxx是呼叫ID。当HANGUP 请求由用户应用150发送给UA 202时，所述UA 2(^发送HANGUP响应以^_确认所述呼叫;故结束。HANGUP响应的形式可以为"hangup OK"或 者 "hangup disconnected"。SUBSCRIBE请求由用户应用150发送给UA 202以便预订出席服务 或其它通知服务。SUBSCRIBE请求包括用于预定服务的地址、用于预 订请求的期满时间以及所述预订请求所涉及的事件。SUBSCRIBE请求 的典型形式是 "subscribe someone@domain. com: 3600 ttt presence" 或 "subscribe someone at his domain, com: 3600 ttt presence autofresh'，，其中tt t表示在预订请求很短的期满时间。 响应于SUBSCRIBE请求，UA 202命令SA 204执行SIP预订过程。在成 功地完成SIP预订过程之后，SA 204通知UA 202，所述UA 202随后通 过发送SUBSCRIBE响应来通知用户应用150。 SUBSCRIBE响应包括用于 预定服务的地址、所述预订很短的期满时间和状态消息。期满时间 可以不同于所请求的时间。SUBSCRIBE请求选择性地可以包括状态代 码和'autorefresh'命令以便当它期满时自动地刷新所述SUBSCRIBE 请求。SUBSCRIBE请求可能由于重定向请求而失败。在这种情况下， SUBSCRIBE响应可以返回新的地址并且UA 202可以使用新的地址来重 新预订。如果成功地执4于预订，那么SUBSCRIBE响应的形式为 "subscribe ttt me@mydomain. com: 3600 successful :200"， 并 且如果所述预订失败，那么所述形式为 "subscribe ttt me@mydomain.com 3600 failed:481"。NOTIFY请求从UA 202发送到用户应用150以<更向用户应用150通 知向用户应用150给出出席通知的出席实体的出席状态改变。NOTIFY 请求包括消息大小、用于触发NOTIFY的事件类型、消息主体的mime 类型以及消息数据。NOTIFY请求的典型形式为"notify 30 someone@hisdomain. com presence application/pidf+xml\alice is now available"。用户应用150用"Notify OK"作出响应以亏更确i人 丽IFY请求。PUBLISH请求用于出席服务及其它通知服务。PUBLISH请求由用户;服务器。PUBLISH请求:括出席服一务器的地址和用于PUBLISH请求 的期满时间。PUBLISH请求选择性地可以包括'autorefresh，命令 以便当它期满时自动地刷新所述PUBLI SH请求。典型的PUBLI SH请求 其形式为"publish ttt me@mydomain.com 3600"。如果公布成功， 那么 UA 202 用 "publish ttt me@mydomain.com 3600 successful: 200"来对用户应用150作出响应，并且如果/^布失败， 那么用"publish ttt me@mydomain.com 3600 failed: 481"来作出响应o附录B中的表2描述了在SA API中所使用的请求和响应。主要请求 包括REGISTER请求、INVITE请求、ACK请求、SUBSCRIBE请求、NOTIFY 请求、PUBLISH请求和BYE请求，其对应于标准的SIP请求。使用 REGISTER请求来向SIP登记者登记。使用INVITE和ACK请求来建立SIP 会话。使用SUBSCRIBE, NOTIFY和PUBLISH请求来实现出席服务或其 它通知服务。使用BYE请求来终止SIP会话。在SA API中所使用的一 些请求对应于通用的SIP请求并且使用相同的名称。根据上下文哪个 请求正被提及应当是清楚的。然而为了避免混乱，使用前缀SIP来标 识向/从SA 204所发送的标准SIP请求和响应。响应于来自用户应用150的相应REGISTER请求，从UA 202向SA 204 发送REGISTER请求。REGISTER请求包括网络地址以及选择性地还包 括SIP登记者或SIP代理的端口 。 REGISTER请求的形式为"register server@network.com" 。 SA 204响应于REGISTER请求，来依照如IETF RFC 3261所描述的SIP来试图向SIP登记者登记。SA 204向UA 202发 送用于表明REGISTER请求的状态的REGISTER响应。如果登记尝试是 成功的，那么示例性的REGISTER响应的形式为"register OK",或 者如果登记尝试未成功，那么所述形式为"register failed"。在呼叫的发起端响应于来自用户应用150的CALL请求，INVITE请 求被UA 202发送给SA 204。 SA INVITE请求包括被呼叫方的地址或可 以被解析为有效地址的用户ID，用于指定将建立的呼叫类型的呼叫 类型以及对于每个所指定呼叫类型来说用于媒体会话的主机地址。对于每个呼叫类型可以使用相同的主机地址，或者可以使用不同的 地址。示例性的INVITE请求的形式为"invite alice@domain.com video/h263 me@mydomain. com: xxx audio/amrme@mydomain. com: xxx，，，其中xxx表明端口号。在发送INVITE请求 之后，UA 202等待来自SA 204的响应。SA 204响应于INVITE请求， 向在INVITE请求中所指定的被呼叫方发送SIP INVITE请求并且等待
响应。如果成功地建立了连接，那么SA 204向UA 202发送用于表明 所述邀请被接受的INVITE响应。INVITE响应包括会话标识符，这里 被称作为呼叫ID。响应于在呼叫的接收端接收SIP INVITE， INVITE请求还可以由SA 204发送到UA 202。在这种情况下，INVITE请求包括用于发信号的呼 叫方的地址以及由所述呼叫方用于媒体会话的一个或多个地址。从 UA 202到SA 204的INVITE响应除并未包括会话标识符之外，与上述 相同。在这种情况下，在SA 204接收来自呼叫方的SIP ACK之后，会 话标识符在ACK请求中被从SA 204发送到UA 202。SUBSCRIBE请求由UA 202发送给SA 204以便开始预订出席服务或 其它通知服务。SUBSCRIBE请求包括用户想要从中接收出席状态信息 的一方或出席服务器的地址。SA 204当收到来自UA 202的SUBSCRIBE 请求时，向在SA SUBSCRIBE请求中所指定的主机发送SIP SUBSCRIBE 请求并且等待响应。向其发送SIP SUBSCRIBE请求的主机把SIP NOTIFY请求返回到SA 204。 SIP NOTIFY请求表明SIP SUBSCRIBE请求 是否被授权，并且如果是的话，包括当前的出席状态信息。SA 204 确认SIP NOTIFY请求并且向UA 202发送NOTIFY请求，所述NOTIFY请 求包含出席代理的出席状态信息。直到预订期满，每当出席状态信 息改变时，授权预订的出席代理发送SIP NOTIFY请求，并且SA 204 向UA 202发送相应的NOTIFY请求以便把出席信息转送到UA 202。PUBLISH请求由UA 202发送给SA 204以便当用户的出席状态存在 改变时通知出席服务器。如果SA 204正作为出席服务器起作用，那 么SA 204向其订户发送N0TIFY请求以便向订户通知出席状态的改 变。如果使用独立的出席服务器来分送出席信息，那么SA 204向出 席服务器发送相应的SIP PUBLISH请求。在发送SIP PUBLISH请求之 后，SA 204向UA 202发送用于表明PUBLISH请求的状态的PUBLISH响应。BYE请求由UA 202发送给SA 204或反之亦然以便终止SIP会话。当 SA 204接收来自UA 204的BYE请求时，它向另一方发送SIP BYE请求 以便终止会话。 一旦SIP BYE请求被确认，那么SA 204向UA 202发送 BYE响应以便确认所述BYE请求。当UA 202接收来自SA 204的BYE请求 时，它关闭为在BYE请求中所指定的呼叫而打开的连接。在这种情况
下，因为BYE请求是强制的，所以不要求对BYE请求的响应。附录C中的表3描述了MA API。 MA API中的主要请求包括LISTEN 请求、CONNECT请求、SEND请求、0PEN请求、PEER请求和CLOSE请求。LISTEN请求由UA 202发送给MA 206以便开始用于多媒体消息发送 的MSRP会话。UA 202响应于来自用户应用150的呼叫请求来发送 LISTEN请求，以用于请求MSRP会话。LISTEN请求选择性地可以包括 远程主机的地址，其中可以从所述地址进行连接。当在LISTEN请求 中指定远程主机时，只从所指定的主机接受连接。响应于LISTEN请 求，MA 206打开用于媒体连接的端口并且向UA 202发送LISTEN响应， 以给出用于所述媒体连接的地址和端口 。在呼叫的接收端，CONNECT请求由UA 202发送给MA 206以便建立 MSRP连接。在呼叫的接收端的用户从呼叫方接受用于加入呼叫的邀 请之后，典型情况下发送CONNECT请求。CONNECT请求包括由呼叫方 在SIP INVITE中所指定的网络地址和端口 。示例性的CONNECT请求的 形式为"connect anybody@domain.com"。响应于CONNECT请求，MA 206依照MSRP来建立连接并且向UA 202发送CONNECT响应。CONNECT响 应包括CONNECT请求的状态以及选择性地还包括状态代码。示例性的 CO腿CT响应的形式为"connect 0K，，或"connect failed" 一旦建立MSRP会话，那么就使用SEND请求来发送多媒体消息。当 UA 202接收来自媒体客户端200的MSG请求时，UA 202产生SEND请求 并把它发送给MA 206。 SEND请求包括用于唯一标识呼叫的呼叫ID、 消息长度、消息类型和消息数据，在所述呼叫中正发送消息。示例 性的SEND请求的形式为"SEND xxx匪text/plain\n this is the text" 。 MA 206随后依照MSRP来发送消息。当消息被确认时，MA 206 向UA 202发送用于标识呼叫并且表明SEND请求的状态的SEND响应。 SEND请求选择性地可以包括状态代码。示例性的SEND响应的形式为 用于表明成功递送的"send xxx OK"或用于表明所述消息未被成功 递送的"send xxx failed"。使用OPEN请求来发起RTP会话。UA 202响应于来自用户应用150 的ACCEPT请求来向MA 206发送0PEN请求。OPEN请求选择性地包括远 程主机的网络地址，其中将从所述地址接受媒体连接。如果远程主 机地址被包括在OPEN请求中，那么只从在OPEN请求中所指定的地址 接受媒体连接。响应于OPEN请求，MA 206打开用于媒体连接的端口 并且返回用于表明媒体连接的网络地址和端口的OPEN响应。OPEN响 应表明OPEN请求的状态，并且如果成功的话，那么包括为RTP连接所打开的主4几和端口的网络地址。一旦建立媒体连接，那么在呼叫的发起端的UA 202向MA 206发送 PEER请求以便向MA 206提供在另一端为RTP会话所打开的主机地址和 端口。 PEER请求的唯一参数是用于媒体连接的网络地址和端口。不 要求对PEER地址请求的响应。示例性的PEER请求的形式为"PEER someon6@domain.com，，。使用CLOSE请求来终止用于RTP或MSRP会话的媒体连接。UA 202 响应于来自用户应用150的HANG-UP请求来向MA 206发送CLOSE请求。UA、 SA和MA API还可以具有SET请求以便使某些参数能够在初始 化期间被预先配置。SET请求包括参数名和被分配给所命名参数的 值。可以使用SET请求来为不同的媒体配置具体到用户的设置，诸如 用户名、别名、联系地址以及默认源和汇点。图5到7是用于图示IMS命令和响应怎样由多媒体应用使用的呼叫 流程图。图5图示了典型的SIP登记过程。图6是用于图示示例性的 MSRP会话的呼叫流程图。图7是用于图示示例性的RTP会话的呼叫流 程图。图5是用于图示SIP注册过程的呼叫流程图。在图5中，用户A正向 SIP登记者登记。用于用户A的用户应用150使用在表1中所示出的API 来向UA 202发送REGISTER请求(a) 。 UA 202接收请求，追加具体到 用户的配置数据，并且把REGISTER请求转送到SA 204。具体到用户 的配置数据可以包括诸如用户名、别名和联系地址之类的数据。响 应于REGISTER请求，SA 204发起SIP登记过程。SA 204才艮据从UA 202 所接收的信息来构造SIP REGISTER请求，利用按完整SIP请求所要求 的默认设置来扩充此信息。SA 204向SIP登记者发送SIP REGISTER请 求(c) 。 IMS核心40可以把临时的SIP响应(SIP IOO尝试)返回到 SA 204 (d)以便防止不必要的SIP请求重发。因此，SA 204不要求 任何动作。如果登记成功，那么SIP登记者向SIP代理发送SIP响应 (SIP 200 OK) (f)并且SIP代理把SIP登记者的响应中继到SA 204 (g) 。 SA 204把用于向用户应用150通知所述登记成功的SA响应发
送到用户代理(h)。现在用户A能够使用其登记的ID来发送并接收 SIP消息。图6图示了在两个用户之间的典型MSRP会话中的呼叫流程。MSRP 会话是其中可以使用SEND请求来交换一 系列消息的上下文。MSRP经 由诸如TCP之类的可靠传输协议来在会话模式中提供端到端的消息 传输。利用SIP作为消息载体使用SDP提供回答模型(IETF RFC 3264 ) 来建立MSRP会话。为了简要地概括，端点A可以通过发送具有用于表 示端点A的临时地址的提供消息(SIP INVITE)来发起与端点B的通 信会话。如果端点B希望加入会话，那么它打开到端点A的TCP连接并 且发送以由端点A所提供的地址为目的的MSRP VISIT请求。在访问所 述会话之后，端点B发送对SIP INVITE请求的回答。所述回答包含用 于通信会话的端点B的地址。在此交换之后，端点A和B可以交换消 息。利用SEND请求来发送消息并且接收端点用OK应答作出响应。端 点A和B经由MSRP VISIT请求所建立的TCP连接向在In the SIP INVITE SDP主体中所表明的地址发送消息。本发明使在端点A和B的用户应用与MSRP、 SIP和SDP的细节相隔 离，所述细节如图6所示由UA 202、 SA 204和MA 206来处理。在图6 中所图示的过程使用在附录的表1-3中所定义的API。用户应用150通 过向媒体客户端200发送CALL请求(a )来发起MSRP会话。响应于CALL 请求，UA 202向MA 206发送MA LISTEN请求(b)以命令所述MA 206 打开TCP套接字以接受来自在CALL请求中所指定对等体的TCP连接。 MA 206向UA 202发送MA LISTEN响应(c)，包括为媒体连接所打开 的主机和端口的网络地址。然后UA 202通过向SA 204发送SA INVITE 请求(d)来命令SA 204发起通信会话。SA INVITE请求包含在CALL 请求中所包括的参数以及由MA 206为媒体连接所提供的网络地址和 端口。 SA INVITE选择性地可以包括具体到用户的配置数据，诸如用 户名、别名等。还可以由用户应用150使用在表1中所示出的SET请求 来设置用于用户指定配置数据的参数值。SA 204使用常规的SIP信令来建立MSRP会话。SA 204根据它从UA 202所接收的信息来构造SIP INVITE请求，以利用按完整SIP INVITE 请求所要求的默认设置来扩充此信息。SA 204向端点B发送SIP INVITE请求(e) 。 SIP INVITE请求包括用于描述多媒体会话的SDP (对话描述协议)主体。当等待来自在端点B的SA 204的响应时，在 端点A的SA 204可以从网络接收用于表明该网络试图与端点B建立连 接的临时SIP响应("100尝试")(f)。一旦SIP INVITE请求由在端点B的SA 204接收，它就向UA 202发 送SA INVITE请求(h)并且可以向在端点A的SA 204发送用于表明所 述SA2(M正在"呼唤(ringing)"在端点B的用户的临时响应(g)。 在端点A的SA 204随后可以向UA 202发送临时的STATUS响应(k)以 向在端点A的UA 202提供呼唤指示。在端点A的UA 202在一些应用中 可以向用户应用150提供临时的状态信息(1)以便向用户通知正尝 试到达在端点B的用户。响应于INVITE请求，在端点B的UA 202向用户应用150发送CALL 请求(i)以便向用户应用150通知接收了对MSRP会话的邀请。CALL 请求包括用于标识呼叫方和呼叫类型的信息。用户应用150为了应答 CALL请求而发送用于表明用户是否希望回答呼叫的ACCEPT请求(j)。在此例子中，在端点B的用户接受所述邀请。如果呼叫涉及 一种以上类型的媒体，那么在端点B的用户在ACCEPT请求中指定接受 哪个媒体。然后在端点B的UA 202向MA 206发送C0NNECT请求(m)以 便打开媒体连接，例如TCP连接。在端点B的MA 206向在端点A的MA 206 发送MSRP VISIT消息(n)以便建立MSRP连接。在端点A的MA 206向 MSRP VISIT发送肯定响应(MSRP 200 OK )以便在端点A和B之间建立 MSRP连接(o)。在建立媒体连接之后，在端点B的MA 206向在端点B 的UA 202发送C0NNECT响应(Connect 200 OK)以^f更表明成功地建立了媒体连接(P)。在此刻，SIP INVITE请求尚未被接受。在端点B的UA 202向在端 点B的SA 204发送SA INVITE响应(INVITE 200 OK) (q)，其用于 表明所述SA 204应当接受加入与端点A的MSRP会话的邀请。在端点B 的SA 204向在端点A的SA 204发送SIP INVITE响应(SIP 200 OK + SDP 主体)(r) 。 SIP INVITE响应包括用于确认MSRP会话参数的SDP主 体。SIP INVITE响应是对在步骤(e)的SIP INVITE请求的回答并且 包含由端点B用于媒体连接的网络地址和端口。在端点A的SA 204确 认SIP 200 OK响应以便完成SIP信号交换(s)。在端点A， SA 204发 送用于表明在步骤(a)所请求的连接已成功建立的SA INVITE响应 (t)。此消息包括用于唯一标识所述呼叫的呼叫标识符，以及在端点B用于媒体连接的主机和端口的网络地址。在端点A的UA 202随后 向用户应用150发送用于表明在步骤(a)所请求的连接被成功建立 的CALL响应(u)。在端点B， SA 204响应于SIP ACK向UA 202发送ACK 请求(v)，其用于表明与端点A的连接是成功的并且包括SIP会话标 识符。UA 202随后向用户应用150发送用于表明建立与端点A连接的 ACCEPT响应(w)。端点A和B现在可以开始发送并接收消息。在端点A的用户应用产生多媒体消息，其在MSG请求中被传递给UA 202 (x)。 MSG请求包括用于标识会话、消息类型和消息大小的信息。 UA 202构造并把SEND请求转送到MA 206 (y)，其具有在MSG请求中 所指定的参数，用于指导MA 206把多媒体消息转送到端点B。 MA 206 使用MSRP协议来递送多媒体消息。MA 206产生MSRP SEND请求(z), 根据完整MSRP SEND请求的需要来提供缺省参数，并且向在端点B的 MA 206发送所述请求。在端点B的MA 206从MSRP SEND请求中提取消 息内容并且在MA SEND请求内把所述消息递送到在端点B的UA 202(aa)。在端点B的UA 202使用MSG请求来把消息内容转送到用户应 用150(bb)。在端点B的用户应用150通过发送MSG响应(MSG 200 0K) 来确认收到消息(cc)并且UA 202随后把用于表明所述消息被成功 递送的SEND响应转送到MA 206 ( dd )。所述MA 206发送MSRP OK响应(MSRP 200 OK)以便确认收到消息(ee)。在端点A的MA 206选择 性地可以转换MSRP响应(MA SEND 200 OK)并将其转送到在端点A的 UA 202 (ff),所述UA 202随后选择性地可以向在端点A的用户应用 150发送用于表明所述消息已被成功递送的MSG响应(MSG 200 OK)(gg)。为了结束会话，在端点A的用户应用150向其UA 202发送HANG-UP 请求(hh)。端点B还可以依照相同的方式来结束会话。在端点A的 UA 202向在端点B的SA 204发送用于表明在请求中所指定的呼叫应当 被结束的SA BYE请求(ii) 。 SA 204根据在步骤所建立的SIP会话参 数来产生SIP BYE请求(r )并且向端点B发送此消息。在端点B的SA 204 接收SIP BYE请求并且应答以便确认收到所述消息(kk)。在端点A， SA 204向UA 202发送用于确认媒体会话被关闭的BYE响应(11) 。 UA 202向用户应用150发送HANGUP响应(mm)以^便向用户应用150通知媒
体会话被关闭，并且向MA 206发送CL0SE请求(nn )以便关闭为所述 媒体会话所打开的连接。在端点B的SA 204产生BYE请求(oo )并且 把所述BYE请求转送到UA 202，其用于表明MSRP会话已经被关闭。类 似地，在端点B的UA 202向用户应用150发送HANGUP请求(pp )以便 向用户应用通知MSRP会话被关闭，并且向MA 206发送CL0SE请求以便 关闭为所述媒体会话所打开的连接(qq)。图7图示了在端点A和B之间的示例性RTP会话。在图7中所图示的 过程使用在附录的表l-3中所定义的API。在端点A的用户应用150向 媒体客户端200发送CALL请求(a)以便发起RTP会话。CALL请求包括 用于标识被呼叫方和呼叫类型的信息。响应于CALL请求，在端点A的 UA 202向MA 206发送MA OPEN请求(b)以《更命令所述MA 206打开UDP 连接以用于与在所述CALL请求中所指定对等体的RTP会话。MA 206打 开UDP套接字并且把MA Open响应返回到UA 202 ( c )，所述MA Open 响应包含为RTP会话所打开的UDP套接字的网络地址和端口 。然后在 端点A的UA 202结束到SA 204的SA INVITE请求(d) 。 SA INVITE请 求包括来自在步骤(a)所进行的CALL请求的参数、由MA 206在步骤(c)所提供的连接信息以及选择性地用户指定的配置数据，诸如用 户名和别名。还可以由用户应用150使用在表1中所示出的SET请求来 设置用于用户指定配置数据的参数值。SA 204使用常规的SIP信令来与端点B建立通信会话。SA 204向端 点B发送SIP INVITE请求(e) 。 SIP INVITE请求包括用于描述多媒 体会话的SDP主体。SDP主体描述了包括会话和编解码器参数的媒 体。当等待来自在端点B的SA 204的响应时，在端点A的SA 204可以 从网络接收用于表明该网络正试图与端点B建立连接的临时响应")。一旦SIP INVITE请求由在端点B的SA 204接收，它就向UA 202发 送SA INVITE请求(h)以便打开RTP连接并且可以向在端点A的SA 204 发送用于表明所述SA 204正在"呼唤，，在端点B的用户的临时响应 (g)。在端点A的SA 204随后可以向UA 202发送临时的STATUS响应 以向在端点A的UA 202提供呼唤指示(k)。在端点A的UA 202在一些 应用中可以向用户应用150提供临时的状态信息(1)以便向用户通 知正尝试呼唤在端点B的用户。
在步骤(h)的INVITE请求包括用于标识端点A和用于RTP会话的 媒体类型的信息。UA 202通过发送CALL请求来向用户应用150通知接 收了对RTP会话的邀请(i )。用户应用150利用ACCEPT请求来应答CALL 请求(j)，在此例子中所述ACCEPT请求用于表明在端点B的用户已 经接受用于加入RTP会话的邀请。如果呼叫涉及一个以上类型的媒 体，那么在端点B的用户在ACCEPT请求中指定将接受的媒体。例如， 如果请求视频会议，那么在端点B的用户可以选择接受音频并且拒绝 视频。在端点B的用户接受SIP邀请之后，UA 202向MA 206发送MA OPEN 请求(m)以便打开用于RTP会话的媒体连接。在端点B的MA 206打开 UDP连接并且向UA 202发送MA OPEN响应(n)，所述MA OPEN响应给 出了用于RTP会话的媒体连接的地址和端口。在此，在步骤(e)所 发送的SIP INVITE请求尚未被接受。在端点B的UA 202向在端点B的 SA 204发送SA INVITE响应(INVITE 200 OK) (o)，其用于表明所 述SA 204应当接受加入与端点A的RTP会话的邀请。此请求包括由MA 206在Open响应中所返回的媒体主机和端口信息。在端点B的SA 204 向在端点A的SA 204发送SIP INVITE响应(SIP 200 OK + SDP主体) (p) 。 SIP INVITE响应包括用于确认为建立全双工通信所要求的RTP 连接参数的SDP主体。SIP INVITE响应是对在步骤(e)的SIP INVITE 请求的回答。在端点A的SA 204确认SIP 200 OK响应以便完成SIP信 号交换(q)。在端点A， SA 204发送用于表明在步骤(d)所请求的连接已成功 建立的SA INVITE响应(r)。此消息包括用于唯一标识所述呼叫的 呼叫标识符，以及在端点B用于媒体连接的主机和端口的网络地址。 在端点A的UA 202随后向用户应用150发送用于表明在步骤(a)所请 求的连接被成功建立的CALL响应(s)，并且向MA 206发送PEER请求 (t)，其具有在SA INVITE响应中所包含的RTP连接参数。在端点B, SA 204响应于SIP ACK向UA 202发送ACK请求(u),其用于表明与端 点A的连接被成功建立。UA 202随后向用户应用150发送用于表明建 立与端点A连接的ACCEPT响应(v)。端点A和B现在可以开始发送并 接收RTP媒体(w)。为了结束会话，在端点A的用户应用150向其UA 202发送HANG-UP
请求(x)。端点B还可以依照相同的方式来结束会话。在端点A的UA 202向在端点B的SA 204发送用于表明在请求中所指定的RTP会话应当 被结束的SA BYE请求(y) 。 SA 204根据在步骤(p)所建立的SIP会 话参数来产生SIP BYE请求(z)并且向端点B发送此消息。在端点B 的SA 204接收SIP BYE请求并且应答以便确认收到所述消息(aa )。 在端点A， SA 204向UA 202发送用于确认RTP会话^皮关闭的BYE响应(bb) 。 UA 202向用户应用150发送HANGUP响应(cc )以^更向用户应 用150通知RTP会话被关闭，并且向MA 206发送CL0SE请求(dd )以便 关闭为所述RTP会话所打开的连接。在端点B的SA 204产生BYE请求并 且把所述BYE请求转送到UA 202 ( ee )，所述BYE请求用于表明RTP会 话已经被关闭。在端点B的UA 202向用户应用150发送HANGUP请求(ff )以便向用户应用通知RTP会话被关闭，并且向MA 206发送CLOSE 请求(gg)以便关闭为所述媒体会话所打开的连接(gg)。图8图示了包括用于JAVA应用的应用接口的媒体客户端200的另 一实施例。如前所述，在图8中所示出的实施例包括UA 202、 SA 204 和MA 206。除本地的UA API之外，图8中的媒体客户端200还包括用 于JAVA应用的JAVA应用接口 (JAVA API) 。 JAVA API是面向连接的 应用接口。 JAVA API包括使JAVA应用能够向SIP代理登记、打开连接(呼叫)、查询远程端的能力、发送/接收消息、重定向媒体字符串 以及挂起连接的命令。像本地IMA API的JAVA API提供了高级抽象， 用于使JAVA应用与诸如SIP和SDP之类的低级协议的细节相隔离。 JAVA API使JAVA应用能够与用户代理通信，同时信令代理和媒体代 理处理基础的信令和媒体操作。具有JAVA API的媒体客户端200通过 处理通常在JAVA应用中所发现的信令和操作任务来使JAVA应用更易 于写入。因为JAVA应用不会直接访问更低级的协议，诸如SIP和SDP,同的移4终端中X作。此外，'劣质JAV:;用在网络内造成问题的: 会变得更小。J A V A应用还不必担心直接访问低级协议所带来的配置 和部署问题。作为替代，配置和部署问题由媒体客户端200来处理。 设备制造商已经使用用户化过程来配置具体到特定操作者网络的设 置并且可以容易地为特定的操作者网络来配置媒体客户端200。在本发明的某些实施例中，MA 206能够把媒体直接路由到媒体再
现设备，当用户应用150不需要处理数据时绕过所述用户应用150。 例如在媒体流送中，用户应用150典型情况下接收媒体流并且把媒体 流输出到媒体播放器而没有任何数据处理。在此情况中，MA 206可 以把媒体流直接路由到媒体播放器。图9图示了从远程设备到本地媒 体再现设备(例如，移动终端100的扬声器和/或显示器)的典型媒 体(例如，视频或音频)流送。媒体流穿过协议堆栈的较低层并且 被MA 206直接路由到媒体播放器，诸如视频解码器。媒体流经由IP、 UDP和RTP堆栈向上传递到视频解码器。图9还图示了从照相机经由 RTP、 UDP和IP堆栈向下传递的输出以便传输到远程设备。媒体流和 摄像机输出都未流入到MA 204的高层或应用层。在一些应用中，用 户应用150可能想要接收媒体流。图10图示了向/从用户应用的典型 媒体流。在本发明的优选实施例中，用户应用150可以指导怎样路由媒体 或消息。为了能够由用户应用150选择性路由媒体，UA API可以包括 由用户应用150发送到媒体客户端200的SETROUTE请求以便为媒体流 指定特定的源或汇点。源或汇点可以在移动终端100内部或外部。MA API包括相应的SETROUTE请求，其由UA 202发送到MA 206以便配置用 于指定将怎样路由媒体流的路由表。UA API和MA API还可以包括用 于控制媒体流的其它请求，诸如用于暂停活动媒体流的PAUSE请求和 用于恢复所暂停媒体流的RESUME请求。图11和12图示了其中可以使用本发明的媒体客户端200的各个方 式。图ll图示了三个网络通信设备——移动设备IOO、摄像机300和 视频播放器350 。移动设备100包括如图3中所图示的媒体客户端 200，包括UA 202、 SA 204和MA 206。视频播放器350包括MA 206。 在此例子中，移动设备100的用户希望播放从摄像机300到远程视频 播放器350的视频。这例如对于人们当离开度假时监视他们的家来说 是有用的。移动设备100中的UA 202与远程视频播放器350中的MA 206 建立TCP连接。移动设备100中的SA 204使用SIP与摄像机300建立信 令连接。在移动设备IOO、摄像机300和视频播放器之间的通信在因 特网或其它通信网络12上是对等的。为了发起媒体会话，移动设备100中的应用150使用在图7中所示 出的过程。应用150通过向UA 202发送CALL请求来发起媒体会话，所
述UA 202也位于移动设备100中。移动设备100中的UA 202向远程净见 频播放器350中的MA 206发送0PEN请求以便打开用于RTP会话的UDP套 接字连接。经由TCP套接字连接来发送OPEN请求。应当注意，在此例 子中移动设备100控制远程定位的MA 206。视频播放器350中的MA 206 把用于RTP连接的网络地址和端口返回到移动设备100中的UA 202。 UA 202通过向SA 204发送INVITE请求来命令SA 204建立RTP会话。SA 204也位于移动设备100中。INVITE请求包括由视频播放器350中的MA 206所提供的网络地址和端口 。由视频播放器350所提供的网络地址 和端口包括在被发送到摄像机300的SIP INVITE中。摄像机300把用 于RTP连接的网络地址和端口返回到移动设备100中的SA 204，所述 SA 204随后向UA 202提供此信息。移动设备100中的UA 202向视频播 放器350中的MA 206发送PEER请求，其包含由摄像机300所提供的网 络地址和端口以便在视频播放器350和摄像机300之间建立RTP连 接。然后视频播放器350可以接收来自摄像机300的视频流。在图12所示出的例子中，存在两个网络通信设备——移动设备 100和DVR/DVD播放器400,其在这里被简单地认为是DVD播放器400。 移动设备100的用户希望播放从远程DVD播放器400到移动设备100的 DVD或存储的数字视频。DVD播放器400例如可以位于用户的家里。移 动设备100和DVD播放器400都包括如图3所示的媒体客户端。DVD播放 器400中的应用控制DVD播放器400的操作并且如下所述能够经由因 特网来进行遥控。移动设备100通过使用MSRP向DVD播放器400发送命 令来远程控制DVD播放器4 00 。遥控指令被作为文本消息从移动设备 100发送到DVD播放器400。适于DVD播放器的示例性命令包括"播 放"、"停止"、"暂停"、"恢复"、"快进"和"选择"。使用 经由MSRP所发送的基于文本的命令，移动设备100可以命令DVD播放 器400把视频和/或音频经由因特网流送到移动设备100。为了远程控制DVD播放器400，移动设备100与DVD播放器400建立 MSRP会话来用于向DVD播放器传输命令和/或控制信号，并且建立独 立的RTP会话以便把视频和/或音频从DVD播放器400流送到移动设备 100。分别使用如图6和7所示的过程来建立MSRP和RTP会话。使用 MSRP，移动设备100向DVD播放器400发送作为文本消息的命令。在此 例子中，MSRP消息被DVD播放器400中的媒体客户端200传递到应用150,这里被称作为遥控应用，DVD播放器400中的遥控应用150分析 由移动设备100所发送的命令并且相应地控制DVD播放器400。如图8 和9所示，DVD播放器400可以具有用于有选择地路由媒体流的能力。 DVD播放器400中的遥控应用150使用SETROUTE请求可以命令DVD播放 器400在RTP会话内向移动设备100发送视频和/或音频流。那些本领 域技术人员还会认识到移动设备100可以命令DVD播放器400向另一 远程联网的通信设备发送媒体。图12中所图示的方法可以用来远程控制各式各样的设备，诸如摄 像机、数字式静物摄影机、打印机、扫描器、复印机、家庭立体声 系统、电视或计算机。那些本领域技术人员还应当认识到，可以把 媒体从移动设备100流送到远程设备。例如，本发明可以用来把音频 从便携式DVD或CD播放器流送到家庭计算机以便所述音频可以被记 录并存储在所述家庭计算机上。作为另一例子，本发明可以用来把 视频和/或音频从便携式摄像机流送到家庭计算机以便把所述视频 和/或音频记录并存储在所述家庭计算机上。当然在不脱离本发明的精神和本质特征的情况下可以依照除这 里所阐明的那些之外的其它具体方式来实施本发明。因此本实施例 在各个方面将被认为是说明性的而并非是限制性的，并且在所附权 利要求的意思和等效范围内的所有变化都旨在包含在本发明的范围 内。
权利要求
1.一种用于联网通信设备(100)的媒体客户端(200)，包括用户代理(202)，用于与所述联网通信设备(100)中的多媒体应用(150)通信；第一网络接口(208)，用于在所述用户代理(202)和多媒体应用(150)之间通信；信令代理(204)，在所述用户代理(202)的控制下执行信令操作以便建立并终止通信会话；和媒体代理(206)，在所述用户代理(202)的控制下发送并接收多媒体消息。
2. 如权利要求l所述的媒体客户端(200 ),其中所述用户代理 (202 )远离于所述多媒体应用(l50)。
3. 如权利要求2所述的媒体客户端(200 ),其中所述用户代理 (202 )位于网络服务器(40)中。
4. 如权利要求l所述的媒体客户端(200 )，进一步包括第二网 络接口 (210),用于在所述用户代理(202 )和信令代理(204 )之 间通信。
5. 如权利要求4所述的媒体客户端(200 )，其中所述信令代理 (204 )远离于所述多媒体应用(150)。
6. 如权利要求5所述的媒体客户端(500 ),其中所述信令代理 (2(H)位于网络服务器(40)中。
7. 如权利要求4所述的媒体客户端(200 )，其中所述信令代理 (204 )远离于所述用户代理(202 )。
8. 如权利要求4所述的媒体客户端(200 )，进一步包括第三网 络接口 (212)，用于在所述用户代理(202 )和媒体代理(206 )之 间通信。
9. 如权利要求8所述的媒体客户端(200 )，其中所述媒体代理 (206 )远离于所述多媒体应用(l50)。
10. 如权利要求9所述的媒体客户端(200 )，其中所述媒体代 理(206 )位于网络服务器(40)中。
11. 如权利要求9所述的媒体客户端(200 )，其中所述媒体代 理(206 )远离于所述用户代理(202 )。
12. 如权利要求8所述的媒体客户端(200 )，其中所述第一、 第二和第三网络接口 ( 208， 210， 212)包括TCP连接。
13. 如权利要求l所述的媒体客户端(200 )，其中所述用户代 理(202 )、信令代理(204 )和媒体代理(206 )位于通信网络(10) 的网络服务器(40)内，并且其中所述多媒体应用(150)位于所述 联网通信设备(100)中并且远程访问所述媒体客户端(200 )。
14. 如权利要求8所述的媒体客户端(200 )，其中所述信令代 理(204 )和媒体代理(206 )位于通信网络(10 )的网络服务器(40 ) 内，并且其中所述用户代理(202 )位于所述联网通信设备(100) 中并且远程访问所述信令和媒体代理(204， 206 )。
15. 如权利要求l所述的媒体客户端(200 )，其中所述媒体代 理(206 )响应于来自所述多媒体应用(150)的命令来有选择地在 所述多媒体应用(150)和一个或多个媒体播放器(300, 350 )之间 路由媒体流。
16. 如权利要求l所述的媒体客户端(200 ),其中所述用户代 理(202 )包括JAVA应用接口 (214)。
17. —种被配置为向位于联网通信设备(100)中的多媒体应用 (150)提供多媒体支持的媒体客户端(200 ),所述联网通信设备 (100)通信地链接到通信网络(10)，所述媒体客户端(200 )包括用户代理(202 )，用于与所述联网通信设备(100)中的多媒体 应用(150)通信；信令代理(204 ),在所述用户代理(202 )的控制下执行信令操 作以便建立并终止通信会话；和媒体代理(206 )，在所述用户代理(202 )的控制下发送并接收 多媒体消息；其中所述一个或多个代理(202， 204, 206 )远离于所述联网通 信设备(100)。
18，如权利要求17所述的媒体客户端(200 ),其中所述远程代 理(202， 204， 206 )包括用于支持经由通信网络(10)与远程代理 (202， 204， 206 )通信的网络接口 ( 208， 210, 212)。
19.如权利要求17所迷的媒体客户端(200 )，其中所述用户代理(202 )、信令代理(204 )和媒体代理(206 )远离于所述联网通 信设备(100)并且其中所述用户代理(202 )具有用于在所述多媒 体应用(150)和用户代理(202 )之间通信的网络接口 ( 208 )。
20. 如权利要求19所述的媒体客户端(200 )，其中所述用户代 理(202 )、信令代理(204 )和媒体代理(206 )位于所述通信网络(10)中并且可经由所述通信网络(10)来访问。
21. 如权利要求17所述的媒体客户端(200 )，其中所述用户代 理(202 )位于所述联网通信设备(100)中并且其中所述信令代理(204 )远离于所述联网通信设备(100)并且具有能够在所述用户 代理(202 )和信令代理(204 )之间通信的网络接口 (210)。
22. 如权利要求21所述的媒体客户端(200 ),其中所述信令代 理(204 )位于所述通信网络(10)中并且可经由所述通信网络(10) 来访问。
23. 如权利要求17所述的媒体客户端(200 ),其中所述用户代 理(202 )位于所述联网通信设备(100)中并且其中所述媒体代理(206 )远离于所述联网通信设备(100)并且具有能够在所述用户 代理(202 )和媒体代理(206 )之间通信的网络接口 (212)。
24. 如权利要求23所述的媒体客户端(200 )，其中所述媒体代 理(206 )位于所述通信网络(10)中并且可经由所述通信网络(10) 来访问。
25. 如权利要求23所述的媒体客户端(200 ),其中所述媒体代 理(206 )位于另一联网通信设备(100)中并且可经由通信网络(10) 来访问。
26. —种用于为移动设备(100)建立媒体会话的方法，包括 把媒体客户端(200 )的组件存储在网络服务器(40)中，其中所述媒体客户端(200 )与所述移动设备(100)中的媒体应用(150) 通信；由所述媒体客户端(200 )接收来自所述媒体应用(150)的应用命令；由所述媒体客户端(200 )响应于所述应用命令来执行媒体和信 令操作以便建立媒体会话。
27. 如权利要求26所述的方法，其中所述媒体客户端(200 )包 括用于与所述媒体应用(150)通信的用户代理(202 )、在所述用 户代理(202 )的控制下建立并终止媒体会话的信令代理(204 )以 及在所述用户代理(202 )的控制下发送并接收媒体的媒体代理 (206 )。
28. 如权利要求27所述的方法，其中所述用户代理(202 )位于 所述网络服务器MO)中并且经由第一网络接口 ( 208 )与所述媒体 应用(150)通信。
29. 如权利要求28所述的方法，其中所述信令代理(204 )远离 所述用户代理(202 )位于所述网络(10)中。
30. 如权利要求29所述的方法，进一步包括 在所述用户代理(202 )和信令代理(204 )之间建立第二网络接口 ( 210);并且经由所述第二网络接口 ( 210)在所述用户代理(202 )和信令代 理(204 )之间发送通信。
31. 如权利要求30所述的方法，其中所述媒体代理(206 )远离 所述用户代理(202 )位于所述网络(10)中。
32. 如权利要求31所述的方法，进一步包括 在所述用户代理(202 )和媒体代理(206 )之间建立第三网络接口 ( 212);并且经由所述第三网络接口 ( 212)在所述用户代理(202 )和媒体代 理(206 )之间发送通信。
33. 如权利要求27所述的方法，其中所述信令代理(204 )位于 所述网络服务器(40)中。
34. 如权利要求33所述的方法，其中所述信令代理(204 )经由 网络接口 (210)与所述用户代理(202 )通信，并且其中所述用户 代理(202 )位于所述移动设备(100)中。
35. 如权利要求27所述的方法，其中所述媒体代理(206 )位于 所述网络(10)中。
36. 如权利要求35所述的方法，其中所述媒体代理(206 )经由 网络接口 (212)与所述用户代理(202 )通信，并且其中所述用户 代理(202 )位于所述移动设备(100 )中。
全文摘要
一种用于联网通信设备(100)的媒体客户端(200)包括用于与所述联网通信设备(100)中的多媒体应用(150)通信的用户代理(202)。所述用户代理(202)向多媒体应用(150)提供高级应用接口。信令代理(204)在所述用户代理(202)的控制下执行为建立并维护通信会话所必须的信令操作。媒体代理(206)在所述用户代理(202)的控制下执行媒体操作。媒体客户端(200)可以位于网络(10)中并且由多媒体应用(150)远程访问。用户代理(202)、信令代理(204)和媒体代理(206)具有网络接口(208，210，212)，用于使这些元件能够在所述网络(10)内被分布并且远程访问。
文档编号H04L29/06GK101133616SQ200580048821
公开日2008年2月27日 申请日期2005年7月11日 优先权日2004年12月31日
发明者D·W·肖普, J·W·本内特, S·马杜拉 申请人:索尼爱立信移动通讯股份有限公司