CN101355552A - 一种控制流媒体的方法及装置 - Google Patents

Abstract

本发明公开了一种控制流媒体的方法及装置，其中，该方法包括：控制服务器在与控制客户端的会话初始协议SIP初始流媒体协商过程中接收到流媒体控制信息，根据该流媒体控制信息控制传输给控制客户端的流媒体。本发明实施例提供的方法及装置在减少占用系统资源和控制反应时间的情况下实现对流媒体的控制。

Description

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

技术领域

本发明涉及通信网络中的流媒体业务，特别涉及一种控制流媒体的方法及装置。

背景技术

流媒体业务是近几年迅速发展的一种新业务，该业务利用流式传输技术，在包交换网络上，如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)和归属签约用户服务器(HSS，HomeSubscriber 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是一个应用层的控制协议，可以用来建立、修改和终止多媒体会话或会议，SIP也支持邀请参与者参加已经存在的会话，比如多方会议。

实时流协议(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，MediaDelivery 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)，其中包括传送控制子层以及传送功能实体，用于使用IMS Core预留的承载资源采用组播方式传输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通道用于完成对流媒体的控制，而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之间的媒体通道；

步骤206、Control Server通过媒体通道向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消息，建立媒体通道；

步骤304、Contro Client要对流媒体进行控制操作，则向Control Server发送再次访问(Re-INVITE)消息，携带用于进行RTSP通道协商的RTSP参数以及进行媒体通道协商的流媒体请求信息；

在本步骤中，进行媒体通道协商的流媒体请求信息与步骤301中请求的相同；

步骤305、接收到该Re-INVITE消息的Control Server向Control Client返回200消息，该消息携带进行RTSP通道协商的RTSP响应参数以及进行媒体通道协商的流媒体响应信息；

在本步骤中，进行媒体通道协商的流媒体响应信息与步骤302中响应的相同；

步骤306、Control Client向Control Server发送ACK消息，建立与ControlServer之间的RTSP通道；

步骤307、在建立的RTSP通道上，Control Client向Control Server发送PLAY控制操作命令，其中携带要播放流媒体的播放信息，包括：流媒体播放初始位置信息、或/和流媒体播放结束位置信息、或/和流媒体播放持续时长等信息；

步骤308、接收到PLAY控制操作命令的Control Server根据该命令携带的播放信息确定要播放的流媒体，向Control Client返回200消息，ControlServer向Control Client通过步骤303建立的媒体通道播放确定的流媒体。

从图3可以看出，该方法在对要在媒体通道传输的流媒体进行控制时，需要进行SIP重协商的三次握手交互以及建立RTSP通道后才能进行，这不仅占用了系统的资源，而且使对在媒体通道传输的流媒体的控制反应时间较长，降低了用户接收流媒体的体验度。

发明内容

本发明实施例提供一种控制流媒体的方法，该方法能够在减少占用系统资源和控制反应时间的情况下实现对流媒体的控制。

本发明实施例还提供一种控制流媒体的装置，该装置能够在减少占用系统资源和控制反应时间的情况下实现对流媒体的控制。

根据上述目的，本发明实施例的技术方案是这样实现的：

一种控制流媒体的方法，该方法包括：

控制服务器在与控制客户端的会话初始协议SIP初始流媒体协商过程中接收到流媒体控制信息，根据该流媒体控制信息控制传输给控制客户端的流媒体。

一种实现流媒体控制的装置，该装置包括协商模块和接收模块，其中，

协商模块，用于在和实现流媒体控制的进行SIP初始流媒体协商过程中协商流媒体控制信息；接收模块，用于接收实现流媒体控制的发送的流媒体。

从上述方案可以看出，本发明实施例在不需要对媒体通道传输的流媒体进行复杂控制时，就不建立媒体控制通道用于对流媒体进行控制，而只在进行SIP协商时将流媒体控制信息由Control Client发送给Control Server，由Control Server根据该信息在媒体通道上进行流媒体控制，从而不需要给媒体控制通道预留资源，在减少占用系统资源和控制反应时间的情况下实现对流媒体的控制。

附图说明

图1为现有技术基于IMS的IPTV业务的业务功能架构示意图；

图2为现有技术对流媒体进行控制的方法一流程图；

图3为现有技术对流媒体进行控制的方法二流程图；

图4为本发明实施例控制流媒体的方法流程图；

图5为本发明具体实施例一控制流媒体的方法流程图；

图6为本发明具体实施例二控制流媒体的方法流程图；

图7为本发明实施例控制流媒体的系统示意图；

图8为本发明实施例控制流媒体的Control Client示意图；

图9为本发明实施例控制流媒体的Control Server示意图。

具体实施方式

为使本发明的目的、技术方案和优点更加清楚，下面结合附图对本发明实施例作进一步的详细描述。

为了能够在减少占用系统资源和减少控制反应时间的情况下实现对流媒体的控制，本发明实施例在不需要对媒体通道传输的流媒体进行复杂控制操作时，如播放或录制控制操作，就不建立媒体控制通道用于对流媒体进行控制，而只在进行SIP协商时将流媒体控制信息由Control Client发送给Control Server，由Control Server根据该信息在媒体通道上进行流媒体的控制，从而减少了建立媒体控制通道占用的资源以及建立媒体控制通道所需要的时间。

更进一步地，本发明实施例还可以在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部分)：

