一种控制流媒体的方法及装置的制作方法

专利名称：一种控制流媒体的方法及装置的制作方法
技术领域：
本发明涉及通信网络中的流媒体业务，特别涉及一种控制流媒体的方法 及装置。
背景技术：
流媒体业务是近几年迅速发展的一种新业务，该业务利用流式传输技
术，在包交换网络上，如IMS网络上传输多媒体文件，包括视频和音频等 文件内容，这些文件内容不需要用户设备(UE， User Equipment)在访问时 完全下载就可以立即播放。流媒体业务实现的关键技术就是流式传输技术， 而流式传输技术把连续的视频和音频等文件内容经过处理后存储在包交换 网络中的服务器上，使UE可以访问该服务器， 一边下载文件内容， 一边观 看收听文件内容，而不需要等整个文件内容都下载后才可以观看收听文件内 容。
在3GPP版本5 (R5，Release)阶段，引入了 IMS, IMS叠加在分组域 网络之上，由呼叫控制功能(CSCF, Call Session Control Function )、媒体 网关控制功能(MGCF, Media Gateway Control Function )、媒体资源功能
(MRF, Media Resource Function)和归属签约用户月l务器(HSS, Home Subscriber Server)等功能实体组成。其中CSCF又可以分为服务CSCF
(S-CSCF)、代理CSCF (P-CSCF)和查询CSCF (I-CSCF )三个逻辑实体。 S-CSCF是IMS的业务交换中心，执行会话控制，维持会话状态，负责管理 UE信息，产生计费信息等；P-CSCF是UE接入IMS的接入点，完成UE注 册，负责服务质量(QoS)控制和安全管理等；I-CSCF负责IMS域之间的 互通，管理S-CSCF的分配和选择，对外隐藏网络拓朴和配置，产生计费数
据等。MGCF控制网关，实现IMS和其它网络的互通。MRF提供媒体资源。 HSS存储UE的签约数据和配置信息等。IMS网络主要采用会话发起协议 (SIP, Session Initial Protocol)以及直径(Diameter)协议等。
SIP是一个应用层的控制协议，可以用来建立、修改和终止多i某体会话 或会议，SIP也支持邀请参与者参加已经存在的会话，比如多方会i义。
实时流协议(RTSP， Real Time Streaming Protocol)是应用级协议，控 制实时数据的发送，主要用于流媒体业务的实时数据发送。RTSP提供一种 可扩展框架，进行实时数据，如音频与视频的受控传送以及点播传送。RTSP 目的在于控制多个数据传送会话，提供选择传送通道的方法，提供基于实时 传输协议(RTP, Real Time Transport Protocol)选择传输机制的方法。
RTSP对流媒体可以提供专业化的支持，但是在一些基本功能上同SIP 有重叠，因为SIP具有良好的路由、易扩展、移动性支持和会话支持功能， 同时SIP +会话描述协议(SDP, Session Description Protocol)可以才是供一 些基础的流媒体控制功能，因此目前提出采用通过SIP协商媒体控制通道方 式来协商RTSP通道，这样既可以利用SIP已有的功能，同时又可以利用专 业化的媒体控制操作在协商的RTSP通道进行专门的媒体控制操作，避免对 RTSP进行同SIP已有功能重复的扩展。
基于IMS的因特网协议电视(IPTV, IP Television)业务就是在IMS 整体架构下提供IPTV业务，充分利用IMS网络中已有的注册、认证、路由、 会话控制与建立、业务触发、计费、端到端服务质量(QoS, Quality of Service ) 保证等机制来为UE提供流媒体业务及融合流媒体和实时会话业务的流媒体 业务。也就是说，UE到内容的多媒体会话是通过IMS已有的会话控制机制 来完成，在建立会话过程中，需要为流媒体的传送预留承载资源。
图1为现有技术基于IMS的IPTV业务的业务功能架构示意图，其中， IPTV媒体功能实体(MF， Media Function )负责通过IMS到UE的流媒体 的控制和交付。IPTV Media Function从功能角度可以分解为媒体控制功能实 体(MCF， Media Control Function)和媒体交付功能实体(MDF, Media
Delivery Function ) 。 MDF通常为 一些媒体服务器，在MCF的控制下向UE 传输流媒体，MCF还能接收和处理由UE发送的控制操作命令，这些命令通 常釆用RTSP实现，例如流媒体的快进、后退、暂停和定位等操作命令等。 IPTV业务控制功能(IPTV Service Control Functions )用于在通过核心(Core ) IMS接收到UE发送的IPTV业务请求时，为UE选择MF进行处理，Core IMS 可以为UE的IPTV业务预留资源。该图1中还包括与UE相连接的用户签 约服务功能实体(UPSF, User Profile Server Function ),用于存储UE的签 约信息；业务单信息功能实体(SSF, Service Discovery Function ),用于给 UE提供可浏览和选择的业务单信息。在UE和IPTV MF和UE之前还包括 传送层(Transport Processing Functions )，其中包括传送控制子层以及传送 功能实体，用于使用IMSCore预留的承载资源采用组播方式传输LTV业务 的流媒体，在传送层和Core IMS之间还包括网络附着子系统(NASS, Network Attachment Subsystem )以及资源和允许控制子系统(RACS ， Resource and Adission Control Subsystem )。
在现有技术中，RTSP被选择用来实现流媒体的控制，同时也具有一些 会话控制功能和媒体控制功能，在遇到新的对流媒体控制时，通常就是对 RTSP进行扩展，但引入的扩展通常在SIP已经定义，从而造成功能重复， 在同时存在两种协议共同工作的场合下还可能发生冲突。
目前，为了对流媒体进行控制，首先，需要在控制客户端(Control Client) 和控制服务器(Control Server)之间采用SIP初始流媒体协商RTSP通道和 媒体通道；然后，在根据协商建立的RTSP通道上对流媒体进行控制；最后， 协商建立的媒体通道根据在RTSP通道对流媒体的控制传输流媒体。其中， Control Client可以为UE; Control Server可以是MCF或MF。 RTSP通道用 于完成对流i某体的控制，而RTSP定义的建立(SETUP)消息、通告 (ANNOUNCE)消息、描述(DESCRIBE)消息以及卸载(TEARDOWN) 消息均可由SIP协商过程替代。
图2为现有技术对流媒体进行控制的方法一流程图，涉及的网络实体包
括Control Client以及Control Server,其具体步骤为
步骤201 、 Control Client向Control Server发送访问(INVITE )消息， 携带用于进行RTSP通道协商的RTSP参数以及进行媒体通道协商的流媒体 请求信息；
步骤202、 接收到该INVITE消息的Control Server向Control Client返 回200消息，该消息携带进行RTSP通道协商的RTSP响应参数以及进行媒 体通道协商的流媒体相关的响应(answer );
步骤203、 Control Client向Control Server发送确认(ACK )消息，建 立与Control Server之间的RTSP通道；
步骤204、在建立的RTSP通道上，Control Client向Control Server发送 播放(PLAY)控制操作命令，其中携带要播放流媒体的播放信息，包括 流媒体播放初始位置信息、或/和流媒体播放结束位置信息、或/和持续时长 等信息；
步骤205、接收到PLAY控制操作命令的Control Server根据该命令携 带的播放信息确定要播放的流媒体，向Control Client返回200消息，建立 与Control Server之间的i某体通道；
步骤206、 Control Server通过i某体通道向Control Client播放确定的流 媒体。
在该实施例中，通过SIP中的INVITE/200/ACK消息完成RTSP通道和 :樣体通道的协商，协商完成后建立RTSP通道，在该RTSP通道上发送对流 媒体的控制操作命令，例如PLAY控制操作命令，媒体通道的建立在RTSP 消息之后被执行。但是，对于某些流媒体的控制，开始时并不需要对流媒体 进行复杂控制，而只需要简单控制，例如使用PLAY控制操作命令要求 Control Server将确定位置或设定时长的流媒体分发给Control Client,此时 只需要通过媒体通道播放流媒体即可，而无需对播放的流媒体进行复杂控 制。
在图2中要求媒体通道的建立必须在建立RTSP通道之后进行，并且通
过RTSP通道对在媒体通道传输的流媒体进行控制，这样对于简单的流媒体 控制，如仅仅进行流媒体的播放或录制的控制，而不对流媒体进行时移搡作
的控制，仍然需要建立RTSP通道，这会占用系统的连接资源，造成系统的 连接资源浪费。
同时，因为建立RTSP通道需要穿越NASS，这也会浪费在NASS设备 上的资源，例如NASS需要进行打开RTSP通道以及相应的防止老化操作时 会浪费在NASS设备上的资源。
在现有技术中，还有一种方法可以实现对流媒体的控制，如图3所示， 其具体步骤为
步骤301 、 Control Client向Control Server发送INVITE消息，携带用于 进行媒体通道协商的流媒体请求信息；
步骤302、 接收到该INVITE消息的Control Server向Control Client返 回200消息，该消息携带用于进行媒体通道协商的流媒体相关的answer;
步骤303、 Control Client向Control Server发送ACK消息，建立i某体通
道；
步骤304、 Contro Client要对流々某体进行控制操作，则向Control Server 发送再次访问(Re-INVITE)消息，携带用于进行RTSP通道协商的RTSP 参数以及进行媒体通道协商的流媒体请求信息；
在本步骤中，进行媒体通道协商的流媒体请求信息与步骤301中请求的 相同；
步骤305、接收到该Re-INVITE消息的Control Server向Control Client 返回200消息，该消息携带进行RTSP通道协商的RTSP响应参凄t以及进行 媒体通道协商的流媒体响应信息；
在本步骤中，进行媒体通道协商的流媒体响应信息与步骤302中响应的
相同；
步骤306、 Control Client向Control Server发送ACK消息，建立与Control Server之间的RTSP通道；
步骤307、在建立的RTSP通道上，Control Client向Control Server发送 PLAY控制操作命令，其中携带要播放流媒体的播放信息，包括流媒体播 放初始位置信息、或/和流媒体播放结束位置信息、或/和流媒体播放持续时 长等信息；
步骤308、接收到PLAY控制操作命令的Control Server根据该命令携 带的播放信息确定要播放的流媒体，向Control Client返回200消息，Control Server向Control Client通过步骤303建立的媒体通道播放确定的流媒体。
从图3可以看出，该方法在对要在媒体通道传输的流媒体进^N空制时， 需要进行SIP重协商的三次握手交互以及建立RTSP通道后才能进4亍，这不 仅占用了系统的资源，而且使对在媒体通道传输的流媒体的控制反应时间较 长，降低了用户接收流媒体的体验度。

