CN101399759B - 一种业务提供实体对媒体流控制的方法、***和装置 - Google Patents
一种业务提供实体对媒体流控制的方法、***和装置 Download PDFInfo
- Publication number
- CN101399759B CN101399759B CN2007101615624A CN200710161562A CN101399759B CN 101399759 B CN101399759 B CN 101399759B CN 2007101615624 A CN2007101615624 A CN 2007101615624A CN 200710161562 A CN200710161562 A CN 200710161562A CN 101399759 B CN101399759 B CN 101399759B
- Authority
- CN
- China
- Prior art keywords
- media
- resource server
- rtsp
- control
- media resource
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N7/00—Television systems
- H04N7/16—Analogue secrecy systems; Analogue subscription systems
- H04N7/173—Analogue secrecy systems; Analogue subscription systems with two-way working, e.g. subscriber sending a programme selection signal
- H04N7/17309—Transmission or handling of upstream communications
- H04N7/17336—Handling of requests in head-ends
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
- H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
- H04N21/238—Interfacing the downstream path of the transmission network, e.g. adapting the transmission rate of a video stream to network bandwidth; Processing of multiplex streams
- H04N21/2387—Stream processing in response to a playback request from an end-user, e.g. for trick-play
Landscapes
- Engineering & Computer Science (AREA)
- Multimedia (AREA)
- Signal Processing (AREA)
- Telephonic Communication Services (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Mobile Radio Communication Systems (AREA)
Abstract
本发明公开了一种业务提供实体对媒体流控制的方法,用户设备与媒体资源服务器之间存在媒体流连接以及RTSP控制通道,包括如下步骤:业务提供实体***体资源服务器执行禁止用户终端的媒体流控制操作;业务提供实体发起对媒体流的控制操作,所述对媒体流的控制操作由媒体资源服务器执行;业务提供实体***体资源服务器执行恢复用户设备的媒体流控制操作。本发明还公开了另外一种业务提供实体对媒体流控制的方法、一种业务提供实体对媒体流控制的***以及一种业务提供实体。本发明可以实现在某些业务场景下业务提供实体控制指定媒体流进行VCR操作。
Description
技术领域
本发明涉及IP电视(IPTV)技术领域,特别涉及一种业务提供实体对媒体流控制的方法、***和装置。
背景技术
IPTV是一种利用宽带有线电视网,集互联网、多媒体、通讯等多种技术于一体,向家庭用户提供包括数字电视在内的多种交互式服务的崭新技术。IPTV使用传输控制协议/因特网协议(TCP/IP)作为承载协议进行单播、广播或组播视频业务,有效地将电视网、电话网和互联网三个领域结合在一起,是三网融合最具代表性的业务。
IP多媒体子***(IMS,IP Multimedia Subsystem)是一个独立于接入技术的基于IP的标准体系,IMS与现存的语音和数据网络(不论是如PSTN、ISDN、因特网等固定网络,还是如GSM、CDMA等移动网络)都可以互通。IMS体系使得通过各种类型的用户设备(UE)都可以建立对等的IP通信,并可以获得所需要的服务质量。除会话管理之外,IMS体系还涉及完成服务提供所必须的功能(例如注册、安全、计费、承载控制、漫游)。即IMS体系构成了IP核心网的核心。
为了实现IMS对固定网络用户接入的统一控制,在网络架构中引入了网络附着子***(NASS,Network Attachment Sub-System)和资源与接纳控制子***(RACS,Resource and Admission Control Subsystem)。NASS用于完成对UE附着于接入网络的管理,包括用户验证和网络地址分配、位置管理。RACS则主要用于完成策略控制、资源预留和接纳控制,业务/应用层面可利用RACS请求接入网预留相关的资源。
基于IMS的IPTV架构,将直接重用IMS的相关功能实体,并通过适当增加新的功能实体以及对现有功能实体相关功能的扩充,实现对IPTV业务的支持。
图1示出了现有技术中基于IMS的IPTV架构的一种组网示意图。如图1所示,每一个IPTV业务由一对IPTV业务控制功能(SCF,Service Control Functions)和IPTV媒体功能(MF,Media Functions)组成。其中,SCF是一种会话初始协议(SIP,Session Initiation Protocol)应用服务器,作为业务提供实体,其任务主要包括:(1)会话初始化时进行授权;(2)实施修改流程,检查用户的数据,以决定是否允许用户访问该业务;(3)账号控制;(4)选择相应的MF。MF作为媒体资源服务器,负责媒体流的控制和递交,可被分为媒体控制功能(MCF)和媒体递交功能(MDF)。其中,MCF的任务主要包括:(1)处理媒体流的控制;(2)监视MDF的状态(可选);(3)管理和UE的交互;(4)在MCF控制多个MDF时,选择一个MDF;(5)感知不同MDF的状态和内容的分发;(5)产生计费信息。MDF的任务主要包括:(1)处理媒体流的递交;(2)上报状态给MCF
在流媒体应用中,UE通过与MCF建立实时流协议(Real Time Stream Protocol,RTSP)控制通道,***体流实现卡带式影像录放机(Video Cassette Recording,VCR)操作,包括快进、后退、暂停、定位、正常播放等。某些情况下,运营商或业务提供商希望通过SCF实现对指定的媒体流进行VCR控制操作。而目前的IPTV中没有相关技术实现SCF对媒体流的控制操作,因此,需要提出一种技术方案,使得SCF能够对媒体流进行VCR控制操作。如果SCF和UE都能够对媒体流进行控制操作,则会出现VCR控制冲突,因此还需要解决所述VCR冲突的问题。
发明内容
有鉴于此,本发明实施例提出一种业务提供实体对媒体流控制的方法,能够实现业务提供实体对媒体流的控制。用户设备与媒体资源服务器之间存在媒体流连接以及RTSP控制通道,包括如下步骤:
业务提供实体***体资源服务器执行禁止用户终端的媒体流控制操作;
业务提供实体发起对媒体流的控制操作,所述对媒体流的控制操作由媒体资源服务器执行;
业务提供实体***体资源服务器执行恢复用户设备的媒体流控制操作。
本发明实施例还提出一种业务提供实体对媒体流控制的***,包括:
媒体资源服务器,用于建立自身与用户设备之间的媒体流;还用于建立自身与用户设备的RTSP控制通道;以及根据来自业务提供实体的禁止指示,禁止自身与用户设备的RTSP控制通道;
业务提供实体,用于向所述媒体资源服务器发送对所述媒体流的控制命令;用于向媒体资源服务器发送禁止指示,所述禁止指示用于禁止所述用户设备与媒体资源服务器之间的RTSP控制通道;
所述媒体资源服务器还用于根据所述业务提供实体的控制命令,对媒体流进行控制操作。
本发明实施例还提出一种业务提供实体,包括:
媒体流控制模块,用于向媒体资源服务器发起对媒体流的控制操作;所述媒体流控制模块进一步包括:
避免冲突单元,用于向媒体资源服务器发送禁止指示,所述禁止指示用于禁止用户设备与媒体资源服务器之间的RTSP控制通道;还用于向媒体资源服务器发送允许指示,所述允许指示用于允许所述用户设备与媒体资源服务器之间已被禁止的RTSP控制通道。
从以上技术方案可以看出,业务提供实体通过暂时禁止用户设备的媒体流控制操作,然后业务提供实体向媒体资源服务器发送媒体流控制命令,可以实现在某些业务场景下业务提供实体控制指定媒体流进行后退、快进、暂停、定位的操作。
附图说明
图1为现有技术中基于IMS的IPTV架构的一种组网示意图;
图2为本发明实施例的基本架构流程图;
图3为本发明第一实施例的信令流程图;
图4为本发明第二实施例的信令流程图;
图5为媒体控制的通用架构;
图6为本发明第三实施例的信令流程图;
图7为本发明第四实施例的信令流程图;
图8为本发明第五实施例的信令流程图;
图9为本发明第六实施例的信令流程图;
图10为本发明实施例中的业务提供实体结构框图。
具体实施方式
为使本发明的目的、技术方案和优点更加清楚,下面结合附图对本发明作进一步的详细阐述。
以TISPAN的IPTV架构为例,本发明实施例中的业务提供实体为业务控制功能实体SCF,媒体资源服务器为媒体功能实体MF。而媒体功能实体MF可以包括媒体控制功能实体MCF和媒体交付功能实体MDF。业务开展过程中,业务控制功能实体SCF与媒体控制功能实体MCF进行交互实现业务,媒体控制功能实体MCF***体交付功能实体MDF完成媒体处理和交付。本发明实施例中,不再描述MDF与MCF之间的交互过程,而将两者作为整体描述为MF。
在IMS架构中,本发明实施例中的业务提供实体为应用服务器AS,媒体资源服务器为媒体资源功能实体MRF。而媒体资源功能实体MRF包括媒体资源功能控制实体MRFC和媒体资源功能处理实体MRFP。业务开展过程中,应用服务器AS与媒体资源功能控制实体MRFC进行交互实现业务,媒体资源功能控制实体MRFC***体资源功能处理实体MRFP完成媒体处理和交付。
以下以TISPAN IPTV为业务场景描述实施例,其相关流程同样可应用于IMS架构下AS与MRFC的交互,在实施例中就不再重复描述。
本发明方案的第一个目的就是实现SCF对媒体流进行后退、快进、暂停、定位等VCR控制操作。图2示出了本发明方案的总体流程框架,在UE与MF之间已经存在媒体流连接的情况下,执行如下步骤:
步骤201a:SCF业务触发,发起对UE与MF间媒体流的控制;
步骤202a:SCF发起媒体流的控制操作;
步骤203a:MF执行所述对媒体流的控制操作。
本发明方案的另一个目的是解决SCF与UE同时进行媒体流VCR控制所引起的VCR控制冲突。在UE与MF之间已经存在媒体流以及RTSP控制通道的情况下,执行如下步骤:
步骤201b:在SCF发起媒体流的控制操作之前,SCF发起禁止所述UE与MF之间的控制通道;
步骤202b:在SCF发起媒体流的控制操作之后,SCF发起激活所述UE与MF之间的控制通道。
上述两个方案也可以一起使用,简单地说,就是将步骤201b添加到步骤201a和步骤202a之间,而将步骤202b添加到步骤203a之后。
根据具体实现方式的不同,下面通过三个实施例对实现SCF的VCR操作进行详细阐述。
实施例一:RTSP控制方式
RTSP是应用级协议,控制实时数据的发送。RTSP提供了一个可扩展框架,使实时数据(如音频与视频)的受控、点播传送成为可能。数据源包括现场数据(如直播)与存储在剪辑中数据(如VOD等)。该协议目的在于控制多个数据传送会话,提供选择传送通道的方法,传送通道如UDP、组播UDP与TCP,提供基于RTP选择传输机制的方法。
RTSP控制方式包括:
1、SCF与MF通过会话描述协议(SDP,Session Description Protocol)协商,建立一个SCF与MF间的RTSP通道与被控制的媒体流之间的关联;
2、SCF通过RTSP通道***体流;
3、完成控制操作后,释放SCF与MF间的RTSP通道,基于通道重用等原因,RTSP通道也可以不释放。
本实施例的具体实现流程如图3所示,包括如下步骤:
步骤301~306:UE通过SCF与MF进行SIP SDP交互,建立了媒体流。
步骤307:SCF上触发业务,需要发起对UE媒体流的控制。
步骤308:SCF向MF发送会话内邀请(INVITE)消息,携带SDP offer,新建一个SCF与MF间的RTSP控制通道,
下面给出该邀请消息的一个示例:
INVITE sip:MF.example.com SIP/2.0
Via:...
Route:...
Max-Forwards:...
From:...
To:...
Call-ID:...
CSeq:...
v=0
o=SCF 2000000020000001IN IP4scf.example.com
s=
c=IN IP4uehost.example.com
t=00
m=video 30100RTP/AVP 3132
a=rtpmap:31H261/90000
a=label:1
m=application 9TCP/RTSP rtsp
a=fmtp:rtsp version:2.0
a=rtspid m-stream:1
m=application 9TCP/RTSP rtsp /*新建的SCF与MF间的RTSP通道*/
c=IN IP4scf.example.com
a=fmtp:rtsp version:2.0
a=rtspid m-stream:1
a=connection:new
a=setup:active
步骤309:MF返回200OK,携带SDP应答(SDP answer)。
下面给出所述200OK消息的一个示例:
SIP/2.0200OK
Via:...
Max-Forwards:...
From:...
To:...
Call-ID:...
CSeq:...
v=0
o=MF 3000000030000000IN IP4MF.example.com
s=
c=IN IP4MF.example.com
t=00
m=video 50100RTP/AVP 3132
a=rtpmap:31H261/90000
a=label:1
m=application 60010TCP/RTSP rtsp
a=fmtp:rtsp version:2.0
a=rtspid m-stream:1
m=application 60020TCP/RTSP rtsp /*新建的SCF与MF间的RTSP通道*/
a=fmtp:rtsp version:2.0
a=rtspid m-stream:1
a=connection:new
a=setup:passive
步骤310:SCF发送ACK确认,SCF与MF间建立RTSP通道。
步骤311:SCF通过所述RTSP通道向MF发送RTSP命令***体流,MF执行所述命令,进行相应的VCR操作。
步骤312:SCF向MF发送会话内INVITE消息,携带SDP offer,将新建的SCF与MF间的RTSP通道释放;某些场景下基于通道重用的考虑也可以不释放该RTSP通道。
下面给出所述INVITE消息的一个示例:
INVITE sip:MF.example.com SIP/2.0
Via:...
Route:...
Max-Forwards:...
From:...
To:...
Call-ID:...
CSeq:...
v=0
o=SCF 2000000020000002IN IP4scf.example.com
s=
c=IN IP4uehost.example.com
t=00
m=video 30100RTP/AVP 3132
a=rtpmap:31H261/90000
a=label:1
m=application 9TCP/RTSP rtsp
a=fmtp:rtsp version:2.0
a=rtspid m-stream:1
m=application 0TCP/RTSP rtsp /*将新建的SCF与MF间的RTSP通道释放*/
c=IN IP4scf.example.com
a=fmtp:rtsp version:2.0
a=rtspid m-stream:1
a=connection:new
a=setup:active
步骤313:MF返回200OK,携带SDP answer。
下面给出所述200OK消息的一个示例:
SIP/2.0200OK
Via:...
Max-Forwards:...
From:...
To:...
Call-ID:...
CSeq:...
v=0
o=MF 3000000030000000IN IP4MF.example.com
s=
c=IN IP4MF.example.com
t=00
m=video 50100RTP/AVP 3132
a=rtpmap:31H261/90000
a=label:1
m=application 60010TCP/RTSP rtsp
a=fmtp:rtsp version:2.0
a=rtspid m-stream:1
m=application 0TCP/RTSP rtsp /*将新建的SCF与MF间的RTSP通道释
放*/
a=fmtp:rtsp version:2.0
a=rtspid m-stream:1
a=connection:new
步骤314:SCF发送ACK确认。
通过以上流程,实现了SCF通过RTSP控制通道对UE与MF之间的媒体流进行控制操作。
实施例二:SIP消息控制方式
SIP是由Interne工程任务组(IETF)制订的多媒体通信***框架协议之一,是用于建立、改变或结束多媒体会话的应用层协议,与实时传输协议(RTP,Real Timing Transmission Protocol)/实时传输控制协议(RTCP,Real-time Transport Control Protocol)、SDP、RTSP、域名***(DNS,Domain Name System)等协议配合,共同完成IMS中的会话建立及媒体协商;一旦建立会话,媒体流将使用RTP协议在承载层中直接传送,在一次会话中可以灵活的交互多种媒体。
SIP消息控制方式包括:
SCF向MF发送关联媒体流所属会话的SIP消息,该SIP消息中携带控制指示,用于***体流;所述控制指示包括:快进、后退、暂停、定位、正常播放等;
本实施例的具体实现流程如图4所示,包括如下步骤:
步骤401~406:UE通过SCF与MF进行SIP SDP交互,建立媒体流。
步骤407:SCF上触发业务,发起对UE媒体流的控制。
步骤408:SCF向MF发送携带后退指示的INFO消息,***体流后退;
步骤409:MF返回200OK响应消息;
步骤410:SCF向MF发送携带定位指示的INFO消息,***体流定位;
步骤411:MF返回200OK响应消息;
步骤412:SCF向MF发送携带正常播放指示的INFO消息,***体流正常播放;
步骤413:MF返回200OK响应消息;
作为实施例,下面给出一个XML描述方式的媒体流控制的指示:
1、定义MIME Type:application/RTSP-control+xml
2、定义XML名字空间Namespace:urn:ieft:params:xml:ns:rtsp-control
3、控制脚本可以如下:
<?xml version=″1.0″encoding=″UTF-8″?>
<rtsp-control xmlns=″urn:ietf:params:xml:ns:rtsp-policy″
xmlns:xsi=″http://www.w3.org/2001/XMLSchema-instance″>
</play> /*正常播放*/
</rtsp-control>
<?xml version=″1.0″encoding=″UTF-8″?>
<rtsp-control xmlns=″urn:ietf:params:xml:ns:rtsp-policy″
xmlns:xsi=″http://www.w3.org/2001/XMLSchema-instance″>
</pause> /*暂停*/
</rtsp-control>
<?xml version=″1.0″encoding=″UTF-8″?>
<rtsp-control xmlns=″urn:ietf:params:xml:ns:rtsp-policy″
xmlns:xsi=″http://www.w3.org/2001/XMLSchema-instance″>
<goto type=″time″> /*按时间定位*/
2005-08-15T10:20:00.000-05:00
</goto>
<?xml version=″1.0″encoding=″UTF-8″?>
<rtsp-control xmlns=″urn:ietf:params:xml:ns:rtsp-policy″
xmlns:xsi=″http://www.w3.org/2001/XMLSchema-instance″>
<goto type=″file″> /*按文件偏移定位,偏移量为19881千字节*/
19881k
</goto>
</rtsp-control>
<?xml version=″1.0″encoding=″UTF-8″?>
<rtsp-control xmlns=″urn:ietf:params:xml:ns:rtsp-policy″
xmlns:xsi=″http://www.w3.org/2001/XMLSchema-instance″>
<fastmove direct=″forward″> /*按2倍速率快进,direct设为″back″,
则按2倍速率后退*/
2
</fastmove></rtsp-control>
当然,还存在其它的方式描述媒体流的控制指示。如通过已有的SIP头域或定义新的SIP头域携带指示,但其表达的思想类似,在此就不在重复举例。使用SIP INFO消息只是一种实施例,其它SIP消息,如MESSAGE也可用在该流程中替换INFO实现相同的功能,在此就不在重复举例。
实施例三:媒体控制消息方式
IETF的一个草案(draft-boulton-sip-control-framework-04.txt)定义了一个媒体控制的通用架构,如图5所示,该架构定义了三个逻辑角色:媒体控制服务器(Control Server)、媒体控制客户端(Control Client)和媒体控制通道(Control Channel),其中,
媒体控制服务器为逻辑实体,用于接受媒体控制客户端的媒体处理请求消息,执行具体的媒体处理操作,如:放音、录音、媒体混合等;
媒体控制客户端为逻辑实体,向媒体控制服务器发送消息,请求处理媒体资源;
媒体控制通道为媒体控制客户端通过SIP与媒体控制服务器间进行SDP交互,协商建立的基于可靠连接的传递控制消息的通道。
该架构中,媒体控制客户端与媒体控制服务器通过SIP SDP交互建立媒体控制通道,媒体控制客户端通过媒体控制通道向媒体控制服务器发送媒体控制消息,实现媒体控制处理。在基于TISPAN的IPTV架构中,MF为媒体控制服务器,SCF为媒体控制客户端;在IMS***中,MRF为媒体控制服务器,AS为媒体控制客户端。
媒体控制消息方式包括:
1、如果待控制的媒体流所属的SCF与MF间的媒体会话没有对应的媒体控制通道,SCF与MF通过SDP协商建立一个对应该媒体会话的媒体控制通道;
2、SCF通过通道2向MF发送媒体控制消息携带控制指示***体流;这样的控制指示包括:快进、后退、暂停、定位、正常播放等。
3、释放SCF与MF间新建的媒体控制通道即通道2,基于某些原因,例如通道重用等,媒体控制通道也可以不释放。
本实施例的具体实现流程如图6所示,包括如下步骤:
步骤601~606:UE通过SCF与MF进行SIP SDP交互,建立了媒体流和RTSP控制通道。
步骤607:SCF上触发业务,需发起对UE媒体流的控制;
步骤608:SCF向MF发送会话内INVITE消息,携带SDP offer,通过SDP协商建立媒体控制通道。
下面给出所述INVITE消息的一个示例:
INVITE sip:MF.example.com SIP/2.0
Via:...
Route:...
Max-Forwards:...
From:...
To:...
Call-ID:...
CSeq:...
v=0
o=SCF 2000000020000001IN IP4scf.example.com
s=
c=IN IP4uehost.example.com
t=00
m=video 30100RTP/AVP 3132
a=rtpmap:31H261/90000
a=label:1
m=application 9TCP/RTSP rtsp
a=fmtp:rtsp version:2.0
a=rtspid m-stream:1
m=application 7575TCP/ESCS /*新建的SCF与MF间的媒体控制通道*/
c=IN IP4scf.example.com
a=setup:active
a=connection:new
步骤609:MF返回200OK,携带SDP answer;
下面给出所述200OK消息的一个示例:
SIP/2.0200OK
Via:...
Max-Forwards:...
From:...
To:...
Call-ID:...
CSeq:...
v=0
o=MF 3000000030000000IN IP4MF.example.com
s=
c=IN IP4MF.example.com
t=00
m=video 50100RTP/AVP 3132
a=rtpmap:31H261/90000
a=label:1
m=application 60010TCP/RTSP rtsp
a=fmtp:rtsp version:2.0
a=rtspid m-stream:1
m=application 7563TCP/ESCS /*新建的SCF与MF间的媒体控制通道*/
a=setup:passive
a=connection:new
步骤610:SCF发送ACK确认,SCF与MF间建立媒体控制通道;
步骤611:SCF通过媒体控制通道向MF发送媒体控制消息,携带快进、后退、定位、暂停、正常播放指示,***体流;
步骤612:SCF向MF发送媒体控制消息MRequest携带快进指示,***体流快进;
步骤613:MF执行媒体流快进操作,并返回MResponse响应消息;
步骤614:SCF向MF发送媒体控制消息MRequest携带暂停指示,***体流暂停;
步骤615:MF执行媒体流暂停操作,并返回MResponse响应消息;
步骤616:SCF结束对媒体流的控制,向MF发送会话内INVITE消息,携带SDP offer,释放新建的媒体控制通道;某些场景下媒体控制通道也可以不释放,因此该步骤可省略。
下面给出所述INVITE消息的一个示例:
INVITE sip:MF.example.com SIP/2.0
Via:...
Route:...
Max-Forwards:...
From:...
To:...
Call-ID:...
CSeq:...
v=0
o=SCF 2000000020000002IN IP4scf.example.com
s=
c=IN IP4uehost.example.com
t=00
m=video 30100RTP/AVP 3132
a=rtpmap:31H261/90000
a=label:1
m=application 9TCP/RTSP rtsp
a=fmtp:rtsp version:2.0
a=rtspid m-stream:1
m=application 0TCP/ESCS /*释放新建的SCF与MF间的媒体控制通道*/
c=IN IP4scf.example.com
a=setup:active
a=connection:new
步骤617:MF返回200OK,携带SDP answer;
下面给出所述200OK消息的一个示例:
SIP/2.0200OK
Via:...
Max-Forwards:...
From:...
To:...
Call-ID:...
CSeq:...
v=0
o=MF 3000000030000000IN IP4MF.example.com
s=
c=IN IP4MF.example.com
t=00
m=video 50100RTP/AVP 3132
a=rtpmap:31H261/90000
a=label:1
m=application 60010TCP/RTSP rtsp
a=fmtp:rtsp version:2.0
a=rtspid m-stream:1
m=application 0TCP/ESCS /*释放新建的SCF与MF间的媒体控制通道*/
a=setup:passive
a=connection:new
步骤618:SCF发送ACK确认。
媒体控制消息携带媒体流的控制指示实施例可以采用与SIP消息控制方式实施类似的方案。
以下再通过三个实施例对避免VCR操作冲突的实现过程进行详细阐还。
实施例四:SDP协商方式来避免VCR操作冲突
本实施例的具体实现流程如图7所示,包括如下步骤:
步骤701~706:UE通过SCF与MF进行SIP SDP交互,建立了媒体流和RTSP控制通道(RTSP Channel),该RTSP控制通道称为通道1。
步骤707:SCF上触发业务,需要禁止UE的VCR操作。
步骤708:SCF向MF发送会话内邀请(INVITE)消息,携带SDP offer,将UE的RTSP通道即通道1设为去激活状态。
下面给出该邀请消息的一个示例:
INVITE sip:MF.example.com SIP/2.0
Via:...
Route:...
Max-Forwards:...
From:...
To:...
Call-ID:...
CSeq:...
v=0
o=SCF 2000000020000001IN IP4scf.example.com
s=
c=IN IP4uehost.example.com
t=00
m=video 30100RTP/AVP 3132
a=rtpmap:31H261/90000
a=label:1
m=application 9TCP/RTSP rtsp
a=fmtp:rtsp version:2.0
a=rtspid m-stream:1
a=inactive /*将UE的RTSP通道设为去激活状态*/
步骤709:MF返回2000K,携带SDP应答(SDP answer)。
下面给出所述200OK消息的一个示例:
SIP/2.0200OK
Via:...
Max-Forwards:...
From:...
To:...
Call-ID:...
CSeq:...
v=0
o=MF 3000000030000000IN IP4MF.example.com
s=
c=IN IP4MF.example.com
t=00
m=video 50100RTP/AVP 3132
a=rtpmap:31H261/90000
a=label:1
m=application 60010TCP/RTSP rtsp
a=fmtp:rtsp version:2.0
a=rtspid m-stream:1
a=inactive /*将UE的RTSP通道设为去激活状态*/
步骤710:SCF发送ACK确认。
步骤711:SCF向UE发送会话内INVITE消息,携带SDP offer,将UE的RTSP通道设为去激活状态,从而使UE知道RTSP通道被禁用;
以下给出所述INVITE消息的一个示例:
INVITE sip:uehost.example.com SIP/2.0
Via:...
Route:...
Max-Forwards:...
From:...
To:...
Call-ID:...
CSeq:...
v=0
o=SCF 3000000030000001IN IP4scf.example.com
s=
c=IN IP4MFhost.example.com
t=00
m=video 50100RTP/AVP 3132
a=rtpmap:31H261/90000
a=label:1
m=application 60010TCP/RTSP rtsp
a=fmtp:rtsp version:2.0
a=rtspid m-stream:1
a=inactive /*将UE的RTSP通道设为去激活状态*/
步骤712:UE返回200OK,携带SDP answer;
以下给出所述200OK消息的一个示例:
SIP/2.0200OK
Via:...
Max-Forwards:...
From:...
To:...
Call-ID:...
CSeq:...
v=0
o=UE 6000000060000000IN IP4MF.example.com
s=
c=IN IP4uehost.example.com
t=00
m=video 80100RTP/AVP 3132
a=rtpmap:31H261/90000
a=label:1
m=applic ation 9TCP/RTSP rtsp
a=fmtp:rtsp version:2.0
a=rtspid m-stream:1
a=inactive /*将UE的RTSP通道设为去激活状态*/
步骤713:SCF发送ACK确认;
步骤714:SCF与MF进行SDP协商,恢复UE的VCR操作;
步骤715:SCF向MF发送会话内INVITE消息,携带SDP offer,将UE的RTSP通道设为激活状态;
以下给出所述INVITE消息的一个示例:
INVITE sip:M F.example.com SIP/2.0
Via:...
Route:...
Max-Forwards:...
From:...
To:...
Call-ID:...
CSeq:...
v=0
o=SCF 2000000020000002IN IP4scf.example.com
s=
c=IN IP4 uehost.example.com
t=00
m=video 50100RTP/AVP 3132
a=rtpmap:31H261/90000
a=label:1
m=application 9TCP/RTSP rtsp
a=fmtp:rtsp version:2.0
a=rtspid m-stream:1
a=sendrecv /*将UE的RTSP通道设为激活状态*/
步骤716:MF返回200OK,携带SDP answer;
以下给出所述200OK消息的一个示例:
SIP/2.0200OK
Via:...
Max-Forwards:...
From:...
To:...
Call-ID:...
CSeq:...
v=0
o=MF 3000000030000000IN IP4MF.example.com
s=
c=IN IP4M F.example.com
t=00
m=video 50100RTP/AVP 3132
a=rtpmap:31H261/90000
a=label:1
m=application 60010TCP/RTSP rtsp
a=fmtp:rtsp version:2.0
a=rtspid m-stream:1
a=sendrecv /*将UE的RTSP通道设为激活
状态*/
步骤717:SCF发送ACK确认;
步骤718:SCF向UE发送会话内INVITE消息,携带SDP offer,将UE的RTSP通道设为激活状态,从而使UE知道RTSP通道可用;
以下给出所述INVITE消息的一个示例:
INVITE sip:uehost.example.com SIP/2.0
Via:...
Route:...
Max-Forwards:...
From:...
To:...
Call-ID:...
CSeq:...
v=0
o=SCF 3000000030000002IN IP4scf.example.com
s=
c=IN IP4MFhost.example.com
t=00
m=video 50100RTP/AVP 3132
a=rtpmap:31H261/90000
a=label:1
m=application 60010TCP/RTSP rtsp
a=fmtp:rtsp version:2.0
a=rtspid m-stream:1
a=sendrecv /*将UE的RTSP通道设为激活状态*/
步骤719:UE返回200OK,携带SDP answer;
以下给出所述200OK消息的一个示例:
SIP/2.0200OK
Via:...
Max-Forwards:...
From:...
To:...
Call-ID:...
CSeq:...
v=0
o=UE 6000000060000000IN IP4MF.example.com
s=
c=IN IP4uehost.example.com
t=00
m=video 80100RTP/AVP 3132
a=rtpmap:31H261/90000
a=label:1
m=application 9TCP/RTSP rtsp
a=fmtp:rtsp version:2.0
a=rtspid m-stream:1
a=sendrecv /*将UE的RTSP通道设为激活状态*/
步骤720:SCF发送ACK确认;
上述实施例流程中SCF分别向MF和UE发送会话内的INVITE消息没有先后顺序,可以同时向MF和UE发送,不必等200OK返回;SCF还可以向MF和UE发送更新(UPDATE)消息实现SDP协商。
第四实施例流程中给出了去激活RTSP通道的一种方式,还可以将RTSP通道设为MF只发送a=sendonly,UE只接收的模式a=recvonly,实现去激活;或者将RTSP控制通道关联的媒体流去关联,如:a=rtspid m-stream:1中,将rtspid m-stream后面关联的媒体流标签1去掉;
通过以上流程,实现了SCF通过与MF之间进行SDP协商,禁止UE对该媒体流的控制操作,然后再恢复UE对媒体流的控制操作,这样可以避免出现VCR操作冲突。
实施例五:通过SIP消息来避免VCR冲突。
本实施例的具体实现流程如图8所示,包括如下步骤:
步骤801~806:UE通过SCF与MF进行SIP SDP交互,建立媒体流和RTSP控制通道,该RTSP控制通道称为通道1。
步骤807:SCF上触发业务,需要禁止UE的VCR操作。
步骤808:SCF向MF发送会话内INVITE消息,携带SDP offer,通过SDP协商将UE的RTSP通道即通道1设为去激活状态,禁止UE的RTSP操作。
下面给出所述INVITE消息的一个示例:
INVITE sip:MF.example.com SIP/2.0
Via:...
Route:...
Max-Forwards:...
From:...
To:...
Call-ID:...
CSeq:...
v=0
o=SCF 2000000020000001IN IP4scf.example.com
s=
c=IN IP4uehost.example.com
t=00
m=video 30100RTP/AVP 3132
a=rtpmap:31H261/90000
a=label:1
m=application 9TCP/RTSP rtsp
a=fmtp:rtsp version:2.0
a=rtspid m-stream:1
a=inactive /*将UE的RTSP通道设为去激活状态*/
步骤809:MF返回200OK,携带SDP answer。
下面给出所述200 OK消息的一个示例:
SIP/2.0200OK
Via:...
Max-Forwards:...
From:...
To:...
Call-ID:...
CSeq:...
v=0
o=MF 30000000 30000000IN IP4MF.example.com
s=
c=IN IP4M F.example.com
t=00
m=video 50100RTP/AVP 3132
a=rtpmap:31H261/90000
a=label:1
m=application 60010TCP/RTSP rtsp
a=fmtp:rtsp version:2.0
a=rtspid m-stream:1
a=inactive /*将UE的RTSP通道设为去激活状态*/
步骤810:SCF发送ACK确认。
步骤811:SCF结束对媒体流的控制,向MF发送会话内INVITE消息,携带SDP offer,通过SDP协商将UE的RTSP通道即通道1设为激活状态。
下面给出所述INVITE消息的一个示例:
INVITE sip:MF.example.com SIP/2.0
Via:...
Route:...
Max-Forwards:...
From:...
To:...
Call-ID:...
CSeq:...
v=0
o=SCF 2000000020000002IN IP4scf.example.com
s=
c=IN IP4uehost.example.com
t=00
m=video 30100RTP/AVP 3132
a=rtpmap:31H261/90000
a=label:1
m=application 9TCP/RTSP rtsp
a=fmtp:rtsp version:2.0
a=rtspid m-stream:1
a=sendrecv /*将UE的RTSP通道设为激活状态*/
步骤812:MF返回200OK,携带SDP answer。
下面给出所述200OK消息的一个示例:
SIP/2.0200OK
Via:...
Max-Forwards:...
From:...
To:...
Call-ID:...
CSeq:...
v=0
o=MF 30000000 30000000I N IP4 MF.example.com
s=
c=IN IP4MF.example.com
t=00
m=video 50100RTP/AVP 3132
a=rtpmap:31H261/90000
a=label:1
m=application 60010TCP/RTSP rtsp
a=fmtp:rtsp version:2.0
a=rtspid m-stream:1
a=sendrecv /*将UE的RTSP通道设为激活状态*/
步骤813:SCF发送ACK确认。
实施例六:通过媒体控制消息避免VCR冲突
本实施例的具体实现流程如图9所示,包括如下步骤:
步骤901~906:UE通过SCF与MF进行SIP SDP交互,建立媒体流和RTSP控制通道;
步骤907:SCF上触发业务,需要禁止UE的VCR操作,SCF与MF进行SDP协商,禁止UE的VCR操作;
步骤908~910:如果SCF与MF间没有可用的媒体控制通道,SCF向MF发送会话内INVITE消息,携带SDP offer,协商建立媒体控制通道;
步骤911:SCF向MF发送媒体控制消息MRequest携带禁止UE的VCR操作指示;
步骤912:MF返回响应消息MResponse;
步骤913:SCF通知UE VCR操作被禁止;
步骤914:SCF向MF发送媒体控制消息MRequest携带允许UE的VCR操作指示;
步骤915:MF返回响应消息MResponse;
步骤916:SCF通知UE允许执行VCR操作。
本发明实施例中的用于实现业务提供实体对媒体流控制的***,至少包括:
媒体资源服务器,用于与用户设备建立媒体流;
业务提供实体,用于向所述媒体资源服务器发送对所述媒体流的控制命令;
则所述媒体资源服务器根据所述媒体资源服务器的控制命令,对媒体流进行控制操作。
根据以上实施例方案,业务提供实体与媒体资源服务器之间的交互关系分为如下三类:
第一类参照本发明第一实施例的方案,通过业务提供实体和媒体资源服务器之间进行SDP协议协商,业务提供实体和媒体资源服务器之间建立RTSP控制通道;业务提供实体通过所述业务提供实体与媒体资源服务器之间的RTSP控制通道,向媒体资源服务器发起对媒体流的控制操作。在完成控制操作后,业务提供实体可以拆除所述与媒体服务器之间的RTSP控制通道,或者出于通道重用的考虑,不拆除该RTSP控制通道。
第二类参照本发明第二实施例方案,业务提供实体向媒体资源服务器发送携带媒体控制命令的SIP消息;媒体资源服务器根据所述SIP消息中携带的媒体控制命令,进行媒体流控制操作。这种交互关系不需要建立二者之间的控制通道。
第三类参照本发明第三实施例方案,所述业务提供实体用于与媒体资源服务器建立媒体控制通道,并通过所述业务提供实体与媒体资源服务器之间的媒体控制通道,向媒体资源服务器发起对媒体流的控制操作。
无论上述三类中的那一类,如果媒体资源服务器与用户设备之间已经建立了RTSP控制通道,则所述业务提供实体还要向媒体资源服务器发送禁止指示,所述禁止指示用于禁止所述用户设备与媒体资源服务器之间的RTSP控制通道;
所述媒体资源服务器根据来自业务提供实体的禁止指示,禁止自身与用户设备的RTSP控制通道。
在业务提供实体完成对媒体流的控制之后,业务提供实体进一步用于向媒体资源服务器发送允许指示,所述允许指示用于允许所述用户设备与媒体资源服务器之间已被禁止的RTSP控制通道。
所述业务提供实体为SCF,媒体资源服务器为MF;
或者,所述业务提供实体为AS,媒体资源服务器为MRF。
本发明实施例的业务提供实体的结构如图10所示,包括:
媒体流控制模块1010,用于向媒体资源服务器发起对媒体流的控制操作。
所述媒体流控制模块1010包括:
避免冲突单元1011,用于向媒体资源服务器发送禁止指示,所述禁止指示用于禁止用户设备与媒体资源服务器之间的RTSP控制通道。所述禁止指示可以是会话内INVITE消息,携带SDP offer,将用户设备的的RTSP控制通道设为去激活状态。所述设为去激活,可以是将RTSP控制通道设为禁用,还可以将RTSP控制通道设为媒体资源服务器只发送a=sendonly,用户设备只接收的模式a=recvonly,实现去激活;或者将RTSP控制通道关联的媒体流去关联。
避免冲突单元1011还用于向媒体资源服务器发送允许指示,所述允许指示用于允许所述用户设备与媒体资源服务器之间已被禁止的RTSP控制通道。允许指示可以为会话内INVITE消息,携带SDP offer,将用户设备的RTSP通道设为激活状态。
所述媒体流控制模块1010还包括如下任一组单元:
第一组:RTSP控制通道单元1012和发送单元1013,RTSP控制通道单元1012用于与媒体资源服务器进行交互,建立业务提供实体与媒体资源服务器之间的RTSP控制通道。
所述交互过程为:RTSP控制通道单元1012向媒体资源服务器发送会话内INVITE消息,携带SDP offer,新建一个业务提供实体与媒体资源服务器之间的RTSP控制通道媒体资源服务器收到该INVITE消息后,向RTSP控制通道单元1012返回一个200OK消息,携带SDP应答;RTSP控制通道单元1012再向媒体资源服务器发送ACK确认。
发送单元1013用于通过所述业务提供实体与媒体资源服务器之间的RTSP控制通道,向媒体资源服务器发送媒体流控制命令。
第二组:SIP消息发送单元1014,用于向媒体资源服务器发送携带媒体控制命令的SIP消息。所述携带媒体控制命令的SIP消息可以是INFO消息,媒体资源服务器收到INFO消息后,执行相应的媒体流控制操作。
第三组:媒体控制通道单元1015,用于与媒体资源服务器进行交互,建立业务提供实体与媒体资源服务器之间的媒体控制通道;所述交互过程可以包括:
媒体控制通道单元1015向媒体资源服务器发送会话内INVITE消息,携带SDP offer;媒体资源服务器返回200OK,携带SDP answer;媒体控制通道单元1015再向媒体资源服务器发送ACK确认。
发送单元1016,用于通过所述业务提供实体与媒体资源服务器之间的媒体控制通道,向媒体资源服务器发送媒体流控制命令。所述媒体流控制命令携带在媒体控制消息(MRequest)中。
本发明解决了在某些业务场景下业务提供实体需要控制指定媒体流进行后退、快进、暂停、定位的操作。
以上所述仅为本发明的较佳实施例而已,并不用以限制本发明,凡在本发明的精神和原则之内所作的任何修改、等同替换和改进等,均应包含在本发明的保护范围之内。
Claims (15)
1.一种业务提供实体对媒体流控制的方法,其特征在于,用户设备与媒体资源服务器之间存在媒体流连接以及RTSP控制通道,包括如下步骤:
业务提供实体***体资源服务器执行禁止用户终端的媒体流控制操作;
业务提供实体发起对媒体流的控制操作,所述对媒体流的控制操作由媒体资源服务器执行;
业务提供实体***体资源服务器执行恢复用户设备的媒体流控制操作。
2.根据权利要求1所述的方法,其特征在于,所述业务提供实体***体资源服务器,禁止用户设备的媒体流控制操作包括:
业务提供实体向媒体资源服务器发送会话内第一邀请消息,所述第一邀请消息将所述用户设备的RTSP控制通道设为去激活状态;
所述媒体资源服务器根据所述第一邀请消息,将所述用户设备的RTSP控制通道设为去激活状态。
3.根据权利要求2所述的方法,其特征在于,所述业务提供实体***体资源服务器,恢复用户设备的媒体流控制操作包括:
业务提供实体向媒体资源服务器发送会话内第二邀请消息,所述第二邀请消息将所述用户设备的RTSP控制通道设为激活状态;
所述媒体资源服务器根据所述第二邀请消息,将所述用户设备的RTSP控制通道设为激活状态。
4.根据权利要求2所述的方法,其特征在于,所述的去激活状态是禁止RTSP控制通道传递控制消息。
5.根据权利要求3所述的方法,其特征在于,所述的激活状态是允许RTSP控制通道传递控制消息。
6.一种业务提供实体对媒体流控制的***,其特征在于,包括:
媒体资源服务器,用于建立自身与用户设备之间的媒体流;还用于建立自身与用户设备的RTSP控制通道;以及根据来自业务提供实体的禁止指示,禁止自身与用户设备的RTSP控制通道;
业务提供实体,用于向所述媒体资源服务器发送对所述媒体流的控制命令;用于向媒体资源服务器发送禁止指示,所述禁止指示用于禁止所述用户设备与媒体资源服务器之间的RTSP控制通道;
所述媒体资源服务器还用于根据所述业务提供实体的控制命令,对媒体流进行控制操作。
7.根据权利要求6所述的***,其特征在于,所述业务提供实体进一步用于向媒体资源服务器发送允许指示,所述允许指示用于允许所述用户设备与媒体资源服务器之间已被禁止的RTSP控制通道。
8.根据权利要求6或7所述的***,其特征在于,所述业务提供实体用于和媒体资源服务器建立RTSP控制通道,并通过所述业务提供实体与媒体资源服务器之间的RTSP控制通道,向媒体资源服务器发起对媒体流的控制操作。
9.根据权利要求6或7所述的***,其特征在于,所述业务提供实体用于向媒体资源服务器发送携带媒体控制命令的SIP消息;
所述媒体资源服务器用于根据所述SIP消息中携带的媒体控制命令,进行媒体流控制操作。
10.根据权利要求6或7所述的***,其特征在于,所述业务提供实体用于与媒体资源服务器建立媒体控制通道,并通过所述业务提供实体与媒体资源服务器之间的媒体控制通道,向媒体资源服务器发起对媒体流的控制操作。
11.根据权利要求6或7所述的***,其特征在于,所述业务提供实体为业务控制功能实体SCF,媒体资源服务器为媒体控制功能实体MCF或媒体功能实体MF;
或者,所述业务提供实体为应用服务器AS,媒体资源服务器为媒体资源功能实体MRF。
12.一种业务提供实体,其特征在于,包括:
媒体流控制模块,用于向媒体资源服务器发起对媒体流的控制操作;
所述媒体流控制模块进一步包括:
避免冲突单元,用于向媒体资源服务器发送禁止指示,所述禁止指示用于禁止用户设备与媒体资源服务器之间的RTSP控制通道;还用于向媒体资源服务器发送允许指示,所述允许指示用于允许所述用户设备与媒体资源服务器之间已被禁止的RTSP控制通道。
13.根据权利要求12所述的业务提供实体,其特征在于,所述媒体流控制模块包括:
RTSP控制通道单元,用于与媒体资源服务器进行交互,建立业务提供实体与媒体资源服务器之间的RTSP控制通道;
发送单元,用于通过所述业务提供实体与媒体资源服务器之间的RTSP控制通道,向媒体资源服务器发送媒体流控制命令。
14.根据权利要求12所述的业务提供实体,其特征在于,所述媒体流控制模块包括:
SIP消息发送单元,用于向媒体资源服务器发送携带媒体控制命令的SIP消息。
15.根据权利要求12所述的业务提供实体,其特征在于,所述媒体流控制模块包括:
媒体控制通道单元,用于与媒体资源服务器进行交互,建立业务提供实体与媒体资源服务器之间的媒体控制通道;
发送单元,用于通过所述业务提供实体与媒体资源服务器之间的媒体控制通道,向媒体资源服务器发送媒体流控制命令。
Priority Applications (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN2007101615624A CN101399759B (zh) | 2007-09-29 | 2007-09-29 | 一种业务提供实体对媒体流控制的方法、***和装置 |
PCT/CN2008/071819 WO2009043241A1 (fr) | 2007-09-29 | 2008-07-30 | Procédé, système et dispositif permettant à une entité prestataire de services de réguler un flux multimédia |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN2007101615624A CN101399759B (zh) | 2007-09-29 | 2007-09-29 | 一种业务提供实体对媒体流控制的方法、***和装置 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN101399759A CN101399759A (zh) | 2009-04-01 |
CN101399759B true CN101399759B (zh) | 2011-07-06 |
Family
ID=40518027
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN2007101615624A Expired - Fee Related CN101399759B (zh) | 2007-09-29 | 2007-09-29 | 一种业务提供实体对媒体流控制的方法、***和装置 |
Country Status (2)
Country | Link |
---|---|
CN (1) | CN101399759B (zh) |
WO (1) | WO2009043241A1 (zh) |
Families Citing this family (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN101808348B (zh) * | 2010-04-12 | 2014-01-01 | 中兴通讯股份有限公司 | 一种会话管理指令的处理方法、装置和*** |
CN106912030B (zh) * | 2015-12-22 | 2021-03-12 | 大唐移动通信设备有限公司 | 一种组呼方法及装置 |
Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN1741633A (zh) * | 2004-08-27 | 2006-03-01 | 华为技术有限公司 | 实现电路域移动流媒体点播的***及其方法 |
CN1960254A (zh) * | 2006-11-22 | 2007-05-09 | 北京邮电大学 | 基于ip多媒体子***的视频电话通行证业务实现方法和*** |
CN1992607A (zh) * | 2005-12-30 | 2007-07-04 | 西门子通信技术(北京)有限公司 | 一种基于ip的多媒体子***的通信应用方法 |
Family Cites Families (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN100403794C (zh) * | 2004-12-29 | 2008-07-16 | 华为技术有限公司 | 一种实现流媒体业务的视讯终端和方法 |
-
2007
- 2007-09-29 CN CN2007101615624A patent/CN101399759B/zh not_active Expired - Fee Related
-
2008
- 2008-07-30 WO PCT/CN2008/071819 patent/WO2009043241A1/zh active Application Filing
Patent Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN1741633A (zh) * | 2004-08-27 | 2006-03-01 | 华为技术有限公司 | 实现电路域移动流媒体点播的***及其方法 |
CN1992607A (zh) * | 2005-12-30 | 2007-07-04 | 西门子通信技术(北京)有限公司 | 一种基于ip的多媒体子***的通信应用方法 |
CN1960254A (zh) * | 2006-11-22 | 2007-05-09 | 北京邮电大学 | 基于ip多媒体子***的视频电话通行证业务实现方法和*** |
Also Published As
Publication number | Publication date |
---|---|
WO2009043241A1 (fr) | 2009-04-09 |
CN101399759A (zh) | 2009-04-01 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN101547189B (zh) | 一种CoD业务的建立方法,***和装置 | |
EP2175591B1 (en) | A method, a system, a device and a computer program readable medium for realizing the services of network televison | |
CN100579209C (zh) | 基于ngn网络实现时移电视业务的方法及***、媒体资源设备 | |
US8307049B2 (en) | Method and device for obtaining media description information of IPTV services | |
EP2071838A1 (en) | A system, device and method of suppoting ims terminals to share iptv services | |
CN101378491B (zh) | 一种实现画中画视频的方法、***及实体装置 | |
EP2736219A1 (en) | Switching between delivery methods in an IPTV communication network | |
US20100122281A1 (en) | Method and system for controlling authorization of service resources | |
CN101378492B (zh) | 一种实现网络录制的方法、***及装置 | |
CN101299748A (zh) | 在iptv业务中应用终端能力信息的方法、***及装置 | |
EP2299707A1 (en) | Interactive iptv system and content pushing method thereof | |
CN101547402A (zh) | 一种建立iptv多播业务的方法及设备 | |
CN101399759B (zh) | 一种业务提供实体对媒体流控制的方法、***和装置 | |
CN101415250B (zh) | Ip互联网络电视***中会话建立的方法、***及实体 | |
CN101741723B (zh) | 网络中的分布式资源管理 | |
CN101453402A (zh) | 一种对媒体流控制的方法、***及设备 | |
CN101378401B (zh) | 业务资源授权控制的方法、***和设备 | |
CN101340428A (zh) | 媒体服务器切换过程中提供媒体流的方法及*** | |
CN101588277B (zh) | 基于ims的iptv***的互连装置及其启动、点播和直播方法 | |
CN101588534B (zh) | 基于ims的iptv***的互连装置及其启动、点播和直播方法 | |
CN101588533B (zh) | 基于ims的iptv***的互连装置及其启动、点播和直播方法 | |
CN101355552A (zh) | 一种控制流媒体的方法及装置 | |
CN101399725B (zh) | 用户终端、vcr操作的网络控制方法、装置 | |
CN101459572A (zh) | 一种在ip分组网中实现关联媒体流的方法及装置 | |
CN101588535B (zh) | 基于ims的iptv***的互连装置及其启动、点播和直播方法 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
C06 | Publication | ||
PB01 | Publication | ||
C10 | Entry into substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
C14 | Grant of patent or utility model | ||
GR01 | Patent grant | ||
CF01 | Termination of patent right due to non-payment of annual fee |
Granted publication date: 20110706 Termination date: 20140929 |
|
EXPY | Termination of patent right or utility model |