v＝0//版本号

o＝alice 28908445262890844526IN IP4a.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 IP4a.atlanta.example.com//连接信息，其中网络类型为Internet，地址类型为IPV4，地址为a.atlanta.example.com

t＝00//媒体会话开始和结束时间都置为0表示起始和结束时间不受限

m＝application 9TCP/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-ranges:NPT//表示rtsp用到的时间表示类型为NPT方式

a＝fmtp:rtsp h-rangeclock＝19960213T143205Z-；time＝19970123T143720Z//此处给出了准备播放媒体的位置信息，从clock指示的位置开始播放。

a＝fmtp:rtsp h-supported:deferred//表示本端支持延迟建立RTSP通道方式。

a＝connection:new//表示该TCP连接为新建连接

a＝setup:active//表示本端是连接发起方

a＝rtspid m-stream:10//给出该媒体控制通道号，用于同媒体通道进行关联

m＝audio 6666RTP/AVP 0//用于描述媒体通道的信息，表示为音频，在6666端口收媒体，媒体类型号为0

a＝rtpmap:0PCMU/8000//表示媒体类型为G711U，8KHZ采样

a＝recvonly//表示该媒体只用于接收

a＝label:10//给该媒体通道一个标识，用于同前面媒体控制通道中的描述a＝rtsp-id m-stream:10进行关联

在该消息中，通过提供a＝fmtp:rtsp h-range....指定播放的流媒体起始位置、终止位置和持续时长中的一种或多种等流媒体控制信息，这样就可以不用建立RTSP通道，而直接在SIP协商过程中将流媒体控制信息发送给Control Server。

在该消息中，通过提供a＝fmtp:rtsp h-supported:deferred，通知ControlServer，Control Client支持延迟建立RTSP通道。Control Server如果不支持延迟建立RTSP通道，则可以在200消息的响应中带上a＝fmtp:rtsph-unsupported:deferred或不予理睬，此时双方需要采用立即建立RTSP通道方式在成功完成SIP初始流媒体协商后，建立RTSP通道；Control Server如果同意延迟建立RTSP通道，则在200消息的响应中携带a＝fmtp:rtsph-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 2808844564IN IP4b.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 IP4b.biloxi.example.com//连接信息，其中网络类型为Internet，地址类型为IPV4，地址为b.biloxi.example.com

t＝00//媒体会话开始和结束时间都置为0表示起始和结束时间不受限

m＝application 554TCP/RTSP rtsp//表示RTSP媒体控制通道信息，其中application表示该media line用于应用，554为RTSP使用的TCP连接本端监听端口，后面表示该TCP连接用于RTSP。

a＝connection:new//表示该TCP连接为新建连接

a＝setup:passive//表示本端为连接接收方

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，05Sep 200609:56:44GMT//给出时间

a＝fmtp:rtsp h-rtp-info:url＝″rtsp://b.biloxi.example.com/scene″

ssrc＝1631654733:seq＝53961；rtptime＝0