发明内容
本发明实施例提供一种控制流媒体的方法，该方法能够在减少占用系统 资源和控制反应时间的情况下实现对流媒体的控制。
本发明实施例还提供一种控制流媒体的装置，该装置能够在减少占用系 统资源和控制反应时间的情况下实现对流媒体的控制。
根据上述目的，本发明实施例的技术方案是这样实现的
一种控制流媒体的方法，该方法包括
控制服务器在与控制客户端的会话初始协议SIP初始流媒体妨、商过程 中接收到流媒体控制信息，根据该流媒体控制信息控制传输给控制客户端的 流々某体。
一种实现流媒体控制的装置，该装置包括协商模块和接收模块，其中，
协商模块，用于在和实现流媒体控制的进行SIP初始流媒体协商过程中
协商流媒体控制信息；接收模块，用于接收实现流媒体控制的发送的流媒体。
从上述方案可以看出，本发明实施例在不需要对媒体通道传输的流媒体
进行复杂控制时，就不建立媒体控制通道用于对流媒体进行控制，而只在进
行SIP协商时将流媒体控制信息由Control Client发送给Control Server,由 Control Server根据该信息在媒体通道上进行流媒体控制，从而不需要给媒 体控制通道预留资源，在减少占用系统资源和控制反应时间的情况下实现对 流媒体的控制。


