一种获取IPTV业务媒体描述信息的方法及装置

摘要

本发明公开了一种获取IPTV业务媒体描述信息的方法，包括以下步骤：网络侧设备接收用户终端通过核心IMS发送的获取媒体描述信息的SIP请求，所述请求中携带内容标识；所述网络侧设备将所述内容标识对应的媒体描述信息携带在SIP响应消息中，通过所述核心IMS发送给所述用户终端。本发明通过SIP消息获取媒体描述信息实现COD业务的会话建立。

权利要求

1.一种获取IPTV业务媒体描述信息的方法，其特征在于，包括以下步骤：网络侧设备接收用户终端通过核心IMS发送的获取媒体描述信息的SIP请求，所述请求中携带内容标识；

所述网络侧设备将所述内容标识对应的媒体描述信息携带在SIP响应消息中，通过所述核心IMS发送给所述用户终端；

其中所述网络侧设备将所述内容标识对应的媒体描述信息携带在响应消息中之前还包括：所述网络侧设备从内容描述元功能获取媒体描述信息；

所述获取媒体描述信息的SIP请求为OPTIONS或INVITE。

2.如权利要求1所述获取IPTV业务媒体描述信息的方法，其特征在于，所述媒体描述信息包括内容控制通道和/或内容交付通道参数。

3.如权利要求1所述获取IPTV业务媒体描述信息的方法，其特征在于，所述内容描述元功能是网络侧设备内部的功能，或者是独立的功能实体。

4.如权利要求1至3中任一项所述获取IPTV业务媒体描述信息的方法，其特征在于，所述网络侧设备为业务控制功能SCF或媒体功能MF。

5.如权利要求1所述获取IPTV业务媒体描述信息的方法，其特征在于，所述媒体描述信息通过SDP或XML方式携带在响应消息中。

6.一种网络侧设备，其特征在于，包括：

接收单元，用于接收用户终端通过核心IMS发送的获取媒体描述信息的SIP请求，所述请求中携带内容标识；

生成单元，用于生成响应消息，所述响应消息中的SDP携带所述内容标识对应的媒体描述信息；

发送单元，用于将所述响应消息通过所述核心IMS发送给所述用户终端；

获取单元，用于从内容描述元功能获取媒体描述信息；

其中所述获取媒体描述信息的SIP请求为OPTIONS或INVITE。

7.如权利要求6所述网络侧设备，其特征在于，其中所述内容描述元功能是网络侧设备内部的功能，或者是独立的功能实体。

8.如权利要求6所述网络侧设备，其特征在于，所述网络侧设备为业务控制功能SCF或媒体功能MF。

说明书

技术领域

本发明涉及通信技术领域，尤其涉及一种获取IPTV业务媒体描述信息的方法及装置。

背景技术

IMS(IP Multimedia Subsystem，IP多媒体子系统)是最初在3GPP(3rdGeneration Partnership Project，第三代移动通信标准化伙伴项目)R5阶段增加的WCDMA(Wideband Code Division Multiple Access，宽带码分多址接入)网络中叠加在已有分组域上的一个子系统，采用分组域为其上层控制信令和媒体交付的承载通道，引入SIP(Session Initiation Protocol，会话初始协议)作为业务控制协议，利用SIP简单、易扩展、媒体组合方便的特点，通过将业务控制与承载控制分离，提供丰富的多媒体业务。对IMS进行标准化的国际标准组织主要有3GPP和TISPAN(Telecommunications and Internet convergedServices and Protocol for Advanced Networking，电信和互联网融合业务及高级网络协议)。3GPP侧重于从移动的角度对IMS进行研究，而TISPAN则侧重于从固定的角度对IMS提出需求，并统一由3GPP完善，最终实现IMS对固定接入和移动接入的统一控制。
IMS based IPTV(基于IMS的IP电视)是在TISPAN提出的在IMS的整体架构下提供IPTV业务，以充分利用IMS网络中已有的注册、认证、路由、会话控制与建立、业务触发、计费、端到端QoS(Quality of Service，服务质量)保证等机制来为用户提供流媒体业务及融合流媒体和实时会话业务的多媒体业务。也就是说，用户到内容的多媒体会话是通过IMS已有的会话控制机制完成，在建立会话过程中，需要为媒体流的传送预留承载资源。
现有技术中，CoD流程会话建立过程的主要特点是：由于在CoD业务过程中用户能对所看的内容进行VCR控制(如前进、后退、暂停等)，因此该业务需要建立媒体控制通道(用于VCR操作)和媒体交付通道(用于传送所看的内容)。根据媒体控制通道和媒体交付通道建立方式的不同，TISPAN中定义的CoD业务流程，主要可以分为两种：第一种方式是媒体控制通道和媒体交付通道在SIP会话建立过程中同时建立；第二种方式是在会话建立初始过程中先建立媒体控制通道，然后再通过会话更改建立媒体交付通道。
采用第一种方式的情况是终端UE已经从EPG(电子节目单)上获取所观看的内容的媒体信息，如该内容包括哪些媒体行，如音频、视频、文本等，因此可以协商和建立该媒体交付通道。采用第二种方式，即先通过SIP会话建立过程协商建立媒体控制通道(通常是RTSP通道)，然后在终端和媒体服务器之间建立媒体交互控制会话，然后通过媒体控制消息的交互获取媒体网络参数信息，然后在会话更改过程中发起建立内容交付通道。
事实上，第二种方式相对于第一种方式存在以下缺陷：如导致会话建立时间延长，大致过程如下：在会话初始建立(通常采用SIP消息)后，终端和网络(媒体服务器)之间还要再发起媒体控制消息(通常是RTSP DESCRIBE消息)建立媒体控制会话，然后在媒体控制会话消息中交换媒体的内容信息，最后再通过会话更改过程(又回到SIP消息)来完成媒体通道的建立。导致用户的服务体验降低，因此目前的规范中对采用第二种方式的应用条件有如下限制：只有当网络只提供给了用户媒体控制通道的网络参数信息(没有提供内容交付通道的网络参数信息)，初始会话建立内容交付通道才是可选的(即采用第二种方式)。然而，第二种方式需要终端UE和网络侧有更多的交互，对终端提出更多的需求，并导致会话建立延迟，使得用户的体验变差。

发明内容

本发明实施例提供一种CoD业务实现方法及设备，通过SIP消息获取媒体描述信息实现CoD业务的会话建立。
发明实施例提供了一种获取IPTV业务媒体描述信息的方法，包括以下步骤：
网络侧设备接收用户终端通过核心IMS发送的获取媒体描述信息的SIP请求，所述请求中携带内容标识；
所述网络侧设备将所述内容标识对应的媒体描述信息携带在SIP响应消息中，通过所述核心IMS发送给所述用户终端。
本发明实施例提供了一种网络侧设备，包括：
接收单元，用于接收用户终端通过核心IMS发送的获取媒体描述信息的SIP请求，所述请求中携带内容标识；
生成单元，用于生成响应消息，所述响应消息中的SDP携带所述内容标识对应的媒体描述信息；
发送单元，用于将所述响应消息通过所述核心IMS发送给所述用户终端。
本发明实施例提供了一种媒体控制协商方法，其特征在于，包括以下步骤：
网络侧设备接收用户终端发送的控制模式信息；
所述网络侧设备向所述用户终端返回控制模式信息，所述控制模式信息通过SIP头域或消息体的SDP属性行携带。
本发明的实施例中，用户终端可以从SCF或MF等相关实体获取控制参数、网络参数及内容媒体描述等信息，并根据这些参数进行相应操作。

附图说明

图1是现有技术中对CoID业务的描述流程图；
图2是本发明实施例二中获取媒体描述信息的系统结构图；
图3是本发明实施例三中获取媒体描述信息的方法流程图；
图4是本发明实施例四中获取媒体描述信息的方法流程图；
图5是本发明实施例五中一种实现媒体控制的方法流程图；
图6是本发明实施例六中一种实现媒体控制的方法流程图；
图7是本发明实施例七中一种实现媒体控制的系统结构示意图；
图8是本发明实施例八中终端在发起CoD会话请求前一种获取媒体信息的方法流程图；
图9是本发明实施例九中终端在发起CoD会话请求前另一种获取媒体信息的方法流程图；
图10是本发明实施例十中终端在发起CoD会话请求过程中获取媒体信息的方法流程图；
图11是本发明实施例十一中终端在发起CoD业务请求中另一种获取媒体信息的方法流程图；
图12是本发明实施例十二中一种网络侧设备的结构示意图；
图13是本发明实施例十三中用户终端与网络实体通过协商确定最终使用的控制模式的流程图。

