基于 NGN网络实现时移电视业务的方法及系统、 媒体资源设备 本申请要求于 2006年 3月 2日提交中国专利局、申请号为 200610034107.3、 发明名称为"一种在基于 NGN网络实现时移电视业务的方法及其系统,,的中国 专利申请的优先权, 其全部内容通过引用结合在本申请中。 技术领域
本发明涉及 NGN 网络中实现时移电视的技术, 具体涉及一种基于 NGN 网络实现时移电视业务的方法及系统、 媒体资源设备。
背景技术
时移电视(shift TV )是随着宽带网絡的成熟应运而生的一种视频业务, 是目前发展势头迅猛的互联网电视(IPTV, Internet Protocol Television )所能 提供的业务形式之一, 它所提供的服务能够让用户在看直播电视节目的时候, 实现对节目的暂停、后退等操作,并能够快进到当前直播电视正在播放的时刻。
现有技术中一种实现时移电视的方法为基于现有 IP网络的实现时移电视 业务的解决方案:
如图 1所示, 整个系统由头端 101、 中间件 102、 视频点播(VOD ) 系统 103以及机项盒 104等构成, 其中:
头端 101用于接收电视节目并进行编码以用于 IP网络传送; 中间件 102 为用户终端提供节目单并处理用户对节目的控制操作; VOD系统 103从头端 101 接收电视节目并进行录制, 在用户使用时移操作时为用户提供单播节目 源; 机顶盒 104接收节目解码后传输节目内容给显示终端显示, 它与中间件 102交互为用户提供节目单显示, 接受用户控制指令并与网络交互完成控制。
在所述系统中使用时移电视业务的基本过程为:
机顶盒 104开始从中间件 102获取节目单,根据节目单在机顶盒 104加入 播放所选节目的组播组接收电视节目, 该节目是以组播方式发送的;
若用户选择节目暂停,或者快退操作, 则机顶盒 104向中间件 102发出请 求, 中间件 102与 VOD系统 103交互定位对应的单播节目源并传递地址给中 间件 102, 中间件 102反馈给机顶盒 104;
随后机顶盒 104从 VOD 系统 103 获取单播节目流并使用实时流协议 ( RTSP, Real Time Streaming Protocol )对该节目进行控制。 若用户选择快进 并赶上直播节目 , 则机顶盒 104再次切换到组播接收状态。
上述方案属于针对现有 IP 网络的方案, 并不一定适用于下一代网络 ( NGN, Next Generation Network )„
NGN是基于分组技术的融合型网络, 以分组交换为主, 釆用承载与控制 分离的架构。 其架构图分为业务层和传送层, 其中业务层包括: 公共交换电话 网 /综合业务数字网( PSTN/ISDN, Public Switched Telephone Network/ Integrated Services Digital Network )仿真子系统、互联网协议多媒体子系统( IMS , Internet protocol Multimedia Subsystem )、 其它应用子系统, 以及被多个应用子系统共 享的用户数据和基于这些业务层子系统向用户提供业务的应用服务器 ( Application Server )。
其中, IMS 是第三代移动通信合作伙伴项目 (3GPP , 3rd Generation Partnership Project ) R5阶段增加的宽带码分多址( WCDMA, Wideband Code Division Multiple Access ) 网络中叠加在已有分组域之上的一个子系统, 引入 SIP协议作为业务控制协议, 提供丰富的多媒体业务; IMS中的会话建立由会 话发起协议( SIP, Session Initiation Protocol ), 实时传输协议 /实时传输控制协 议 ( RTP/RTCP, Real-time Transport Protocol/Real-time Transport Control Protocol )、 会话描述协议(SDP, Session Description Protocol )、 RTSP以及域 名服务( DNS , Domain Name Service )等协议配合完成。
IMS 中主要的功能实体包括控制用户注册、 会话等功能的呼叫控制实体 CSCF、提供各种业务逻辑控制功能的 AS、 集中管理用户签约数据的归属用户 服务器 HSS 以及用于实现与电路交换网互通的媒体网关控制功能 /IP多媒体- 媒体网关(MGCF / IM-MGW ), 用户通过当前所在地代理节点代理-呼叫控 制功能实体 ( P-CSCF )接入 IMS, 会话和业务触发控制及与 AS的业务控制 交互则由其注册地的归属域服务节点 S-CSCF (服务-呼叫控制功能实体)完 成。
也就是说, NGN支持采用 SIP通讯的方式, 而在现有技术中, 业务的请 求和控制信令是通过 HTTP/RTSP实现的, 并没有充分利用 SIP的潜在能力,
所以现有技术中实现时移电视的方法并不适用于 NGN。
发明内容
本发明的实施例提供一种基于 NGN 网络实现时移电视业务的方法及系 统、 媒体资源设备, 可以在 NGN网络中实现时移电视业务。
本发明的一个实施例提供一种基于下一代网络实现时移电视业务的方法, 包括:
终端发起的业务请求经过呼叫会话控制功能实体路由至应用服务器; 应用服务器根据所述业务请求向媒体资源实体发起资源请求;
媒体资源实体向应用服务器返回业务请求响应;所述业务请求响应中至少 携带媒体资源实体确定的媒体传输参数;
所述应用服务器经过会话控制功能实体将所述业务请求响应路由至终端; 根据所述确定的媒体传输参数, 终端与媒体资源实体建立组播业务流; 当终端请求进行业务流控制时,媒体资源实体和终端进行单播协商,根据 单播协商结果向终端发送单播业务流。
本发明的另一个实施例提供一种基于下一代网络实现时移电视业务的方 法, 包括:
终端发起的业务请求经过呼叫会话控制功能实体路由至应用服务器;所述 业务请求中携带终端的实时流协议媒体控制通道参数;
应用服务器根据所述业务请求向媒体资源控制功能实体发起资源请求; 媒体资源控制功能实体和媒体资源承载实体进行交互后,向应用服务器返 回业务请求响应;所述业务请求响应中携带媒体资源承载实体确定的实时流协 议媒体控制通道参数;
所述症用服务器经过呼叫会话控制功能实体将所述业务请求响应路由至 终端;
根据所述确定的实时流协议媒体控制通道参数,终端与媒体资源承载实体 建立实时流协议连接;
终端与媒体资源承载实体使用所述实时流协议连接协商媒体传输参数,建 立组播业务流;
当终端请求进行业务流控制时, 某体资源承载实体和终端进行单播协商,
根据单播协商结果向终端发送单播业务流。
本发明的再一个实施例提供一种基于下一代网络实现时移电视业务的方 法, 包括:
终端发起的业务请求经过呼叫会话控制功能实体路由至应用服务器;所述 业务请求中携带终端的实时流协议媒体控制通道参数;
应用服务器根据所述业务请求向媒体资源控制功能实体发起资源请求; 媒体资源控制功能实体和媒体资源承载实体进行交互后,向应用服务器返 回业务请求响应;所述业务请求响应中携带媒体资源控制功能实体确定的实时 流协议媒体控制通道参数;
所迷应用服务器经过呼叫会话控制功能实体将所述业务请求响应路由至 终端;
根据所述确定的实时流协议媒体控制通道参数,终端与媒体资源控制功能 实体建立实时流协议连接;
终端使用所述实时流协议连接通过媒体资源控制功能实体与媒体资源承 载实体协商媒体传输参数, 建立组播业务流;
当终端请求进行业务流控制时, 媒体资源承载实体和终端进行单播协商, 根据单播协商结果向终端发送单播业务流。
本发明的又一个实施例提供一种基于下一代网络实现时移电视业务的系 统, 包括: 应用服务器、 媒体资源控制功能实体、 媒体资源承载实体、 代理呼 叫会话控制功能实体和服务呼叫会话控制功能实体; 其中,
应用服务器用于^^据来自所述终端的业务请求向媒体资源控制功能实体 发起资源请求, 所述业务请求中至少携带终端的媒体传输参数; 将来自所述媒 体资源控制功能实体的业务请求响应路由至终端;
媒体资源控制功能实体用于和媒体资源承载实体进行交互,向应用服务器 返回业务请求响应;所述业务请求响应中至少携带媒体资源承载实体确定的媒 体传输参数;
媒体资源承载实体用于确定媒体传输参数, 根据所述确定的媒体传输参 数, 与终端建立组播业务流; 在终端请求进行业务流控制时, 和终端进行单播 协商, 根据单播协商结果向终端发送单播业务流;
代理呼叫会话控制功能实体用于转发终端和服务呼叫会话控制功能实体 之间的请求和响应消息;
服务呼叫会话控制功能实体用于根据触发规则将业务请求触发到应用服 务器, 对消息进行路由。
本发明的另外一个实施例提供一种基于下一代网络实现时移电视业务的 系统, 包括: 应用服务器、 媒体资源控制功能实体、 媒体资源承载实体、 代理 呼叫会话控制功能实体和服务呼叫会话控制功能实体; 其中,
应用服务器用于根据来自所述终端的业务请求向媒体资源控制功能实体 发起资源请求, 所述业务请求中携带终端的实时流协议媒体控制通道参数; 将 来自所述媒体资源控制功能实体的业务请求响应路由至终端;
媒体资源控制功能实体用于和媒体资源承载实体进行交互,向应用服务器 返回业务请求响应;所述业务请求响应中携带媒体资源承载实体确定的实时流 协议媒体控制通道参数;
媒体资源承载实体用于确定实时流协议媒体控制通道参数,根据所述确定 的实时流协议媒体控制通道参数, 与终端建立实时流协议连接; 使用所述实时 流协议连接与终端协商媒体传输参数,建立组播业务流; 在终端请求进行业务 流控制时, 和终端进行单播协商, 根据单播协商结果向终端发送单播业务流; 代理呼叫会话控制功能实体用于转发终端和月 务呼叫会话控制功能实体 之间的请求和响应消息;
服务呼叫会话控制功能实体用于根据触发规则将业务请求触发到应用服 务器, 对消息进行路由。
本发明的再一个实施例提供一种媒体资源设备装置, 包括: 媒体资源控制 功能实体以及媒体资源承载实体; 其中,媒体资源控制功能实体用于和媒体资 源承载实体进行交互, 向应用服务器返回业务请求响应; 所述业务请求响应中 至少携带媒体资源承载实体确定的媒体传输参数;
媒体资源承载实体用于确定媒体传输参数, 才 据所述确定的媒体传输参 数, 与终端建立组播业务流; 在终端请求进行业务流控制时, 和终端进行单播 协商, 根据单播协商结果向终端发送单播业务流。
本发明的另一个实施例提供一种媒体资源设备装置, 包括:媒体资源控制
功能实体以及媒体资源承载实体; 其中,
媒体资源控制功能实体用于和媒体资源承载实体进行交互,向应用服务器 返回业务请求响应;所述业务请求响应中携带媒体资源承载实体确定的实时流 协议媒体控制通道参数;
媒体资源承载实体用于确定实时流协议媒体控制通道参数,根据所述确定 的实时流协议媒体控制通道参数,与终端建立实时流协议连接;使用所述实时 流协议连接与终端协商媒体传输参数,建立组播业务流; 在终端请求进行业务 流控制时, 和终端进行单播协商, 根据单播协商结果向终端发送单播业务流。
本发明的实施例利用 NGN中原有的功能实体 MRFC和 MRFP完成组播业 务流到单播业务流的切换控制并提供单播业务流, 在 NGN网络中提供时移电 视业务, 丰富了 IMS业务; 并且用户认证、 安全、 计费等可以釆用 IMS的现 有机制或者增强机制, 可以充分利用现有的资源。
附图说明
图 1为基于现有 IP网络的时移电视方案图;
图 2为本发明实施例的系统架构图;
图 3为本发明实施例一的流程图;
图 4为本发明实施例二中方式 1流程图;
图 5为本发明实施例二中方式 2流程图;
图 6为本发明实施例三流程图;
图 7为本发明实施例四流程图;
图 8为本发明媒体资源设备装置实施例示意图;
图 9为本发明媒体资源设备装置另一实施例的示意图。
具体实施方式
下面结合具体实施例和附图对本发明进行详细说明。
如图 2所示, 本发明所述的系统包括终端 201、 代理 CSCF ( Call Session
Control Function, 呼叫会话控制功能) 206、服务 CSCF 205、 AS (应用服务器) 202、 MRFC (媒体资源控制功能实体) 203和 MRFP (媒体资源承载功能实体) 204等。
终端 201用于和 AS 202进行业务协商, 请求 AS 202提供服务。 代理 CSCF
206用于转发终端 201和服务 CSCF 205之间的请求和响应消息。 服务 CSCF 205 用于根据触发规则把业务请求消息触发到 AS 202, 对消息进行路由; AS 202 用于向用户提供业务, 与终端 201进行必要的业务协商; 根据协商的结果向 MRFC 203提出媒体资源请求; MRFC 203接收 AS 202的媒体资源请求并控制 MRFP 204进行媒体资源的分配。 MRFP 204受 MRFC 203的控制向终端 201提供 媒体资源, 如提供视频 /音频节目流。
其中, 代理 CSCF 206和服务 CSCF 205可以称之为 CSCF。 MRFC 203和 MRFP 204可以称之为 MRF。
本发明的实施例中,将时移电视业务的实现分为两个基本过程:一个是收 看实时节目时建立组播业务流并接收的过程;另一个是当用户进行节目控制时 (如暂停、 后退、 快进)发生的由接收组播流向请求单播流转换的过程, 这两 个过程配合完成整个时移电视的控制过程。
收看实时节目建立组播业务流并接收的过程中, 用户终端 (UE ) 需要获 得实时节目的組播源地址和节目组播地址以及节目编码格式, 在 IMS网络里, 组播源对应于 MRFC (媒体资源控制功能实体)和 MRFP (媒体资源处理功能 实体) , 其中 MRFC作为媒体控制面, MRFP作为媒体传输面。 由于电视信号 的采集和编码等过程并非本发明重点所在,因此本发明技术方案中假定时移电 视编码的结果在 MRFP处获取,本发明所述的技术方案中用户终端和 AS之间采 用 SIP信令协商 RTSP地址和端口信息和 /或媒体传输参数后建立组播业务流。
在业务进行过程中, 需要为用户提供节目 '控制(暂停、 后退、 快进甚至协 商新的单播业务流等)的机制, 为了支持用户的控制命令, 本发明所述的技术 方案采用把节目流从组播流切换为单播流后实施控制的方法实现,具体的切换 机制如实施例所述。
根据建立组播业务流以及在组播业务流和单播业务流之间切换机制的不 同, 本发明可采用如下的实施例:
实施例一:
使用 SIP进行 RTSP协商以建立组播业务流, 使用 RTSP进行后续业务控制 和业务流切换的机制;
建立初始组播业务流的过程可以采用 SIP进行业务协商, 在 SIP协商过程中
只协商 RTSP通道信息 , 至少包括 RTSP地址和端口信息, 协商 RTSP地址和端 口号信息后用户终端再以所协商的 RTSP通道采用 RTSP标准过程与 RTSP信令 终结点进行传输参数协商 (RTP、 RTCP、 编解码格式等) , 其中采用组播地 址进行节目流的发送,建立初始的业务流后, 节目以组播流从服务侧发送给用 户。
具体过程如下: 终端向 AS发送的业务请求, 该请求中携带终端的 RTSP地 址和端口信息。 该请求路由后到达媒体控制功能实体(MRFC ) , 媒体控制功 能实体控制媒体承载功能实体 MRFP , 交互获得媒体承载功能 MRFP实体为 RTSP连接分配的端口信息。 MRFC返回的业务请求应答中携带了 MRFP的 RTSP连接的地址和端口信息。 终端根据收到的 RTSP地址和端口信息, 向该地 址和端口建立 RTSP连接。 RTSP连接建立成功后, 终端再通过 RTSP连接协商 用于传输媒体流的 RTP地址和端口等参数信息。
如果用户在收看过程中进行播放控制 (倒退、 暂停等) , 则使用 RTSP进 行业务流的重新协商, 以使得业务以单播方式从业务点提供给用户。 为了切 换到单播业务流, 需要对现有的服务侧 RTSP实现方式进行修改: 即服务侧收 到用户指令后不应当拒绝该控制指令, 而是根据控制指令判断用户终端需要 进行单播业务流的协商, 并从服务侧发起和用户的单播业务协商, 包括协商 单播传输参数、 编解码规格等, 协商过程采用 RTSP的标准协商过程进行。 协 商的结果使得服务侧可以以单播方式向用户提供业务流, 而用户的控制指令 则施加到该单播业务流上。
为了提供单播业务流, 服务侧首先对以组播方式发送的节目进行单播录 制, 并提供单播发送资源。 同时为了节省网络资源, 用户可以在协商过程中 请求关闭以组播方式播放的节目流; 对于服务侧而言, 如果还有其他用户在 接收节目, 则只需要确认该用户请求而不需要关闭节目流。 当然, 为了处理 效率, 该服务侧可以选择一直发送节目流, 至于用户是否接收和使用则由业 务状态决定。
服务侧为了支持播放控制, 需要在业务开始时就记录每个用户相关的业 务流类型并维持与用户的 RTSP通信。 一旦用户进行播放控制, 服务侧可以基 于用户指令进行相应动作,如可以根据"后退"、 "暂停 "指令决定向用户提供单
播业务流并对单播业务流施加相应控制。 此外, 在对单播业务流施加控制时, 如果"快进"指令所指示的时间点超过实时节目流当前时间 (时间点在 RTSP中 有多种表示方法, 服务侧可以折算成统一表示以进行比较) , 则服务侧可以 与用户重新进行协商关闭单播流, 转而向用户提供组播业务流, 从而切换到 实时节目流; 这一协商过程使用 RTSP的标准过程进行即可。 当然, 切换到实 时节目流后, 此时再按"快进,,键对服务侧而言可以不处理。
实施例一的流程图如附图 3所示:
步驟 301、 终端发起向 AS的业务请求(该请求以 SIP进行, 在 SDP中进行 RTSP通道协商, 为了在 SDP里携带 RTSP参数, 可以使用 SDP中类似对会议控 制的处理方式, 增加对媒体传输控制通道的指定) , 该请求经过 P- CSCF、 S-CSCF路由到 AS;
步骤 302、 AS根据该请求发起向 MRFC的资源请求,该请求要求 MRFC确定 RTSP媒体控制通道;
步驟 303、 MRFC与 MRFP进行交互确定 RTSP媒体控制通道参数,该参数由 MRJFP分配并终结在 MRFP上; 其交互使用 H.248协议进行;
步骤 304、 MRFC获得了 RTSP媒体控制通道参数后向 AS返回结果, 其中携 带 RTSP控制参数;
步驟 305、 AS将上述协商结果经 S-CSCF、 P-CSCF路由给用户终端, 用户 终端获得 RTSP连接参数;
步驟 306、 用户终端和 MRFP建立 RTSP连接;
步骤 307、 用户终端和 MRFP进行媒体传输参数协商, 该协商过程用于确定 提供业务的組播地址和端口等信息,組播地址和端口在服务侧可能是预先规划 好的, 也有可能是临时分配的;
步骤 308、 获得业务组播地址后, 用户终端和 MRFP之间需要建立组播转发 路径, 该过程可以使用 IGMP和 PIM-SM等配合进行;
步骤 309、 组播转发路径建立完成后, 初始的业务流就建立起来了, 电视 节目以组播方式从 MRFP传递到用户终端;
步骤 310、 如果此时用户施加控制动作, 如"后退", 该动作被转化为 RTSP 的控制指令发送给 MRFP;
步骤 311、 在服务侧(MRPP )收到上述的控制指令后, 它判断该指令是针 对单播业务流的, 需要进行组播到单播业务流的切换后才能控制, 因此使用 RTSP与用户终端进行单播业务流的协商, 在协商过程中对组播业务流去激活 或者停止(是否真正停止组播业务流发送取决于服务侧的策略, 即组播业务流 对该用户而言只是逻辑上停止了发送),服务侧在组播到单播切换时需要根据 现有的组播业务流对应的节目定位单播节目源并进行系统资源的分配;
步骤 312、 单播流协商完成后用户终端和 MRFP建立单播传输流, 节目以单 播方式发送给用户;
步骤 313、针对对单播业务流用户使用已有的 RTSP控制通道进行播放控制, 如"后退"、 "前进 "等;
步骤 314、 经过一段时间, 用户要求回到收看实时直播节目, 需要重新向 用户提供组播业务流来实现;其控制可能体现在用户按"快进"键使得所选时间 点超出了实时节目的当前时间点 , 该控制指令通过 RTSP传递给 MRFP;
步骤 315、 MRFP通过上述控制指令所携带的时间信息确定需要切换到组播 业务流; 它与用户终端进行媒体传输参数协商, 停止单播业务流, 激活组播业 务流;
步骤 316、 业务流以组播方式发送给用户。
在前述实施例一的方案中, RTSP参数是由 MRFP分配后, 由 MRFC返回给 AS, 再携带给终端使用的。 本领域的技术人员理解, 另外一种可能的实现形 式是: RTSP参数是由 MRPC所分配的, 由 MRFC返回给 AS, 再携带给终端使 用。 后续 RTSP连接建立在终端和 MRFC之间, 由 MRFC将 RTSP控制信令转换 成 H.248控制信令或者 MRFC作为 RTSP代理进行媒体资源控制 (即控制 MRFP ) , 包括媒体播放控制和媒体传输参数的分配等。
实施例二:
建立初始组播业务流的过程采用 SIP进行业务协商,在 SIP协商中协商 RTSP 通道信息和媒体传输参数, 至少包括 RTSP地址和端口、 业务组播地址和端口 等。
具体过程如下: 用户终端向 AS发送 SIP请求, 该请求中同时携带终端的 RTSP地址和端口信息以及用于传输媒体流的 RTP地址和端口信息。 该请求路
由后到达 MRFC, MRFC控制 MRFP, 交互获得 MRFP为 RTSP连接和 RTP连接 分配的端口信息。 从而在 MRFC返回的业务请求应答中, 同时携带了 MRFP的 RTSP连接的地址和端口信息以及 RTP连接的地址和端口信息。 这样, 经过交 互后,终端和 MRFP之间可以直接建立起用于交互控制的 RTSP连接和用于传输 媒体流的 RTP连接。
組播流和单播流之间的切换由 SIP和 RTSP配合进行,具体可采用如下两种 方式:
方式 1: 在用户进行播放控制时, 以所协商的 RTSP通道进行单播业务协商 和播放控制, 以 SIP信令通知服务侧结束或者去活组播业务流。
当用户进行播放控制时, 控制请求以 RTSP控制命令传递给服务侧, 对于 月良务侧的处理要求同实施例一所述。 当用户与服务侧的 RTSP协商完成后, 用 户侧可以使用业务初始的 SIP会话发送媒体更新, 具体采用 SIP 更新 ( Update ) 方法进行: 指示关闭或者去活 (如设置初始业务接收端口为 0 )指定媒体流, 从而在信令经过 IMS进行路由时使得网络侧实体可以正确释放资源, 如上述通 过 P-CSCF的组播控制所引起的资源占用。
当用户终端重新需要切换到组播业务流时(如"前进,,指令超过当前实时节 目时间点) , 服务侧可以通过 RTSP信令与用户协商关闭单播业务流, 同时, 服务侧可以使用 SIP的 Update方法更新媒体描述以激活组播业务流, 网络侧重 新向用户发送组播业务流并进行必要的转换。
方式 2: 在用户进行播放控制时, 以 SIP信令进行单播传输参数的协商, 以 初始协商的 RTSP通道进行播放控制。
当用户进行播放控制时, 控制请求以 RTSP控制命令传递给服务侧, 对于 服务侧的处理要求同实施例一中所述的要求,当服务侧检测到需要切换到组播 业务流时 (如"前进"指令超过当前实时节目时间点) , 服务侧可以使用 SIP的 Update方法更新媒体描述以进行单播业务流的协商, 该协商过程保持 RTSP通 道不变, 仅停止或者去激活组播业务流, 并增加单播业务流传输参数的协商, 这个协商过程釆用 SDP的标准协商机制进行。 协商完成后, RTSP的控制指令 事实上施加在单播业务流上。
上述 SIP协商信令经过 IMS进行路由时使得网络侧实体可以正确 #放资源,
如上述通过 P-CSCF的组播控制所引起的资源占用。
上述过程中 RTSP仅用于播放控制作用而不用于传输参数协商, 这需要对 RTSP进行修改, 以使其满足要求。
方式 1的具体流程图如附图 4所示:
步骤 401、 终端发起向 AS的业务请求 (该请求以 SIP进行, 在 SDP中进行
RTSP通道和媒体传输参数的协商,为了在 SDP里携带 RTSP参数,可以使用 SDP 中类似对会议控制的处理方式, 增加对媒体传输控制通道的协商) , 该请求 经过 P-CSCF、 S-CSCF路由到 AS;
步骤 402、 AS根据该请求发起向 MRFC的资源请求,该请求要求 MRFC确定 RTSP媒体控制通道和媒体传输参数;
步骤 403、 MRFC与 MRFP进行交互确定 RTSP媒体控制通道参数和媒体传输 参数, 该参数由 MRFP分配并终结在 MRFP上; 其交互使用 H.248进行;
步骤 404、 MRFC获得了 RTSP媒体控制通道参数和媒体传输参数后向 AS返 回结果;
步骤 405、 AS将上述协商结果经 S-CSCF、 P-CSCF路由给用户终端, 用户 终端获得 RTSP连接参数和媒体传输参数;
步骤 406、 为了给媒体流提供传输质量保障, 在上述协商报文经过 P-CSCF 进行路由时, P-CSCF可以根据媒体描述信息向 SPDF请求进行组播控制过程; 步骤 407、 根据步骤 5的协商结果用户终端和 MRFP建立 RTSP连接; 步骤 408、获得业务组播地址后,用户终端和 MRPP之间建立组播转发路径, 该过程可以使用 IGMP和 PIM-SM等配合进行;
步骤 409、 组播转发路径建立完成后, 初始的业务流就建立起来了, 电视 节目以组播方式从 MRFP传递到用户终端;
步骤 410、 如果此时用户施加控制动作, 如"后退", 该动作导致使用 SIP进 行媒体重协商, 该过程可以使用 SIP的 Update方法进行, 对组播业务流进行去 激活或者停止; 该协商经 P-CSCF路由时 P-CSCF可以采取正确动作以释放所占 用的网络资源; 该协商过程在 MRFC和 MRFP之间可以使用 H.248进行;
步驟 411、 用户的控制动作进一步转化为 RTSP的控制指令发送给 MRPP; 在服务侧(MRFP )收到控制指令后, 它判断该指令应当施加到单播业务流上
的, 因此需要进行组播到单播业务流的切换才能进行控制, 由于上面已经使用 SIP停止了组播业务流发送, 因此服务侧 ( MRFP )只需要才艮据现有的组播业务 流对应的节目定位单播节目源并进行系统资源的分配, ; MRFP确定需要进行 单播业务协商后使用 RTSP和用户终端进行单播业务流传输协商;
步骤 412、单播流协商完成后用户终端和 MRPP建立单播传输流, 节目以单 播方式发送给用户;
步骤 413、针对对单播业务流, 用户使用已有的 RTSP控制通道进行播放控 制, 如"后退"、 "前进 "等;
步骤 414、 经过一段时间, 用户要求回到收看实时直播节目, 重新向用户 提供组播业务流(其控制可能体现在用户按 "快进 "键使得所选时间点超出了实 时节目的当前时间点, 该控制指令通过 RTSP传递给 MRFP; MRFP确定需要进 行组播到单播业务流切换, 因此采用 RTSP终结单播业务流发送) ;
步骤 415、 用户终端进而使用 SIP激活组播业务流传输, 该 SIP信令经过 P-CSCF和 S-CSCF路由, P-CSCF可以按前述方式进行组播控制; 该协商过程在 MRFC和 MRFP之间可以使用 H.248进行;
步骤 416、 业务流以组播方式发送给用户。
方式 2的具体的流程图如附图 5所示:
步骤 501、 终端发起向 AS的业务请求(该请求以 SIP进行, 在 SDP中进行 RTSP通道和媒体传输参数的协商,为了在 SDP里携带 RTSP参数,可以使用 SDP 中类似对会议控制的处理方式, 增加对媒体传输控制通道的协商) , 该请求 经过 P-CSCF、 S-CSCF路由到 AS;
步骤 502、 AS根据该请求发起向 MRFC的资源请求,该请求要求 MRJFC确定 RTSP媒体控制通道和媒体传输参数;
步骤 503、 MRFC与 MRFP进行交互确定 RTSP媒体控制通道参数和媒体传输 参数, 该参数由 MRFP分配并终结在 MRFP上; 其交互使用 H.248进行;
步骤 504、 MRFC获得了 RTSP媒体控制通道参数和媒体传输参数后向 AS返 回结果;
步驟 505、 AS将上述协商结果经 S-CSCF、 P-CSCF路由给用户终端, 用户 终端获得 RTSP连接参数和媒体传输参数;
步骤 506、 为了给媒体流提供传输质量保障, 在上述协商报文经过 P-CSCF 进行路由时, P-CSCF可以根据媒体描述信息向 SPDF请求进行组播控制过程; 步骤 507、 根据协商结果用户终端和 M FP建立 RTSP连接;
步骤 508、 获得业务组播地址后, 用户终端和 MRFP之间需要建立组播转发 路径, 该过程可以使用 IGMP和 PIM-SM等配合进行;
步驟 509、 组播转发路径建立完成后, 初始的业务流就建立起来了, 电视 节目以组播方式从 MRFP传递到用户终端;
步骤 510、 此时用户施加控制动作, 如"后退", 该动作导致使用 SIP进行媒 体重协商, 该过程可以使用 SIP的 Update方法进行, 对组播业务流进行去激活 或者停止, 在 SIP信令中同时进行单播业务流的协商, 以确定单播传输参数; 资源; 该协商过程在 MRFC和 MRFP之间可以使用 H.248进行;
步驟 511、 单播流协商完成后用户终端和 MRFP建立单播传输流, 节目以单 播方式发送给用户;
步骤 512、针对单播业务流,用户使用已有的 RTSP控制通道进行播放控制, 如"后退"、 "前进,,等;
步骤 513、 经过一段时间, 用户要求回到收看实时直播节目, 重新向用户 提供组播业务流(其控制可能体现在用户按 "快进 "键使得所选时间点超出了实 时节目的当前时间点); 用户终端进而使用 SIP激活组播业务流传输, 该 SIP信 令经过 P-CSCF和 S-CSCF路由, P-CSCF可以按前述方式进行组播控制; 与此同 时, 在 SIP协商过程中停止单播业务流的传输; 该协商过程在 M FC和 MRPP 之间可以使用 H.248进行;
步驟 514、 业务流以组播方式发送给用户。
在前述实施例二的方案中, RTSP参数是由 MRFP分配后, 由 MRFC返回给 AS, 再携带给终端使用的。 本领域的技术人员理解, 另外一种可能的实现形 式是: RTSP参数是由 MRFC所分配的, 由 MRFC返回给 AS, 再携带给终端使 用。 后续 RTSP连接建立在终端和 MRFC之间, 由 MRFC将 RTSP控制信令转换 成 H.248控制信令或者 MRFC作为 RTSP代理进行媒体资源控制 (即控制 MRFP ) , 包括媒体播放控制和媒体传输参数的分配等。
实施例三: 建立初始组播业务流的过程采用以 SIP进行业务协商, 在初始 SIP协商中只协商媒体传输参数, 至少包括业务组播地址和端口等。 在完成上 述初始协商后业务流以组播方式发送。
具体说明如下: 终端发起向 AS的 SIP业务请求, 在 SDP中进行媒体传输参 数的协商; AS根据该请求发起向 MRFC的资源请求, 该请求要求 MRFC确定 媒体传输参数; MRFC与 MRPP进行交互确定媒体传输参数, 该参数由 MRFP 分配并终结在 MRFP上; MRFC获得了媒体传输参数后向 AS返回结果, 其中携 带协商结果; AS将上述协商结果经 S-CSCF、 P- CSCF路由给用户终端, 用户终 端获得媒体传输参数; 获得业务组播地址后, 用户终端和 MRFP之间建立组播 转发路径, 建立初始的组播业务流。
当用户进行播放控制时, 用户可以使用 SIP的 Update消息进行 RTSP传输通 道的协商, 该报文中可以停止或者去激活组播业务流。 新协商的 RTSP通道则 用作后续操作的控制, 其使用方式同实施例二中所述的两种方方式。
具体流程图如附图 6所示:
步驟 601、 终端发起向 AS的业务请求(该请求以 SIP进行, 在 SDP中进行媒 体传输参数的协商) , 该请求经过 P-CSCF、 S-CSCF路由到 AS;
步驟 602、 AS根据该请求发起向 MRFC的资源请求, 该请求要求 MRFC确 定媒体传输参数;
步驟 603、 MRFC与 MRFP进行交互确定媒体传输参数, 该参数由 MRFP分 配并终结在 MRFP上; 其交互使用 H.248进行;
步骤 604、 MRFC获得了媒体传输参数后向 AS返回结果, 其中携带协商结 果;
步驟 605、 AS将上述协商结果经 S-CSCF、 P-CSCF路由给用户终端, 用户 终端获得媒体传输参数;
步骤 606、 为了给媒体流提供传输廣量保障, 在上述协商报文经过 P-CSCF 进行路由时, P-CSCF可以根据媒体描述信息向 SPDF请求进行组播控制过程; 步骤 607、 获得业务组播地址后, 用户终端和] VCRJFP之间需要建立组播转 发路径, 该过程可以使用 IGMP和 PIM-SM等配合进行;
步骤 608、 组播转发路径建立完成后, 初始的业务流就建立起来了, 体现
为电视节目以组播方式从 MRFP传递到用户终端;
步骤 609: 如果此时用户施加控制动作, 如"后退", 该动作导致使用 SIP进 行媒体重协商, 该过程可以使用 SIP的 Update方法进行, 对组播业务流进行去 激活或者停止, 在 SIP信令中同时进行单播业务流的协商, 以确定单播传输参 数和 RTSP控制通道;该协商报文经 P-CSCF路由时 P-CSCF可以采取正确动作以 释放所占用的网络资源; 该协商过程在 MRFC和 MRFP之间可以使用 H.248进 行。
在前述实施例三的方案中, RTSP参数是由 MRFP分配后, 由 MRFC返回给 AS, 再携带给终端使用的。 本领域的技术人员理解, 另外一种可能的实现形 式是: RTSP参数是由 MRFC所分配的, 由 MRFC返回给 AS, 再携带给终端使 用。 后续 RTSP连接建立在终端和 MRFC之间, 由 MRFC将 RTSP控制信令转换 成 H.248控制信令或者 MRFC作为 RTSP代理进行媒体资源控制 (即控制 MRFP ) , 包括媒体播放控制和媒体传输参数的分配等。
实施例四: 建立初始组播业务流的过程采用以 SIP进行业务协商方式, 对 于后续的业务控制过程通过扩展 SIP功能进行支持, 不需要 RTSP参与。
当用户进行播放控制时,可以以 SIP作为播放控制信令,对 SIP作相应扩展, 如以 xml-based的脚本语言来描述控制信息承载在 SIP信令中来达到控制目的。 服务侧收到用户控制指令后需要将组播业务流切换到单播业务流,这一切换过 程可以釆用 SIP Update消息进行, 在其中停止或者去激活组播业务流, 并进行 单播业务流的协商, 该协商过程可以采用媒体协商的标准机制完成。 上述 SIP 协商信令经过 IMS进行路由时使得网络侧实体可以正确释放资源, 如上述通过 P-CSCF的组播控制所 ]起的资源占用。
具体的流程图如附图 7所示,其中步骤 701至步骤 708与实施例三中步骤 601 至步骤 608—致, 以下说明不同的步骤:
步骤 709、 如果此时用户施加控制动作, 如"后退", 该动作导致使用 SIP进 行媒体重协商, 该过程可以使用 SIP的 Update方法进行, 对组播业务流进行去 激活或者停止, 在 SIP信令中同时进行单播业务流的协商, 以确定单播传输参 数; 该协商报文经 P-CSCF路由时 P-CSCF可以采取正确动作以释放所占用的网 络资源; 该协商过程中 MRFC与 MRFP之间可以使用 H.248交互完成;
步骤 710、单播流协商完成后用户终端和 MRFP建立单播传输流, 节目以单 播方式发送给用户;
步骤 711、 针对单播业务流, 用户使用 SIP进行播放控制, 通过为每一个控 制指令定义新的 SIP方法或者仅定义一个控制方法, 具体控制以 xml-based语言 描述的控制指令, 携带在该方法中传递给 MRFC, 进而由 MRFC对 MRFP进行 控制 (如使用 H.248 ) ;
步骤 712、 经过一段时间, 用户要求回到收看实时直播节目, 重新向用户 提供组播业务流(其控制可能体现在用户按 "快进 "键使得所选时间点超出了实 时节目的当前时间点); 用户终端进而使用 SIP激活组播业务流, 该 SIP信令经 过 P-CSCF和 S-CSCF路由, P-CSCF可以按前述方式进行组播控制; 与此同时, 在 SIP协商过程中停止单播业务流;该协商过程中 MRFC与 MRFP之间可以使用 H.248交互完成;
步骤 713、 业务流以组播方式发送给用户。
除上述的实施例之外 ,建立组播流和在组播流和单播流之间切换方式还可 以进行不同于上述实施例的组合。
请再次参阅图 2, 本发明实施例的基于下一代网络实现时移电视业务的系 统中, 包括终端 201、 代理 CSCF ( Call Session Control Function, 呼叫会话控 制功能实体) 206、 服务 CSCF 205、 AS (应用月良务器) 202、 MRFC (媒体资 源控制功能实体) 203和 MRFP (媒体资源承载功能实体) 204等。
其中, 本发明实施例的系统适用于多种场景。
在一种场景中,应用服务器 202用于根据来自所述终端 201的业务请求向 媒体资源控制功能实体 203发起资源请求,所述业务请求中至少携带终端的媒 体传输参数;将来自所述媒体资源控制功能实体 203的业务请求响应路由至终 端 201;
媒体资源控制功能实体 203用于和媒体资源承载实体 204进行交互,向应 用服务器 202返回业务请求响应;所述业务请求响应中至少携带媒体资源承载 实体确定的媒体传输参数;
媒体资源承载实体 204用于确定媒体传输参数,根据所述确定的媒体传输 参数, 与终端 201建立组播业务流; 在终端 201请求进行业务流控制时, 和终
端 201进行单播协商, 根据单播协商结果向终端 201发送单播业务流; 代理呼叫会话控制功能实体 206用于转发终端 201和服务呼叫会话控制功 能实体 205之间的请求和响应消息;
服务呼叫会话控制功能实体 205 用于^ ^据触发规则将业务请求触发到应 用服务器 202, 对消息进行路由。
在另一种场景中,应用服务器 202用于根据来自所述终端 201的业务清求 向媒体资源控制功能实体 203发起资源请求,所述业务请求中携带终端的实时 流协议媒体控制通道参数;将来自所述媒体资源控制功能实体 203的业务请求 响应路由至终端 201 ;
媒体资源控制功能实体 203用于和媒体资源承载实体 204进行交互,向应 用服务器 202返回业务清求响应;所述业务清求响应中携带媒体资源承载实体 确定的实时流协议媒体控制通道参数;
媒体资源承载实体 204用于确定实时流协议媒体控制通道参数,根据所述 确定的实时流协议媒体控制通道参数,与终端 201建立实时流协议连接;使用 所述实时流协议连接与终端 201协商媒体传输参数, 建立组播业务流; 在终端 201请求进行业务流控制时, 和终端 201进行单播协商, 根据单播协商结果向 终端 201发送单播业务流;
代理呼叫会话控制功能实体 206用于转发终端 201和服务呼叫会话控制功 能实体 205之间的请求和响应消息;
服务呼叫会话控制功能实体 205 用于根据触发规则将业务请求触发到应 用服务器 202, 对消息进行路由。
下面对本发明实施例的媒体资源设备装置进行介绍,本发明实施例的媒体 资源设备装置包括: 媒体资源控制功能实体 203以及媒体资源承载实体 204。
其中, 本发明实施例的媒体资源设备装置适用于多种场景。
请参阅图 8, 在一种场景中, 媒体资源控制功能实体 203用于和媒体资源 承载实体 204进行交互, 向应用服务器 202返回业务请求响应; 所述业务请求 响应中至少携带媒体资源承载实体确定的媒体传输参数;
媒体资源承载实体 204用于确定媒体传输参数,根据所述确定的媒体传输 参数, 与终端 201建立组播业务流; 在终端 201请求进行业务流控制时, 和终
端 201进行单播协商, 根据单播协商结果向终端 201发送单播业务流。
其中, 媒体资源控制功能实体 203包括: 接收单元 801 , 交互单元 802以 及响应单元 803;
所述接收单元 801用于接收来自应用服务器的媒体资源请求;所述交互单 元 802用于根据所述接收单元 801接收到的媒体资源请求与媒体资源承载实体 204交互; 响应单元 803用于向应用服务器 202返回业务请求响应, 所述业务 请求响应中至少携带媒体资源承载实体确定的媒体传输参数。
其中, 媒体资源承载实体 204包括: 确定单元 804, 用于确定媒体传输参 数; 组播单元 805, 用于根据所述确定的媒体传输参数, 与终端 201建立组播 业务流; 单播单元 806, 用于在终端 201请求进行业务流控制时, 和终端 201 进行单播协商, 根据单播协商结果向终端 201发送单播业务流。
请参阅图 9, 在另一种场景中, 媒体资源控制功能实体 203用于和媒体资 源承载实体 204进行交互, 向应用服务器 202返回业务请求响应; 所述业务请 求响应中携带媒体资源承载实体确定的实时流协议媒体控制通道参数;
媒体资源承载实体 204用于确定实时流协议媒体控制通道参数,根据所述 确定的实时流协议媒体控制通道参数, 与终端 201建立实时流协议连接;使用 所述实时流协议连接与终端 201协商媒体传输参数, 建立组播业务流; 在终端 201请求进行业务流控制时, 和终端 201进行单播协商, 根据单播协商结果向 终端 201发送单播业务流。
其中, 媒体资源控制功能实体 203包括: 接收单元 901 , 交互单元 902以 及响应单元 903;
所述接收单元 901用于接收来自应用服务器的媒体资源请求;所述交互单 元 902用于根据所述接收单元 901接收到的媒体资源请求与媒体资源承载实体 204交互; 响应单元 903用于向应用服务器 202返回业务请求响应, 所述业务 请求响应中至少携带媒体资源承载实体确定的实时流协议媒体控制通道参数。
其中, 媒体资源承载实体 204包括: 确定单元 904, 用于确定实时流协议 媒体控制通道参数; 连接建立单元 905, 用于根据所述确定的实时流协议媒体 控制通道参数, 与终端 201建立实时流协议连接; 组播单元 906, 用于使用所 述实时流协议连接与终端 201协商媒体传输参数,建立组播业务流; 单播单元
907, 用于在终端 201请求进行业务流控制时, 和终端 201进行单播协商, 根 据单播协商结果向终端 201发送单播业务流。
本发明的实施例利用 NGN中原有的功能实体 MRFC和 MRFP完成组播业 务流到单播业务流的切换控制并提供单播业务流, 在 NGN网络中提供时移电 视业务, 丰富了 IMS业务; 并且用户认证、 安全、 计费等可以采用 IMS的现 有机制或者增强机制, 可以充分利用现有的资源。