图1为现有技术基于IMS的IPTV业务的业务功能架构示意图2为现有技术对流媒体进行控制的方法一流程图3为现有技术对流媒体进行控制的方法二流程图4为本发明实施例控制流媒体的方法流程图5为本发明具体实施例一控制流媒体的方法流程图6为本发明具体实施例二控制流媒体的方法流程图7为本发明实施例控制流媒体的系统示意图8为本发明实施例控制流媒体的Control Client示意图9为本发明实施例控制流媒体的Control Server示意图。
具体实施例方式
为使本发明的目的、技术方案和优点更加清楚，下面结合附图对本发明 实施例作进一步的详细描述。
为了能够在减少占用系统资源和减少控制反应时间的情况下实现对流 媒体的控制，本发明实施例在不需要对媒体通道传输的流媒体进行复杂控制 操作时，如播放或录制控制操作，就不建立媒体控制通道用于对流i某体进行 控制，而只在进行SIP协商时将流媒体控制信息由Control Client发送给 Control Server,由Control Server根据该信息在i某体通道上进行流J 某体的控 制，从而减少了建立媒体控制通道占用的资源以及建立媒体控制通道所需要 的时间。
更进一 步地，本发明实施例还可以在SIP协商过程中对要建立的力某体控
制通道进行协商，当需要对流媒体进行复杂控制时，如进行时移操作时(包 括对流媒体进行快进、快退或暂停等控制操作)，根据预先协商好的媒体控 制通道参数建立媒体控制通道，在媒体控制通道上发送控制操作命令，控制 在媒体通道传输的流媒体。这样，在减少了控制反应时间的情况下实现对流 媒体的控制。
在本发明实施例中，采用RTSP通道作为媒体控制通道进行详细的说明。
本发明实施例提供的方法主要包括在SIP初始流媒体协商过程中指定
流媒体控制信息，包括要播放或录制的流媒体标识以及流媒体位置等信息，
而不通过建立的RTSP通道上发送控制操作命令指示；在SIP初始流媒体协 商过程中协商延迟建立RTSP通道，如果协商双方都接受，则在协商完成后 不立刻建立RTSP通道，而只建立媒体通道，协商过程中可选地协商延迟建 立RTSP通道的时间范围，缺省为不指定时间范围；第三个技术特^正，RTSP 通道的建立时机依靠Control Client的决定，例如，Control Client接收到对 流媒体的复杂控制，确定只有通过RTSP消息交互才能完成本次对流媒体的 控制，此时则根据在SIP初始流媒体协商过程中协商好的RTSP参数建立 RTSP通道。
图4为本发明实施例控制流媒体的方法流程图，其具体步骤为 步骤401、 Control Client发送INVITE消息，其中携带用于协商延迟建
立RTSP通道的RTSP参数、用于协商建立媒体通道的媒体请求信息以及流
媒体控制信息。
在本步骤中，为了实现不经过RTSP通道的对流媒体的控制操作命令就 对媒体通道的流媒体进行控制，所以在INVITE消息中增加了流媒体控制信 息，该流媒体控制信息一般只是预先设定的对流媒体进行简单控制的信息， 如播放或录制设定初始位置、结束位置和持续时长的流媒体中的一种或多种等。
例如INVITE消息可以为(该实施例没有SIP消息部分，只包括SDP 部分)
o=alice 2890844526 2890844526 IN IP4 a.atlanta.example.com 〃表示 会话标识，用户名为Alice, session ID为2890844526，版本号为2890844526, 网络类型为Internet,地址类型为IPV4,地址为用URI形式表述的 a.atlanta.example.com
s=Streaming Session 〃session名字为 "Streaming Session"
i=A Streaming session declared within the session description protocol 〃 会话信息描述为"流媒体会话采用SDP进行描述"
c=IN IP4 a.atlanta.example.com 〃连接信息，其中网络类型为 Internet,;也址类型为IPV4，J4址为a.atlanta.example.com
t=0 0 〃媒体会话开始和结束时间都置为o表示起始和结束时间不
受限
m=application 9 TCP/RTSP rtsp 〃表示RTSP媒体控制通道信
息，其中application表示该media line用于应用，9为无意义的TCP缺省监 听端口 (因本端是发起连接方，为动态端口 ，因此此参数实际没有具体含义)， 后面表示该TCP连接用于RTSP。
a=fmtp:rtsp request-uri: rtsp:〃b.biloxi.example.com/scene 〃表示 rtsp的server侧地址(即request-uri)
a=fmtp:rtsp version: 2.0 〃表示rtsp版本号
a=fmtp:rtsp h-accept-mnges: NPT 〃表示rtsp用到的时间表示类型 为NPT方式
a=fmtp:rtsp h-range clock=19960213T143205Z-;time=19970123T143720Z 〃此处给出了准备播 放媒体的位置信息，从clock指示的位置开始播放。
a=fmtp:rtsp h-supported:deferred 〃表示本端支持延迟建立RTSP通 道方式。
a=connection:new 〃表示该TCP连接为新建连接
a=setup:active 〃表示本端是连接发起方
a=rtspid m-stream:10 〃给出该媒体控制通道号，用于同i某体通道进
行关联
m=audio 6666 RTP/AVP 0 〃用于描述媒体通道的信息，表示为音 频，在6666端口收媒体，蜂梦类型号为0
a=rtpmap:0 PCMU/8000 〃表示媒体类型为G711U, 8KHZ采样 a=recvonly 〃表示该媒体只用于接收
a=label:10 〃给该媒体通道一个标识，用于同前面媒体控制通道中 的描述a=rtsp-id m-stream:10进4亍关联
在该消息中，通过提供a = fmtp: rtsp h-mnge....指定播放的流J 某体起始 位置、终止位置和持续时长中的一种或多种等流媒体控制信息，这样就可以 不用建立RTSP通道，而直接在SIP协商过程中将流媒体控制信息发送给 Control Server。
在该消息中,通过提供a=fmtp:rtsp h-supported:deferred， 通知Control Server, Control Client支持延迟建立RTSP通道。Control Server如果不支持 延迟建立RTSP通道，则可以在200消息的响应中带上a=fmtp:rtsp h-unsupported:deferred或不予理睬，此时双方需要采用立即建立RTSP通道 方式在成功完成SIP初始流媒体协商后，建立RTSP通道；Control Server 如果同意延迟建立RTSP通道，则在200消息的响应中携带a=fmtp:rtsp h-required:deferred以完成SIP初始流媒体协商，这表明双方协商一致将延迟 建立RTSP通道，建立的时机将由Control Client确定，Control Server在整 个传输流媒体过程中对Control Client进行监听，确定Control Client何时发 起建立RTSP通道的过程。
在本发明实施例中，为了防止Control Client后续不建立RTSP通道， 还可以在a行中增力口 expires参数,如a=fmtp:rtsp h-supported:deferred; a=fmtp:h-expires=60，表明在60分钟之内如果Control Client后续没有发起 建立RTSP通道的过程，则Control Server在60分钟时直接发起建立RTSP
通道的过程。
步骤402、 Control Server返回200消息，其中携带用于协商延迟建立 RTSP通道的RTSP响应参数、用于协商建立媒体通道的流媒体相关的answer 以及控制流媒体响应信息。
例如200消息携带的响应可以为(本实施例没有SIP消息部分，只包括 SDP部分)
v=0 〃版本号
o=bob 2808844564 2808844564 IN IP4 b.biloxi.example.com 〃表示 会话标识，用户名为Bob, session ID为2808844564,版本号为2808844564， 网络类型为Internet,地址类型为IPV4,地址为用URI形式表述的 b.biloxi.example.com
s=Streaming Session〃 session名字为"Streaming Session"
i=A Streaming session declared within the session description protocol 〃会话信息描述为"流媒体会话采用SDP进行描述"
c=IN IP4 b.biloxi.example.com 〃连接信息，其中网络类型为 Internet, i也址类型为IPV4,i也址为b.biloxi.example.com
t=0 0 〃媒体会话开始和结束时间都置为o表示起始和结束时间不受
限
m=application 554 TCP/RTSP rtsp 〃表示RTSP媒体控制通道信 息，其中application表示该media line用于应用，554为RTSP使用的TCP 连接本端监听端口，后面表示该TCP连接用于RTSP。
a=connection:new 〃表示该TCP连接为新建连才妻
a=setup:passive 〃表示本端为连4!4妾^j文方
a=control: rtsp:〃b,biloxi.example.com/scene 〃RTSP控制URI， 表示 本端Server的URI
a=fmtp:rtsp version: 2.0 〃RTSP版本号
a=fmtp:rtsp h-accept-ranges: NPT 〃表示接受的时戳处理类型 a=fmtp:rtsp h-session: 6238237 〃本端生成该RTSP session ID a=fmtp:rtsp h-date: Tue， 05 Sep 2006 09:56:44 GMT 〃给出时间 a=fmtp:rtsp h-rtp-info: url="rtsp:〃b.biloxi.example.com/scene"
ssrc=l 631654733 :seq=53961 ;rtptime=0
〃表示同RTSP控制的媒体会话相关的RTP信息，例如其中的ssrc属性。
a=rtspid m-stream:lO 〃给该媒体控制通道一个标识，用于同其控制
的媒体通道之间的关联
m=audio 8888 RTP/AVP 0 〃i某体通道的描述，表示i某体端口 8888,
PT值为0
a=rtpmap:0 PCMU/8000 〃表示编解码类型为G711U, 8KHZ采样 a=sendonly 〃表示本端媒体只用于发送 a=label:10 〃给该媒体通道一个表示，用于同前面媒
体控制通道进行关联
在该消息中，如果Control Server不需要延迟建立RTSP通道，则需要 丢 弃 a=fmtp:rtsp h-supported:deferred 或 携 带 a=fmtp:rtsp h-unsupported:deferred ( 在示例中， 已经丢弃 了 a=fmtp:rtsp h隱supported:deferred，表示Control Server不延迟建立RTSP通道)；如果 Control Server不支持RTSP，则将通过m = application O...方式来拒绝建立 RTSP通道，即端口号为O(在示例中，Control Server支持RTSP)。需要 注意的是,丟弃 a=fmtp:rtsp h-supported:deferred 或携带 a=fmtp:rtsp h-unsupported:deferred并不影响SIP初始流媒体协商过程的成功，只能表示 RTSP通道不能延迟建立。
步骤403、 Control Client向Control Server发送ACK消息，表示确认。
步骤404、 Control Server根据协商好的媒体通道信息建立媒体通道，根 据在SIP初始流媒体协商过程中Control Client发送的流媒体控制信息通过 建立的媒体通道传输确定的流媒体。
步骤405、 Control Client要对媒体通道传输的流媒体进行控制，该控制
过程需要通过RTSP消息才能完成，则发起建立RTSP通道的过程(如果要 延迟建立RTSP通道的话)，即根据在SIP初始流媒体协商过程协商好的 RTSP通道参数建立与Control Server之间的RTSP通道。
在本步骤中，在Control Client中预先设置有对应于要建立RTSP通道 的控制操作命令以及对流媒体的控制规则，当Control Client要对流媒体控 制时，判断是否符合所设置的控制规则或是否为所设置的控制操作命令，如 果是，则发起建立RTSP通道的过程；如果否，则不进行。
在本步骤中，设置的对应于要建立RTSP通道的控制操作命令可以为快 退、快进以及暂停、录制等时移控制操作命令，也可以为对流媒体画面进行 控制的空间移位控制操作命令，设置的对应于要建立RTSP通道的对流媒体 的控制规则也可以为更改当前在媒体通道播放或录制的流媒体的位置信息 等。
步骤406、 Control Client建立了 RTSP通道后，Control Client向Control Server发送对媒体通道传输的流媒体的控制操作命令。
步骤407、 Control Server接收到该控制操作命令后，对在媒体通道传输 的流媒体执行该控制操作命令，返回200消息。
执行该控制操作命令的过程与现有技术相同。
在本发明实施例中，也可以在INVITE消息中的Request统 一 资源标识 符(URI )中通过携带参数的形式来指示流媒体控制信息，此时对Request URI 增加用户类型(user) -rtsp作为URI参数，用于指示携带了流媒体控制信 息，并携带范围(range)特征信息，Range的具体含义可以参考RFC2326 标准中RTSP对该头域的定义， 一般表示播放或录制流媒体的初始位置信息、 结束位置信息、和流媒体持续时长中的 一种或多种等流媒体控制信息。例如
Sip:
rtspclient@examplem.com;user=rtsp range=clock%3Dx960213T143205Z-%3B x;time%3Dxl9970123T143720Z 〃 user=rtsp表示携带了流媒体控制信
自、 其中，相对RFC3261标准对该头域的ABNF语法可以定义如下
= "sip:" [ userinfo ] hostport
uri-pammeters [ headers ] = "sips:" [ userinfo〗hostport
uri-parameters [ headers ] = W uri-pammeter)
=transport-param / user-param / method-param
/ ttl-param / maddr-param / lr-param /
="user=" ( "phone" / "ip" / "rtsp"/other-user) 〃指示 =" " header *( "&" header )
=(hname "=" hvalue) / ("range=，，Range) 〃头域中指
SIP-URI
SIPS-URI
uri-parameters uri-parameter
other-param
user-par纖 进行rtsp协商
headers
示携带Range
Range = "Range" HCOLON ranges-list [exec-time] CRLF 〃
新增SIP URI中携带的header
ranges-list = ranges-spec *(COMMA ranges-spec)
=SEMI "time" EQUAL utc-time = 叩t-range / utc-range / smpte-range / range-ext =extension-format "=" range-value = l*(rtsp-unreserved / quoted-string /":") = smpte-type "=" smpte-range-spec
exec-time ranges-spec
range-ext
range-value
smpte-range
smpte-range-spec
smpte-type
smpte-type-extension
=(smpte-time "-" [ smpte-time ]) / ( "-" smpte-time ) "smpte" / "smpte-30-drop" / "smpte-25" / smpte-type-extension ;other timecodes may be added —■ token
smpte-time=1*2DIGIT ":" 1*2DIGIT ":" 1*2DIGIT [":"1*2DIGIT [ "." 1 "DIGIT ]]
npt-range= "npt=" npt-range-spec ; Section 3.5
npt-range-spec=(npt-time "-" [ npt-time ] ) / ( "-" npt-time )
npt-time= "now" / npt-sec / npt-hhmmss
npt-sec="DIGIT [ ""DIGIT]
叩t-hhmmss=npt-hh ":" npt-mm ":" npt-ss [ "." *DIGIT ]
npt-hh= 1*DIGIT ; any positive number
npt-mm=1承2DIGIT ; 0-59
npt-ss=1*2DIGIT ; 0-59
utc-r肌g6= "clock=" utc-range-spec ; Section 3.6
utc-range-spec=(utc-time "-" [ utc-time ] ) / ( "-" utc-time )
utc-time=utc-date "T" utc-clock "Z"
utc-date=8DIGIT ; < YYYYMMDD >
utc-clock=6DIGIT [ "." fraction ]; < HHMMSS.fraction >
fraction=1*DIGIT
其中在SIP URI的参数中携带了用于指示流媒体的播放位置信息(可以包括clock/time或smpte或npt指示)，这样即孑吏Control Server完全不支才争 RTSP,即对SIP中携带RTSP参数无法进行识别或相应处理，也可以根据此 SIP URI进行流媒体的定位并从定位的位置上开始播放。在本实施例中， clock/time或smpte或npt都是时钟的表示形式。smpte ( Society of Motion Picture and Television Engineers )用于表示流媒体移动图像的标准制定信息， 其7于时戮的表示形式为hour:minutes:seconds:frames.subframes , 如 smpte=10:00:00-10:07:00:05.01; npt为Normal Play Time,用于表示流i某体 相对开始位置的绝对位置信息，如叩t-12:05:03.3-表示从时间12:05:03中低 三帧到结尾；clock/time为ISO 8601标准定义的绝对时间信息，给出的是绝 对时间UTC。例如1996年11月8日14点37分20.25秒可以表示成 19961108T143720.25Z。
在本发明实施例中，对SIP-URI也可以采用如下两种方式
第一种方式
Sip:rtspclient@examplem.com;rtsp-range=clock%3Dx960213T143205Z-% 3Bx;time%3Dxl9970123T143720Z
其中不用携带user=rtsp参数而直接携带range头域信息来表示流媒体控
制4吕息;
第二种方式
Sip:rtspclient;rtsp-range=clock%3Dx960213T143205Z-%3Bx;time%3Dxl 9970123T143720Z@examplem.com
其中将range信息内容置入(^前的用户信息(userinfo )部分，可以表示 需要播放的媒体位置信息，即表示流媒体控制信息。
图5为本发明具体实施例一提供的实现控制流媒体的方法流程图，该方 法应用在基于IMS的IPTV业务构架中，其中Control Client为UE, Control Server为MF。在该实施例中，对于IPTV业务中的内容点播(COD, Content on Demend)或时移电视(Time-shifted TV ) , UE在获取的电子节目菜单 (EPG)中如果获得网络侧RTSP通道参数以及媒体通道信息，可以在 INVITE消息中携带，在经过了网络侧的SCF转发并同MF完成了 SIP初始 流媒体协商后，UE不需要建立立即同MF之间的RTSP通道。UE在INVITE 消息中可能仅需要浏览COD内容或从电视节目初始位置开始播放(TsTV业 务)，此时就不需要建立RTSP通道，而只需要在INVITE消息中携带流媒 体控制信息即可；如果UE在后续过程中需要对流媒体进行时移控制或暂停 控制时，就需要在建立RTSP通道之后完成该控制，这时可以依靠预先协商 的RTSP参数建立RTSP通道且在其上对通过媒体通道传输的流媒体进行控 制。
实现图5的具体步骤为
步骤501 、 UE向Core IMS发送INVITE消息，其中携带用于协商延迟
建立RTSP通道的RTSP参数、用于协商建立媒体通道的媒体请求信息以及 流媒体控制信息。
步骤502、 Core IMS和边界网关功能实体(BGF, Border Gateway Function )之间根据该INVITE消息对媒体资源进行资源预留。 步骤503、 Core IMS向SCF转发该INVITE消息。
步骤504、 SCF选择处理该INVITE消息的MF,向所选择的MF发送 INVITE消息。
在本步骤中，如何选^奪处理该INVITE消息的MF可以釆用现有技术。 步骤505、该MF接收到INVITE消息后，根据自身策略，处理该消息 携带的用于协商延迟建立RTSP通道的RTSP参数、用于协商建立媒体通道 的媒体请求信息以及流媒体控制信息，生成用于协商延迟建立RTSP通道的 RTS响应参数、用于协商建立i某体通道的流媒体相关的answer以及控制流 媒体响应信息携带在200中，发送给SCF。
步骤506、 SCF将该200转发给Core IMS。
步骤507、 Core IMS和BGF之间根据该200消息对媒体资源进行资源 预留。
步骤508、 Core IMS将该200消息转发给UE。
步骤509、 UE和MF之间根据协商好的媒体请求信息建立媒体通道， MF根据协商好的控制媒体信息将对应的流媒体通过该媒体通道传输给UE。
步骤510、用户对通过UE接收到的流媒体进行控制操作，UE判断该控 制操作需要RTSP消息才能完成，则根据协商好的RTSP参数发起建立RTSP 通道的过程。
步骤511、UE在建立的RTSP通道上向MF发送携带流媒体控制操作命 令的RTSP消息，对媒体通道传输的流媒体进行控制操作。
步骤512、 MF根据RTSP消息对流媒体完成控制操作后，返回控制结 果给UE。
在INVITE消息和MF返回的200消息中携带SDP描述的携带用于协商 延迟建立RTSP通道的RTSP参数以及流媒体控制信息与图4所述的过程相
同，这里不再赘述。
图6为本发明具体实施例二提供的实现控制流媒体的方法流程图，该方 法应用在基于IMS的IPTV业务构架中，其中Control Client为UE, Control Server为MF。该实施例是实现对网络提供的个人一见频录制(nPVR, Network Personal Video Recorder )业务的控制方法，其中使用了延迟建立RTSP通道 的方式。在该实施例中，对于nPVR业务，假设由nPVRSCF根据UE提交 的录制计划在录制事件到时发起SIP会话，此时管理nPVR SCF的nPVRMF 与管理用于录制流媒体的COD SCF的COD MF之间进行媒体通道和媒体控 制通道的协商，完成nPVR MF和COD MF之间的媒体通道和RTSP通道的 协商后，nPVR MF并未立刻同COD MF之间建立RTSP通道，因此此时二 者仅限于非常简单的流媒体录制控制，nPVR MF只要接收流媒体并进行本 地录制即可。但可能根据录制计划，在录制过程中或录制完成后会需要对流 媒体进行其他控制操作，例如根据录制计划，当录制到某个时刻，开始快进 到某个流媒体位置时再重新录制，此时nPVRSCF将根据预先的录制计划产 生对流媒体的复杂控制，此时nPVR SCF将通知该事件给nPVR MF, nPVR MF将根据协商好的RTSP通道参数同CODMF之间建立RTSP通道以完成 对流媒体的复杂控制。
图6所示的方法具体实现步骤为
步骤601、 nPVRSCF向nPVRMF发送SIP消息，请求用于协商延迟建 立RTSP通道的RTSP参数、用于协商建立媒体通道的媒体请求信息以及流 媒体控制信息。
步骤602、nPVRMF根据自身设置的策略，向nPVR回复SIP响应消息， 携带用于协商延迟建立RTSP通道的RTSP参数、用于协商建立i某体通道的 媒体请求信息以及流媒体控制信息。
步骤603、 nPVR SCF向COD SCF发起SIP初始流媒体协商过程，即发 送SIP协商消息，其中携带步骤602由nPVR MF回复的SIP响应消息携带
的信息。
步骤604、 COD SCF向COD MF转发SIP协商消息。
步骤605、 CODMF根据自身设置的策略以及接收到的SIP协商消息，
生成用于协商延迟建立RTSP通道的RTSP响应参数、用于协商建立々某体通
道的流媒体相关的answer以及控制流媒体响应信息，向COD SCF返回SIP
协商响应消息，其中携带生成的响应信息。
步骤606、 COD SCF向nPVR SCF转发该SIP协商响应消息。
步骤607、 nPVRSCF向nPVRMF发送ACK消息，携带步骤606所述
SIP协商响应消息携带的信息。
在该步骤中，已经在nPVR和COD两侧完成了 RTSP通道以及i某体通
道的协商。
步骤608、 nPVR MF通知nPVR SCF即将根据控制流媒体响应信息对建 立的媒体通道传输的流媒体开始录制。
在本步骤中，是通过TISPAN定义的Y2接口上报。
在本步骤中，COD MF可以将流媒体向nPVRMF通过建立的i某体通道 进行传输，nPVR MF对传输的流媒体进行本地录制。
步骤609、nPVR SCF根据设定的录制计划或由SSF接收到的录制搡作， 在某个时刻点，需要跳过当前广告或无关内容，例如球赛中场休息的10分 钟事件，则确定将媒体通道传输的流媒体暂停录制10分钟或快进10分钟， 这时nRVR SCF通知nPVR MF此时需要对通过i某体通道传输的流纟某体进行 复杂控制，需要发起建立RTSP通道。
步骤610、 nPVR MF同COD MF之间按照协商好的延迟建立RTSP通 道的RTSP参数建立RTSP通道后，发送对流媒体的控制操作命令，如发送 暂停录制10分钟或快进10分钟后，再次对流媒体进行录制，CODMF对流 媒体按照控制操作命令进行操作。
在图6中所述对延后建立RTSP通道以及对流媒体的录制操作可以参考 图4所述的步骤，此处不再赘述。
在图6中，Control Client为nPVR MF, Control Server为COD MF。
本发明实施例还提供一种实现流媒体控制的系统，如图7所示，该系统 包括Control Client和Control Server,其中，
Control Client和Control Server进行SIP初始流媒体协商过程中协商流 媒体控制信息，Control Server根据协商的流媒体控制信息确定要传输的流 媒体，发送给Control Client 。
在本发明实施例中，所述Control Client为第一 Control Client,所述 Control Server为第一 Control Server, 第一 Control Client在牙口第一 Control Server进行SIP初始流媒体协商过程中协商用于延迟建立媒体控制通道的媒 体控制参数，第一 Control Client和第一 Control Server之间根据所述媒体控 制参数延后建立媒体控制通道后，第一 Control Client在所建立的媒体控制 通道上向第一 Control Client发送控制操作命令，第一 Control Client根据通 过延后建立的媒体控制通道接收控制搡作命令，对通过媒体通道传输的流媒 体进行控制。
在具体实现时，Control Client和Control Server之间交互的流媒体控制 信息通过SIP消息携带传输，可以携带在SIP消息的range域中，或携带在 SIP消息的URI中。
相应地，Control Client和Control Server之间交互的用于延迟建立媒体 控制通道的媒体控制参数也通过SIP消息携带传输。
其中，Control Client具体结构如图8所示，包括协商模块和接收模块， 其中，协商模块在和Control Server进行SIP初始流媒体协商过程中协商流 媒体控制信息；接收模块接收Control Server发送的流媒体。
在图8中，所述Control Client还包括建立通道模块和发送模块，所述 协商模块，进一步在和Control Server进行SIP初始流媒体协商过程中协商 用于延迟建立媒体控制通道的媒体控制参数发送给建立通道模块，建立通道 模块根据接收的所述媒体控制参数延后建立媒体控制通道，发送模块，在所 建立的媒体控制通道上发送控制操作命令。
其中，Control Server具体结构如图9所示，包括协商模块和发送模块， 其中，协商模块，在和Control Client进行SIP初始流媒体协商过程中协商 流媒体控制信息发送给发送模块，发送模块根据接收的协商模块协商的流媒 体控制信息确定要传输的流媒体，发送给Control Client。
在具体实现时，Control Client收发的流媒体控制信息通过SIP消息携带 传输，可以携带在SIP消息的range域中，或携带在SIP消息的URI中。
相应地，Control Client收发的用于延迟建立媒体控制通道的媒体控制参 数也通过SIP消息携带传输。
在图9中，所述Control Server还进一步包括接收模块和执行模块，其 中，协商模块，进一步在和Control Client进行SIP初始流媒体协商过程中 协商用于延迟建立媒体控制通道的媒体控制参数；接收模块，通过延后建立 的媒体控制通道接收Control Client发送的控制操作命令发送给执行模块， 执行模块根据接收模块接收的所述命令对通过媒体通道传输的流媒体进行 控制。
在具体实现时，Control Server收发的流媒体控制信息通过SIP消息携 带传输，可以携带在SIP消息的range域中，或携带在SIP消息的URI中。
相应地，Control Server收发的用于延迟建立媒体控制通道的士某体控制 参数也通过SIP消息携带传输。
从上述本发明实施例详细叙述的方法及装置可以得出
第一，在对流媒体只有筒单的控制时，如录制或播放等控制，本发明实 施例通过在SIP初始流媒体协商过程中协商流媒体控制信息而实现对在媒体 通道传输的流媒体的控制，而不需要另外建立媒体控制通道对流媒体进行控 制。
第二，在无法确定后续是否对流媒体有其他控制或复杂控制时，为了避 免建立媒体控制通道而引起的资源浪费，在SIP初始流媒体协商过程中引入 协商延后建立媒体控制通道的机制来延后建立媒体控制通道。直到后续有对 流媒体的其他控制或复杂操作时，才通过在SIP初始流媒体协商过程中协商
好的媒体控制参数建立媒体控制通道后发送控制操作命令对媒体通道传输 的流媒体进行控制。
第三，在通过媒体通道传输流媒体的过程中，在当前没有建立媒体控制 通道但后续需要建立时，通过在SIP初始流媒体协商过程中提前协商好的媒 体控制参数，避免后续建立媒体控制通道时过多的消息交互，提高了控制媒 体流的反应时间，提高了用户的体验度。
以上是对本发明具体实施例的说明，在具体的实施过程中可对本发明的 方法进行适当的改进，以适应具体情况的具体需要。因此可以理解，根据本 发明的具体实施方式
只是起示范作用，并不用以限制本发明的保护范围。
权利要求
1、一种控制流媒体的方法，其特征在于，该方法包括控制服务器在与控制客户端的会话初始协议SIP初始流媒体协商过程中接收到流媒体控制信息，根据该流媒体控制信息控制传输给控制客户端的流媒体。
2、 如权利要求l所述的方法，其特征在于，所述流媒体控制信息携带 在SIP消息中媒体控制通道描述信息中，所述流媒体控制信息为播放流媒体 位置信息。
3、 如权利要求1所述的方法，其特征在于，所述流媒体控制信息携带 在SIP消息中的统一资源标识符中，所述流媒体控制信息为播放流J泉体位置 信息。
4、 如权利要求3所述的方法，其特征在于，所述流媒体控制信息是通 过在SIP消息中的统一资源标识符进行指定。
5、 如权利要求4所述的方法，其特征在于，所述流媒体控制信息通过 在SIP消息中的统一资源标识符指定的过程为通过统 一 资源标识符中的使用类型指定携带了流媒体控制信息；或者通 过统 一 资源标识符中的用户信息或统 一 资源标识符-参数指定来指定流媒体 控制信息。
6、 如权利要求l所述的方法，其特征在于，在与控制客户端的SIP初 始流媒体协商过程中，该方法还包括控制服务器在与控制客户端的SIP初始流媒体协商过程中协商延后建 立媒体控制通道；控制服务器接收到控制客户端通过延后建立的媒体控制通道传输的控 制操作命令，对传输给控制客户端的流媒体进行控制。
7、 如权利要求6所述的方法，其特征在于，在接收到控制客户端通过 延后建立的媒体控制通道传输的控制操作命令之前，该方法还包括 控制客户端根据设置对应于要建立媒体控制通道的控制操作命令或对 流媒体的控制规则，判断要发送的控制操作命令符合所设置的控制规则或为 所设置的控制操作命令时，根据协商结果延后建立媒体控制通道，通过延后 建立的媒体控制通道发送控制操作命令。
8、 一种实现流媒体控制的装置，其特征在于，该装置包括协商模块和 接收模块，其中，协商模块，用于在进行SIP初始流媒体协商过程中和控制服务器协商流媒体控制信息；接收模块，用于接收控制服务器发送的流媒体。
9、 如权利要求8所述的装置，其特征在于，所述装置还包括建立通道 模块和发送模块，其中，所述协商模块，进一步用于在进行SIP初始流媒体协商过程中和控制服 务器协商用于延迟建立媒体控制通道的媒体控制参数；建立通道模块，用于根据所述媒体控制参数延后建立媒体控制通道； 发送模块，用于在所建立的媒体控制通道上发送控制操作命令。
10、 一种实现流媒体控制的装置，其特征在于，该装置包括协商模块和 发送模块，其中，协商模块，用于在和控制客户端进行SIP初始流媒体协商过程中协商流 媒体控制信息；发送模块，用于根据协商模块协商的流媒体控制信息确定要传输的流媒 体，发送给控制客户端。
11、 如权利要求10所述的装置，其特征在于，该装置还进一步包括接 收模块和执行模块，其中，所述协商模块，进一步用于在和控制客户端进行SIP初始流媒体协商过 程中协商用于延迟建立媒体控制通道的媒体控制参数；接收模块，用于通过延后建立的媒体控制通道接收控制客户端发送的控 制操作命令；执行模块，用于根据接收模块接收的所述命令对通过媒体通道传输的流 媒体进行控制。
全文摘要
本发明公开了一种控制流媒体的方法及装置，其中，该方法包括控制服务器在与控制客户端的会话初始协议SIP初始流媒体协商过程中接收到流媒体控制信息，根据该流媒体控制信息控制传输给控制客户端的流媒体。本发明实施例提供的方法及装置在减少占用系统资源和控制反应时间的情况下实现对流媒体的控制。
文档编号H04L29/06GK101355552SQ20071013005
公开日2009年1月28日 申请日期2007年7月25日 优先权日2007年7月25日
发明者漆宝剑, 鹏 王, 雷晓松 申请人:华为技术有限公司