CN101133616A - 用于联网通信设备的媒体客户端体系结构 - Google Patents

Abstract

一种用于联网通信设备(100)的媒体客户端(200)包括用于与所述联网通信设备(100)中的多媒体应用(150)通信的用户代理(202)。所述用户代理(202)向多媒体应用(150)提供高级应用接口。信令代理(204)在所述用户代理(202)的控制下执行为建立并维护通信会话所必须的信令操作。媒体代理(206)在所述用户代理(202)的控制下执行媒体操作。媒体客户端(200)可以位于网络(10)中并且由多媒体应用(150)远程访问。用户代理(202)、信令代理(204)和媒体代理(206)具有网络接口(208，210，212)，用于使这些元件能够在所述网络(10)内被分布并且远程访问。

Description

用于联网通信设备的媒体客户端体系结构

背景技术

蜂窝式电话网络最初被开发以便主要提供经由线路交换网络的话音服务。尽管线路交换网络仍然被广泛使用，然而目前趋势趋向于分组交换网络，其不仅提供话音服务而且提供高速分组数据服务，用于使移动用户能够在网络上冲浪、读取电子邮件、下载视频和音频文件并且完成因特网用户可以在固定网络上所做的许多其它事情。然而，实时的多媒体在移动式网络中仍然存在问题，这是因为大部分分组数据服务由最佳效果网络提供，所述网络缺少实时多媒体服务所需要的服务质量保证。由于缺乏标准化，网络操作者常常还限于只提供他们的设备销售商所支持的那些IP服务。缺乏标准化还使网络操作者难于从第三方开发者购买捆绑的服务。

IP多媒体子系统(IMS)被开发来提供通用、标准化的体系结构和标准化接口以便在移动式联网环境中提供IP服务。IMS网络不取决于访问技术并且实际上与任何分组交换网络相互操作，所述分组交换网络包括UMTS、cdma2000、GPRS和EDGE网络。IMS使用会话启动协议(SIP)作为服务控制协议，所述会话启动协议(SIP)使操作者能够同时提供多个应用。IMS标准会加速在移动终端上采用IP服务，使用户能够使用移动终端上的单个客户端来经由语音、视频或文本通信。

尽管IMS向移动用户承诺更丰富的体验，然而网络操作者对投资用于实现IMS的设备很犹豫，直到存在足够量的具有IMS能力的订户以便使投资值得进行。目前使用的大部分蜂窝式电话缺乏IMS能力，因此用于IMS服务的潜在订户池相对较小。把IMS能力扩展到缺乏固有IMS能力的传统移动终端可能会向网络操作者提供更宽阔的市场并且鼓励投资IMS技术和装备。

发明内容

本发明涉及一种以网络为中心的媒体客户端，用于向移动终端用户提供SIP和/或IMS能力。媒体客户端可以包括在移动终端内，或者可以位于移动式网络中并且由所述移动终端远程访问。远程访问能力使IMS服务能够被提供给原本缺乏IMS能力的传统移动终端。

媒体客户端包括经由第一网络接口与多媒体应用通信的用户代理、经由第二网络接口与所述用户代理通信的信令代理以及经由第三网络接口与所述用户代理通信的媒体代理。网络接口使得能够进行本地和/或远程访问。用户代理向多媒体应用提供高级应用接口，用于把所述多媒体应用与基础网络协议的细节相隔离。媒体客户端还可以包括JAVA应用接口。信令代理在用户代理的指导下操作并且执行为建立、修改以及终止通信会话所必须的信令任务以用于媒体转送。媒体代理在用户代理的控制下操作并且执行媒体操作，诸如管理媒体连接并且把媒体路由到适当的再现设备。用户代理、信令代理和媒体代理可以一同位于网络内或者可以分布在网络组件之间。