//表示同RTSP控制的媒体会话相关的RTP信息，例如其中的ssrc属性。

a＝rtspid m-stream:10//给该媒体控制通道一个标识，用于同其控制的媒体通道之间的关联

m＝audio 8888RTP/AVP 0//媒体通道的描述，表示媒体端8888，PT值为0

a＝rtpmap:0PCMU/8000//表示编解码类型为G711U，8KHZ采样

a＝sendonly//表示本端媒体只用于发送

a＝label:10//给该媒体通道一个表示，用于同前面媒体控制通道进行关联

在该消息中，如果Control Server不需要延迟建立RTSP通道，则需要丢弃a＝fmtp:rtsp h-supported:deferred或携带a＝fmtp:rtsph-unsupported:deferred(在示例中，已经丢弃了a＝fmtp:rtsph-supported:deferred，表示Control Server不延迟建立RTSP通道)；如果Control Server不支持RTSP，则将通过m＝application 0...方式来拒绝建立RTSP通道，即端口号为0(在示例中，Control Server支持RTSP)。需要注意的是，丢弃a＝fmtp:rtsp h-supported:deferred或携带a＝fmtp:rtsph-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向ControlServer发送对媒体通道传输的流媒体的控制操作命令。

步骤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-％3Bx；time％3Dx19970123T143720Z//user＝rtsp表示携带了流媒体控制信息。

其中，相对RFC3261标准对该头域的ABNF语法可以定义如下：

    SIP-URI         ＝″sip:″[userinfo]hostport

                        uri-p arameters[headers]

    SIPS-URI        ＝″sips:″[userinfo]hostport

                        uri-parameters[headers]

    uri-parameters  ＝*(″；″uri-parameter)

    uri-parameter   ＝transport-param/user-param/method-param

                                /ttl-param/maddr-param/lr-param/

other-param

    user-param      ＝″user＝″(″phone″/″ip″/“rtsp”/other-user)//指示

进行rtsp协商

    headers         ＝″？″header*(″&″header)

    header          ＝(hname ″＝″hvalue)/(“range＝”Range)//头域中指

示携带Range

    Range           ＝″Range″HCOLON ranges-list[exec-time]CRLF//

新增SIP URI中携带的header

    ranges-list     ＝ranges-spec*(COMMA ranges-spec)

    exec-time       ＝SEMI″time″EQUAL utc-time

    ranges-spec     ＝npt-range/utc-range/smpte-range

                      /range-ext

    range-ext       ＝extension-format″＝″range-value

    range-value     ＝1*(rtsp-unreserved/quoted-string/″:″)

    smpte-range     ＝smpte-type″＝″smpte-range-spec

    smpte-range-spec＝(smpte-time″-″[smpte-time])

                            /(″-″smpte-time)

    smpte-type      ＝″smpte″/″smpte-30-drop″

                    /″smpte-25″/smpte-type-extension

                    ；other timecodes may be added

    smpte-type-extension  ＝token

smpte-time        ＝1*2DIGIT″:″1*2DIGIT″:″1*2DIGIT

                    [″:″1*2DIGIT[″.″1*2DIGIT]]

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           ＝1*DIGIT[″.″*DIGIT]

npt-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-range         ＝″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 MotionPicture and Television Engineers)用于表示流媒体移动图像的标准制定信息，其对时戳的表示形式为：hour:minutes:seconds:frames.subframes，如smpte＝10:00:00-10:07:00:05.01；npt为Normal Play Time，用于表示流媒体相对开始位置的绝对位置信息，如npt＝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％3Dx19970123T143720Z

其中不用携带user＝rtsp参数而直接携带range头域信息来表示流媒体控制信息；

第二种方式：

Sip：rtspclient；rtsp-range＝clock％3Dx960213T143205Z-％3Bx；time％3Dx19970123T143720Z@examplem.com

其中将range信息内容置入@前的用户信息(userinfo)部分，可以表示需要播放的媒体位置信息，即表示流媒体控制信息。

以下列举两个具体的实施例说明本发明实施例提供的方法。

