WO2009006820A1 - Method and system for providing media flow during swith of media servers - Google Patents

Description

媒体服务器切换过程中提供媒体流的方法及系统 技术领域

本发明涉及因特网协议多媒体子系统（IMS, IP Multimedia Subsystem) 领域， 特别涉及一种在 IMS 网络中媒体服务器切换过程中提供媒体流的方法 及系统。

背景技术

媒体流业务或因特网协议电视 ( IPTV, IP Television) 业务是近几年迅 速发展的一种新业务。 这两种业务利用流式传输技术， 在包交换网络上， 如 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, 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, Ses s ion Ini t ia l Protocol ) 以及直 径 ( Diameter )协议等。

SIP是一个应用层的控制协议， 可以用来建立、 修改和终止多媒体会话或 会议， SIP也支持邀请参与者参加已经存在的会话， 比如多方会议。

实时流协议（RTSP, Rea l Time Streaming Protocol )是应用级协议， 控 制实时数据的发送， 主要用于媒体流业务或因特网协议电视业务的实时数据 发送。 RTSP提供一种可扩展框架， 进行实时数据， 如音频与视频的受控传送 以及点播传送。 RTSP 目的在于控制多个数据传送会话， 提供选择传送通道的 方法， 提供基于 RTP选择传输机制的方法。

基于 IMS的 IPTV业务就是在 IMS整体架构下提供 IPTV业务，充分利用 IMS 网络中已有的注册、 认证、 路由、 会话控制与建立、 业务触发、 计费、 端到 端 QoS保证等机制来为 UE提供媒体流业务及融合媒体流和实时会话业务的多 媒体业务。 也就是说， UE到内容的多媒体会话是通过 IMS已有的会话控制机 制来完成， 在建立会话过程中， 需要为媒体流的传送预留承载资源。

图 1为现有技术基于 IMS的 IPTV业务的业务功能架构示意图，其中， IPTV 媒体功能实体 ( IPTV Media Funct ion ) 负责通过 IMS到 UE的媒体流的控制 和交付。 I PT V Me d i a Func t i on从功能角度可以分解为媒体控制功能实体（ MCF , Media Control Funct ion ) 和媒体交付功能实体 ( MDF , Media Del ivery Funct ion )。 MDF通常为一些媒体服务器， 在 MCF的控制下向 UE传输媒体流， MCF还能接收和处理由 UE发送的播放控制操作命令， 这些命令通常釆用 RTSP 实现， 例如媒体流的快进、 后退、 暂停和定位等操作命令。 IPTV业务控制功 能 ( IPTV Service Control Funct ions )用于在通过 IMS核心 （Core )接收 到 UE发送的 IPTV业务请求时， 为 UE选择 IPTV Media Funct ion进行处理， IMS Core可以为 UE的 IPTV业务预留资源。

IPTV业务是一种向 UE提供多媒体内容的业务， 例如直播电视业务或视频 点播业务。 在视频点播业务中， 当媒体内容的规模比较大时， 需要存放在多 个媒体服务器中， 并且为了提高媒体内容检索的速度， 同一个媒体内容也可 能分片存放在不同的媒体服务器上。 在视频点播业务的使用过程中， UE 可以 进行视频盒式录制 （VCR, Video Cas set te Recording )操作， 如进行快进、 快退、 暂停以及定位等操作， 即可发送播放控制操作命令， 控制 IPTV媒体功 能实体传输的媒体流。 如果在正常播放过程中或 UE进行 VCR操作等原因导致 需要播放的媒体内容不在当前媒体服务器上时， 则需要切换到新的媒体服务 器上。

但是， 目前没有明确给出如何在媒体服务器的切换过程中不间断提供媒体 流的技术。 业界通常的做法是釆用媒体重协商的方式， 进行媒体服务器的切 换后， 再由切换到的媒体服务器提供媒体流， 即需要切换媒体服务器时， 通 过 IMS Core重新进行 UE和切换到的媒体服务器之间的媒体参数协商， 协商 完成后，切换到的媒体服务器为 UE提供包括媒体内容的媒体流。对于基于 IMS 的 IPTV业务来说， 就是使用 IMS Core的会话控制功能进行更改会话的操作， 以重新在 UE与切换到的媒体服务器之间协商媒体参数后进行切换， 该切换到 的媒体服务器为 UE提供包括媒体内容的媒体流。

在实现本发明的过程中， 发明人发现现有技术中至少存在如下问题： 上述这种在媒体服务器的切换过程中提供媒体流的方法存在降低 IMS网络 的响应速度的问题， 原因是媒体流的播放控制是 UE与 MCF之间直接进行处理 的， 而进行媒体重协商的会话控制是通过 IMS Core的 SIP信令处理的， 因此， 进行媒体重协商方式切换媒体服务器所经过的环节比较多，并需要重新在 IMS 网络中进行资源预留后， 才能由切换到的媒体服务器提供媒体流， 这些都会 影响 IMS网络的响应速度， 严重时会造成媒体流的中断， 影响通过 UE接收媒 体流的用户体验。

发明内容

本发明实施例提供一种媒体服务器切换过程中提供媒体流的方法， 该方法 能够在不影响 IMS 网络响应速度的情况下， 实现在媒体服务器切换过程中提 供媒体流， 不造成媒体流的中断。

本发明实施例还提供一种媒体服务器切换过程中提供媒体流的系统， 该系 统能够在不影响 IMS 网络响应速度的情况下， 实现在媒体服务器切换过程中 提供媒体流， 不造成媒体流的中断。

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

一种媒体服务器切换过程中提供媒体流的方法， 所述媒体服务器为媒体交 付功能实体， 该方法包括：

为用户设备提供媒体流的媒体交付功能实体由第一媒体交付功能实体切 换到第二媒体交付功能实体；

第二媒体交付功能实体为用户设备提供的媒体流， 由第一媒体交付功能实 体代理发送。

一种媒体服务器切换过程中提供媒体流的系统， 所述媒体服务器为媒体交 付功能实体， 该系统包括： 第一媒体交付功能实体、 第二媒体交付功能实体、 媒体控制功能实体， 其中，

媒体控制功能实体， 用于在为用户提供媒体流的媒体交付功能实体由第一 媒体交付功能实体切换到第二媒体交付功能实体时， 控制第一媒体交付功能 实体和第二媒体交付功能实体；

第二媒体交付功能实体， 用于在媒体控制功能实体的控制下将为用户设备 提供的媒体流发送给第一媒体交付功能实体；

第一媒体交付功能实体， 用于在媒体控制功能实体的控制下代理发送从第 二媒体交付功能实体接收的媒体流给用户设备。

一种媒体服务器切换过程中提供媒体流的方法， 所述媒体服务器为媒体交 付功能实体， 该方法包括：

为用户设备提供媒体流的媒体交付功能实体由第一媒体交付功能实体切 换到第二媒体交付功能实体；

第二媒体交付功能实体使用媒体控制功能实体为该媒体流预先分配的媒 体参数发送媒体流。

一种媒体服务器切换过程中提供媒体流的系统， 所述媒体服务器为媒体交 付功能实体， 该系统包括： 第一媒体交付功能实体、 第二媒体交付功能实体、 媒体控制功能实体， 其中，

媒体控制功能实体， 用于为用户设备提供媒体流的媒体交付功能实体由第 一媒体交付功能实体切换到第二媒体交付功能实体时， 为第二媒体交付功能 实体分配与第一媒体交付功能实体发送媒体流的相同媒体参数后， 发送给第 二媒体交付功能实体；