具体实施方式

由于现有技术中，RTSP(Real Time Streaming Protocol，实时流协议)的会话协商和建立过程对上述操作方式有比较好的支持，如建立聚合模式，可以同步控制所有媒体交付通道，也可以采用单独模式，可以对每一个媒体交付通道单独控制。
在IMS的CoD(Content on Demand，内容点播)业务中，RTSP会话的相关参数是在SIP会话建立过程中进行协商的，不再有RTSP的会话建立过程(如，RTSP的Setup消息)，而是在SIP会话建立完成后，直接采用RTSP消息进行VCR操作控制。由于相关的RTSP参数都是在SIP/SDP(SessionDescription Protocol，会话描述协议)消息中进行携带并进行协商，因此，在IMS based IPTV业务环境中，SIP/SDP消息无法指示CoD业务中对内容的单个或多个媒体交付通道的VCR操作，即当用户通过RTSP消息进行VCR操作时，无法对内容的某个或者某几个媒体通道进行VCR操作；即现有技术中的SIP/SDP消息无法将这些信息传递给用户终端。
本发明实施例一提供了一种媒体控制指示方法，通过SDP中的属性行指示各媒体流的控制状态，即SDP中标识多个媒体交付通道是同步控制还是单独控制，还是混合控制(既存在同步控制，又存在单独控制)，同步控制是指对多个媒体流同时进行控制，单独控制是指对单个媒体流进行控制。属性可以通过多种方式表示，下面举几个例子进行说明。
以下所有实施例中，通过属性行关联的媒体交付通道对应的媒体流是需要相应的媒体控制通道进行控制的，未关联的媒体流是没有相应的媒体控制通道进行控制；
第一种方式是通过属性行描述媒体交付通道与媒体控制通道的关系，这两者之间的关系也就是SDP中相应描述信息的关系。
采用a＝:
其中attribute标识媒体控制属性(如，RTSP会话控制)，可以为字符集或其它，value标识媒体控制通道信息，可以为字符集、数字，其中字符集可以为RTSP URL或其它，数字可以为RTSP会话标识Session ID或其它。
该属性行可以放在第一个媒体行“m＝”行前作为会话级属性，描述控制所有媒体交付通道对应的媒体控制通道。
该属性行可以放在媒体行“m＝”行后作为媒体级属性，描述控制该媒体交付通道对应的媒体控制通道。
以下实施例中属性行是以“a＝control:”为例说明，不排除有其它描述方式。
会话级属性行示例1如下：
a＝control:rtsp://foo/twister
m＝audio 1306 RTP/AVP 0//描述音频媒体交付通道的媒体行
m＝video 1308 RTP/AVP 26//描述视频媒体交付通道的媒体行
m＝application 9 TCP iptv_rtsp//描述媒体控制通道的媒体行
a＝fmtp:rtsp h-uri＝rtsp://foo/twister
其中，“a＝control:”属性行作为会话级属性，表示音频和视频媒体交付通道对应的媒体流同步控制，媒体控制信息是属性行中RTSP URL为rtsp://foo/twister对应的媒体控制通道的描述信息，包括媒体控制通道的媒体行、属性行、RTSP会话属性行、RTSP媒体流标识属性行中的一个或多个，且不限于这些信息。“m＝”是媒体行，可以为rtsp://foo/twister，实际应用中的具体形式不限于此。
媒体级属性行示例2如下：
m＝audio 1306 RTP/AVP0//描述音频媒体交付通道的媒体行
a＝control:rtsp://foo/twister
m＝video 1308 RTP/AVP 26//描述视频媒体交付通道的媒体行
a＝control:rtsp://foo/twister
m＝text 1310 RTP/AVP wb//描述文本媒体交付通道的媒体行
m＝application 9 TCP iptv_rtsp//描述媒体控制通道的媒体行
a＝fmtp:rtsp h-uri＝rtsp://foo/twister
其中，“a＝control:”属性行作为媒体级属性，表示音频和视频媒体交付通道对应的媒体控制信息是属性行中RTSP URL为rtsp://foo/twister对应的媒体控制通道的描述信息，包括媒体控制通道的媒体行、属性行、RTSP会话属性行、RTSP媒体流标识属性行中的一个或多个，且不限于这些信息。文本媒体交付通道无相应的a＝control:”属性行，表示无相应的媒体控制通道进行控制；“m＝”是媒体行，可以为rtsp://foo/twister，实际应用中的具体形式不限于此。
媒体级属性行示例3如下：
m＝audio 1306 RTP/AVP0//描述音频媒体交付通道的媒体行
a＝control:rtsp://foo/twister/audio
m＝video 1308 RTP/AVP26//描述视频媒体交付通道的媒体行
a＝control:rtsp://foo/twister/video
m＝application 9 TCP iptv_rtsp//描述媒体控制通道的媒体行
a＝fmtp:rtsp h-uri＝rtsp://foo/twister/audio
m＝application 11 TCP iptv_rtsp//描述媒体控制通道的媒体行
a＝fmtp:rtsp h-uri＝rtsp://foo/twister/video
其中，“m＝audio”是音频媒体行，“a＝control:rtsp://foo/twister/audio”是对该音频媒体行对应的音频媒体流进行单独控制的属性行；“m＝video”是视频媒体行，“a＝control:rtsp://foo/twister/video”是对该视频媒体行对应的视频媒体流进行单独控制的属性行。表示音频和视频媒体交付通道各自对应的媒体控制信息是各自属性行中RTSP URL为rtsp://foo/twister/audio和rtsp://foo/twister/video对应的媒体控制通道的描述信息，包括媒体控制通道的媒体行、属性行、RTSP会话属性行、RTSP媒体流标识属性行中的一个或多个，且不限于这些信息。“a＝”行和“m＝”行的描述只是个示例，具体形式不限于此。
另外，在该种方式下，虽然UE可单独对每个媒体进行控制，而不强制同步控制下，但实际应用中也可以对多个媒体的同步控制，例如同时发出多个控制消息，每个控制消息控制一个媒体通道，以达到对所有媒体流的同步控制。
第二种方式中，通过组属性行描述媒体交付通道与媒体控制通道的关系，这两者之间的关系也就是SDP中相应描述信息的关系。
采用组属性行a＝group:semantics*(space identification-tag)
其中语义semantics用于标识媒体控制属性，可以为字符集或其它，identification-tag为媒体流标识，可以为数字、代号token或其它；表示媒体流标识为identification-tag取值的媒体流采用统一的媒体控制通道来控制。媒体流标识为“a＝mid:”流标识属性行中的流标识值或“a＝label:”流标签属性行中的流标签值。具体示例4如下：
a＝group:<控制属性(control)流标识(12)>
a＝control:rtsp://foo/twister
m＝audio 1306 RTP/AVP0
a＝mid:1
m＝video 1308 RTP/AVP 26
a＝mid:2
m＝text 1310 RTP/AVP wb
a＝control:rtsp://foo/twister/text
m＝application 9 TCP iptv_rtsp//描述媒体控制通道的媒体行
a＝fmtp:rtsp h-uri＝rtsp://foo/twister
m＝application 9 TCP iptv_rtsp//描述媒体控制通道的媒体行
a＝fmtp:rtsp h-uri＝rtsp://foo/twister/text
其中，“a＝group:<控制属性(control)流标识(12)>”为组属性行，指示媒体流标识为1对应的音频媒体流和媒体流标识为2对应的视频媒体流同步控制，“a＝control:rtsp://foo/twister”进一步指示两媒体交付通道对应的媒体控制信息是属性行中的RTSP URL为rtsp://foo/twister对应的媒体控制通道的描述信息，包括媒体控制通道的媒体行、属性行、RTSP会话属性行、RTSP媒体流标识属性行中的一个或多个，且不限于这些信息。而对“m＝text 1310RTP/AVP wb”媒体行对应的文本媒体流进行单独控制，其媒体控制信息为RTSP URL为rtsp://foo/twister/text对应的媒体控制通道的描述信息。“a＝”和“m＝”行的描述只是个示例，具体形式不限于此。
示例5：
a＝group:<控制属性(control)标签标识值(1)>
a＝control:rtsp://foo/twister
m＝audio 1306 RTP/AVP 0
a＝label:1
m＝video 1308 RTP/AVP 26
a＝label:1
m＝text 1310 RTP/AVP wb
a＝control:rtsp://foo/twister/text
m＝application 9 TCP iptv_rtsp//描述媒体控制通道的媒体行
a＝fmtp:rtsp h-uri＝rtsp://foo/twister
m＝application 9 TCP iptv_rtsp//描述媒体控制通道的媒体行
a＝fmtp:rtsp h-uri＝rtsp://foo/twister/text
其中，“a＝group:<控制属性(control)标签标识值(1)>”为组属性行，指示标签标识为1对应的音频媒体流和视频媒体流进行同步控制，“a＝control:rtsp://foo/twister”进一步指示两媒体交付通道对应的媒体控制信息是属性行中的RTSP URL为rtsp://foo/twister对应的媒体控制通道的描述信息，包括媒体控制通道的媒体行、属性行、RTSP会话属性行、RTSP媒体流标识属性行中的一个或多个，且不限于这些信息。text可采用单独控制，其媒体控制信息为RTSP URL为rtsp://foo/twister/text对应的媒体控制通道的描述信息。其中“a＝”行的描述只是个示例，具体形式不限于此。
示例6：
a＝group:rtspcontrol 1 2
m＝audio 1306RTP/AVP 0//描述媒体交付通道的媒体行
a＝mid:1
m＝video 1308RTP/AVP 26//描述媒体交付通道的媒体行
a＝mid:2
m＝text 1310RTP/AVP wb
a＝mid:3
m＝application 9TCP iptv_rtsp//描述媒体控制通道的媒体行
a＝mid:4
其中，“a＝group:rtspcontrol 1 2”为组属性行，指示媒体流标识为1对应的音频媒体流和媒体流标识为2对应的视频媒体流同步控制，且媒体控制通道信息是媒体控制通道对应的媒体描述信息，包括媒体行、属性行、RTSP会话属性行、RTSP媒体流标识属性行中的一个或多个，且不限于这些信息。媒体流标识为4对应的文本媒体流无媒体控制通道对其媒体流进行控制。“a＝”和“m＝”行的描述只是个示例，具体形式不限于此。
媒体流标识采用“a＝label:”流标签属性行的方式与示例6类似，只是用“a＝label:”属性行替换“a＝mid:”属性行，组属性行中的媒体流标识改为“a＝label:”属性行中的标签值。
或者采用组属性行a＝group:semantics*(space identification-tag)
其中语义semantics用于标识媒体控制属性，可以为字符集或其它，identification-tag用于标识媒体控制通道信息及媒体流标识信息，媒体控制通道信息可以为字符集、数字，其中字符集可以为RTSP URL或其它，数字可以为RTSP会话标识Session ID、RTSP媒体控制流标识或其它；RTSP媒体控制流标识和媒体流标识信息可以为数字、代号token或其它。RTSP媒体控制流标识和媒体流标识为“a＝mid:”流标识属性行中的流标识值或“a＝label:”流标签属性行中的流标签值。具体示例7如下：
a＝group:control rtsp://foo/twister 1 2
m＝audio 1306 RTP/AVP 0
a＝mid:1
m＝video 1308 RTP/AVP 26
a＝mid:2
m＝application 9 TCP iptv_rtsp//描述媒体控制通道的媒体行
a＝mid:3
a＝fmtp:rtsp h-uri＝rtsp://foo/twister
其中，“a＝group:control rtsp://foo/twister 1 2”为组属性行，指示媒体流标识为1对应的音频媒体流和媒体流标识为2对应的视频媒体流同步控制，其媒体控制信息是RTSP URL为rtsp://foo/twister对应的媒体控制通道的描述信息，包括媒体控制通道的媒体行、属性行、RTSP会话属性行、RTSP媒体流标识属性行中的一个或多个，且不限于这些信息。“a＝”和“m＝”行的描述只是个示例，具体形式不限于此。
示例8：
a＝group:rtspcontro1 3 1 2
m＝audio 1306 RTP/AVP 0//描述音频媒体交付通道的媒体行
a＝mid:1
m＝video 1308 RTP/AVP 26//描述视频媒体交付通道的媒体行
a＝mid:2
m＝application 9 TCP iptv_rtsp//描述媒体控制通道的媒体行
a＝mid:3
其中，“a＝group:rtspcontrol 3 1 2”为组属性行，指示媒体流标识为1对应的音频媒体流和媒体流标识为2对应的视频媒体流同步控制，且媒体控制信息是媒体流标识为3对应的媒体描述信息，包括媒体行、属性行、RTSP会话属性行、RTSP媒体流标识属性行中的一个或多个，且不限于这些信息。“a＝”和“m＝”行的描述只是个示例，具体形式不限于此。
媒体流标识采用“a＝label:”流标签属性行的方式与示例8类似，只是用“a＝label:”属性行替换“a＝mid:”属性行，组属性行中的媒体流标识改为“a＝label:”属性行中的标签值。
或者采用组属性行a＝group:semantics*(space identification-tag)
其中语义semantics用于标识媒体控制通道信息，可以为字符集、数字，其中字符集可以为RTSP URL或其它，数字可以为RTSP会话标识Session ID、RTSP媒体控制流标识或其它。
identification-tag为媒体流标识，可以为数字、代号token或其它；表示媒体流标识为identification-tag取值的媒体流采用统一的媒体控制通道来控制。媒体流标识为“a＝mid:”流标识属性行中的流标识值或“a＝label:”流标签属性行中的流标签值。具体示例9如下:
a＝group:rtsp://foo/twister 1 2
m＝audio 1306 RTP/AVP 0
a＝mid:1
m＝video 1308 RTP/AVP 26
a＝mid:2
m＝application 9TCP iptv_rtsp//描述媒体控制通道的媒体行
a＝mid:3
a＝fmtp:rtsp h-uri＝rtsp://foo/twister
其中，“a＝group:rtsp://foo/twister 1 2”为组属性行，指示媒体流标识为1对应的音频媒体流和媒体流标识为2对应的视频媒体流同步控制，其媒体控制信息是RTSP URL为rtsp://foo/twister对应的媒体控制通道的描述信息，包括媒体控制通道的媒体行、属性行、RTSP会话属性行、RTSP媒体流标识属性行中的一个或多个，且不限于这些信息。“a＝”和“m＝”行的描述只是个示例，具体形式不限于此。
媒体流标识采用“a＝label:”流标签属性行的方式与示例9类似，只是用“a＝label:”属性行替换“a＝mid:”属性行，组属性行中的媒体流标识改为“a＝label:”属性行中的标签值。
第三种方式中，通过属性行描述媒体交付通道媒体行对应的媒体流与相应媒体控制通道的关系，这两者之间的关系也就是SDP中相应描述信息的关系。
采用a＝:
其中attribute标识媒体控制属性，可以为字符集或其它，value标识媒体控制通道信息及媒体流标识信息，媒体控制通道信息可以为字符集、数字，其中字符集可以为RTSP URL或其它，数字可以为RTSP会话标识Session ID、RTSP媒体控制流标识或其它；RTSP媒体控制流标识和媒体流标识信息可以为数字、代号token或其它。RTSP媒体控制流标识和媒体流标识为“a＝mid:”流标识属性行中的流标识值或“a＝label:”流标签属性行中的流标签值。
示例10如下：
a＝rtspcontrol:rtsp://foo/twister 1 2
m＝audio 1306 RTP/AVP0
a＝mid:1
m＝video 1308 RTP/AVP 26
a＝mid:2
m＝application 9TCP iptv_rtsp//描述媒体控制通道的媒体行
a＝mid:3
a＝fmtp:rtsp h-uri＝rtsp://foo/twister
其中a＝rtspcontrol:rtsp://foo/twister 1 2表示媒体流标识为1和2的媒体(即音频和视频媒体)需同步控制，且其媒体控制信息是RTSP URL为rtsp://foo/twister对应的媒体控制通道的描述信息，包括媒体控制通道的媒体行、属性行、RTSP会话属性行、RTSP媒体流标识属性行中的一个或多个，且不限于这些信息。其中“a＝”行的描述只是个示例，具体形式不限于此。
示例11如下：
a＝rtspcontrol:rtsp://foo/twister 1
m＝audio 1306 RTP/AVP 0
a＝label:1
m＝video 1308 RTP/AVP 26
a＝label:1
m＝application 9 TCP iptv_rtsp//描述媒体控制通道的媒体行
a＝fmtp:rtsp h-uri＝rtsp://foo/twister
其中a＝rtspcontrol:rtsp://foo/twister 1表示媒体流标签标识为1的媒体(即音频和视频媒体)需同步控制，且其媒体控制信息是RTSP URL为rtsp://foo/twister对应的媒体控制通道的描述信息，包括媒体控制通道的媒体行、属性行、RTSP会话属性行、RTSP媒体流标识属性行中的一个或多个，且不限于这些信息。其中“a＝”行的描述只是个示例，具体形式不限于此。
第四种方式中，通过属性行描述媒体交付通道媒体行对应的媒体流与相应媒体控制通道的关系，这两者之间的关系也就是SDP中相应描述信息的关系。
采用a＝:
其中attribute标识媒体控制属性，可以为字符集或其它，value标识被控制的媒体流标识信息。媒体流标识信息可以为数字、代号token或其它。媒体流标识为“a＝mid:”流标识属性行的流标识值或“a＝label:”流标签属性行的流标签值。
示例12：
m＝audio 1306 RTP/AVP 0//描述音频交付通道的媒体行
a＝label:1
m＝video 1308RTP/AVP 26//描述视频交付通道的媒体行
a＝label:1
m＝application 9TCP iptv_rtsp//描述媒体控制通道的媒体行
a＝rtspcontrol:1
其中a＝rtspcontrol:1表示媒体流标签标识为1的媒体由相应的媒体控制通道控制，a＝label:1标签属性行标识音频和视频的标签都为1，两媒体采用同步控制，且其媒体控制信息是媒体控制通道的描述信息，包括媒体控制通道的媒体行、属性行、RTSP会话属性行、RTSP媒体流标识属性行中的一个或多个，且不限于这些信息。其中a＝”行的描述只是个示例，实际扩展中可能不是采用rtspcontrol这样的字符来标识，具体形式不限于此。
示例13：
m＝audio 1306 RTP/AVP 0//描述音频交付通道的媒体行
a＝mid:1
m＝video 1308 RTP/AVP 26//描述视频交付通道的媒体行
a＝mid:2
m＝application 9TCP iptv_rtsp//描述媒体控制通道的媒体行描述
a＝rtspcontrol:1 2
其中a＝rtspcontrol:1 2表示媒体流标识为1和2的媒体由相应的媒体控制通道控制，“a＝mid:”属性行标识音频和视频的标识分别为1和2，两媒体采用同步控制，且其媒体控制信息是媒体控制通道的描述信息，包括媒体控制通道的媒体行、属性行、RTSP会话属性行、RTSP媒体流标识属性行中的一个或多个，且不限于这些信息。其中a＝”行的描述只是个示例，实际扩展中可能不是采用rtspcontrol这样的字符来标识，具体形式不限于此。
如果有多个媒体控制通道(如，RTSP)的媒体行，和多个媒体交付通道(如，RTP)媒体行，则通过多个媒体控制通道(如，RTSP)的媒体行下的属性(如：“a＝rtspcontrol:”)行中不同的媒体流标识和媒体交付通道(如，RTP)媒体行下的“a＝label:”属性行中的流标签值或“a＝mid:”属性行中的流标识值匹配，来指示不同的媒体控制通道(如，RTSP)控制不同的媒体，如一个媒体控制通道(如，RTSP)用来控制音频媒体，另外一个媒体控制通道(如，RTSP)用来控制视频媒体和文本媒体等。
第五种方式中，通过媒体控制通道(如，RTSP)的媒体行下的属性行，描述媒体交付通道媒体行对应的媒体流与相应媒体控制通道的关系，这两者之间的关系也就是SDP中相应描述信息的关系。
采用a＝:
其中attribute标识媒体控制属性，可以为字符集或其它，value标识媒体控制通道信息及媒体流标识信息，其中，媒体控制通道信息可以为字符集、数字，其中字符集可以为RTSP URL或其它，数字可以为RTSP会话标识Session ID、RTSP媒体控制流标识或其它；RTSP媒体控制流标识和媒体流标识信息可以为数字、代号token或其它。RTSP媒体控制流标识和媒体流标识为“a＝mid:”流标识属性行中的流标识值或“a＝label:”流标签属性行中的流标签值。
示例1如下：
m＝audio 1306 RTP/AVP 0
a＝mid:1
m＝video 1308 RTP/AVP 26
a＝mid:2
m＝application 9TCP iptv_rtsp//描述媒体控制通道的媒体行描述
a＝rtspcontrol:rtsp://foo/twister 1 2
其中a＝rtspcontrol:rtsp://foo/twister 1 2表示媒体流标识为1和2的媒体由属性行“a＝rtspcontrol”对应的媒体控制通道控制，且其RTSP URL为rtsp://foo/twister，a＝mid:”属性行标识音频和视频的标识分别为1和2，两媒体采用同步控制，且其媒体控制信息是媒体控制通道的描述信息，包括媒体控制通道的媒体行、属性行、RTSP会话属性行、RTSP媒体流标识属性行中的一个或多个，且不限于这些信息。其中a＝”行的描述只是个示例，实际扩展中可能不是采用rtspcontrol这样的字符来标识，具体形式不限于此。
示例2如下：
m＝audio 1306 RTP/AVP 0
a＝label:1
m＝video 1308 RTP/AVP 26
a＝label:1
m＝application 9TCP iptv_rtsp//描述媒体控制通道的媒体行描述
a＝rtspcontrol:rtsp://foo/twister 1
其中a＝rtspcontrol:rtsp://foo/twister 1表示媒体流标签标识为1的媒体由属性行“a＝rtspcontrol”对应的媒体控制通道控制，且其RTSP URL为rtsp://foo/twister，a＝label:”属性行标识音频和视频的标签标识都为1，两媒体采用同步控制，且其媒体控制信息是媒体控制通道的描述信息，包括媒体控制通道的媒体行、属性行、RTSP会话属性行、RTSP媒体流标识属性行中的一个或多个，且不限于这些信息。其中“a＝”行的描述只是个示例，实际扩展中可能不是采用rtspcontrol这样的字符来标识，具体形式不限于此。
如果有多个媒体控制通道(如，RTSP)的媒体行，和多个媒体交付通道(如，RTP)媒体行，则通过多个媒体控制通道(如，RTSP)的媒体行下的属性(如：“a＝rtspcontrol:”)行中不同的媒体流标识和媒体交付通道(如，RTP)媒体行下的“a＝label:”属性行中的流标签值或“a＝mid:”属性行中的流标识值的属性值的匹配，来指示不同的媒体控制通道(如，RTSP)控制不同的媒体，如一个媒体控制通道(如，RTSP)用来控制音频媒体，另外一个媒体控制通道(如，RTSP)用来控制视频媒体和文本媒体等。
上述实施例中，以属性行携带RTSP URL为例，实际上，也可以携带SIPURI，TV URI或者任何一种可以标识媒体内容的标识。
本实施例通过属性行实现指示媒体控制通道(如，RTSP)所控制的媒体交付通道(如，RTP)，实现方式更为灵活，既可以用来指示只有一个媒体控制通道的情况下所控制的一个或多个媒体交付通道，也可以用来指示在有多个媒体控制通道的情况下，每个媒体控制通道所控制的一个或多个媒体通道。
本发明实施例二提供了一种获取媒体控制会话信息的系统，包括：用户终端，用于通过核心IMS向网络侧设备发送请求消息，所述请求消息中携带内容标识；网络侧设备，用于接收所述用户终端通过核心IMS发送的请求消息后，将所述内容标识对应的媒体控制会话信息，携带在媒体控制组属性行中，通过所述核心IMS发送给所述用户终端。内容描述元功能实体，用于给所述网络侧设备提供媒体控制会话信息。
本发明实施例提供了一种网络侧设备，包括：响应消息生成单元，用于生成响应消息，所述响应消息中的媒体控制组属性行携带不同媒体控制会话信息；响应消息发送单元，用于将所述响应消息通过所述核心IMS发送给所述用户终端；描述信息获取单元，用于获取内容标识对应的媒体控制会话信息。
本发明实施例还提供了一种获取媒体控制会话信息的系统，包括：用户终端，用于通过核心IMS向网络侧设备发送请求消息，所述请求消息中携带内容标识；网络侧设备，用于接收所述用户终端通过核心IMS发送的请求消息后，将所述内容标识对应的媒体控制会话信息，携带在媒体控制属性行a＝:中，通过所述核心IMS发送给所述用户终端，其中，attribute标识媒体控制属性，value标识媒体流标识；内容描述元功能实体，用于给所述网络侧设备提供媒体控制会话信息。
本发明实施例还提供了一种网络侧设备，包括：响应消息生成单元，用于生成响应消息，所述响应消息中的媒体控制属性行a＝:携带媒体控制会话信息，其中，attribute标识媒体控制属性，value标识媒体流标识；响应消息发送单元，用于将所述响应消息通过所述核心IMS发送给所述用户终端；描述信息获取单元，用于获取内容标识对应的媒体控制会话信息。
本发明实施例三中的获取媒体描述信息的方法，UE发起CoD业务请求，Offr中同时协商媒体控制通道和媒体交付通道，MF从内容描述元功能实体中获取内容不同媒体成分的控制描述后，向UE返回SDP Answer。具体过程如图3所示，包括以下步骤：
步骤s301，UE向Core IMS发起CoD业务请求，携带内容标识、SDP Offer等信息，其中业务请求可以为SIP INVITE请求或其它请求。
步骤s302，Core IMS将该CoD业务请求转发给SCF。
步骤s303，SCF通过所述内容标识选择适当的MF，并将SDP Offer发送给MF。
步骤s304，MF从内容描述元功能中获取所述内容标识对应的内容不同媒体的控制描述信息，如一个内容对应的多个媒体流是采用同步控制，还是单独控制，还是混合控制方式，其中内容描述元功能可作为MF的内部功能模块，或作为独立的功能实体存在。该步骤可选。
步骤s305至步骤s307，MF根据得到的内容不同媒体的控制描述信息，生成相应的SDP Answer，该SDP Answer中包括指示各媒体流的控制会话信息的属性行(如实施例一中描述)；并通过业务响应返回给UE，其中业务响应可以为200OK、183请求，或其它响应。
本发明实施例四中的获取媒体描述信息的方法，UE发起CoD业务请求，Offer中同时协商媒体控制通道和媒体交付通道，SCF从内容描述元功能实体中获取内容不同媒体成分的控制描述后，向UE返回SDP Answer。具体过程如图4所示，包括以下步骤：
步骤s401和步骤s402，UE通过Core IMS向SCF发起CoD业务请求，该请求中携带内容标识、SDP Offer等信息。其中业务请求可以为SIP INVITE请求，或其它请求。
步骤s403，SCF通过所述内容标识选择适当的MF，并将SDP Offer发送给该MF。
步骤s404，该MF向SCF返回SDP Answer，其中携带内容控制通道和内容交付通道的描述信息。
步骤s405，SCF从内容描述元功能中获取内容标识对应的内容不同媒体的控制描述信息，如，一个内容对应的多个媒体流是采用同步控制，还是单独控制，还是混合控制方式，其中内容描述元功能可作为SCF的内部功能模块，或作为独立的功能实体存在。该步骤可选。
步骤s406和步骤s407，SCF根据得到的内容不同媒体的控制描述信息，生成相应的SDP Answer，该SDP Answer中包括指示各媒体流的控制会话信息的属性行(如实施例一中描述)，并通过业务响应返回给UE，其中业务响应可以为200OK、183请求，或其它响应。
如图5所示，本发明实施例五提供了一种实现媒体控制的方法，包括以下步骤：
步骤S501、用户终端通过Core IMS发送携带媒体控制通道和媒体交付通道关系信息的请求消息给网络侧设备。
其中，媒体控制通道和媒体交付通道关系信息，可以是从SSF中获取的，采用实施例一中描述的方式携带在请求消息的SDP中，通过Core IMS发送给网络侧设备。
为方便说明，对关系信息在请求消息中的携带方式进行举例如下：
a＝group:rtspcontrol 1 2
m＝audio 1306 RTP/AVP 0//描述媒体交付通道的媒体行
a＝mid:1
m＝video 1308 RTP/AVP 26//描述媒体交付通道的媒体行
a＝mid:2
m＝text 1310 RTP/AVP wb
a＝mid:3
m＝application 9 TCP iptv_rtsp//描述媒体控制通道的媒体行
a＝mid:4
其中，“a＝group:rtspcontrol 1 2”为组属性行，指示媒体流标识为1对应的音频媒体流和媒体流标识为2对应的视频媒体流同步控制，且媒体控制通道信息是媒体控制通道对应的媒体描述信息，包括媒体行、属性行、RTSP会话属性行、RTSP媒体流标识属性行中的一个或多个，且不限于这些信息。媒体流标识为4对应的文本媒体流无媒体控制通道对其媒体流进行控制。“a＝”和“m＝”行的描述只是个示例，具体形式不限于此。
媒体流标识采用“a＝label:”流标签属性行的方式与示例6类似，只是用“a＝label:”属性行替换“a＝mid:”属性行，组属性行中的媒体流标识改为“a＝label:”属性行中的标签值。
需要进一步指出的是，上述的携带方式只是本发明的优选实施例，其他的携带方式参照本发明实施例一中的详细说明，携带方式的变化，并不影响本发明的保护范围。
步骤S502、网络侧设备向用户终端返回响应消息，该响应消息携带媒体描述信息。
其中，媒体描述信息具体为媒体交付通道信息和/或媒体控制通道信息，可以携带在响应消息的SDP中。
步骤S503、用户终端根据关系信息与媒体描述信息，进行媒体控制。
需要进一步指出的是，在本实施例中，网络侧设备，为SCF或MF或其他可以实现上述网络侧设备功能的网络实体，具体实体的差别不影响本发明的保护范围。
如图6所示，本发明实施例六提供了一种实现媒体控制的方法，包括以下步骤：
步骤S601、用户终端通过Core IMS向网络侧设备发送业务请求消息。
用户终端向Core IMS发起CoD业务请求，携带内容标识等信息，其中业务请求可以为SIP INVITE请求或其它请求。
步骤S602、网络侧设备向用户终端返回响应消息，该响应消息携带关系信息和媒体描述信息。
其中，关系信息具体指媒体控制通道和媒体交付通道关系信息，采用实施例一中描述的方式携带于响应消息的SDP中。
为方便说明，对关系信息在请求消息中的携带方式进行举例如下：
a＝group:rtspcontrol 3 1 2
m＝audio 1306 RTP/AVP0//描述音频媒体交付通道的媒体行
a＝mid:1
m＝video 1308 RTP/AVP 26//描述视频媒体交付通道的媒体行
a＝mid:2
m＝application 9 TCP iptv_rtsp//描述媒体控制通道的媒体行
a＝mid:3
其中，“a＝group:rtspcontrol 3 1 2”为组属性行，指示媒体流标识为1对应的音频媒体流和媒体流标识为2对应的视频媒体流同步控制，且媒体控制信息是媒体流标识为3对应的媒体描述信息，包括媒体行、属性行、RTSP会话属性行、RTSP媒体流标识属性行中的一个或多个，且不限于这些信息。“a＝”和“m＝”行的描述只是个示例，具体形式不限于此。
媒体流标识采用“a＝label:”流标签属性行的方式与示例8类似，只是用“a＝label:”属性行替换“a＝mid:”属性行，组属性行中的媒体流标识改为“a＝label:”属性行中的标签值。
需要进一步指出的是，上述的携带方式只是本发明的优选实施例，其他的携带方式参照本发明实施例一中的详细说明，携带方式的变化，并不影响本发明的保护范围。
步骤S603、用户终端根据关系信息与媒体描述信息，进行媒体控制。
需要进一步指出的是，在本实施例中，网络侧设备，为SCF或MF或其他可以实现上述网络侧设备功能的网络实体，具体实体的差别不影响本发明的保护范围。
如图7所示，本发明实施例七提供了一种实现媒体控制的系统，包括：
用户终端1，用于获取媒体控制通道和媒体交付通道关系信息，并根据关系信息与媒体描述信息，进行媒体控制。
进一步，用户终端1还可以用于通过核心IMS向网络侧设备2发送请求消息，请求消息的SDP中携带关系信息。
进一步，该系统中还可以包括网络侧设备2，用于发送响应消息，响应消息的SDP中携带媒体控制通道和媒体交付通道关系信息。
进一步，该系统中还可以包括业务选择功能SSF 3，用于提供媒体控制通道和媒体交付通道关系信息给用户终端1。业务选择功能是在IMS-based IPTV架构下用来提供业务选择信息，如电子节目单EPG信息等的实体。
在上述系统的实施例中，网络侧设备2可以SCF或MF或其他。
本发明实施例还提供了一种用户终端1，可以包括
获取单元11，用于获取媒体控制通道和媒体交付通道关系信息；
控制单元12，用于根据关系信息与媒体描述信息，进行媒体控制。
该用户终端，还可以进一步包括，发送单元13，用于发送请求消息，请求消息的SDP中携带媒体控制通道和媒体交付通道关系信息。
本发明实施例还提供了一种网络侧设备2，包括
接收单元21，用于接收请求消息；
发送单元22，用于发送响应消息，响应消息的SDP中携带媒体控制通道和媒体交付通道关系信息。
进一步的，SSF 3，还用于提供业务选择信息，如电子节目单EPG信息等。
需要进一步指出的是，在本实施例中，网络侧设备2可以SCF或MF或其他。
本发明的实施例中，通过SIP/SDP消息属性行描述媒体控制通道(如，RTSP)所控制的媒体交付通道(如，RTP)，可以实现CoD业务中对内容的所有媒体交付通道进行同步VCR操作或对单个媒体交付通道进行VCR操作。
现有技术中，CoD流程会话建立过程的主要特点是：由于在CoD业务过程中用户能对所看的内容进行VCR控制(如前进、后退、暂停等)，因此该业务需要建立媒体控制通道(用于VCR操作)和媒体交付通道(用于传送所看的内容)。根据媒体控制通道和媒体交付通道建立方式的不同，TISPAN中定义的CoD业务流程，主要可以分为两种：第一种方式是媒体控制通道和媒体交付通道在SIP会话建立过程中同时建立；第二种方式是在会话建立初始过程中先建立媒体控制通道，然后再通过会话更改建立媒体交付通道。
采用第一种方式的情况是终端UE已经从EPG(电子节目单)上获取所观看的内容的媒体信息，如该内容包括哪些媒体行，如音频、视频、文本等，因此可以协商和建立该媒体交付通道。采用第二种方式，即先通过SIP会话建立过程协商建立媒体控制通道(通常是RTSP通道)，然后在终端和媒体服务器之间建立媒体交互控制会话，然后通过媒体控制消息的交互获取媒体网络参数信息，然后在会话更改过程中发起建立内容交付通道。
事实上，第二种方式相对于第一种方式存在以下缺陷：如导致会话建立时间延长，大致过程如下：在会话初始建立(通常采用SIP消息)后，终端和网络(媒体服务器)之间还要再发起媒体控制消息(通常是RTSP DESCRIBE消息)建立媒体控制会话，然后在媒体控制会话消息中交换媒体的内容信息，最后再通过会话更改过程(又回到SIP消息)来完成媒体通道的建立。导致用户的服务体验降低，因此目前的规范中对采用第二种方式的应用条件有如下限制：只有当网络只提供给了用户媒体控制通道的网络参数信息(没有提供内容交付通道的网络参数信息)，初始会话建立内容交付通道才是可选的(即采用第二种方式)。然而，第二种方式需要终端UE和网络侧有更多的交互，对终端提出更多的需求，并导致会话建立延迟，使得用户的体验变差。
本发明实施例利用SIP会话消息中的OPTIONS方法，在无法或没有通过SSF获取内容的网络参数或内容媒体信息时，例如：用户没法访问SSF(业务发现功能实体，即相当于电子节目单功能，通常采用HTTP协议)、或能访问SSF，但SSF不提供所需要的信息；或用户没有访问SSF，直接发起业务请求，来动态的获取内容的网络参数和/或媒体信息，从而使得用户UE在没有从SSF获取网络参数的情况下也能采用规范中的第一种方式，或采用类似规范中的改进后的第二种方式。
UE在发起CoD会话请求前，采用SIP OPTIONS向网络发起请求，请求中要求获取网络实体(图中的媒体服务器MF)的媒体控制通道(如RTSP)的网络参数信息和/或所请求内容的网络参数和/或媒体交付通道描述信息，网络在SIP OPTIONS的请求响应消息中返回媒体控制通道的网络参数信息和/或所请求内容的网络参数和/或媒体交付通道描述信息，从而UE能在发起会话请求前获取了媒体控制通道(如RTSP)的网络参数及媒体交付通道信息，从而可以按上述第一种方式发起CoD业务请求，建立媒体控制通道和媒体交付通道。
另外，采用第二种方式时，在初始协商建立媒体控制通道(如RTSP)会话后，需要再重新利用控制消息获取媒体交付通道信息，然后再通过SIP建立会话，这种方式效率不高。
因此，在第二种方式的初始协商建立媒体控制通道过程中，用户终端UE可以在会话建立(SIP会话)过程中或建立后，用户终端UE发起采用SIPOPTIONS方法发起请求要求获取所请求的内容的网络参数和/或媒体交付通道信息(这一步即完成了终端和网络侧通过媒体控制通道来获取内容网络参数和/或媒体交付通道信息)，在获取所需的信息后，直接采用规范中所描述的会话更改流程完成媒体交付通道的建立，该方案中获取内容网络参数和/或媒体交付通道信息步骤可以与媒体控制通道的协商建立同步完成，而现在所描述方案是先后完成，因此本方案既有利于会话建立过程中UE和网络多个实体过多交互，也有利于缩短整个会话建立(包括媒体控制通道建立和媒体交付通道建立)的时间，提升对用户的服务体验。
本发明实施例八，终端在发起CoD会话请求前，请求媒体控制通道的网络参数信息和/或媒体交付通道的网络参数，如图7所示，包括以下步骤：
步骤s801，用户终端UE在发起CoD会话请求前，向Core IMS发起SIPOPTIONS请求。携带的消息参数如下：
OPTIONS sip:[e-mail] SIP/2.0
Via:SIP/2.0/UDP pc33.atlanta.com；branch＝z9hG4bKhjhs8ass877
Max-Forwards:70
To:
From:Alice；tag＝1928301774
Call-ID:a84b4c76e66710
CSeq:63104OPTIONS
Contact:
Accept:application/sdp
Content-Length:0
该步骤中的请求消息的参数描述只是个示例，具体实现时不限于此，还可以有其它描述形式。消息中携带所请求的点播内容的标识XXXMoiveID，在Accept头域中指示接收的消息体类型为SDP信息，实现时还可以为XML信息或其它类型的消息，只需将Accept头域中的“application/sdp”改为“application/xml”或“application/xxx”
步骤s802，Core IMS向提供点播业务的SCF(业务控制功能)转发该请求消息。
步骤s803，SCF根据所请求内容标识XXXMoiveID，选择一个合适的MF，该选择功能也可以在MF上完成，由MF完成选择其它合适的MF并转发请求，或其它独立的功能实体完成，具体方式不是本发明的关注点。
步骤s804，SCF向所选择的MF转发此请求消息。
步骤s805，MF根据所请求的内容标识XXXMoiveID，向内容描述元功能获取内容的媒体描述信息、媒体控制通道和/或媒体交付通道的网络参数信息。其中，内容描述元功能可能是MF内部的一个功能、也有可能是一个独立的功能实体。该步骤可选。
步骤s806，MF向SCF返回200OK响应消息，消息中携带参数如下：
SIP/2.0 200 OK
Via:SIP/2.0/UDP pc33.atlanta.com；branch＝z9hG4bKhjhs8ass877
；received＝192.0.2.4
To:；tag＝93810874
From:Alice；tag＝1928301774
Call-ID:a84b4c76e66710
CSeq:63104 OPTIONS
Contact:
Accept:application/sdp
Content-Type:application/sdp
Content-Length:164
v＝0
o＝-28908442562890842807IN IP4172.16.2.93——网络地址信息
s＝RTSP Session
i＝An Example of RTSP Session Usage
a＝control:rtsp://foo/twister——媒体控制会话信息
t＝00
m＝audio 0RTP/AVP 0——音频行媒体信息，如音频编码等
a＝control:rtsp://foo/twister/audio
m＝video 0 RTP/AVP 26——视频行媒体信息，如视频编码等
a＝control:rtsp://foo/twister/video
...——其它可能的媒体属性信息
该步骤中的响应消息的参数描述只是个示例，具体实现时不限于此，还可以有其它描述形式。由于请求消息中的Accept头域中指示接收的消息体类型为SDP信息，所以响应消息中的消息体类型也为SDP；具体实现时，请求消息中的Accept头域中指示接收的消息体类型还可以为XML信息或其它类型的消息，相应地，响应消息中的消息体类型也可以为XML或其它类型，即将Content-Type头域中的“application/sdp”改为“application/xml”或“application/xxx”，媒体控制会话信息的描述方式还可以为实施例一描述的其它方式。
若XML方式，具体消息体内容的示例为：