图5为本发明具体实施例一提供的实现控制流媒体的方法流程图，该方法应用在基于IMS的IPTV业务构架中，其中Control Client为UE，ControlServer为MF。在该实施例中，对于IPTV业务中的内容点播(COD，Contenton 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 GatewayFunction)之间根据该INVITE消息对媒体资源进行资源预留。

步骤503、Core IMS向SCF转发该INVITE消息。

步骤504、SCF选择处理该INVITE消息的MF，向所选择的MF发送INVITE消息。

在本步骤中，如何选择处理该INVITE消息的MF可以采用现有技术。

步骤505、该MF接收到INVITE消息后，根据自身策略，处理该消息携带的用于协商延迟建立RTSP通道的RTSP参数、用于协商建立媒体通道的媒体请求信息以及流媒体控制信息，生成用于协商延迟建立RTSP通道的RTS响应参数、用于协商建立媒体通道的流媒体相关的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，ControlServer为MF。该实施例是实现对网络提供的个人视频录制(nPVR，NetworkPersonal Video Recorder)业务的控制方法，其中使用了延迟建立RTSP通道的方式。在该实施例中，对于nPVR业务，假设由nPVR SCF根据UE提交的录制计划在录制事件到时发起SIP会话，此时管理nPVR SCF的nPVR MF与管理用于录制流媒体的COD SCF的COD MF之间进行媒体通道和媒体控制通道的协商，完成nPVR MF和COD MF之间的媒体通道和RTSP通道的协商后，nPVR MF并未立刻同COD MF之间建立RTSP通道，因此此时二者仅限于非常简单的流媒体录制控制，nPVR MF只要接收流媒体并进行本地录制即可。但可能根据录制计划，在录制过程中或录制完成后会需要对流媒体进行其他控制操作，例如根据录制计划，当录制到某个时刻，开始快进到某个流媒体位置时再重新录制，此时nPVR SCF将根据预先的录制计划产生对流媒体的复杂控制，此时nPVR SCF将通知该事件给nPVR MF，nPVRMF将根据协商好的RTSP通道参数同COD MF之间建立RTSP通道以完成对流媒体的复杂控制。

图6所示的方法具体实现步骤为：

步骤601、nPVR SCF向nPVR MF发送SIP消息，请求用于协商延迟建立RTSP通道的RTSP参数、用于协商建立媒体通道的媒体请求信息以及流媒体控制信息。

步骤602、nPVR MF根据自身设置的策略，向nPVR回复SIP响应消息，携带用于协商延迟建立RTSP通道的RTSP参数、用于协商建立媒体通道的媒体请求信息以及流媒体控制信息。

步骤603、nPVR SCF向COD SCF发起SIP初始流媒体协商过程，即发送SIP协商消息，其中携带步骤602由nPVR MF回复的SIP响应消息携带的信息。

步骤604、COD SCF向COD MF转发SIP协商消息。

步骤605、COD MF根据自身设置的策略以及接收到的SIP协商消息，生成用于协商延迟建立RTSP通道的RTSP响应参数、用于协商建立媒体通道的流媒体相关的answer以及控制流媒体响应信息，向COD SCF返回SIP协商响应消息，其中携带生成的响应信息。

步骤606、COD SCF向nPVR SCF转发该SIP协商响应消息。

步骤607、nPVR SCF向nPVR MF发送ACK消息，携带步骤606所述SIP协商响应消息携带的信息。

在该步骤中，已经在nPVR和COD两侧完成了RTSP通道以及媒体通道的协商。

步骤608、nPVR MF通知nPVR SCF即将根据控制流媒体响应信息对建立的媒体通道传输的流媒体开始录制。

在本步骤中，是通过TISPAN定义的Y2接口上报。

在本步骤中，COD MF可以将流媒体向nPVR MF通过建立的媒体通道进行传输，nPVR MF对传输的流媒体进行本地录制。

步骤609、nPVR SCF根据设定的录制计划或由SSF接收到的录制操作，在某个时刻点，需要跳过当前广告或无关内容，例如球赛中场休息的10分钟事件，则确定将媒体通道传输的流媒体暂停录制10分钟或快进10分钟，这时nRVR SCF通知nPVR MF此时需要对通过媒体通道传输的流媒体进行复杂控制，需要发起建立RTSP通道。