第二媒体交付功能实体， 用于使用从媒体控制功能实体接收的媒体参数发 送媒体流给用户设备。

一种媒体服务器切换过程中提供媒体流的方法， 所述媒体服务器为媒体功 能实体， 该方法包括：

为用户设备提供媒体流的媒体功能实体由第一媒体功能实体切换到第二 媒体功能实体， 第二媒体功能实体为用户设备提供的媒体流， 由第一媒体功 能实体代理发送。

一种媒体服务器切换过程中提供媒体流的系统， 所述媒体服务器为媒体功 能实体， 该系统包括： 第一媒体功能实体、 第二媒体功能实体， 其中，

第二媒体功能实体， 用于为用户设备提供媒体流的媒体功能实体由第一媒 体功能实体切换到第二媒体功能实体时， 将为用户设备提供的媒体流发送给 第一媒体功能实体；

第一媒体功能实体， 用于代理发送从第二媒体功能实体接收的媒体流给用 户设备。

从上述方案可以看出， 本发明实施例提供的方法及系统， 在进行媒体服务 器切换过程中提供媒体流时， 不通过 IMS Core进行 UE和切换到的媒体服务 器之间的重协商过程， 而釆用当前为 UE服务的媒体服务器代理切换到的媒体 服务器的方式、 或者釆用给切换到的媒体服务器分配与当前为 UE服务的媒体 服务器相同的媒体流参数的方式， 提供媒体流， 从而在媒体服务器切换过程 中保持给 UE发送的媒体流的媒体流参数不变。 由于本发明实施例不像现有技 术那样釆用通过 IMS Core进行 UE和切换到的媒体服务器之间的重协商过程， 对于媒体服务器的切换只是在网络侧进行， 而不需要与 UE进行交互协商， 实 现了在不影响 IMS 网络响应速度的情况下实现在媒体服务器切换过程中提供 媒体流， 不造成媒体流的中断。

附图说明

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

图 2为本发明实施例媒体流代理方式实现媒体服务器切换的结构示意图； 图 3为本发明实施例媒体流代理方式实现媒体服务器切换的方法流程图； 图 4为本发明实施例媒体流的源 IP地址和端口号集中管理方式实现媒体 服务器切换的结构示意图；

图 5为本发明实施例媒体流的源 IP地址和端口号集中管理方式实现媒体 服务器切换的方法流程图；

图 6为本发明实施例播放控制及媒体代理方式实现媒体服务器切换的结构 示意图；

图 7为本发明实施例播放控制及媒体代理方式实现媒体服务器切换的方法 流程图；

图 8为本发明具体实施例一釆用 RTP级代理的媒体代理方式实现媒体服务 器切换的结构示意图；

图 9为本发明具体实施例一釆用 RTP级代理的媒体代理方式实现媒体服务 器切换的方法流程图；

图 10 为本发明具体实施例二釆用应用级代理的媒体代理方式实现媒体服 务器切换的方法流程图；

图 11为本发明具体实施例三釆用媒体流源 IP地址和端口号集中管理方式 实现切换媒体服务器的网络架构图； 图 12为本发明具体实施例三釆用媒体流源 IP地址和端口号集中管理方式 实现切换媒体服务器的方法流程图；

图 13 为本发明具体实施例四釆用播放控制及媒体代理方式实现媒体服务 器切换的结构示意图；

图 14 为本发明具体实施例四釆用播放控制及媒体代理方式实现媒体服务 器切换的方法流程图。

具体实施方式

为了在不影响 IMS网络响应速度的情况下实现在媒体服务器切换过程中提 供媒体流， 不造成媒体流的中断， 本发明实施例在基于 IMS的 IPTV业务使用 过程中， 当为 UE提供媒体流的媒体服务器发生切换时， 不进行 UE和切换到 的媒体服务器之间的重协商过程， 只在网络侧进行提供不同媒体流的媒体服 务器的切换过程， 保持给 UE发送的媒体流的媒体流参数不变。 在本发明实施 例中， 媒体流参数可以为媒体流的源 IP地址和端口号， 以下釆用媒体流的媒 体参数为媒体流的源 IP地址和端口号进行详细说明。

在提供媒体流的过程中发生媒体服务器切换的原因可以有多种，可以是 1 ) 由于 UE发送播放控制命令所指示的媒体内容不在当前为 UE提供媒体流的媒 体服务器上； 2 ) 由于当前为 UE提供媒体流的媒体服务器由于网络故障或自 身故障， 而导致需要切换到备份的媒体服务器为 UE提供媒体流； 3 ) 当 UE请 求的媒体内容比较大时， 分别存储到几个媒体服务器上， 由几个媒体服务器 进行切换， 为 UE提供不间断媒体内容的媒体流。

本发明实施例釆用上述原因 1 ), 即由于 UE发送播放控制命令所指示的媒 体内容不在当前为 UE提供媒体流的媒体服务器上， 而导致在提供媒体流时发 生媒体服务器切换进行详细说明。

具体地， 本发明实施例提供了三种类型的解决方式保持给 UE提供媒体流 在本次 IPTV业务中的源 IP地址和端口号不变， 这三种方式分别是媒体流代 理方式、 媒体流的源 IP地址和端口号集中管理方式、 以及播放控制及媒体代 理方式， 以下分别对这三种解决方式进行详细的说明。

第一种解决方式， 媒体流代理方式

图 2为本发明实施例媒体流代理方式实现在媒体服务器切换过程中提供媒 体流的网络结构示意图， 涉及到的实体包括 MCF、 MDF以及 UE。 其中， UE为 IPTV终端，用于接收 MDF发送的媒体流； MDF1是当前为 UE提供媒体流的 MDF , MDF2是切换后为 UE提供媒体流的 MDF。 UE和 MCF之间通过播放控制接口进行 信息交互， 该接口可以釆用 RTSP , MCF分别和 MDF1 以及 MDF2之间通过媒体 控制接口进行信息交互， MDF1和 UE之间通过媒体传送接口进行信息交互， MDF1 和 MDF2之间通过媒体代理接口进行信息交互。 在本实施例中， 其他 MDF也可 以通过媒体代理接口和 MDF1进行信息交互， 如 MDF3以及 MDF4等分别通过媒 体代理接口和 MDF1进行信息交互。

在基于 IMS的 IPTV业务使用过程中， UE通过播放控制接口访问 MCF , 发 送播放控制命令进行播放控制操作， 如快进、 快退以及定位等操作。 MCF接收 到 UE发送的播放控制命令后， 通过媒体控制接口控制 MDF1向 UE传送所需要 的媒体流， 该媒体流通过 MDF1和 UE之间的媒体传送接口传送。 当 MDF1没有 UE所需要的媒体内容时， 具有该媒体内容的其他 MDF , 如 MDF2在 MCF1的控 制下通过媒体代理接口将该媒体内容发送给 MDF1 ,由 MDF1通过媒体传送接口 代理发送给 UE。

图 3为本发明实施例媒体流代理方式实现在媒体服务器切换过程中提供媒 体流的方法流程图， 假设当前为 UE提供媒体内容的为 MDF1 , 切换后为 UE提 供媒体内容的为 MDF2 , 控制进行 MDF之间切换的为 MCF , 其具体步骤为： 步骤 301、 MCF在为 UE提供 IPTV业务时， 选择 MDF1 , 控制 MDF1为 UE发 送 UE所需要的媒体内容的媒体流。

