专利名称：经通信网络远程控制媒体装置的方法
经通信网络远禾呈控制媒体装置的方法发明背景移动和IP网络的融合使业务提供商能够向移动用户提供以前 只可供诸如因特网等固定网络中的用户使用的新IP业务。此外， 移动和IP网络的融合将使诸如蜂窝电话和个人数字助理等移动装 置能够与其它网络装置通信。这种融合将允许以新方式使用移动装 置，以增强移动装置的利用，丰富用户体验。移动装置的一个可能 使用是远程控制媒体装置，如^ 某体记录器(例如录像机和录音机)、 媒体播放器(例如视频和音频播放器)和媒体存储装置。发明内容本发明涉及经诸如因特网等通信网络的媒体装置远程控制。远 程装置和媒体装置均包括管理媒体连接的媒体代理。远程装置与受 到控制的媒体装置建立媒体会话。在媒体会话上下文中媒体装置将 控制消息作为多媒体消息发送到媒体装置。在一个示范实施例中，媒体装置可建立并发媒体会话。并发会 话中的一个会话建立在媒体装置与远程装置之间，以便将控制命令 从远程装置发送到媒体装置。另 一并发会话用于向或从媒体装置发 射媒体。第二媒体会话可与远程装置或与另一装置建立。
图1是可使用本发明媒体客户端的无线通信网络的功能框图。图2是示出移动通信网络中IP多媒体子系统(IMS)基本组件的 框图。图3示出根据本发明的媒体客户端的体系结构。 图4示出实现i某体客户端的各种方法。
图5是示出SIP登记过程的呼叫流程图。图6是示出MSRP ^S舌的呼叫流程图。 图7是示出RTP会话的呼叫流程图。图8示出具有JAVA应用接口的々某体客户端的备选实施例。图9和图IO示出根据本发明的媒体内容选择性路由。图11示出一个应用，其中本发明用于在视频服务器与远程视频播放器之间建立媒体会话。图12示出一个应用，其中本发明用于远程控制DVD播放器并将媒体从远程DVD播放器流式传输到移动通信装置。具体实现方式图1示出可采用本发明的移动通信网络10。虽然本发明在移 动通信网络10的上下文中描述，但本领域的技术人员将理解，本发明也可在固定网络中用于固定连网通信装置之间的通信。术语"连 网通信装置"在本文中使用时包括能够通过诸如因特网等网络通信 的任何装置。移动通信网络10包括无线电接入网络(RAN)20、核心网络(CN) 30和IP多媒体子系统(IMS) 40。 RAN 20支持通过空中接口与移动 终端100的无线电通信。移动终端100是如本文中使用的该术语表 示的连网的通信装置。移动通信网络10 —般包括不止一个RAN 20, 但图1中只显示了一个RAN。 CN 30为诸如WEB浏览和电子邮件 等分组交换业务提供到因特网12或其它分组数据网络(PDN)的连 接，并可为诸如话音和传真业务等电路交换业务提供到公共交换电 话网络(PSTN) 14和/或综合数字业务网络(ISDN) 16的连接。CN 30 例如可包括通用分组无线电业务(GPRS)网络、CDMA2000网络或 UMTS网络。CN 30包括与IMS 40互连的接入网关32。接入网关 32可包括用于GPRS网络的GPRS网关服务节点(GGSN)或用于 CDMA2000网络的分组数据服务节点(PDSN)。 IMS 40将接入独立、
基于IP的多媒体业务提供到移动终端100，并支持各种IP业务， 包括基于IP的话音(VoIP)、视频和音频流式传输、电子邮件、WEB 浏览、视频会议、即时消息传递、存在和其它业务。IMS 40使用开放接口和诸如会话启动协议(SIP)等接入独立的 会话控制协议(SCP)支持多媒体应用。会话描述协议(SDP)用于媒体 协商。SDP在IETF RFC 2327和3264中描述。SIP是用于在一个或 多个参与者之间建立、修改和终止通信会话的会话控制协议。这些 会话例如可包括因特网多媒体会议、因特网电话呼叫和多媒体分 发。SIP在IETF文档RFC 3261中描述。虽然如本文中所述的本发 明优选实施例使用SIP，但本领域的技术人员将理解，本发明也可 使用其它SCP。类似于SIP的另一公知协议是H. 323。 SIP的细节 不是本发明的内容，但下面提供了 SIP的简要概述以便更好地将本 发明置于上下文中。SIP是一种信令协议，其l吏用基于ASCII的信令消息在两个或 更多个参与者之间建立通信会话。用户通过在本文中称为SIP地址 的唯一地址标识。用户使用其指定的SIP地址向登记员服务器登记。 登记员服务器在请求时将此地址提供到位置服务器。用户启动呼叫时，SIP请求发送到SIP服务器(代理服务器或重 定向服务器)。请求包括在消息标题中的主叫方地址和被叫方地址。 如果代理服务器接收SIP请求，它将SIP请求转发到被叫方。被叫 方可以为另一用户，或者可以为用户的归属网络中的应用服务器。 被叫方响应代理服务器，而代理服务器又将该响应转发到主叫方。 主叫方确认该响应，随后在主叫方与被叫方之间建立会话。IETF RFC 中所述的实时传送协议(RTP)或正TF RFC中所述的消息会话中继协 议(MSRP)用于主叫方与#皮叫方之间的通信。如果重定向服务器接收到SIP请求，则重定向服务器联系位置 服务器以确定到被叫方的路径，并随后将该信息发送到主叫方。主 叫方确认信息的接收，并随后将SIP请求重新发送到在重定向信息
中标识的服务器(其可能为代理服务器的被叫方)。当SIP请求到达 被叫方时，被叫方做出响应，并且主叫方确认该响应。随后，使用RTP或MSRP开始通信。SIP只用于处理与呼叫控制和会话管理有 关的信令消息。如上所述，SIP使移动通信网络10内的应用能够建立通信会 话。该应用可位于移动终端100中或IMS 40中的应用服务器中。 另外，该应用可位于不同的网全各10中。图2示出IMS 40的基本部件及其与CN 30的关系。IMS 40包 括通过IP网络互连的一个或多个呼叫状态控制功能(CSCF) 42、媒 体网关控制功能(MGCF) 44、樣体网关(MGW) 46、传输信令网关 (T-SGW) 48以及归属用户服务器(HSS) 50。 IMS 40还可包括向移 动终端100提供多媒体业务的应用服务器52。 CSCF 42充当SIP服 务器，以处理用于建立、修改和终止通信会话的会话控制信令。CSCF 42执行的功能包括呼叫控制、地址转换、认证、能力协商及用户简 档管理。HSS 50与CSCF 42对接以提供有关用户的当前位置和预 订信息的信息。应用服务器50向移动终端100提供多媒体业务或 其它IP业务。MGCF 44、 MGW46和T-SGW48支持与诸如PSTN 或ISDN等外部网络的互连。MGCF 44控制管理外部网络与IMS 40 之间连4妄的一个或多个MGW 46。 MGCF 44配置MGW 46，并将SIP 消息转换为不同的格式，诸如ISDN用户部分(ISUP)消息。MGCF 44 将转换的消息转发到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看来是可通过简单地打开、关闭、 读和写命令操控的简单数据流，也称为管道。图3示出媒体客户端200的基本体系结构。i某体客户端200包 括用户代理(UA)202、信令代理(SA) 204和媒体代理(MA) 206。 UA 202与用户应用150通信，并将应用命令转换为适当的信令和媒体 操作。SA 204和MA 206在UA202的控制和指导下操作。UA 202 对连接管理有全面的控制，并分别将信令和媒体管理任务委托给SA 204和MA 206。在所示实施例中，SA 204实现SIP和SDP协议以 处理信令任务。SA 204使用基于IP的UDP传输消息。诸如H.323 等其它会话控制协议也可使用。信令任务包括建立、修改和取消通 信会话、协商会话参数、询问远程装置以确定能力以及存在检测。 MA 206实现消息会话中继协议(MSRP)和实时传输协议(RTP)，并 包括一 个或多个媒体播放器以处理媒体和输出媒体到媒体再现装 置。MA 206管理媒体连接，根据媒体类型和用户设置路由媒体， 并调用媒体播放器以根据需要处理媒体。MA206使用TCP和/或基 于IP的UDP传输RTP和MSRP消息。在一些实现中，可采用单片方案，在单个应用中将UA202、 SA 204和MA 206集成在一起。在图3所示实施例中，UA202、 SA204 和MA206之间的网^4妄口 208、210和212允许其中UA202、SA204 和MA 206可以为分布在移动通信网络10内的单独应用的实现。 接口 208、 120、 212可4吏用TCP插口连接或其它类型网络接口 ， 允许从用户应用150远程定位UA 202、 SA 204和/或MA 206。分布式方案与单片方案相比有几个优点。媒体客户端200可位 于IMS 40或其它IP网络中的网络服务器中，并可由移动终端100
例如使用TELNET打开插口连接而远程访问。因此，IMS业务可提 供到无固有IMS能力的移动终端100。 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的分开也允许独立i某体(例如TV)和控制(例 如远程控制)装置的优化实现。图4示出媒体客户端200的一些可能布置。在图4中，NCDA 和NCD B跨通信网络建立了多媒体通信会话。NCD A含有与NCD IOO中用户应用150通信的功能全面的J^某体客户端200。 NCDB缺 少固有的IMS能力，并使用位于网络10内的远程媒体客户端200 的业务。这种情况下，位于NCD B中的用户应用150可通过例如 TELNET等TCP插口连接与位于网络服务器中的媒体客户端200向NCD B提供相同的功能。远程访问媒体客户端200的能力使得 将IMS业务扩展到传统移动终端成为可能，这又为网络运营商提供 了值得在IMS技术中投资所必需的临界质量。NCD C含有与连网 通信装置100中用户应用及位于网络中的SA 204和MA 206通信 的UA 202。媒体客户端200实现为在诸如PC或移动终端100等主机装置 上运行的进程。主机装置包括存储实现本发明的代码的存储器、执 行代码的一个或多个孩i处理器以及提供网络接入的通信接口 。 UA 202、 SA 204和MA 206可位于不同主机中。在主机启动后，媒体 客户端200打开指定端口例如端口 3500上的服务器插口，用于在 UA 202与用户应用150之间通信。要与力某体客户端200通信的任 一用户应用150可打开同一端口上的客户端插口。用于在UA 202
和用户应用150之间通信的端口可在配置文件中指定。对于UA202 与SA 204之间或UA 202与MA 206之间的通信，可打开不同的端 口 。在一个示范实施例中，媒体客户端200对于用户应用150与媒 体客户端200之间的通信使用基于文本的接口协议(UA API)。用户 应用150与々某体客户端200之间的所有通信都通过文本字符串读取 并写到TCP插口。 IMS协议4吏用两种类型的通信消息-请求和响 应。用户应用150—般发送请求到UA202以启动事务处理，但UA 202也可发送请求到用户应用150。请求一般具有由空格隔开的参 数。UA 202 —^:响应该请求发送响应到客户端。响应有两种临 时和最终。临时响应不结束由对应请求启动的事务处理。最终响应 终止事务处理。UA 202与SA 204之间的应用接口(SA API)和UA 202与MA 206之间的应用接口 (MA API)类似于UA API也使用基于文本的接 口协议。UA 292要求SA 204或MA 206采取动作的请求启动UA 202 与SA 204或MA 206之间的事务处理。附录A中的表1记录了用 于UAAPI的示范请求和响应。附录B中的表2记录了用于SA API 的示范请求和响应。附录C中的表3记录了用于MA API的示范请 求和响应。UA API中的主要请求是登记请求、呼叫请求、MSG请求、接 受请求、桂断请求、预订请求、通知请求及公布请求。登记请求、 预订请求、通知请求及公布请求对应于标准SIP请求，但为用户应 用150提供更级的抽象化。登记请求由用户应用150发送到i某体客户端200，以向SIP登 记员登记。典型的登记"i貪求为"register aol.com"或"register msn.com: 5050"形式。响应登记请求，UA 202指示SA 204执行SIP登记。 在向SIP登记员登记后，SA 204发送消息到UA 202，指示登记尝 试的状态，例如成功或失败。示范登记响应在登记成功时为"register
200:OK",并在登记未成功时为"register lxx:failed"。下面更详细描 述的图5示出了登记过程的信号流。呼叫请求由用户应用150发送到UA 202以连接远程装置。呼 叫请求用于启动RTP或MSRP会话。呼叫请求包括标识被叫方和 呼叫类型的信息，如用户ID、別名或完全限定的网络地址。涉及到 代理时，呼叫请求可指定被叫方的用户ID。未涉及代理时，呼叫请 求可提供要连接到的远程主机的完全限定的地址和端口。呼叫类型 例如可包括MIME类型和子类型，例如video/h263或audio/amr。 呼叫请求一^殳采用"ca11 alice video/h263，，或"ca11 alice@ims.net:5060 video/h263，，或"ca11 10.0.0.1:5060 video/h263，，的形式。在单个呼叫请 求中可包括不止一个呼叫类型。视呼叫请求的结果而定，UA 202 发送呼叫响应，指示呼叫请求的结果或状态。示范呼叫响应在连接 成功建立时为"call connected",或在连接未成功时为"call failed"。 呼叫响应可选择包括提供另外信息的状态代码，如指示呼叫请求不 成功原因的错误代码。连接成功时，用户应用150可开始通过RTP 或MSRP连接发送和接收媒体和/或消息。在有呼入时，呼叫请求也可由UA 202发送到用户应用150。 这种情况下，呼叫请求包括标识主叫方而不是被叫方的信息。其它 情况下，呼叫请求是相同的。标识主叫方的信息可包括被叫方的用 户ID或远程主机的完全限定的地址。当呼叫请求从UA202发送到 用户应用150时，用户应用150不发送呼叫响应。相反，用户应用 150发送终止呼叫请求的接受请求。接受请求由用户应用150响应呼叫请求而发送，以指示UA202 接受或拒绝呼入。接受请求包括指示UA 202应接受或拒绝呼叫的 命令，并可选择包括指示例如拒绝呼叫的原因的代码。如果在呼叫 请求中指定了不止一种呼叫类型，则用户应用150可接受子集并拒 绝其余的。为了接受并非所有指定呼叫类型，用户应用在接受请求 中包括已接受呼叫类型的列表。UA 202应接受那些列出的并拒绝
其余的。如果接受请求中未指定呼叫类型，则UA 202默认可接受 在呼叫请求中指定的所有呼叫类型。典型的接受请求形式为接受呼 叫的"accept yes"或拒绝呼叫的"accept no"。如果并非所有指定的呼 叫类型都被接受，则接受请求具有的形式为"accept OK audio/amr"， 其指定接受的呼叫类型。一见连接是否成功建立而定，UA 202将接受响应发送到用户应 用150。接受响应包括指示连4妄是否成功建立的状态消息，并可选 择包括状态代码。典型的接受响应具有的形式为"accept OK"或 "accept Failed: 1 xx"。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"。对于二进制lt据，MSG请求形式为 "msg xxx nnn mime/type\n",其中xxx为呼叫ID, 并且nnn为数据 緩冲区长度。二进制消息的示例为"msg 111 43 image/jpg\n31290759...93285"。 UA 202发送MSG响应到用户应用 150,以指示MSG请求的成功输送或失败。示范MSG响应形式在 消息成功输送时为"MSG OK",并在消息未成功输送时为"MSG Failed: 1 xx，'。挂断请求用于终止连接。挂断请求可由用户应用150发送到媒 体客户端200,或反之亦然。挂断请求可包括单个词"hang-up，，或单 个字母"h"和指定到被结束呼叫的呼叫ID。示范挂断请求形式为 "hangup xxx",其中xxx为呼叫ID。当挂断请求由用户应用150发 送到UA 202时，UA 202发送桂断响应以确认呼叫;陂结束。挂断响 应形式可以为"hangup OK，，或"hangup disconnected"。
预订请求由用户应用150发送到UA 202,以预订存在业务或 其它通知业务。预订请求包括予贞订业务的地址、预订请求的截止时 间以及与预订请求有关的事件。预订请求的典型形式为"subscribe someone@domain.com:3600 ttt presence"或"subscribe someone at his domain.com:3600 ttt presence autofresh"，其中ttt表示以秒计的予贞订 请求的截止时间。响应于预订^清求，UA 202指示SA 204执行SIP 预订过程。在SIP预订过程成功完成后，SA 204通知UA 202，而 UA 202又通过发送预订响应而通知用户应用150。预订响应包括预 订业务的地址、以秒计的预订的截止时间和状态消息。截止时间可 能与请求的不同。预订请求可选择包括状态代码和"自动刷新"命 令，以便在预订请求截止时自动刷新该请求。预订请求可能由于重 定向请求而失败。在这种情况下，预订响应可返回一个新地址，并 且UA 202可使用新地址重新预订。预订响应形式在预订成功执行 时为"subscribe ttt me@mydomain.com:3600 successful:200"， 并在子贞 订失败时为"subscribe ttt me@mydomain.com 3600 failed:481"。通知请求/人UA202发送到用户应用150，以通知用户应用150 存在实体的存在状态变化，向用户应用150提供存在通知。通知请 求包括消息大小、触发通知的事件类型、消息体的MIME类型及消 息凄丈寺居。通知"i,求的典型形式为"notify 30 someone@hisdomain.com presence application/pidf+xml\alice is now available"。 用户应用150 用"notify OK，，响应，以确认通知请求。公布请求用于存在业务和其它通知业务。在用户的存在状态变 化时，公布请求由用户应用150发送到i某体客户端200，以通知存 在服务器。公布请求包括存在服务器的地址和公布请求的截止时 间。公布请求可选择包括"自动刷新，，命令，以便在公布请求截止时 自动刷新该请求。典型的公布请求采用的形式为"publish ttt me@mydomain.com 3600"。 UA 202对用户应用150的响应在公布 成功时为"publish ttt me@mydomain.com 3600 successful:200", 并在
乂>布失败时为"publish ttt me@mydomain.com 3600 failed:481"。附录B中的表2描述了在SA API中使用的请求和响应。主要 请求包括登记请求、邀请请求、ACK请求、预订请求、通知请求、 公布请求以及再见请求，这些i青求对应于标准SIP请求。登记请求 用于向SIP登记员登记。邀请和ACK请求用于建立SIP会话。预 订、通知和公布请求用于实现存在业务或其它通知业务。再见请求 用于终止SIP会话。SA API中使用的一些请求对应于公共SIP请求 并使用相同的名称。这从引用:^青求的上下文应明白。然而，为避免 混淆，前缀SIP用于标识向M人SA 204发送的标准SIP请求和响应。登记请求/人UA 202发送到SA 204，以响应用户应用150的对 应登记请求。登记请求包括SIP登记员或SIP代理的网络地址并可 选包括其端口。登记请求形式为"register server@network.com"。 SA 204响应登记请求，尝试在IETF RFC 3261中所述根据SIP向SIP 登记员登记。SA 204发送登记响应到UA 202,指示登记请求的状 态。示范登记响应的形式在登i己尝试成功时为"register OK"，或在 登记尝试不成功时为"register failed"。邀请请求由UA 202发送到SA 204，以响应在呼叫始发端用户 应用150的呼叫请求。SA邀请请求包括可解析为有效地址的被叫 方地址或用户ID、指定要建立的呼叫类型的呼叫类型、以及用于每 个指定呼叫类型的媒体会话的主机地址。每个呼叫类型可使用相同 的主机地址，或者可使用不同的地址。示范邀请请求形式为"invite alice@domain.com video/h263 me@mydomain.com:xxx audio/amr me@mydomain.com:xxx，，, 其中xxx指示端口号。在发送邀请请求 后，UA202等待来自SA204的响应。SA204响应邀请请求，发送 SIP邀请请求到在邀请请求中指定的被叫方，并等待响应。连接成 功建立时，SA 204发送邀请响应到UA 202,指示邀请被接受。邀 请响应包括在本文中称为呼叫ID的会话标识符。邀请i青求也可由SA 204发送到UA 202,以响应在呼叫接收端
接收到SIP邀请。在这种情况下，邀请请求包括用于信令的主叫方 地址和由主叫方用于媒体会话的地址。除未包括会话标识符以外，从UA 202到SA 204的邀请响应与如上所述相同。在这种情况下， 在SA 204从主叫方接收到SIP ACK后，会话标识符在ACK请求 中从SA 204发送到UA 202。预订请求由UA 202发送到SA 204,以启动对存在业务或其它 通知业务的预订。预订请求包括用户要接收其存在状态信息的一方 的地址或存在服务器的地址。SA 204在从UA 202接收到预订请求 时，发送SIP预订请求到在SA预订请求中指定的主机，并等待响 应。SIP预订请求发送到的主才几将SIP通知请求返回到SA204。 SIP 通知请求指示SIP预订请求是否被认证，并且如果是，则包括当前 存在状态信息。SA 204确认SIP通知请求，并将包含存在代理的 存在状态信息的通知请求发送到UA 202。直到预订截止，授权预 订的存在代理每当存在状态信息变化时发送SIP通知请求，并且SA 204将对应的通知请求发送到UA 202，以将存在信息转发到UA 202。在用户的存在状态有变化时，公布请求由UA 202发送到SA 204 以通知存在服务器。如果SA 204正在充当存在服务器，则SA 204 将通知请求发送到其用户，以通知用户存在状态的变化。如果单独 的存在服务器用于分发存在信息，则SA 204将对应的SIP公布请 求发送到存在服务器。在发送SIP公布请求后，SA 204将公布响 应发送到UA202，指示公布i會求的状态。再见请求由UA 202发送到SA 204,或反之亦然，以终止SIP 会话。当SA 204从UA 204 4妄收再见请求时，它将SIP再见请求 发送到另一方以终止会话。 一旦SIP再见请求;陂确i人，SA 204便 将再见响应发送到UA 202以确认再见请求。在UA 202从SA 204 接收再见请求时，它关闭为在再见请求中指定的呼叫打开的连接。 这种情况下，由于再见请求是必须遵循的，因此无需对再见请求的响应。附录C中的表3描述MA API。 MA API中的主要请求包括接 听请求、连接请求、发送请求、打开请求、对等i青求及关闭请求。接听请求由UA 202发送到MA 206,以启动用于多i某体消息 传递的MSRP会话。UA 202发送接听请求，以响应用户应用150 请求MSRP会话的呼叫请求。接听请求可选择包括可从中进行连接 的远程主机的地址。当远程主机在接听请求中指定时，将只接受来 自指定主机的连接。响应接听请求，MA 206打开用于媒体连接的 端口，并将接听响应发送到UA 202，提供用于媒体连接的地址和 端口 。连接请求在呼叫接收端由UA 202发送到MA 206以建立MSRP 连接。连接请求一般在呼叫接收端的用户接受主叫方加入呼叫的邀 请后发送。连接请求包括主叫方在SIP邀请中指定的网络地址和端 口。 示范连接请求形式为"connect anybody@domain.com"。 响应连 接请求，MA206根据MSRP建立连接，并发送连接响应到UA 202。 连接响应包括连接请求的状态，并可选择包括状态代码。示范连接 响应形式为"connect OK"或"connect failed"。发送请求用于一旦MSRP会话建立便发送多媒体消息。UA 202 从媒体客户端200接收MSG请求时，UA 202生成发送请求并将其 发送到MA 206。发送请求包括唯一标识在发送消息的呼叫的呼叫 ID、消息长度、消息类型和消息数据。示范发送请求形式为"sendxxx nnn text/plain\n this is the text"。 MA 206又才艮据MSRP发送消息。 消息被确认时，MA 206将发送响应发送到UA 202，标识呼叫并指 示发送请求的状态。发送请求可选择包括状态代码。示范发送响应 形式为"sendxxxOK"，指示成功输送，或者为"send xxx failed",指 示消息未成功输送。打开请求用于启动RTP会话。UA 202将打开请求发送到MA 206,以响应用户应用150的接受请求。打开请求可选择包括将接
受媒体连接的远程主机的网络地址。如果远程主机地址包含在打开 请求中，则将只接受来自打开请求中指定的地址的媒体连接。响应打开请求，MA 206打开用于4某体连接的端口并返回打开响应，指 示用于媒体连接的网络地址和端口 。打开响应指示打开请求的状 态，并在成功时包括用于RTP连接的主机网络地址和打开的端口 。一旦媒体连接建立了，在呼叫始发端的UA 202便将对等请求 发送到MA 206,以向MA 206提供在另 一端用于RTP会话的主机 地址和打开的端口 。用于对等请求的唯一参数是用于媒体连接的网 络地址和端口。无需对对等地址请求做出响应。示范对等请求形式 为"peer someone@domain.com，，。关闭请求用于终止用于RTP或MSRP会话的媒体连接。UA 202 将关闭请求发送到MA206,以响应用户应用150的挂断i青求。UA、 SA和MA API也可具有设置请求，以允许在初始化期间 预配置某些参数。设置请求包括参数名称和分配给所命名参数的 值。设置请求可用于配置用户特定的设置，如用户名、别名、联系 地址和对不同媒体的默认源和宿。图5到图7是示出多媒体应用如何使用IMS命令和响应的呼 叫流程图。图5示出典型的SIP登记过程。图6是示出示范MSRP 会话的呼叫流程图。图7是示出示范RTP会话的呼叫流程图。图5是示出SIP登记过程的呼叫流程图。在图5中，用户A在 向SIP登记员登记。用户A的用户应用150使用表1所示的API， 将登记请求发送到UA 202(a)。 UA 202接收请求，添加用户特定的 配置数据，并将登记请求转发到SA 204。用户特定的配置数据可包 括诸如用户名、别名和联系地址等数据。响应登记请求，SA204启 动SIP登记过程。SA 204从UA 202接收的信息构建SIP登记请求， 将此信息增加有完整SIP请求所需的默认设置。SA 204将SIP登 记请求发送到SIP登记员(c)。 IMS核心40可将临时SP响应(SIP 100 尝试)返回到SA 204(d),以阻止不必要的SIP请求重新传输。因此，
SA 204无需采取动作。如果登i己成功，则SIP登记员将SIP响应(SIP 200 OK)发送到SIP代理(f)，并且SIP代理将SIP登记员的响应中 继到SA 204 (g)。 SA 204将SA响应发送到用户代理(h)，其通知用 户应用150登记成功。用户A现在能够使用其登记的ID发送和接 收SIP消息。图6示出在两个用户之间典型MSRP会话中的呼叫流程。MSRP 会话是可使用发送请求交换一系列消息的上下文。MSRP通过诸如 TCP等可靠的传输协议，在会i舌模式中提供端对端消息传输。MSRP 会话以SIP作为消息载体，使用SDP提供应答模型(正TF RFC 3264) 建立。简而言之，端点A可通过发送带有表示端点A的临时地址 的消息(SIP邀请)，启动与端点B的通信会话。如果端点B要加入 会话，则它打开到端点A的TCP连接，并发送寻址到端点A提供 的地址的MSRP访问请求。在访问会话后，端点B发送对SIP邀请 请求的应答。应答包含用于通^f言会话的端点B地址。在此交换后， 端点A和B可交换消息。消息通过发送请求发送，并且接收端点 通过OK回复响应。端点A和B通过由MSRP访问请求建立的TCP 连接，将消息发送到在SIP邀请SDP消息体中所指示的地址。本发明将在端点A和B的用户应用与MSRP、 SIP和SDP的 细节隔离，如图6所示，这由UA 202、 SA 204和MA 206处理。 图6所示的过程使用附录中表1-3中定义的API。用户应用150通 过将呼叫请求发送到媒体客户端200 (a)而启动MSRP会话。响应呼 叫请求，UA 202将MA接听i青求(b)发送到MA 206，指示MA 206 打开TCP插口，以接受来自呼叫请求中指定的对等的TCP连接。 MA 206将包括用于媒体连接的主机网络地址和打开的端口的MA 接听响应(c)发送到UA 202。 UA 202随后通过将SA邀请请求(d)发 送到SA 204,指示SA 204启动通信会话。SA邀请请求包含在呼 叫请求中包括的参数和MA 206为媒体连接提供的网络地址和端 口。 SA邀请可选择包括用户特定的配置数据，诸如用户名、别名 等。用户指定的配置数据的参凄t值也可通过使用在表1中所示的设 置请求，由用户应用150设置。SA 204使用常规SIP信令建立MSRP会话。SA 204从UA 202 接收的信息构建SIP邀请请求，将此信息增加有完整SIP邀请请求 所需的默认设置。SA 204将SIP邀请请求(e)发送到端点B。 SIP邀 请请求包括描述多媒体会话的SDP(会话描述协议)体。在等待端点 B的SA 204的响应的同时，在端点A的SA 204可从网^^妄收临时 SIP响应("IOO尝试")(f),指示网络正在尝试与端点B建立连接。一旦在端点B的SA 204接收了 SIP邀请请求，它便将SA邀 请请求发送到UA 202 (h)，并可将临时响应(g)发送到在端点A的SA 204,指示SA 204正在"拨打"端点B的用户。在端点A的SA 204 又可将临时状态响应(k)发送到UA 202,以向在端点A的UA 202 提供拨打指示。在端点A的UA202在一些应用中可向用户应用150(1) 提供临时状态信息，以通知用户正在尝试接通在端点B的用户。响应邀请请求，在端点B的UA 202将呼叫请求(i)发送到用户 应用150,以通知用户应用150收到了对MSRP会话的邀请。呼叫 请求包括标识主叫方和呼叫类型的信息。用户应用150在对呼叫请 求的回复中发送接受请求(j),指示用户是否想应答该呼叫。在此示 例中，在端点B的用户接受邀请。如果呼叫涉及不止一种媒体类型， 则在端点B的用户在接受请求中指定接受哪种J 某体。在端点B的UA 202随后将连接请求(m)发送到MA 206以打开纟某体连接，例如TCP 连接。在端点B的MA 206将MSRP访问消息(n)发送到在端点A 的MA 206以建立MSRP连接。在端点A的MA 206发送对MSRP访 问的肯定响应(MSRP 200 OK)，以在端点A与B之间建立MSRP 连才妄(o)。在纟某体连接建立后，在端点B的MA 206将连接响应(连 接200 OK)发送到在端点B的UA 202,以指示々某体连接成功建立(P)。在这一点上，SIP邀请请求尚未4皮接受。在端点B的UA 202 将SA邀请响应(邀请200 OK)发送到在端点B的SA 204,指示SA 204应接受对加入与端点A的MSRP会话的邀请(q)。在端点B的SA 204将SIP邀请响应(SIP 200 OK + SDP体)发送到在端点A的SA 204(r)。 SIP邀请响应包括确认MSRP会话参数的SDP体。SIP邀 请响应是在步骤(e)对SIP邀请请求的应答，并包含由端点B用于媒 体连接的网络地址和端口 。在端点A的SA 204确认SIP 200 OK响 应，以完成SIP握手(s)。在端点A， SA 204发送SA邀"il"响应(t), 指示在步骤(a)请求的连接成功建立。此消息包括唯一标识呼叫的呼 叫标识符和在端点B用于媒体连接的主机网络地址和端口 。在端点 A的UA 202又将呼叫响应(u)发送到用户应用150，指示在步骤(a) 请求的连接成功建立。在端点B, SA 204将ACK请求(v)发送到UA 202以响应SIP ACK，指示与端点A的连4妄成功，并包才舌SIP会话 标识符。UA 202又将接受响应(w)发送到用户应用150,指示与端 点A的连接建立。端点A与B现在可以开始发送和接收消息。在端点A的用户应用生成多媒体消息，该消息在MSG请求(x) 中传递到UA 202。 MSG请求包括标识会话、消息类型和消息大小 的信息。UA 202用MSG请求中指定的参数构建并转发发送请求(y) 到MA 206，指示MA 206将多媒体消息转发到端点B。 MA 206使 用MSRP协议输送多媒体消息。MA 206生成MSRP发送请求(z)， 根据完整MSRP发送请求的需要提供默认参数，并将请求发送到在 端点B的MA 206。在端点B的MA 206从MSRP发送请求中提取 消息内容，并在MA发送请求(aa)内将消息输送到在端点B的UA 202。在端点B的UA 202使用MSG请求将消息内容转发到用户应 用150(bb)。在端点B的用户应用150通过发送MSG响应(MSG200 OK) (cc)确认消息接收，并且UA 202又将发送响应(dd)转发到MA 206，指示消息成功输送。MA206发送MSRP OK响应(MSRP 200 OK) 以确认消息接收(ee)。在端点A的MA 206可选择地转换并转发 MSRP响应(MA发送200 OK)到在端点A的UA 202 (ff),该UA 202
又可选择地将MSG响应(MSG 200 OK)发送到在端点A的用户应用 150,指示消息成功输送(gg)。要结束会话，在端点A的用户应用150将挂断请求发送到其 UA202 (hh)。端点B也可以相同的方式结束会话。在端点A的UA 202将SA再见请求(ii)发送到在端点B的SA 204，指示应结束在请 求中指定的呼叫。SA 204基于在步骤中确定的SIP会话参数生成SIP 再见请求(r)，并将此消息发送到端点B。在端点B的SA 204接收 SIP再见请求，并回复以确认消息接收(kk)。在端点A， SA 204将 再见响应(ii)发送到UA 202，确认媒体会话关闭。UA 202将挂断响 应(mm)发送到用户应用150,以通知用户应用150媒体会话关闭， 并将关闭请求(nn)发送到MA206,以关闭为媒体会话打开的连接。 在端点B的SA 204生成再见请求，并将再见请求转发到UA 202(oo),指示MSRP会话已关闭。类似地，在端点B的UA 202将 挂断请求(pp)发送到用户应用150，以通知用户应用MSRP会话关 闭，并将关闭请求发送到MA 206,以关闭为媒体会话打开的连接 (qq)。图7示出在端点A与B之间的示范RTP会话。图7所示的过 程使用附录中表1-3中定义的API。在端点A的用户应用150将呼 叫请求(a)发送到媒体客户端200以启动RTP会话。呼叫请求包括 标识;故叫方和呼叫类型的信息。响应呼叫请求，在端点A的UA202 将MA打开请求(b)发送到MA 206，指示MA 206为与呼叫请求中 指定的对等的RTP会话打开UDP连接。MA 206打开UDP插口 ， 并将包含为RTP会话打开的UDP插口网络地址和端口的MA打开 响应(c)发送到UA 202。在端点A的UA 202随后结束到SA 204的 SA邀请请求(d)。 SA邀请请求包括在步骤(a)发送的呼叫请求的参 数、在步骤(c)由MA 206提供的连接信息、以及可选择包括用户指 定的配置数据，诸如用户名和别名。用户指定的配置数据的参数值 可使用表1所示的设置请求，由用户应用150设置。
SA 204使用常规SIP信令与端点B建立通信会话。SA 204将 SIP邀请请求发送到端点B (e)。 SIP邀请请求包括描述多媒体会话 的SDP体。SDP体描述包括会话和编解码器参数的+某体。在等待 端点B的SA 204的响应的同时，在端点A的SA 204可从网^4^ 收临时响应(f)，指示网络正在尝试与端点B建立连接。一旦在端点B的SA 204接收了 SIP邀请请求，它便将SA邀 请请求发送到UA 202 (h)以打开RTP连接，并可将临时响应发送到 在端点A的SA 204 (g),指示SA 204在"拨打"端点B的用户。在 端点A的SA 204又可将临时一犬态响应发送到UA 202，以向在端点 A的UA 202提供拨打指示(k)。在端点A的UA 202在一些应用中 可向用户应用150(1)提供临时状态信息，以通知用户正在尝试拨打 在端点B的用户。在步骤(h)的邀请请求包括标识端点A和用于RTP会话的媒体 类型的信息。UA 202通过发送呼叫请求(i)来通知用户应用150收 到对RTP会话的邀请。用户应用150用接受请求(j)回复呼叫请求， 在此示例中，指示在端点B的用户已接受加入RTP会话的邀请。 如果呼叫涉及不止一种类型的媒体，则在端点B的用户可在接受请 求中指定要接受的媒体。例如，如果请求视频会议，则在端点B的 用户可选择接受音频并拒绝视频。在端点B的用户接受SIP邀请后，UA 202将MA打开请求(m) 发送到MA 206，以便为RTP会话打开媒体连接。在端点B的MA 206 打开UDP连接，并将MA打开响应(n)发送到UA 202,提供用于RTP 会话的力某体连接的地址和端口。在这一点，尚未接受在步骤(e)发送 的SIP邀请请求。在端点B的UA 202将SA邀请响应(邀请200 OK) 发送到在端点B的SA 204，指示SA 204应接受加入与端点A的RTP 会话的邀请(o)。此请求包括在打开响应中由MA 206返回的媒体主 机和端口信息。在端点B的SA 204将SIP邀请响应(SIP 200 OK + SDP体)发送到在端点A的SA 204(p)。 SIP邀请响应包括确认建立
全双工通信所需的RTP连接参数的SDP体。SIP邀请响应是在步 骤(e)对SIP邀请请求的应答。在端点A的SA 204确认SIP 200 OK 响应，以完成SIP握手(q)。在端点A， SA 204发送SA邀请响应(r)，指示在步骤(d)请求 的连接成功建立。此消息包括唯一标识呼叫的呼叫标识符和在端点 B用于i某体连接的主机网络地址和端口 。在端点A的UA 202又将 呼叫响应(s)发送到用户应用150,指示在步骤(a)请求的连接成功建 立，并将带有SA邀请响应中包含的RTP连接参数的对等请求(t)发 送到MA 206。在端点B， SA 204将ACK请求(u)发送到UA 202以 响应SIP ACK,指示与端点A的连接成功建立。UA 202又将接受 响应(v)发送到用户应用150,指示与端点A的连接建立。端点A 与B现在可以开始发送和接收RTP i某体(w)。要结束会话，在端点A的用户应用150将挂断请求发送到其 UA 202 (x)。端点B也可以相同的方式结束会话。在端点A的UA 202 将SA再见请求发送到在端点B的SA 204 (y)，指示应结束在请求 中指定的RTP会话。SA 204基于在步骤(p)确定的SIP会话参数生 成SIP再见请求(z),并将此消息发送到端点B。在端点B的SA 204 接收SIP再见请求，并回复以确i^消息接收(aa)。在端点A， SA204 将再见响应(bb)发送到UA 202,确认RTP会话关闭。UA 202将桂 断响应(cc)发送到用户应用150,以通知用户应用150 RTP会话关 闭，并将关闭请求(dd)发送到MA 206,以关闭为RTP会话打开的 连接。在端点B, SA 204生成再见请求，并将再见请求转发到UA 202(ee)，指示RTP会话已关闭。在端点B的UA202将桂断请求(ff) 发送到用户应用150，以通知用户应用RTP会话关闭，并将关闭请 求(gg)发送到MA 206,以关闭为^ 某体会话(gg)打开的连接。图8示出包括用于JAVA应用的应用接口的i某体客户端200的 另一实施例。图8所示实施例包括如上所述的UA 202、 SA 204和 MA 206。除本机UA API夕卜，图8中的i某体客户端200也包括用于JAVA应用的JAVA应用接口(JAVA API)。 JAVA API是面向连接 的应用接口。 JAVA API包括允许JAVA应用向SIP代理登记、打 开连接(呼叫)、查询远端能力、发送/接收消息、重定向+某体字符串 及挂断连接的命令。JAVA API像本机IMA API提供高级抽象化， 将JAVA应用与诸如SIP和SDP等较低级协议的细节隔离。JAVA API使JAVA应用能够与用户代理通信，而信令代理和J 某体代理处 理底层信令和々某体操作。通过处理在JAVA应用中常见的信令和操 作任务，带有JAVA API的媒体客户端200使JAVA应用更易于编 写。由于JAVA应用对诸如SIP和SDP等较低级协议没有直接访 问权，因此对于同一 JAVA应用有更好的机会在不同运营商网络和 不同移动终端中工作。此外，流氓JAVA应用在网络内引起问题的 机会较少。JAVA应用也无需担心直接访问低级协议带来的配置和 部署问题。相反，配置和部署问题由^ 某体客户端200处理。装置制 造商已经使用定制进程配置对特定运营商网络专用的设置，并可轻 松地为特定运营商的网络配置媒体客户端200。在本发明的一些实施例中，在用户应用150不需要处理数据 时，MA 206可能能够将媒体直接路由到媒体再现装置，绕过用户 应用150。例如，在媒体流式传输中，用户应用150 —般接收媒体 流，并将媒体流输出到媒体播放器，而不进行任何数据处理。在此 情况下，MA 206可直接将媒体流路由到媒体播放器。图9示出从 远程装置到本地媒体再现装置(例如移动终端100的扬声器和/或显 示器)的典型媒体(例如视频或音频)流式传输。媒体流通过较低层协 议堆栈，并由MA 206直接路由到诸如视频解码器等媒体播放器。 ^ 某体流通过IP、 UDP和RTP堆栈向上传递到^L频解码器。图9也 示出摄像机的输出通过RTP、 UDP和IP堆栈向下传递，以便传输 到远程装置。媒体流或摄像机输出均不流入MA 204的较高层或应 用层。在一些应用中，用户应用150可能要接收i某体流。图10示 出到/来自用户应用的典型媒体流。 在本发明的一个优选实施例中，用户应用150可指导^!某体或消息如何路由。要使用户应用150实现媒体的选择性路由，UA API 可包括由用户应用150发送到:煤体客户端200的设置路由请求，以 指定媒体流的特定源或宿。源或宿可以在移动终端100内部或外部。 MA API包括由UA 202发送到MA 206的对应设置路由请求，以配 置指定要如何路由媒体流的路由表。UA API和MA API也可包括 控制媒体流的其它请求，如暂停活动媒体流的暂停请求和重新开始 暂停媒体流的重新开始请求。图11和图12示出可使用本发明的媒体客户端200的各种方 式。图11示出三个网络通信装置移动装置100、视频摄像机300 和视频播放器350。移动装置100包含如图3所示包括UA202、 SA 204和MA 206的i某体客户端200。视频播放器350包含MA 206。 在此示例中，移动装置100的用户要将视频摄像机300的一见频重放 到远程视频播放器350。这例如可用于在外渡假时监视某人的家。 移动装置100中的UA 202与远程视频播放器350中的MA 206建 立TCP连接。移动装置100中的SA 204使用SIP与视频摄^f象机300 建立信令连接。移动装置100、视频摄像机300及视频播放器之间 的通信是通过因特网或其它通信网络12的对等通信。为启动媒体会话，移动装置100中的应用150使用图7所示的 过程。应用150通过将呼叫请求发送到也位于移动装置100中的UA 202而启动J(某体会话。移动装置100中的UA 202将打开请求发送 到远程视频播放器350中的MA 206，以打开用于RTP会话的UDP 插口连接。打开请求通过TCP插口连接发送。应注意的是，在此 示例中移动装置100控制位于远端的MA 206。视频播放器350中 的MA 206将用于RTP连接的网络地址和端口返回到移动装置100 中的UA 202。 UA 202通过将邀请请求发送到SA 204，指示SA 204 建立RTP会话。SA 204也位于移动装置100中。邀请请求包括在 视频播放器350中由MA 206提供的网络地址和端口 。 一见频播放器 350提供的网络地址和端口包含在发送到视频摄像机300的SIP邀 请中。视频摄像机300将用于RTP连接的网络地址和端口返回到 移动装置100中的SA 204，而SA 204又将此信息提供到UA 202。 移动装置100中的UA 202将包含视频摄像机300提供的网络地址 和端口的对等请求发送到视频，播放器350中的MA 206，以在视频 播放器350与视频摄像机300之间建立RTP连接。视频播放器350 随后可从视频摄像机300接收—见频流。在图12所示的示例中，有两个连网的通信装置-移动装置100 和在本文中简称为DVD播放器400的DVR/DVD播放器400。移 动装置100的用户要从远程DVD播放器400将DVD或存储的数 字视频重放到移动装置100。 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。 MSRP和RTP会话分别使用如图6和图 7所示的过程建立。使用MSRP，移动装置100将命令作为文本消 息发送到DVD播放器400。在此示例中，MSRP消息由DVD播放 器400中的媒体客户端200传递到在本文称为远程控制应用的应用 150。 DVD播放器400中的远程控制应用150分析移动装置IOO发
送的命令，并相应地控制DVD播放器400。如图8和图9所示，DVD 播放器400可具有选择性地路由媒体流的能力。DVD播放器400 中的远程控制应用150使用设置路由请求，可指示DVD播放器400 将视频和/或音频流发送到在RTP会话内的移动装置100。此外， 本领域的技术人员将认识到，移动装置100可指示DVD播放器400 将々某体发送到另 一远程连网的通信装置。图12中所示的方法可用于远程控制各种各样的装置，如^L频 摄像机、数字静态摄像机、打印机、扫描仪、复印机、家庭立体声 系统、电视或计算机。此外，本领域的技术人员将认识到，媒体可 以从移动装置100流式传输到远程装置。例如，本发明可用于将音 频从便携式DVD或CD播放器流式传输到家用计算机，以便音频 可记录和存储在家用计算机上。又如，本发明可用于将3见频和/或音 频从便携式视频摄像机流式传输到家用计算机，以在家用计算机上 记录和存储^L频和/或音频。当然，在不脱离本发明精神和基本特征的情况下，本发明可以 不同于本文所述那些方式的其它特定方式实现。因此，所示实施例 在所有方面均视为说明而不是限制，并且在随附权利要求书的意义 和等同物范围内的所有更改要涵盖在其中。
权利要求
1.一种远程控制媒体装置(300，350，400)的方法，包括经因特网协议通信链路与所述媒体装置(300，350，400)建立媒体会话；以及在所述多媒体会话的上下文中通过将控制命令作为多媒体消息发送到所述媒体装置(300，350，400)，远程控制所述媒体装置(300，350，400)。
2. 如权利要求1所述的方法，其中使用实时传输协议将所述 控制命令作为文本消息发送。
3. 如权利要求2所述的方法，其中使用消息会话中继协议发 送所述控制命令。
4. 如权利要求2所述的方法，其中使用所述实时传输协议发 送所述控制命令。
5. 如权利要求1所述的方法，其中所述媒体装置(300，350,400) 是媒体播放器(350,400)。
6. 如权利要求1所述的方法，其中所述i某体装置(300,350,400) 是媒体记录器(300)。
7. 如权利要求1所述的方法，其中所述i某体装置(300，350,400) 是媒体存储装置(300)。
8. —种远程控制媒体装置(300，350,400)的装置(100),包括 远程控制应用(150)，生成控制命令；以及 々某体代理(206),用于管理与所述士某体装置(300,350,400)的媒体连接，并将所述控制命令封装在媒体消息中以便发射到所述媒体装 置(300,350，400)。
9. 如权利要求8所述的装置，其中使用实时传输协议将所述 控制命令作为文本消息发送。
10. 如权利要求8所述的装置，其中使用消息会话中继协议发送所述控制命令。
11. 如权利要求8所述的装置，其中所述々某体装置(300,350,400) 是々某体播放器(350，400)。
12. 如权利要求8所述的装置，其中所述々某体装置(300，350,400) 是媒体记录器(300)。
13. 如权利要求8所述的装置，其中所述媒体装置(300，350,400) 是媒体存储装置(300)。
14. 一种控制媒体装置(300,350,400)的方法，包括经因特网协议通信链路与远程装置(100)建立媒体会话； 在所述媒体会话的上下文中从所述远程装置(100)接收封装在媒 体消息中的控制命令；从所述媒体消息中提取所述控制命令；以及 响应所述控制命令控制所述媒体装置(300，350,400)。
15. 如权利要求14所述的方法，其中使用实时传输协议将所 述控制命令作为文本消息接收。
16. 如权利要求15所述的方法，其中使用消息会话中继协议 接收所述控制命令。
17. 如权利要求15所述的方法，其中使用实时传输协议接收 所述控制命令。
18. 如权利要求14所述的方法，其中所述媒体装置(300,350,400) 是媒体播放器(350,400)。
19. 如权利要求14所述的方法，其中所述媒体装置(300,350,400) 是媒体记录器(300)。
20. 如权利要求14所述的方法，其中所述媒体装置(300,350，400) 是々某体存储装置(300)。
21. —种媒体装置(300,350,400)，包括媒体代理(206)，用于管理与远程装置(100)的媒体连接，并从 所述远程装置(lOO)接收封装在:i 某体消息中的控制命令；以及 应用(150)，从所述媒体消息中提取所述控制命令，并响应所述 控制命令控制所述媒体装置(300，350,400)。
22. 如权利要求21所述的媒体装置(300，350,400)，其中使用实 时传输协议将所述控制命令作为文本消息发送。
23. 如权利要求21所述的媒体装置(300，350,400),其中使用消 息会话中继协议发送所述控制命令。
24. 如权利要求21所述的媒体装置(300,350，400),其中所述媒 体装置(300,350,400)是媒体播放器(350,400)。
25. 如权利要求21所述的媒体装置(300,350，400)，其中所述媒 体装置(300,350,400)是媒体记录器(300)。
26. 如权利要求21所述的媒体装置(300，350,400),其中所述媒 体装置(300，350,400)是媒体存储装置(300)。
27. —种使远程装置(100)能够控制本地媒体装置(300，350,400) 的方法，包括经因特网协议通信链路建立并发J(某体会话； 在第 一媒体会话内从所述远程装置(100)将控制命令作为媒体消 息接收；以及在第二i某体会话内响应在所述第一i某体会话内接收的控制命令 发送或接收媒体数据。
28. 如权利要求27所述的方法，其中所述第一和第二媒体会 话都是与所述远程装置(100)进4亍的。
29. 如权利要求27所述的方法，其中所述第二媒体会话内的 所述媒体数据发射到所述远程装置(100)，或从所述远程装置(100) 接收。
30. 如权利要求27所述的方法，其中所述第二媒体会话是与 第二远程装置(100)进行的。
31. 如权利要求27所述的方法，其中所述媒体装置(300,350,400) 是媒体播放器(350,400)。
32. 如权利要求27所述的方法，其牛所述媒体装置(300，350,400) 是媒体记录器(300)。
33. 如权利要求27所述的方法，其中所述媒体装置(300,350,400) 是媒体存储装置(300)。
34. —种媒体装置(300,350,400)，包括信令代理(204),与一个或多个远程装置(100)建立并发媒体会话；媒体代理(206),用于管理到所述远程装置(100)的媒体连接， 并在第 一媒体会话的上下文中从第 一远程装置(100)接收封装在媒体 消息中的控制命令；以及应用(150),从所述媒体消息中提取所述控制命令，并在第二媒 体会话的上下文中响应所述控制命令发送或接收媒体数据。
35. 如权利要求34所述的媒体装置(300,350,400)，其中所述媒 体数据发送到第一远程装置(IOO),或从第一远程装置(100)接收。
36. 如权利要求34所述的媒体装置(300,350，400)，其中所述媒 体数据发送到第二远程装置(l00),或从第二远程装置(1 OO)接收。
37. 如权利要求34所述的媒体装置(300，350，400),其中所述媒 体装置(300,350,400)是媒体播放器(350，400)。
38. 如权利要求34所述的媒体装置(300，350,400)，其中所述媒 体装置(300，350,400)是媒体记录器(300)。
39. 如权利要求34所述的媒体装置(300，350,400),其中所述媒 体装置(300，350,400)是媒体存储装置(300)。
全文摘要
用于连网的通信装置的媒体客户端(200)包括与连网的通信装置中多媒体应用通信的用户代理(202)。用户代理(202)向多媒体应用(150)提供高级应用接口。在用户代理(202)控制下的信令代理(204)执行建立和维护通信会话所需的信令操作。在用户代理(202)控制下的媒体代理(206)执行媒体操作。媒体客户端(200)可位于网络中，并由多媒体应用(150)远程访问。用户代理(202)、信令代理(204)和媒体代理(206)具有允许在网络内分布并远程访问这些部件的网络接口(208，210，212)。
文档编号H04L29/08GK101129045SQ200580048742
公开日2008年2月20日 申请日期2005年7月11日 优先权日2004年12月31日
发明者D·W·肖普, J·W·本内特, S·马杜拉 申请人:索尼爱立信移动通讯股份有限公司