本发明还适用于固定联网通信设备，诸如DVD和CD播放器、数字录像机、摄像机、数字式静物摄影机、扫描器、家庭立体声系统、电视系统和计算机，以便能够经由通信网络在联网通信设备之间进行媒体会话。本发明还可以用来远程控制联网通信设备。

附图说明

图1是其中可以使用本发明的媒体客户端的无线通信网络的功能框图。

图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，不过在图1中只示出了一个。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请求转送到被呼叫方。被呼叫方可以是另一用户或可以是用户家庭网络中的应用服务器。被呼叫方对代理服务器作出响应，所述代理服务器随后把所述响应转送到呼叫方。呼叫方确认所述响应，然后在所述呼叫方和被呼叫方之间建立会话。使用在IETF RFC中所描述的实时转送协议(RTP)或在IETF RFC中所描述的消息会话中继协议(MSRP)以便在呼叫方和被呼叫方之间进行通信。

如果重定向服务器接收SIP请求，那么所述重定向服务器联系位置服务器以便确定通向被呼叫方的路径，继而向呼叫方发送该信息。呼叫方确认接收信息继而向在重定向信息中所标识的服务器(其可以是代理服务器的被呼叫方)重新发送SIP请求。当SIP请求到达被呼叫方时，被呼叫方作出响应并且呼叫方确认该响应。然后通信使用RTP或MSRP开始。只使用SIP来处理与呼叫控制和会话管理相关的信令消息。

如上所述，SIP使移动通信网络10内的应用能够建立通信会话。所述应用可以位于IMS 40的移动终端100或应用服务器中。另外，所述应用可以位于不同的网络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。UA202与用户应用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和MA 206一起集成到单个应用中。在图3所示出的实施例中，在UA 202、SA 204和MA 206之间的网络接口208、210和212使得能够进行这样的实现方式，其中UA 202、SA 204和MA 206可以是在移动通信网络10内分布的独立应用。接口208、210、212可以使用TCP套接字连接或其它类型的网络接口，用于使UA 202、SA 204和/或MA 206能够远离于用户应用150。

分布式处理方法与单片方法相比具有几个优点。媒体客户端200可以位于IMS 40或其它IP网络中的网络服务器中，并且由移动终端100例如使用远程登录来远程访问以便打开套接字连接。从而，可以向本来没有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和NCDB已经跨过通信网络建立了多媒体通信会话。NCD A包括完全功能的媒体客户端200，其与NCD 100中的用户应用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可以位于不同的主机中。在它启动之后，媒体客户端200在例如端口3500之类的指定端口上打开服务器套接字，以便在UA 202和用户应用150之间通信。希望与媒体客户端200通信的任何用户应用150可以在相同的端口上打开客户端套接字。可以在配置文件中指定用于在UA 202和用户应用150之间通信的端口。可以打开不同的端口以便在UA 202和SA 204之间或在所述UA 202和MA 206之间通信。

在一个示例性实施例中，媒体客户端200使用基于文本的接口协议(UA API)以便在用户应用150和所述媒体客户端200之间通信。在用户应用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提供了UAAPI的示例性请求和响应。附录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请求由用户应用150发送给媒体客户端200以便向SIP登记者登记。典型的REGISTER请求采用“register aol.com”或“register msn.com：5050”的形式。响应于REGISTER请求，UA 202命令SA 204执行SIP登记。在向SIP登记者登记之后，SA 204向UA 202发送用于表明登记尝试的状态的消息，例如成功或失败。如果登记成功，那么示例性的REGISTER响应是“register 200：OK”，并且如果所述登记未成功，那么响应为“register 1xx：failed”。下面更详细描述的图5图示了用于登记过程的信号流。

CALL请求由用户应用150发送给UA 202以便与远程设备连接。使用CALL请求来发起RTP或MSRP会话。CALL请求包括用于标识被呼叫方和呼叫类型的信息，诸如用户ID、别名或完全合格的(fullyqualified)网络地址。如果涉及代理，那么CALL请求可以指定被呼叫方的用户ID。如果不涉及代理，那么CALL请求可以给出要连接的远程主机的完全合格的地址和端口。呼叫类型例如可以包括mime类型和子类型，例如视频/h263或音频amr。CALL请求典型情况下采取“call alice video/h263”或“call alice@ims.net：5060video/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请求。