在 UE向 MCF请求 IPTV业务时， 会携带媒体内容信息， MCF根据该媒体内 容信息确定具有对应媒体内容的 MDF , 控制所确定 MDF向 UE发送对应媒体内 容的媒体流。 步骤 302、 MDF1在 MCF的控制下， 分配媒体发送资源， 向 UE发送 UE所需 要的媒体内容的媒体流。

在本步骤中， 假定发送媒体流使用的源 IP地址以及端口号分别为 IP1和 Por t L

步骤 303、 UE在接收 MDF1发送的媒体流过程中， 进行 VCR操作， 即向 MCF 发送播放控制命令, MCF根据该命令携带的媒体内容信息确定需要切换到 MDF2 进行媒体流的传输， MDF2具有对应的媒体内容。

步骤 304、 MCF控制 MDF1代理发送 MDF2的媒体流， 发送给 UE。

步骤 305、 MDF1在 MCF的控制下， 从 MDF2获取代理的媒体流， 发送给 UE , 在发送媒体流的过程中， MDF1 仍然使用原有的源 IP 地址和端口号 （IP1 和

Por t l )。

步骤 306、 为 UE提供的 IPTV业务结束， MCF控制 MDF1和 MDF2分别释放 媒体发送资源， 停止媒体代理和媒体发送。

在上述实施例中，如果在步骤 305之后， UE又进行了 VCR操作， 需要 MDF3 为 UE提供媒体内容， 则 MCF控制 MDF1停止代理 MDF2中的媒体流， MDF1进行 MDF3的媒体流代理， 处理的过程与代理 MDF2中的媒体流过程相同。

第二种解决方式， 媒体流的源 IP地址和端口号集中管理方式

图 4为本发明实施例媒体流的源 IP地址和端口号集中管理方式实现媒体 服务器切换的结构示意图， 涉及到的实体包括 MCF、 MDF 以及 UE。 其中， UE 为 IPTV终端， 用于接收 MDF发送的媒体流； MDF1是当前为 UE提供媒体流的 MDF , MDF2是切换后为 UE提供媒体流的 MDF。 UE和 MCF之间通过播放控制接 口进行信息交互， 该接口可以釆用 RTSP , MCF分别和 MDF1 以及 MDF2之间通 过媒体控制接口进行信息交互， MDF1和 UE之间通过媒体传送接口进行信息交 互， MDF2 和 UE之间通过媒体传送接口进行信息交互。 在本实施例中， 其他 MDF也可以和 UE之间通过媒体传送接口进行信息交互， 如 MDF 3以及 MDF4等 分别和 UE之间通过媒体传送接口进行信息交互。 在本实施例中， MCF通过媒体控制接口， 控制 MDF1或 MDF2向 UE传送媒体 流， 且负责分配 MDF1或 MDF2向 UE传送媒体流时所使用的源 IP地址和端口 号， 即在 UE的本次 IPTV业务中分配给 MDF1或 MDF2发送媒体流的源 IP地址 和端口号保持不变。 MDF在 MCF的控制下， 使用 MCF分配的源 IP地址和端口 号通过媒体传送接口向 UE发送具有其需要的媒体内容的媒体流。

图 5为本发明实施例媒体流的源 IP地址和端口号集中管理方式实现媒体 服务器切换的方法示意图，假设当前为 UE提供媒体内容的为 MDF1 , 切换后为 UE提供媒体内容的为 MDF2 ,控制进行 MDF之间切换的为 MCF , 其具体步骤为： 步骤 501、 MCF在为 UE提供 IPTV业务时， 选择 MDF1 , 并分配本次 IPTV业 务发送媒体流所使用的源 IP地址和端口号， 假设为 IP1和 Por t l , 控制 MDF1 在本次 IPTV业务中为 UE传输媒体流使用该分配的 IP地址和端口号。

步骤 502、 MDF1在 MCF的控制下分配媒体发送资源， 向 UE发送媒体流， 媒体流的源 IP地址和端口号使用 MCF分配的 IP地址和端口号， 分别为 IP1 和 Por t L

步骤 503、 UE在接收 MDF1发送的媒体流过程中， 进行 VCR操作， 即向 MCF 发送播放控制命令, MCF根据该命令携带的媒体内容信息确定需要切换到 MDF2 进行媒体流的传输， MDF2具有对应的媒体内容。

步骤 504、 MCF控制 MDF2向 UE发送 UE所需媒体内容的媒体流， 媒体流的 源 IP地址和端口号使用 MCF分配的 IP地址和端口号， 分别为 IP1和 Por t l。

步骤 505、 MCF控制 MDF1释放为 UE分配的媒体发送资源， 控制 MDF1停止 向 UE发送媒体流， 即停止 IP1和 Por t l的使用。

步骤 506、 为 UE提供的 IPTV业务结束， MCF控制 MDF2释放为 UE分配的 媒体发送资源， 停止向 UE发送媒体流， MCF分配的 IP地址和端口号， 即 IP1 和 Por 11也被释放，可以提供给 UE在下次申请 IPTV业务时或其他 UE申请 I PTV 业务时使用。

在本实施例中， 在步骤 505之后， 如果 UE又进行了 VCR操作， 需要 MDF3 为 UE提供媒体内容， 则 MCF控制 MDF3使用分配给本次 IPTV业务的 IP地址 和端口号， 即 IP1和 p₀r t l向 UE发送 UE所需要媒体内容的媒体流， 并指示 MDF2释放为 UE分配的媒体发送资源， 控制 MDF2停止为 UE发送媒体流。

第三种解决方式， 播放控制及媒体代理方式

图 6为本发明实施例播放控制及媒体代理方式实现媒体服务器切换的结构 示意图， 涉及的网络实体包括 IPTV 媒体功能实体、 SCF (Serv ice Control Funct ion,业务控制功能实体）和 UE。 IPTV媒体功能实体包括 MCF和 MDF, MCF 和 MDF 为逻辑功能实体， 实际部署中， 可能是同一个物理实体， 在这种情况 下， 当 MDF切换时， 实际上 MCF也需要进行切换， 在不进行媒体流重新协商 的情况下， 不仅仅 UE本次 IPTV业务的媒体流发送釆用不变的源 IP地址和端 口号， 进行播放控制的播放控制参数也需要保持不变， 因此， 可以釆用代理 的方式实现。

图 6中的 IPTV媒体功能实体 1是当前为 UE提供媒体流的 IPTV媒体功能 实体， IPTV媒体功能实体 1是切换后为 UE提供媒体流的 IPTV媒体功能实体。 UE为 IPTV终端。 UE和 IPTV媒体功能实体 1之间通过媒体播放控制接口和媒 体传送接口分别进行控制信息和媒体流的交互， 媒体播放控制接口可以釆用 RTSP , 媒体传送接口可以釆用实时传输协议 （RTP , Rea l-Time Transpor t Protocol )₀ 在 IPTV业务使用过程中， UE可以通过媒体播放控制接口进行播 放控制操作， 如快进、 快退、 定位以及暂停等操作。 SCF和 IPTV媒体功能实 体之间通过媒体管理接口进行信息交互， SCF向 IPTV媒体功能实体申请播放 控制资源和媒体发送资源， 以处理 UE的播放控制和向 UE传送所需要的媒体 流。