Audio/Video/Text——媒体组成
Codec——不同媒体的编解码
...——其它信息，如不同媒体成分是否能独立VCR操作，时长等其它内容描述信息

步骤s807，SCF向Core IMS返回200响应消息。
步骤s808，Core IMS向UE返回200响应消息。
UE动态获取所请求内容的媒体交付信息后，终端UE已经从EPG(电子节目单)上获取所观看的内容的媒体信息，如该内容包括哪些媒体行，如音频、视频、文本等，即可按目前规范中定义的第一种方式，会话初始建立过程中即同时建立媒体控制通道和媒体交付通道。
本发明实施例九中，终端在发起CoD会话请求前获取媒体控制通道的网络参数信息和/或媒体交付通道信息，如图8所示，包括以下步骤：
步骤s901，用户终端UE在发起CoD会话请求前，向Core IMS发起SIPOPTIONS请求。携带的消息参数如下：
OPTIONS sip:[e-mail] SIP/2.0
Via:SIP/2.0/UDP pc33.atlanta.com；branch＝z9hG4bKhjhs8ass877
Max-Forwards:70
To:
From:Alice；tag＝1928301774
Call-ID:a84b4c76e66710
CSeq:63104 OPTIONS
Contact:
Accept:application/xml
Content-Length:0
该步骤中的请求消息的参数描述只是个示例，具体实现时不限于此，还可以有其它描述形式。消息中携带所请求的点播内容的标识XXXMoiveID，在Accept头域中指示接收的消息体类型为XML信息，实现时还可以为SDP信息或其它类型的消息，只需将Accept头域中的“application/xml”改为“application/sdp”或“application/xxx”
步骤s902，Core IMS向提供点播业务的SCF(业务控制功能)转发该请求消息。
步骤s903，该SCF根据所请求内容标识XXXMoiveID，向内容描述元功能获取内容的媒体描述信息、媒体控制通道和/或媒体交付通道的网络参数信息。(注：内容描述元功能可能是SCF内部的一个功能、也有可能是一个独立的功能实体)，该步骤可选。
步骤s904，SCF向Core IMS返回200响应消息，消息中携带参数如下：
SIP/2.0200OK
Via:SIP/2.0/UDP pc33.atlanta.com；branch＝z9hG4bKhjhs8ass877
；received＝192.0.2.4
To:；tag＝93810874
From:Alice；tag＝1928301774
Call-ID:a84b4c76e66710
CSeq:63104 OPTIONS
Contact:
Accept:application/xml
Content-Type:application/xml
Content-Length:164