ACCEPT请求由用户应用150响应于CALL请求发送以便命令UA 202接受或拒绝向内呼叫。ACCEPT请求包括用于表明UA 202应当接受或拒绝呼叫的命令以及选择性地包括用于表明例如为什么拒绝呼叫的代码。如果在CALL请求中指定一个以上的呼叫类型，那么用户应用150可以接受其中一个子集并拒绝其余的。为了接受少于所有指定的呼叫类型，用户应用包括ACCEPT请求中所接受呼叫类型的列表。UA202应当接受那些列出的并且拒绝其余的项。如果在ACCEPT请求中没有指定呼叫类型，那么UA 202默认时可以接受在CALL请求中所指定的所有呼叫类型。典型的ACCEPT请求采用“accept yes(接受)”的形式来接受呼叫或者“accept no(不接受)”的形式来拒绝所述呼叫。如果接受少于全部指定的呼叫类型，那么ACCEPT请求具有“accept OK audio/amr”的形式，其指定所接受的呼叫类型。

根据是否成功进行连接，UA 202向用户应用150发送ACCEPT响应。ACCEPT响应包括用于表明是否成功进行连接的状态消息以及选择性地还包括状态代码。典型的ACCEPT响应具有“accept OK”或“accept Failed：1xx”的形式。

MSG请求由用户应用150发送给媒体客户端200以便请求传输消息。MSG请求包括用于标识其中将发送消息的呼叫的呼叫ID或会话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 nnn mime/type\n”的形式，其中xxx是呼叫ID并且nnn是数据缓冲器的长度。二进制信息的例子是“msg 111 43 image/jpg\n31290759...93285”。UA 202向用户应用150发送MSG响应以便表明MSG请求的成功递送或故障。如果消息被成功递送，那么示例性的MSG响应形式为“MSG OK”，并且如果所述消息未被成功递送，那么示例性的MSG响应形式为“MSGFailed：1xx”。

使用HANGUP请求来终止连接。HANGUP请求由用户应用150发送给媒体客户端200或反之亦然。HANGUP请求可以包括单个术语“挂机”或者单个字母“h”以及被分配给正结束的呼叫的呼叫ID。示例性的HANGUP请求的形式为“hangup xxx”，其中xxx是呼叫ID。当HANGUP请求由用户应用150发送给UA 202时，所述UA 202发送HANGUP响应以便确认所述呼叫被结束。HANGUP响应的形式可以为“hangup OK”或者“hangup disconnected”。

SUBSCRIBE请求由用户应用150发送给UA 202以便预订出席服务或其它通知服务。SUBSCRIBE请求包括用于预定服务的地址、用于预订请求的期满时间以及所述预订请求所涉及的事件。SUBSCRIBE请求的典型形式是“subscribe someone@domain.com：3600 tttpresence”或“subscribe someone at his domain.com：3600 tttpresence autofresh”，其中ttt表示在预订请求很短的期满时间。响应于SUBSCRIBE请求，UA 202命令SA 204执行SIP预订过程。在成功地完成SIP预订过程之后，SA 204通知UA 202，所述UA 202随后通过发送SUBSCRIBE响应来通知用户应用150。SUBSCRIBE响应包括用于预定服务的地址、所述预订很短的期满时间和状态消息。期满时间可以不同于所请求的时间。SUBSCRIBE请求选择性地可以包括状态代码和‘autorefresh’命令以便当它期满时自动地刷新所述SUBSCRIBE请求。SUBSCRIBE请求可能由于重定向请求而失败。在这种情况下，SUBSCRIBE响应可以返回新的地址并且UA 202可以使用新的地址来重新预订。如果成功地执行预订，那么SUBSCRIBE响应的形式为“subscribe ttt me@mydomain.com：3600 successful：200”，并且如果所述预订失败，那么所述形式为“subscribe tttme@mydomain.com 3600 failed：481”。