在具体实现中， IPTV媒体功能实体 1通过播放控制接口接收 UE的播放控 制命令后处理， IPTV媒体功能实体 1通过媒体传送接口向 UE传送媒体流。 IPTV 媒体功能实体 1和 IPTV媒体功能实体 1之间通过播放控制代理接口和媒体代 理接口分别进行控制信息和媒体流的交互，当 IPTV媒体功能实体 1上没有 UE 所需要的媒体内容时， 具有该媒体内容的 IPTV媒体功能实体 2将包括该媒体 内容的媒体流通过媒体代理接口发送给 IPTV媒体功能实体 1 ,由 IPTV媒体功 能实体 1代理 IPTV媒体功能实体 2发送给 UE。 IPTV媒体功能实体 1还负责 UE与 IPTV媒体功能实体 2之间的播放控制代理， UE发送的播放控制命令， 将由 IPTV媒体功能实体 1通过与 IPTV媒体功能实体 2之间的播放控制代理 接口转发给 IPTV媒体功能实体 2 , IPTV媒体功能实体 2的播放控制响应消息 也将由 IPTV媒体功能实体 1按照预先为该媒体流分配的播放控制参数转发给 UE。

图 7为本发明实施例播放控制及媒体代理方式实现媒体服务器切换的方法 流程图， 涉及的网络实体包括 UE、 当前为 UE提供媒体流的 IPTV媒体功能实 体 1、 切换后为 UE提供媒体流的 IPTV媒体功能实体 2以及 SCF, 其具体步骤 为：

步骤 701、 SCF在为 UE建立 IPTV业务过程中， 选择 IPTV媒体功能实体 1 为 UE提供媒体流， 指示 IPTV媒体功能实体 1处理 UE的播放控制和向 UE发 送 UE所需媒体内容的媒体流。

步骤 702、 IPTV媒体功能实体 1在业务控制功能的指示下， 为 UE分配播 放控制资源和媒体发送资源，假定发送媒体流的源 IP地址和端口号分别为 IP1 和 Portl , 播放控制的源 IP地址和端口号分别为 IP2和 Port2 , 将分配的播 放控制资源和媒体发送资源信息通过业务控制功能发送给 UE。

IPTV媒体功能实体 1从业务控制功能中得到 UE的接收媒体流地址，将发 送给 UE的媒体流发送到该地址上， 媒体流使用的源 IP地址和端口号分别为 IP1和 Portl。

IPTV媒体功能实体 1在 IP2和 Port2上监听 UE发送的播放控制命令。 步骤 703、 UE在接收 IPTV媒体功能实体 1发送的媒体流过程中进行 VCR 操作， 即发送播放控制命令给 IPTV媒体功能实体 1 , 携带请求的媒体内容信 息。 IPTV媒体功能实体 1接收到后判断自身没有该命令请求的媒体内容， 则 获取具有该命令请求的媒体内容的 IPTV媒体功能实体 2中的该媒体内容。 在本步骤中， IPTV媒体功能实体 1可以通过 SCF获取或直接查询相关数据 库定位到该命令请求的媒体内容存在 IPTV媒体功能实体 2中的信息， 还可以 釆用现有技术中的其他方法获取到。

步骤 704、 IPTV媒体功能实体 1向 IPTV媒体功能实体 1请求代理该命令 请求的媒体内容以及播放控制的代理。

步骤 7 05、 IPTV媒体功能实体 1转发 UE的播放控制命令给 IPTV媒体功能 实体 2 , 将 IPTV媒体功能实体 2的播放控制响应消息转发给 UE , 播放控制的 源 IP地址和端口号仍然分别为 IP2和 Por t 2。

步骤 706、 I PTV媒体功能实体 2 将该命令请求媒体内容的媒体流发送给 IPTV媒体功能实体 1 , 由 IPTV媒体功能实体 1转发给 UE , IPTV媒体功能实 体 1向 UE发送代理的媒体流时， 釆用的源 IP地址和端口号仍然分别为 IP1 和 Por t L

步骤 707、 为 UE提供的本次 IPTV业务结束时， 业务控制功能指示 IPTV媒 体功能实体 1释放播放控制资源和媒体发送资源， IPTV媒体功能实体 1除释 放自身为 UE分配的资源外， 指示 IPTV媒体功能实体 2释放为 UE分配的播放 控制资源和媒体发送资源。

在本实施例中， 步骤 706之后， 如果 UE又进行了 VCR操作， 需要使用新 的 IPTV媒体功能实体 3进行媒体流的传输， 则 IPTV媒体功能实体 1停止代 理 IPTV媒体功能实体 2的播放控制和媒体流，转而代理 IPTV媒体功能实体 3 的播放控制和媒体流， 但是， 值得注意的是， 媒体流发送的源 IP地址和端口 号仍然分别为 IP1和 Por t l ; 播放控制的源 IP地址和端口号仍然分别为 I P2 和 Por t 2。

以下几个具体实施例分别对上述三种解决方式进行举例说明。

具体实施例一， 釆用 RTP级代理的媒体代理方式

本实施例釆用媒体代理方式， 是基于 IMS的 IPTV业务的一个具体实施例， 其网络构架如图 8所示， 其中 UE、 IMS Core和 SCF是现有基于 IMS的 IPTV 业务的系统架构中已有的实体， 在本发明实施例中不做新的修改和要求。 本 发明实施例主要针对基于 IMS的 IPTV业务的系统架构中的 MCF以及 MDF进行 修改。

在图 8中， UE釆用已有的业务交互过程， 如 SIP交互过程通过 IMS Core 与 SCF进行交互， 建立 IPTV业务， 具体由 SCF选择 MCF, 再由 MCF选择一个 具有 UE请求的媒体内容的 MDF。 IPTV业务建立后， UE使用 RTSP进行 VCR操 作， 即向 MCF发送播放控制命令， 如果该命令请求的媒体内容不在当前为 UE 提供媒体流的 MDF上时， MCF选择另一个具有该命令请求的媒体内容的 MDF为 UE提供媒体流,提供媒体流的方式为当前为 UE提供媒体流的 MDF代理的方式， 且不更改本次 IPTV业务的媒体流发送的源 IP地址和端口号。

因此， 需要新增或修改的接口包括： MCF和 MDF之间的接口 C1以及 MDF之 间的接口 Ml。

图 9为本发明具体实施例一釆用 RTP级代理的媒体代理方式切换媒体服务 器的方法流程图， 涉及的网络实体包括 UE、 IMS Core 、 SCF、 MCF、 当前为 UE提供媒体流的 MDF1以及切换后为 UE提供媒体流的 MDF2 , 其具体步骤为： 步骤 901、 用户通过电子节目单选择某个节目后， UE向 IMS Core发送 SIP 访问 （INVITE ) 消息， 携带被选择节目对应的媒体内容信息以及 UE信息。

步骤 902、 IMS Core将 UE发送的 S IP INVITE消息路由到 SCF。

步骤 903、 SCF根据该消息携带的媒体内容信息和 UE信息， 对 UE是否有 权获取对应该媒体内容标识的媒体流， 进行鉴权计费。

步骤 904、 SCF对 UE进行鉴权计费通过后， 根据该消息携带的媒体内容信 息为 UE选择对应的 MCF。

在本步骤中，根据该消息携带的媒体内容信息选择对应的 MCF为现有技术， 不是本发明实施例保护的重点， 这里不再累述。

步骤 905、 SCF向选择的 MCF发送 S IP INVITE消息， 携带媒体内容信息和 UE信息。

在本步骤中， UE信息可以包括 UE位置等信息。

步骤 906、 MCF接收到 SCF发送的消息后， 根据该消息携带的媒体内容信 息为 UE选择提供该信息对应的媒体流的 MDF, 假设为 MDF1。

步骤 907、 MCF向 MDF1请求申请媒体发送资源， 以向 UE发送媒体流， MDF1 返回为媒体流分配的媒体发送资源信息。