Audio/Video/Text——媒体组成
Codec——不同媒体的编解码
...——其它信息，如不同媒体成分是否能独立VCR操作，时长等其它内容描述信息

该步骤中的响应消息的参数描述只是个示例，具体实现时不限于此，还可以有其它描述形式。由于请求消息中的Accept头域中指示接收的消息体类型为XML信息，所以响应消息中的消息体类型也为XML；具体实现时，请求消息中的Accept头域中指示接收的消息体类型还可以为SDP信息或其它类型的消息，相应地，响应消息中的消息体类型也可以为SDP或其它类型，即将Content-Type头域中的“application/xml”改为“application/sdp”或“application/xxx”
若SDP方式，具体消息体内容的示例为：
v＝0
m＝audio 0RTP/AVP 0——音频行媒体信息，如音频编码等
a＝control:rtsp://foo/twister/audio
m＝video 0 RTP/AVP 26——视频行媒体信息，如视频编码等
a＝control:rtsp://foo/twister/video
...——其它可能的媒体属性信息
其中媒体控制会话信息的描述方式还可以为实施例一描述的其它方式。
步骤s905，Core IMS向UE返回200响应消息。
UE动态获取所请求内容的控制通道网络参数和/或媒体交付通道信息后，可按目前规范中定义的第一种方式，即会话初始建立过程中即同时建立媒体控制通道和内容通道。
本发明实施例十中，终端在发起CoD会话请求过程中请求媒体交付通道信息，如图10所示，包括以下步骤：
用户终端先按第二种方式发起初始会话建立，只协商媒体控制通道，在这个过程中，UE可以同时发起获取媒体交付通道相关信息，如图中s1001～s1007所述步骤，具体如下：
步骤s1001，UE向Core IMS发起SIP OPTIONS请求。携带的消息参数如下：
OPTIONS sip:[e-mail] SIP/2.0
Via:SIP/2.0/UDP pc33.atlanta.com；branch＝z9hG4bKhjhs8ass877——这部分参数将与前面所初始会话建立中的SIP消息参数相同，下面参数处理机制类似
Max-Forwards:70
To:
From:Alice；tag＝1928301774
Call-ID:a84b4c76e66710
CSeq:63104OPTIONS
Contact:
Accept:application/sdp
Content-Length:0
该步骤中的请求消息的参数描述只是个示例，具体实现时不限于此，还可以有其它描述形式。消息中携带所请求的点播内容的标识XXXMoiveID，在Accept头域中指示接收的消息体类型为SDP信息，实现时还可以为XML信息或其它类型的消息，只需将Accept头域中的“application/sdp”改为
“application/xml”或“application/xxx”
步骤s1002，Core IMS向提供点播业务的SCF(业务控制功能)转发该请求消息；
步骤s1003，SCF将该请求消息转发给在初始会话建立过程中所选择的MF；
步骤s1004，该MF根据所请求的内容标识XXXMoiveID，向内容描述元功能获取内容的媒体描述信息和/或媒体交付通道的网络参数信息(注：内容描述元功能可能是MF内部的一个功能、也有可能是一个独立的功能实体)，该步骤可选。
步骤s1005，MF向SCF返回200响应消息，消息中携带参数如下：
SIP/2.0 200 OK
Via:SIP/2.0/UDP pc33.atlanta.com；branch＝z9hG4bKhjhs8ass877
；received＝192.0.2.4
To:；tag＝93810874
From:Alice；tag＝1928301774
Call-ID:a84b4c76e66710
CSeq:63104OPTIONS
Contact:
Accept:application/sdp
Content-Type:application/sdp
Content-Length:164
v＝0
o＝-28908442562890842807 IN IP 4 172.16.2.93——网络地址信息
t＝00
m＝audio 0 RTP/AVP 0——音频行媒体信息，如音频编码等
a＝control:rtsp://foo/twister/audio
m＝video 0RTP/AVP 26——视频行媒体信息，如视频编码等
a＝control:rtsp://foo/twister/video
...——其它可能的媒体属性信息
该步骤中的响应消息的参数描述只是个示例，具体实现时不限于此，还可以有其它描述形式。由于请求消息中的Accept头域中指示接收的消息体类型为SDP信息，所以响应消息中的消息体类型也为SDP；具体实现时，请求消息中的Accept头域中指示接收的消息体类型还可以为XML信息或其它类型的消息，相应地，响应消息中的消息体类型也可以为XML或其它类型，即将Content-Type头域中的“application/sdp”改为“application/xml”或“application/xxx”，媒体控制会话信息的描述方式还可以为实施例一描述的其它方式。
具体xml消息内容与实施例五类似，这里不重述。
步骤s1006，SCF向Core IMS返回200响应消息；
步骤s1007，Core IMS向UE返回200响应消息；
UE获取所请求内容的媒体交付通道信息后，即可按当前规范中定义的会话修改流程协商建立媒体交付通道，而不需要等到媒体控制通道建立并通过媒体控制通道交互获取所请求内容的媒体交付通道信息后，再发起会话修改建立媒体交付通道，从而提高CoD的会话建立过程。
本实施例中，SIP OPTIONS消息发给MF进行处理，返回媒体交付通道的相关信息，也可以由SCF处理返回，类似实施例六中的处理方式。
本发明实施例十一中，UE发起CoD业务请求，SDP Offer中携带协商媒体控制通道，MF从内容描述元功能实体中获取内容交付通道的媒体描述信息后，向UE返回SDP Answer，SDP Answer中通过XML或链接等方式携带内容交付通道的媒体描述信息。具体过程如图11所示，包括以下步骤：
步骤s1101，UE向Core IMS发起CoD业务请求，携带内容标识、SDP Offer等信息，其中业务请求可以为SIP INVITE请求或其它请求。
步骤s1102，Core IMS将该CoD业务请求转发给SCF。
步骤s1103，SCF通过所述内容标识选择适当的MF，并将SDP Offer发送给MF。
步骤s1104，MF从内容描述元功能中获取所述内容标识对应的内容交付通道的媒体描述信息，其中内容描述元功能可作为MF的内部功能模块，或作为独立的功能实体存在。该步骤可选。
步骤s1105至步骤s1107，MF根据得到的内容交付通道的媒体描述信息，在返回的业务响应中生成相应的SDP Answer，该SDP Answer以XML或链接等方式携带内容交付通道的媒体描述信息；其中业务响应可以为200OK、183请求，或其它响应。具体xml描述与上述实施例的描述类似，这里不重述。
UE获取所请求内容的媒体交付通道信息后，即可按当前规范中定义的会话修改流程协商建立媒体交付通道，而不需要等到媒体控制通道建立并通过媒体控制通道交互获取所请求内容的媒体交付通道信息后，再发起会话修改建立媒体交付通道，从而提高CoD的会话建立过程。
本实施例中，请求消息如SIP INVITE消息发给MF进行处理，并由MF查询后在响应中通过XML或链接等方式返回内容交付通道的媒体描述信息；也可以由MF返回响应给SCF后，由SCF查询后在响应中通过XML或链接等方式返回内容交付通道的媒体描述信息，类似实施例六中的处理方式。
上述实施例八、九、十、十一只是本发明方案在几种场景下的典型示例，由于SIP协议应用的灵活性，上述使用方式是可以在多个场景下进行应用的。同时，可以通过扩展Accept头域中指示特定的能力信息，来获取内容特定的描述信息，如目前SIP协议中已定义Accept-Encoding和Accept-Language，来分别指示媒体的编码类型以及语言等信息。本发明中的技术方案采用的是SIPOPTIONS方法(该方法在SIP协议中的本意就是获取能力信息)，也有可能采取其它SIP Method，如Subscribe/Notify，Refer等方式来进行，SIP方法符合SIP协议规范，应用方法与本发明中的实施例类似。
还有一种可选的方法是用户在初始会话请求(如Invite消息)中携带的SDP Offer中为空(此时UE没有获取网络参数，无法发起有效的SDP Offer)，网络实体SCF或MF返回的响应消息中SDP Answer中也为空，同时在响应消息中携带针对所请求的内容标识的媒体控制通道和/或媒体交付通道信息、网络参数的描述，该描述可以采用在SIP消息体中xml语言进行描述的方式，也可以是一个描述所请求内容媒体控制通道和/或媒体交付通道信息和/或网络参数信息的地址链接或SDP描述。
针对上述本发明实施例八、九、十、十一所提出的一种获取IPTV业务媒体描述信息的方法，本发明实施例十二，提出一种网络侧设备，包括：
接收单元1，用于接收用户终端通过核心IMS发送的获取媒体描述信息的SIP请求，所述请求中携带内容标识；
生成单元2，用于生成响应消息，所述响应消息中的SDP携带所述内容标识对应的媒体描述信息；
发送单元3，用于将所述响应消息通过所述核心IMS发送给所述用户终端。
其中，进一步的，网络侧设备还包括：
获取单元4，用于从内容描述元功能获取媒体描述信息。
需要进一步指出的是，在本实施例中，网络侧设备具体为SCF或MF或其他可以实现上述网络侧设备功能的网络实体，具体实体的差别不影响本发明的保护范围。
本发明实施例十三中，在会话建立过程中，对控制方式的协商。终端可以在会话建立过程中，和网络侧(以下实施例以媒体服务器为例进行说明，具体实现不限于此)协商对不同媒体支持的控制模式(如，同步、单独控制模式)。终端可以选择自己希望或支持使用的模式，通知给媒体服务器；媒体服务器根据自己支持的模式，确定最终使用的控制模式。具体控制模式的表示，可以采用上面叙述的实施例一中的任意一种方法。该方式在IMS系统下的实施例如下所述：
s1301，UE通知Core IMS它对不同媒体所支持，或者选择的模式。其中，用户终端通知媒体服务器MF自己所支持的模式，可能为支持同步控制模式和/或单独控制模式。或者通知MF用户终端所偏好的模式，如用户终端倾向于采用单独控制模式，或者同步控制模式。具体实现时，该消息可以通过业务请求SIP Invite请求实现，或者通过Options请求实现。具体关于控制模式的具体携带方法，可以通过SIP头域，或者消息体的SDP属性行携带。
(1)通过SIP头域携带时，可以以终端能力，或者用户偏好的方式体现。如通过Contact头域，Request-Disposition头域，Accept-Contact头域、Reject-Contact头域携带。
a)Contact头域如：
Contact:；ControlMode＝″aggregate″
b)Request-Disposition头域如:
Request-Disposition:aggregate
其中可以定义ControlMode指示，其值可以是aggregate和non-aggregate.
通过Accept-Contact头域、Reject-Contact头域携带方法类似于Request-Disposition头域。
上述ControlMode只是一个示意，可以是其它的字符串。
(2)该控制模式也可以通过SIP消息体携带。当在SIP消息体中采用SDP时，具体可以通过属性行携带，即采用a＝:
其中attribute表示媒体控制模式属性，可以为字符集或其它，value表示控制模式，可以为字符集、数字、代号Token或其它。
该属性行可以放置在会话级或者媒体级。在媒体控制通道(如，RTSP)的媒体行下的控制模式属性行示例如下：
m＝video 3400 RTP/AVP 98
……
m＝audio 3456 RTP/AVP 97
……
m＝application 10000 TCP/RTSP iptv_rtsp
……
a＝ControlMode:aggregate——控制模式属性行
或者，也可以通过a＝fmtp属性表示，如；
a＝fmtp:rtsp ControlMode:aggregate
上述SDP表示终端支持同步和单独控制模式的协商，同时，希望本次协商采用同步控制模式。
本发明的实施例中，UE和MF通过协商过程，彼此或者对方是否支持同步控制、单独控制模式，以及彼此所希望采用的方式。为实现该思想，属性行可能存在除了上述方式外的其它构造方式，都在本专利的保护范围之内，如：
a＝aggregate-control:TRUE/False，或者
a＝fmtp:rtsp aggregate-control TRUE/False
S1302、S1303终端UE的请求通过Core IMS，SCF转发给媒体服务器。
S1304，MF向内容描述元功能获取内容的媒体描述信息(注：内容描述元功能可能是MF内部的一个功能、也有可能是一个独立的功能实体)、和/或媒体控制通道、媒体交付通道的网络参数信息，如根据所请求的内容标识XXXMoiveID来获取。该步骤可选。
S1305返回支持，或者确定的模式
媒体服务器MF返回响应，告诉终端MF所支持，或者所选择的控制模式。
同步骤S1301对应，具体实现时，该消息可以通过200OK或183等其它响应消息的SIP头域，或者消息体的SDP属性行携带。
通过SIP头域返回类似步骤S1301，不再赘述。
通过消息体，如SDP携带实例如下，除了携带MF选择的具体模式外，MF还可以进一步携带相关模式的参数，如控制的URL，以及SessionID:
m＝video 3400 RTP/AVP 98
……
m＝audio 3456 RTP/AVP 97
……
m＝application 10000TCP/RTSP iptv_rtsp
……
a＝ControlMode:aggregate//或者，a＝fmtp:ControlMode aggregate
a＝fmtp:iptv_rtsp h-uri＝rtsp://MCF.example.com/video-position
a＝fmtp:iptv_rtsp h-session:123456
a＝m-stream:1，2
在单独模式下，可以返回多个参数信息：
m＝video 3400 RTP/AVP 98
……
m＝audio 3456RTP/AVP 97
……
m＝application 10000TCP/RTSP iptv_rtsp
……
a＝ControlMode:non-aggregate//或者，a＝fmtp:ControlMode non-aggregate
a＝fmtp:iptv_rtsp h-uri＝rtsp://MCF.example.com/video-position/videol
a＝fmtp:rtsp h-session:123456
a＝m-stream:1
a＝fmtp:iptv_rtsp h-uri＝rtsp://MCF.example.com/audio-position/audiol
a＝fmtp:rtsp h-session:234567
a＝m-stream:2
上述媒体控制通道与媒体传送通道的对应的控制关系描述，即媒体控制属性行可以采用上述实施例一方式中的任何一种。
S1306、S1307MF的响应通过SCF、Core IMS，转发给用户终端UE。
本实施例中，请求消息如SIP INVITE或OPTIONS等消息发给MF进行处理，并由MF查询后在响应中返回支持的控制模式；也可以由MF返回响应给SCF后，由SCF查询后在响应中返回支持的控制模式，类似实施例三中的处理方式。
通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到本发明可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件，但很多情况下前者是更佳的实施方式。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本发明各个实施例所述的方法。
以上公开的仅为本发明的几个具体实施例，但是，本发明并非局限于此，任何本领域的技术人员能思之的变化都应落入本发明的保护范围。