NOTIFY请求从UA 202发送到用户应用150以便向用户应用150通知向用户应用150给出出席通知的出席实体的出席状态改变。NOTIFY请求包括消息大小、用于触发NOTIFY的事件类型、消息主体的mime类型以及消息数据。NOTIFY请求的典型形式为“notify 30someone@hisdomain.com presence application/pidf+xml\alice isnow available”。用户应用150用“Notify OK”作出响应以便确认NOTIFY请求。

PUBLISH请求用于出席服务及其它通知服务。PUBLISH请求由用户应用150发送给媒体客户端200以便当用户的出席状态改变时通知出席服务器。PUBLISH请求包括出席服务器的地址和用于PUBLISH请求的期满时间。PUBLISH请求选择性地可以包括‘autorefresh’命令以便当它期满时自动地刷新所述PUBLISH请求。典型的PUBLISH请求其形式为“publish ttt me@mydomain.com 3600”。如果公布成功，那么UA 202用“publish ttt me@mydomain.com 3600successful：200”来对用户应用150作出响应，并且如果公布失败，那么用“publish ttt me@mydomain.com 3600 failed：481”来作出响应。

附录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请求的形式为“registerserver@network.com”。SA 204响应于REGISTER请求，来依照如IETFRFC 3261所描述的SIP来试图向SIP登记者登记。SA 204向UA 202发送用于表明REGISTER请求的状态的REGISTER响应。如果登记尝试是成功的，那么示例性的REGISTER响应的形式为“register OK”，或者如果登记尝试未成功，那么所述形式为“register failed”。

在呼叫的发起端响应于来自用户应用150的CALL请求，INVITE请求被UA 202发送给SA 204。SAINVITE请求包括被呼叫方的地址或可以被解析为有效地址的用户ID，用于指定将建立的呼叫类型的呼叫类型以及对于每个所指定呼叫类型来说用于媒体会话的主机地址。对于每个呼叫类型可以使用相同的主机地址，或者可以使用不同的地址。示例性的INVITE请求的形式为“invite alice@domain.comvideo/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请求还可以由SA204发送到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请求的主机把SIPNOTIFY请求返回到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向其订户发送NOTIFY请求以便向订户通知出席状态的改变。如果使用独立的出席服务器来分送出席信息，那么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请求、OPEN请求、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请求，MA206依照MSRP来建立连接并且向UA 202发送CONNECT响应。CONNECT响应包括CONNECT请求的状态以及选择性地还包括状态代码。示例性的CONNECT响应的形式为“connect OK”或“connect failed”。

一旦建立MSRP会话，那么就使用SEND请求来发送多媒体消息。当UA 202接收来自媒体客户端200的MSG请求时，UA 202产生SEND请求并把它发送给MA 206。SEND请求包括用于唯一标识呼叫的呼叫ID、消息长度、消息类型和消息数据，在所述呼叫中正发送消息。示例性的SEND请求的形式为“SEND xxx nnn text/plain\n this is thetext”。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发送OPEN请求。OPEN请求选择性地包括远程主机的网络地址，其中将从所述地址接受媒体连接。如果远程主机地址被包括在OPEN请求中，那么只从在OPEN请求中所指定的地址接受媒体连接。响应于OPEN请求，MA 206打开用于媒体连接的端口并且返回用于表明媒体连接的网络地址和端口的OPEN响应。OPEN响应表明OPEN请求的状态，并且如果成功的话，那么包括为RTP连接所打开的主机和端口的网络地址。