在本步骤中， 媒体发送资源信息可以釆用会话描述协议 （ SDP, Session Description Protocol )描述， 包括发送媒体流的源 IP地址和端口号， 殳定 为 IP1和 PortL

步骤 908、 MCF建立与 UE之间的用于 VCR控制的 RTSP会话。

步骤 909、 MCF向 SCF返回 SIP 200消息， 携带媒体流的媒体发送资源信 息和建立的 RTSP会话信息。

步骤 910、 SCF将接收到的 SIP 200消息经 IMS Core路由。

步骤 911、 UE接收到该 S I P 200消息。

步骤 912、 UE返回 SIP ACK消息， 携带 UE信息。

在本步骤中， UE信息可以釆用 SDP描述。

步骤 913、 IMS Core接收到 UE的 SIP ACK消息后， 根据 UE侧以及 MDF侧 的 SDP描述， 为 UE预留用于传送媒体流的承载资源。

步骤 914、 SIP ACK消息路由到 SCF。

步骤 915、 SCF将接收到的 SIP ACK消息发送到 MCF。

步骤 916、 MCF根据该 SIP ACK消息获取 UE信息， 控制 MDF1向 UE发送包 括对应 UE请求的媒体内容信息的媒体内容的媒体流。

步骤 917、 在 MCF的控制下， MDF1将封装有媒体流的 RTP包发送到 UE。 步骤 918、 UE发送的 RTCP消息发送到 MDF处理。

RTCP是实时传输控制协议， 是与 RTP同时使用的， 用于向对端反馈 RTP传 送的一些信息， 例如 RTP的丟包情况等， 该 RTCP消息不是播放控制的协议。 RTCP消息为媒体流传输控制消息。

步骤 919、 MDF发送的 RTCP消息将发送到 UE处理。

步骤 920、 用户欣赏节目的过程中， 进行 VCR操作， 例如快进或快退等。 VCR操作的 RTSP消息发送到 MCF , 该消息携带要请求媒体内容信息， 包括媒 体内容标识等。

RTSP消息为播放控制消息。

步骤 921、 MCF检测得到该消息要请求的媒体内容不在 MDF1上， 则选择具 有该消息要请求的媒体内容的 MDF2。

步骤 922、 MCF向 MDF1请求代理 MDF2对应该请求携带的媒体内容信息的 媒体流， MDF1返回准备接收 MDF2发送的承载媒体流的 RTP包的接收 IP地址 和端口号， ^叚定为 IP2以及 Por t 2。

在本步骤中， 釆用的代理为 RTP级代理。

步骤 923、 MCF向 MDF2发送申请媒体发送资源的请求消息， 准备发送 UE 请求的媒体内容的媒体流给 MDF1 ,消息中携带媒体内容信息和 MDF1准备接收 媒体流的目的 IP地址和端口号 （ IP2和 Por t 2 )。

步骤 924、 MDF2根据 MCF发送的请求消息， 将包括对应该消息携带的媒体 内容信息的媒体内容的媒体流承载在 RTP包， 发送到 MDF1准备接收媒体流的 目的 IP地址和端口号上。

步骤 925、 MDF1将从 MDF2接收到的承载媒体流的 RTP包重新处理， 打包 为 IP包， 使用原来的源 IP地址和端口号 （ IP1和 Por t l )发送给 UE。

步骤 926、 UE发送的 RTCP消息将发送到 MDF1处理。

步骤 927、 MDF1发送的 RTCP消息将发送到 UE处理。

步骤 928、 用户结束节目的观看， 发送 S IP BYE消息。

步骤 929、 S IP BYE消息通过 IMS Core路由到 SCF。

步骤 930、 SCF将 S IP BYE消息发送到 MCF。

步骤 931、 MCF指示 MDF2释放为 UE分配的媒体发送资源。 步骤 932、 MCF指示 MDF1释放为 UE分配的媒体发送资源。

步骤 933、 MCF返回 S IP 200消息。

步骤 934、 SCF发送 S IP 200消息到 IMS Core。

步骤 935、 IMS Core接收到 SIP 200消息， 释放预留的承载媒体流资源。 步骤 936、 UE接收到 SIP 200消息， 本次 IPTV业务结束。

具体实施例二， 釆用应用级代理的媒体代理方法

在具体实施例一中， 媒体代理使用的是 RTP级代理， 即被代理的 MDF2发 送承载媒体流的 RTP包给 MDF1 , 由 MDF1处理后重新封装为 IP包发送给 UE。

在具体实施例二中， 媒体代理使用应用级的代理， 即 MDF2发送给 MDF1的 不是承载媒体流的 RTP包， 而是将媒体流直接发送给 MDF1 , 例如釆用文件传 输协议 ( FTP, Fi le Transfer Protocol )方式等发送， 由 MDF1 直接使用媒 体流组装 RTP包发送。

因此， 具体实施例二与具体实施例一中的网络逻辑架构完全一致， 大的流 程也基本一致， 只是 MCF与 MDF1、 MDF2以及 MDF1和 MDF2之间的交互有所不 同， 图 10所示的流程图列举了不同之处。

步骤 1022、 MCF向 MDF1请求代理 MDF2对应该请求携带的媒体内容信息的 媒体流， MDF1返回准备接收 MDF2媒体流的 IP包的接收 IP地址和端口号，假 定为 IP2以及 Por t2。

步骤 1023、 MCF向 MDF2发送申请媒体发送资源的请求消息， 准备发送 UE 请求的媒体内容给 MDF1 ,消息中携带媒体内容信息和 MDF1准备接收媒体流的 目的 IP地址和端口号 （ IP2和 Por t 2 )₀

步骤 1024、 MDF2根据 MCF发送的请求消息， 将对应该消息携带的媒体内 容信息的媒体流发送到该消息携带的 MDF1准备接收媒体流的目的 IP地址和 端口号上。

发送媒体流时可以釆用 FTP方式。

步骤 1025、 MDF1将从 MDF2接收到的媒体流的封装为 RTP包， 使用原来的 源 IP地址和端口号 （ IP1和 Portl )发送给 UE。

在本实施例中，只需要将步骤 1022 ~ 1025替换了图 9中的步骤 922 ~ 925 , 其他的步骤如图 10所示即可实现具体实施例二。

具体实施例三， 媒体流源 IP地址和端口号集中管理的方式

本实施例使用 MCF在为 UE提供的本次 IPTV业务中， 集中管理为 UE发送 媒体流的源 IP地址和端口号。 媒体流的源 IP地址和端口号都是由 MCF集中 管理和分配， MDF发送承载媒体流的 RTP包给 UE时，媒体流发送的源 IP地址 和端口号使用 MCF分配的 IP地址和端口号， 而不能使用 MDF 自己的 IP地址 和端口号。 由于 MDF使用的 IP地址不是其本身的 IP地址， UE使用该 IP地址 作为目的地址发送给 MDF的 RTCP消息， 将不能直接路由给 MDF, 将路由到实 际具有该 IP地址的实体， 该实体需要负责转发 UE发送的 RTCP消息给对应的 MDF。 因此， 该实体需要获知 RTCP消息转发给哪一个 MDF, 需要建立 RTCP消 息原接收 IP地址和端口号与实际接收 IP地址和端口号的对应关系， 这里将 该实体称为 RTCP代理实体。