步骤610、nPVR MF同COD MF之间按照协商好的延迟建立RTSP通道的RTSP参数建立RTSP通道后，发送对流媒体的控制操作命令，如发送暂停录制10分钟或快进10分钟后，再次对流媒体进行录制，COD MF对流媒体按照控制操作命令进行操作。

在图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在和第一ControlServer进行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初始流媒体协商过程中提前协商好的媒体控制参数，避免后续建立媒体控制通道时过多的消息交互，提高了控制媒体流的反应时间，提高了用户的体验度。

以上是对本发明具体实施例的说明，在具体的实施过程中可对本发明的方法进行适当的改进，以适应具体情况的具体需要。因此可以理解，根据本发明的具体实施方式只是起示范作用，并不用以限制本发明的保护范围。

Claims (11)

1、一种控制流媒体的方法，其特征在于，该方法包括：

控制服务器在与控制客户端的会话初始协议SIP初始流媒体协商过程中接收到流媒体控制信息，根据该流媒体控制信息控制传输给控制客户端的流媒体。

2、如权利要求1所述的方法，其特征在于，所述流媒体控制信息携带在SIP消息中媒体控制通道描述信息中，所述流媒体控制信息为播放流媒体位置信息。

3、如权利要求1所述的方法，其特征在于，所述流媒体控制信息携带在SIP消息中的统一资源标识符中，所述流媒体控制信息为播放流媒体位置信息。

4、如权利要求3所述的方法，其特征在于，所述流媒体控制信息是通过在SIP消息中的统一资源标识符进行指定。

5、如权利要求4所述的方法，其特征在于，所述流媒体控制信息通过在SIP消息中的统一资源标识符指定的过程为：

通过统一资源标识符中的使用类型指定携带了流媒体控制信息；或者通过统一资源标识符中的用户信息或统一资源标识符-参数指定来指定流媒体控制信息。

6、如权利要求1所述的方法，其特征在于，在与控制客户端的SIP初始流媒体协商过程中，该方法还包括：

控制服务器在与控制客户端的SIP初始流媒体协商过程中协商延后建立媒体控制通道；

控制服务器接收到控制客户端通过延后建立的媒体控制通道传输的控制操作命令，对传输给控制客户端的流媒体进行控制。

7、如权利要求6所述的方法，其特征在于，在接收到控制客户端通过延后建立的媒体控制通道传输的控制操作命令之前，该方法还包括：

控制客户端根据设置对应于要建立媒体控制通道的控制操作命令或对流媒体的控制规则，判断要发送的控制操作命令符合所设置的控制规则或为所设置的控制操作命令时，根据协商结果延后建立媒体控制通道，通过延后建立的媒体控制通道发送控制操作命令。

8、一种实现流媒体控制的装置，其特征在于，该装置包括协商模块和接收模块，其中，

协商模块，用于在进行SIP初始流媒体协商过程中和控制服务器协商流媒体控制信息；

接收模块，用于接收控制服务器发送的流媒体。

9、如权利要求8所述的装置，其特征在于，所述装置还包括建立通道模块和发送模块，其中，

所述协商模块，进一步用于在进行SIP初始流媒体协商过程中和控制服务器协商用于延迟建立媒体控制通道的媒体控制参数；

建立通道模块，用于根据所述媒体控制参数延后建立媒体控制通道；

发送模块，用于在所建立的媒体控制通道上发送控制操作命令。

10、一种实现流媒体控制的装置，其特征在于，该装置包括协商模块和发送模块，其中，

协商模块，用于在和控制客户端进行SIP初始流媒体协商过程中协商流媒体控制信息；

发送模块，用于根据协商模块协商的流媒体控制信息确定要传输的流媒体，发送给控制客户端。

11、如权利要求10所述的装置，其特征在于，该装置还进一步包括接收模块和执行模块，其中，

所述协商模块，进一步用于在和控制客户端进行SIP初始流媒体协商过程中协商用于延迟建立媒体控制通道的媒体控制参数；

接收模块，用于通过延后建立的媒体控制通道接收控制客户端发送的控制操作命令；

执行模块，用于根据接收模块接收的所述命令对通过媒体通道传输的流媒体进行控制。

Images