一旦建立媒体连接，那么在呼叫的发起端的UA 202向MA 206发送PEER请求以便向MA 206提供在另一端为RTP会话所打开的主机地址和端口。PEER请求的唯一参数是用于媒体连接的网络地址和端口。不要求对PEER地址请求的响应。示例性的PEER请求的形式为“PEERsomeone@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 100尝试)返回到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 INVITESDP主体中所表明的地址发送消息。

本发明使在端点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根据它从UA202所接收的信息来构造SIP INVITE请求，以利用按完整SIP INVITE请求所要求的默认设置来扩充此信息。SA 204向端点B发送SIPINVITE请求(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发送用于表明所述SA 204正在“呼唤(ringing)”在端点B的用户的临时响应(g)。在端点A的SA 204随后可以向UA 202发送临时的STATUS响应(k)以向在端点A的UA 202提供呼唤指示。在端点A的UA 202在一些应用中可以向用户应用150提供临时的状态信息(l)以便向用户通知正尝试到达在端点B的用户。

响应于INVITE请求，在端点B的UA 202向用户应用150发送CALL请求(i)以便向用户应用150通知接收了对MSRP会话的邀请。CALL请求包括用于标识呼叫方和呼叫类型的信息。用户应用150为了应答CALL请求而发送用于表明用户是否希望回答呼叫的ACCEPT请求(j)。在此例子中，在端点B的用户接受所述邀请。如果呼叫涉及一种以上类型的媒体，那么在端点B的用户在ACCEPT请求中指定接受哪个媒体。然后在端点B的UA 202向MA 206发送CONNECT请求(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发送CONNECT响应(Connect 200 OK)以便表明成功地建立了媒体连接(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请求中被传递给UA202(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 OK)来确认收到消息(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)。UA202向用户应用150发送HANGUP响应(mm)以便向用户应用150通知媒体会话被关闭，并且向MA 206发送CLOSE请求(nn)以便关闭为所述媒体会话所打开的连接。在端点B的SA 204产生BYE请求(oo)并且把所述BYE请求转送到UA 202，其用于表明MSRP会话已经被关闭。类似地，在端点B的UA 202向用户应用150发送HANGUP请求(pp)以便向用户应用通知MSRP会话被关闭，并且向MA 206发送CLOSE请求以便关闭为所述媒体会话所打开的连接(qq)。

图7图示了在端点A和B之间的示例性RTP会话。在图7中所图示的过程使用在附录的表1-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建立连接的临时响应(f)。

一旦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会话的邀请。此请求包括由MA206在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的UA202向在端点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发送CLOSE请求(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通过处理通常在J AVA应用中所发现的信令和操作任务来使JAVA应用更易于写入。因为JAVA应用不会直接访问更低级的协议，诸如SIP和SDP，所以相同的JAVA应用有更好的机会在不同的操作者网络中以及在不同的移动终端中工作。此外，劣质JAVA应用在网络内造成问题的机会变得更小。JAVA应用还不必担心直接访问低级协议所带来的配置和部署问题。作为替代，配置和部署问题由媒体客户端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内部或外部。MAAPI包括相应的SETROUTE请求，其由UA 202发送到MA 206以便配置用于指定将怎样路由媒体流的路由表。UA API和MA API还可以包括用于控制媒体流的其它请求，诸如用于暂停活动媒体流的PAUSE请求和用于恢复所暂停媒体流的RESUME请求。

图11和12图示了其中可以使用本发明的媒体客户端200的各个方式。图11图示了三个网络通信设备——移动设备100、摄像机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建立信令连接。在移动设备100、摄像机300和视频播放器之间的通信在因特网或其它通信网络12上是对等的。

为了发起媒体会话，移动设备100中的应用150使用在图7中所示出的过程。应用150通过向UA 202发送CALL请求来发起媒体会话，所述UA 202也位于移动设备100中。移动设备100中的UA 202向远程视频播放器350中的MA 206发送OPEN请求以便打开用于RTP会话的UDP套接字连接。经由TCP套接字连接来发送OPEN请求。应当注意，在此例子中移动设备100控制远程定位的MA 206。视频播放器350中的MA 206把用于RTP连接的网络地址和端口返回到移动设备100中的UA 202。UA 202通过向SA 204发送INVITE请求来命令SA 204建立RTP会话。SA204也位于移动设备100中。INVITE请求包括由视频播放器350中的MA206所提供的网络地址和端口。由视频播放器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播放器400。遥控指令被作为文本消息从移动设备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播放器流送到家庭计算机以便所述音频可以被记录并存储在所述家庭计算机上。作为另一例子，本发明可以用来把视频和/或音频从便携式摄像机流送到家庭计算机以便把所述视频和/或音频记录并存储在所述家庭计算机上。

当然在不脱离本发明的精神和本质特征的情况下可以依照除这里所阐明的那些之外的其它具体方式来实施本发明。因此本实施例在各个方面将被认为是说明性的而并非是限制性的，并且在所附权利要求的意思和等效范围内的所有变化都旨在包含在本发明的范围内。

Claims (36)

1.一种用于联网通信设备(100)的媒体客户端(200)，包括：

用户代理(202)，用于与所述联网通信设备(100)中的多媒体应用(150)通信；

第一网络接口(208)，用于在所述用户代理(202)和多媒体应用(150)之间通信；

信令代理(204)，在所述用户代理(202)的控制下执行信令操作以便建立并终止通信会话；和

媒体代理(206)，在所述用户代理(202)的控制下发送并接收多媒体消息。

2.如权利要求1所述的媒体客户端(200)，其中所述用户代理(202)远离于所述多媒体应用(150)。

3.如权利要求2所述的媒体客户端(200)，其中所述用户代理(202)位于网络服务器(40)中。

4.如权利要求1所述的媒体客户端(200)，进一步包括第二网络接口(210)，用于在所述用户代理(202)和信令代理(204)之间通信。

5.如权利要求4所述的媒体客户端(200)，其中所述信令代理(204)远离于所述多媒体应用(150)。

6.如权利要求5所述的媒体客户端(500)，其中所述信令代理(204)位于网络服务器(40)中。

7.如权利要求4所述的媒体客户端(200)，其中所述信令代理(204)远离于所述用户代理(202)。

8.如权利要求4所述的媒体客户端(200)，进一步包括第三网络接口(212)，用于在所述用户代理(202)和媒体代理(206)之间通信。

9.如权利要求8所述的媒体客户端(200)，其中所述媒体代理(206)远离于所述多媒体应用(150)。

10.如权利要求9所述的媒体客户端(200)，其中所述媒体代理(206)位于网络服务器(40)中。

11.如权利要求9所述的媒体客户端(200)，其中所述媒体代理(206)远离于所述用户代理(202)。

12.如权利要求8所述的媒体客户端(200)，其中所述第一、第二和第三网络接口(208，210，212)包括TCP连接。

13.如权利要求1所述的媒体客户端(200)，其中所述用户代理(202)、信令代理(204)和媒体代理(206)位于通信网络(10)的网络服务器(40)内，并且其中所述多媒体应用(150)位于所述联网通信设备(100)中并且远程访问所述媒体客户端(200)。

14.如权利要求8所述的媒体客户端(200)，其中所述信令代理(204)和媒体代理(206)位于通信网络(10)的网络服务器(40)内，并且其中所述用户代理(202)位于所述联网通信设备(100)中并且远程访问所述信令和媒体代理(204，206)。

15.如权利要求1所述的媒体客户端(200)，其中所述媒体代理(206)响应于来自所述多媒体应用(150)的命令来有选择地在所述多媒体应用(150)和一个或多个媒体播放器(300，350)之间路由媒体流。

16.如权利要求1所述的媒体客户端(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)位于所述网络服务器(40)中并且经由第一网络接口(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)中。

Images