在具体实现中， RTCP代理实体可以为 MCF。 使用 MCF作为该 RTCP代理是 一个很好的选择， 因为这样不需要在基于 IMS的 IPTV业务网络构架中引入新 的实体和接口， 而且 MCF上已经具有真正为 UE提供媒体流的 MDF的 IP地址 和端口号，也就是可以获知 UE发送的 RTCP消息传输给哪一个 MDF。当然， RTCP 代理实体也可以为其他的实体，但是必须在该实体中预先建立 RTCP消息原 IP 接收地址和端口号与实际接收 IP地址和端口号之间的对应关系。

图 11为本发明具体实施例三釆用媒体流源 IP地址和端口号集中管理方式 实现切换媒体服务器的网络架构图， 与具体实施例一不同， MDF2不与 MDF1进 行信息交互， 而直接通过 RTP/RTCP接口与 UE进行信息交互， 将媒体流直接 传输给 UE (媒体流的媒体发送 IP地址和端口号由 MCF分配， 且保证在本次为 UE提供 IPTV业务的过程中不变， 即使 MDF已经切换）。 因此， 本实施例需要 新增或修改的接口包括： MCF和 MDF之间的接口 C2。 图 12为本发明具体实施例三釆用媒体流源 IP地址和端口号集中管理方式 切换媒体服务器的方法流程图， 涉及的网络实体包括 UE、 IMS Core 、 SCF、 MCF、 当前为 UE提供媒体流的 MDF1以及切换后为 UE提供媒体流的 MDF2 , 其 具体步骤为：

步骤 1201、用户通过电子节目单选择某个节目后， UE向 IMS Core发送 SIP INVITE消息， 携带被选择节目对应的媒体内容信息和 UE信息。

步骤 1202、 IMS Core将 UE发送的 SIP INVITE消息路由到 SCF。

步骤 1203、 SCF对 UE是否有权获取对应该媒体内容标识的媒体流， 进行 鉴权计费。

步骤 1204、 SCF对 UE进行鉴权计费通过后， 根据该消息携带的媒体内容 标识为 UE选择对应的 MCF。

步骤 1205、 SCF向选择的 MCF发送 SIP INVITE消息， 携带媒体内容信息 和 UE信息。

在本步骤中， UE信息可以包括 UE位置等信息。

步骤 1206、 MCF接收到 SCF发送的消息后， 根据该消息携带的媒体内容信 息为 UE选择提供该标识对应的媒体内容的媒体流的 MDF, 假设为 MDF1 , 并分 配用于本次 IPTV业务发送承载媒体流的 RTP包的源 IP地址和端口号， 假设 为 IP1和 PortL

该 IP地址可能不是 MDF1本身的 IP地址， 可能为其他实体的 IP地址， 例 如 MCF的 IP地址。

步骤 1207、 MCF向 MDF1请求申请媒体发送资源， 以向 UE发送媒体流， 并 指定使用 MCF分配的 IP地址和端口号（ IP1 , Portl )作为发送承载媒体流的 RTP包的源 IP地址和端口号。

步骤 1208、 MCF建立与 UE之间的用于 VCR控制的 RTSP会话。

步骤 1209、 MCF向 SCF返回 SIP 200消息， 携带媒体流的媒体发送资源信 息和建立的 RTSP会话信息。 步骤 1210、 SCF将接收到的 SIP 200消息经 IMS Core路由。

步骤 1211、 UE接收到该 SIP 200消息。

步骤 1212、 UE返回 S IP ACK消息， 携带 UE信息。

在本步骤中， UE信息可以釆用 SDP描述。

步骤 1213、 IMS Core接收到 UE的 SIP ACK消息后， 根据 UE侧以及 MDF 侧的 SDP描述， 为 UE预留用于传送媒体流的承载资源。

步骤 1214、 S IP ACK消息路由到 SCF。

步骤 1215、 SCF将接收到的 SIP ACK消息发送到 MCF。

步骤 1216、 MCF根据该 SIP ACK消息获取 UE信息， 控制 MDF1向 UE发送 对应 UE请求的媒体内容信息的媒体流。

步骤 1217、 在 MCF的控制下， MDF1将封装有媒体流的 RTP包发送到 UE, 在 RTP包中使用的源 IP地址和端口号分别为 IP1和 Por t l。

步骤 1218、 封装有媒体流的 RTP包从 MDF1发送到 UE。

步骤 1219、 UE发送的 RTCP消息将发送到 IP地址为 IP1的实体， 假定为 MCF, 即 UE向发送媒体流的源 IP地址回复 RTCP消息， 不能直接到 MDF1 , 而 是要路由到 IP地址为 IP1的实体上， 即 MCF。

步骤 1220、 IP地址为 IP1的实体， 转发 RTCP消息给 MDF1。

在本步骤中， 具有 IP地址 IP1的实体为 MCF, MCF根据预先设置的对应关 系， 将 RTCP消息转发给 MDF1。 这里， 由于 IP1和 Por t l是由 MCF分配的， 所 以存储有 IP1和 Por t l与 MDF1之间的对应关系。

步骤 1221、 MDF1发送的 RTCP消息， 发送到 IPTV终端。

步骤 1222、 用户欣赏节目的过程中， 进行 VCR操作， 例如快进或快退等。 VCR操作的 RTSP消息发送到 MCF , 该消息携带要请求媒体内容信息， 包括媒 体内容标识等。

RTSP消息为播放控制消息。

步骤 1223、 MCF检测得到该消息要请求的媒体内容不在 MDF1上， 则选择 具有该消息要请求的媒体内容的 MDF2。

步骤 1224、 MCF向 MDF2发送申请媒体发送资源的请求消息， 以传送指定 的媒体内容，并指定使用 MCF为本次 IPTV业务已分配的 IP地址和端口号（ IP1 和 Portl )作为媒体流的源 IP地址和端口号。

步骤 1225、MCF指示 MDF1释放媒体发送资源， MDF1停止向 UE发送媒体流， 释放对 IP1和 Portl的使用。

步骤 1226、 MDF2根据 MCF发送的请求消息， 将对应该消息携带的媒体内 容信息的媒体流承载在 RTP包发送给 UE,使用 MCF指定的 IP地址和端口号（ IP1 和 Portl )作为媒体流的源 IP地址和端口号。

步骤 1227、 UE发送的 RTCP消息将发送到 IP地址为 IP1的实体， 假定为

MCF, 即 UE向发送媒体流的源 IP地址回复 RTCP消息， 不能直接到 MDF2 , 而 是要路由到 IP地址为 IP1的实体上， 即 MCF。

步骤 1228、 IP地址为 IP1的实体， 转发 RTCP消息给 MDF2。

在本步骤中， 具有 IP地址 IP1的实体为 MCF, MCF根据预先设置的对应关 系， 将 RTCP消息转发给 MDF2。 这里， 由于 IP1和 Portl是由 MCF分配的， 所 以存储有 IP1和 Portl与 MDF2之间的对应关系。

步骤 1229、 MDF2发送的 RTCP消息， 发送到 UE。

步骤 1230、 用户结束节目的观看， UE发送 SIP BYE消息。

步骤 1231、 SIP BYE消息通过 IMS Core路由到 SCF。

步骤 1232、 SCF将 SIP BYE消息发送到 MCF。

步骤 1233、 MCF指示 MDF2释放为 UE分配的媒体发送资源。

步骤 1234、 MCF释放为 UE本次 IPTV业务分配的 IP地址和端口号（ IP1和

Portl ) , 该 IP地址和端口号可以分给其他 UE或该 UE在下次 IPTV业务中使 用。

步骤 1235、 MCF返回 SIP 200消息。

步骤 1236、 SCF发送 SIP 200消息到 IMS Core。 步骤 1237、 IMS Core接收到 SIP 200消息， 释放预留的承载媒体流资源。 步骤 1238、 UE接收到 SIP 200消息， 本次 IPTV业务结束。

具体实施例四， 播放控制代理及媒体代理方式

本实施例釆用播放控制代理及媒体代理方式， 是基于 IMS的 IPTV业务的 一个具体实施例， 其网络架构如图 13所示， 其中 UE、 IMS Core和 SCF是现 有基于 IMS的 IPTV业务的系统架构中已有的实体， 在本发明实施例中不做新 的修改和要求。 本发明实施例主要针对基于 IMS的 IPTV业务的系统架构中的 IPTV媒体功能实体进行修改。

在图 13中， UE釆用已有的业务交互过程， 如 SIP交互过程通过 IMS Core 与 SCF进行交互， 选择 IPTV媒体功能实体， 建立 IPTV业务， 包括媒体播放 控制的协商和媒体流的协商。 IPTV业务建立后， UE使用 RTSP进行 VCR操作， 即向当前为 UE提供服务的 IPTV媒体功能实体发送播放控制命令， 如果该命 令请求的媒体内容不在当前为 UE提供服务的 IPTV媒体功能实体上时，该 IPTV 媒体功能实体选择另一个具有该媒体内容的新 IPTV媒体功能实体。该新 IPTV 媒体功能实体不能与 UE直接交互， 而是由当前为 UE提供服务的 IPTV媒体功 能实体直接与 UE进行交互，播放控制及媒体流均由当前为 UE提供服务的 IPTV 媒体功能实体进行代理转发， 从而在 UE的本次 IPTV业务中实现发送媒体流 的源 I P地址和端口号不变。

因此， 需要新增或修改的接口包括： IPTV媒体功能实体之间的接口 C3和 M3, 分别完成播放控制代理和媒体流代理。

图 14 为本发明具体实施例四釆用播放控制代理及媒体代理方式实现切换 媒体服务器的方法流程图， 涉及的网络实体包括 UE、 IMS Core 、 SCF、 当前 为 UE提供媒体流的 IPTV媒体功能实体 1以及切换后为 UE提供媒体流的 IPTV 媒体功能实体 2 , 其具体步骤为：

步骤 1401、用户通过电子节目单选择某个节目后， UE向 IMS Core发送 SIP INVITE消息， 携带被选择节目对应的媒体内容信息和 UE信息。 步骤 1402、 IMS Core将 UE发送的 SIP INVITE消息路由到 SCF。

步骤 1403、 SCF对 UE是否有权获取对应该媒体内容标识的媒体流， 进行 鉴权计费。

步骤 1404、 SCF对 UE进行鉴权计费通过后， 根据该消息携带的媒体内容 信息为 UE选择对应的 IPTV媒体功能实体 1。

步骤 1405、 SCF向 IPTV媒体功能实体 1发送 SIP INVITE消息， 携带媒体 内容信息和 UE信息。

在本步骤中， UE信息可以包括 UE位置等信息。

步骤 1406、 IPTV媒体功能实体 1分配媒体发送资源， 获取本端媒体信息， 可以釆用 SDP进行描述， 支设本端媒体地址为 IP1和 Por t l。

步骤 1407、 IPTV媒体功能实体 1分配播放控制资源， 获取本端播放控制 的 SDP描述， 建立与 UE之间建立 RTSP会话。

在本步骤中， 假设本端媒体播放控制地址为 IP2以及 Por t2。

步骤 1408、 IPTV媒体功能实体 1向 SCF返回 SIP 200消息， 携带媒体发 送资源信息的 SDP描述和播放控制信息的 SDP描述。

步骤 1409、 S IP 200消息经过 IMS Core路由。

步骤 1410、 UE接收到携带媒体流发送资源信息的 SDP描述和播放控制信 息的 SDP描述的 SIP 200消息。

步骤 1411、 UE返回 S IP ACK消息， 携带 UE信息。

在本步骤中， UE信息釆用 SDP描述。

步骤 1412、 IMS Core处理 UE的 SIP ACK消息， 根据 UE侧和 IPTV媒体功 能实体 1侧的 SDP描述， 为 UE预留将用于传送媒体流的承载资源。

步骤 1413、 S IP ACK消息路由到 SCF , 携带 UE信息。

步骤 1414、 SCF处理 SIP ACK消息， 发送 SIP ACK消息到 IPTV媒体功能 实体 1 , 携带 UE信息。

步骤 1415、 IPTV媒体功能实体 1根据接收到消息携带的 UE信息确定发送 媒体流的地址， 向 UE传送承载媒体流的 RTP包， 并监听是否有 RTSP消息。 在本步骤中， RTSP消息就是播放控制命令。

步骤 1416、 承载媒体流的 RTP包从 IPTV媒体功能实体 1发送到 UE。

步骤 1417、 UE发送的 RTCP消息发送到 IPTV媒体功能实体 1。

步骤 1418、 IPTV媒体功能实体 1发送的 RTCP消息发送到 UE处理。

步骤 1419、 用户欣赏节目的过程中， 进行 VCR操作， 例如快进或快退等。

VCR操作的 RTSP消息发送到 IPTV媒体功能实体 1上，携带要请求的媒体内容 信息， 如媒体内容标识等。

步骤 1420、 IPTV媒体功能实体 1检测到自身没有对应于该消息携带的媒 体内容信息的媒体内容， 查询保存媒体内容位置的数据库或釆用现有技术的 方法， 选择具有对应该消息携带的媒体内容信息的媒体内容的 IPTV媒体功能 实体， 这里假设为 IPTV媒体功能实体 2。

步骤 1421、 IPTV媒体功能实体 1向 IPTV媒体功能实体 1请求代理 IPTV 媒体功能实体 1的播放控制消息和媒体流。

步骤 1422、 IPTV媒体功能实体 1 申请本端的播放控制资源和媒体发送资 源。

步骤 1423、 IPTV媒体功能实体 2向 IPTV媒体功能实体 1返回 IPTV媒体 功能实体 2侧播放控制资源和媒体发送资源的信息， 该信息可以釆用 SDP进 行描述。

步骤 1424、 IPTV媒体功能实体 1向 IPTV媒体功能实体 1发送对应该消息 携带的媒体内容信息的媒体内容的媒体流。

步骤 1425、 IPTV媒体功能实体 1将从 IPTV媒体功能实体 1接收到的媒体 流， 重新处理后封装为 IP包发送给 IPTV终端。

在本步骤中， 媒体流的源 IP地址和端口号仍然使用 IP媒体功能实体 1的 IP地址和端口号。

步骤 1426、 IPTV媒体功能实体 1接收到 IPTV终端的 RTCP消息， 根据目 的 IP地址和端口号， 识别出需要代理转发给 IPTV媒体功能实体 2。

步骤 1427、 RTCP消息从 IPTV媒体功能实体 1代理转发给 IPTV媒体功能 实体 2。

步骤 1428、 IPTV媒体功能实体 2的 RTCP消息发送给 IPTV媒体功能实体 1。 步骤 1429、 IPTV媒体功能实体 1将来自 IPTV媒体功能实体 1的 RTCP消 息发送给 UE。

步骤 1430、 用户进行 VCR操作， UE发送 RTSP消息发送给 IPTV媒体功能 实体 1。

步骤 1431、 IPTV媒体功能实体 1转发 RTCP消息给 IPTV媒体功能实体 2。 步骤 1432、 IPTV媒体功能实体 1的 RTSP消息发送给 IPTV媒体功能实体 1。 步骤 1433、 IPTV媒体功能实体 1转发 IPTV媒体功能实体 1的 RTSP消息 给 UE。

步骤 1434、 用户结束节目的观看， 发送 SIP BYE消息。

步骤 1435、 S IP BYE消息经 IMS Core路由到 SCF。

步骤 1436、 SCF处理 SIP BYE消息后， 发送 SIP BYE消息给 IPTV媒体功 能实体 1。

步骤 1437、 IPTV媒体功能实体 1指示 IPTV媒体功能实体 2释放播放控制 资源和媒体发送资源。

步骤 1438、 IPTV媒体功能实体 1释放自身的播放控制资源和媒体发送资 源。

步骤 1439、 IPTV媒体功能实体 1返回 S IP 200消息。

步骤 1440、 SCF发送 SIP 200消息到 IMS Core。

步骤 1441、 IMS Core接收到 SIP 200消息， 释放预留的承载资源， 将该 消息发送给 UE。

步骤 1442、 UE接收到 SIP 200消息后， 本次 IPTV业务结束。

在图 14中， IPTV媒体功能实体 1代理 IPTV媒体功能实体 1发送的媒体流 时， 也可以釆用 RTP级代理或应用级代理的代理方式进行代理。

综上所述， 本发明实施例提供了在 IPTV业务使用过程中， 在 UE进行 VCR 操作等原因导致媒体服务器需要切换的情况下， 保持媒体流发送的源 IP地址 和端口号保持不变。 本发明通过保持媒体流发送的源 IP地址和端口号保持不 变的方案， 可以保证不需要进行 UE和第二媒体服务器， 即切换后的媒体服务 器之间进行再次协商， 提高了基于 IMS的 IPTV业务的网络提供媒体流的响应 速度， 避免 IPTV业务使用过程中由于媒体服务器切换而导致的媒体流的传输 延迟， 而影响的用户感受。

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

Claims

权 利 要求 书

1、 一种媒体服务器切换过程中提供媒体流的方法， 其特征在于， 所述媒体 服务器为媒体交付功能实体， 该方法包括：

为用户设备提供媒体流的媒体交付功能实体， 由第一媒体交付功能实体切换 到第二媒体交付功能实体；

第二媒体交付功能实体为用户设备提供的媒体流， 由第一媒体交付功能实体 代理发送。

1、 如权利要求 1 所述的媒体服务器切换过程中提供媒体流的方法， 其特征 在于， 所述代理发送是由媒体控制功能实体控制进行的， 所述媒体控制功能实 体管辖第一媒体交付功能实体和第二媒体交付功能实体。

3、 如权利要求 1或 1所述的媒体服务器切换过程中提供媒体流的方法， 其 特征在于， 所述代理包括： 实时传输协议包级代理、 内容级代理。

4、 如权利要求 1或 1所述的媒体服务器切换过程中提供媒体流的方法， 其 特征在于， 所述代理发送包括：

第二媒体交付功能实体将为用户设备提供的媒体流发送给第一媒体交付功 能实体， 第一媒体交付功能实体使用预先为该媒体流分配的媒体参数发送该媒 体流， 所述为该媒体流分配的媒体参数与第一媒体交付功能实体为用户设备提 供的媒体流所分配的媒体参数相同。

5、 一种媒体服务器切换过程中提供媒体流的系统， 其特征在于， 所述媒体 服务器为媒体交付功能实体， 该系统包括： 第一媒体交付功能实体、 第二媒体 交付功能实体、 媒体控制功能实体， 其中，

媒体控制功能实体， 用于在为用户提供媒体流的媒体交付功能实体由第一媒 体交付功能实体切换到第二媒体交付功能实体时， 控制第一媒体交付功能实体 和第二媒体交付功能实体；

第二媒体交付功能实体， 用于在媒体控制功能实体的控制下将为用户设备提 供的媒体流发送给第一媒体交付功能实体； 第一媒体交付功能实体， 用于在媒体控制功能实体的控制下代理发送从第二 媒体交付功能实体接收的媒体流给用户设备。

6、 一种媒体服务器切换过程中提供媒体流的方法， 其特征在于， 所述媒体 服务器为媒体交付功能实体， 该方法包括：

为用户设备提供媒体流的媒体交付功能实体由第一媒体交付功能实体切换 到第二媒体交付功能实体；

第二媒体交付功能实体使用媒体控制功能实体为该媒体流预先分配的媒体 参数发送媒体流。

7、 如权利要求 6 所述的媒体服务器切换过程中提供媒体流的方法， 其特征 在于， 所述媒体控制功能实体为该媒体流预先分配的媒体参数保持不变， 与第 一媒体交付功能实体发送媒体流所使用的媒体参数相同。

8、 一种媒体服务器切换过程中提供媒体流的系统， 其特征在于， 所述媒体 服务器为媒体交付功能实体， 该系统包括： 第一媒体交付功能实体、 第二媒体 交付功能实体、 媒体控制功能实体， 其中，

媒体控制功能实体， 用于为用户设备提供媒体流的媒体交付功能实体由第一 媒体交付功能实体切换到第二媒体交付功能实体时， 为第二媒体交付功能实体 分配与第一媒体交付功能实体发送媒体流的相同媒体参数后， 发送给第二媒体 交付功能实体；

第二媒体交付功能实体， 用于使用从媒体控制功能实体接收的媒体参数发送 媒体流给用户设备。

9、 一种媒体服务器切换过程中提供媒体流的方法， 其特征在于， 所述媒体 服务器为媒体功能实体， 该方法包括：

为用户设备提供媒体流的媒体功能实体由第一媒体功能实体切换到第二媒 体功能实体， 第二媒体功能实体为用户设备提供的媒体流， 由第一媒体功能实 体代理发送。

10、 如权利要求 9所述的媒体服务器切换过程中提供媒体流的方法， 其特征 在于， 所述代理发送为：

第二媒体功能实体将为用户设备提供的媒体流发送给第一媒体功能实体， 第 一媒体功能实体使用预先为该媒体流分配的媒体参数发送该媒体流， 所述为该 媒体流分配的媒体参数与第一媒体功能实体为用户设备提供的媒体流所分配的 媒体参数相同。

11、 如权利要求 9所述的媒体服务器切换过程中提供媒体流的方法， 其特征 在于， 该方法进一步包括：

第二媒体功能实体为用户设备提供的播放控制响应消息， 由第一媒体功能实 体代理发送。

12、 如权利要求 9所述的媒体服务器切换过程中提供媒体流的方法， 其特征 在于， 所述方法还包括：

所述第一媒体功能实体接收到的用户设备发送的播放控制消息后， 将所述播 放控制消息发送给第二媒体功能实体；

所述第一媒体功能实体将接收到的第二媒体功能实体处理播放控制消息后 生成的播放控制响应消息， 利用预先为该媒体流分配的播放控制参数将所述播 放控制响应消息发送给用户设备。

1 3、 一种媒体服务器切换过程中提供媒体流的系统， 其特征在于， 所述媒体 服务器为媒体功能实体， 该系统包括： 第一媒体功能实体、 第二媒体功能实体， 其中，

第二媒体功能实体， 用于为用户设备提供媒体流的媒体功能实体由第一媒体 功能实体切换到第二媒体功能实体时， 将为用户设备提供的媒体流发送给第一 媒体功能实体；

第一媒体功能实体， 用于代理发送从第二媒体功能实体接收的媒体流给用户 设备。