专利名称：一种获取iptv业务媒体描述信息的方法及装置的制作方法
技术领域：
本发明涉及通信技术领域，尤其涉及一种获取IPTV业务媒体描述信息的 方法及装置。
背景技术：
IMS (IP Multimedia Subsystem, IP多媒体子系统)是最初在3GPP (3rd Generation Partnership Project,第三代移动通信标准化伙伴项目)R5阶段增 加的WCDMA ( Wideband Code Division Multiple Access,宽带码分多址接入) 网络中叠加在已有分组域上的一个子系统，采用分组域为其上层控制信令和 i某体交^f寸的岸义载通道，引入SIP ( Session Initiation Protocol,会话初始协i义) 作为业务控制协议，利用SIP筒单、易扩展、媒体组合方便的特点，通过将业 务控制与承载控制分离，提供丰富的多媒体业务。对IMS进行标准化的国际标 准组织主要有3GPP和TISPAN (Telecommunications and Internet converged Services and Protocol for Advanced Networking, 电信禾口互if关网融合业务及高级 网络协议)。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 (电子节目单)上获取所观 看的内容的媒体信息，如该内容包括哪些媒体行，如音频、视频、文本等， 因此可以协商和建立该j泉体交付通道。采用第二种方式，即先通过SIP会话建 立过程协商建立媒体控制通道(通常是RTSP通道)，然后在终端和媒体服务 器之间建立媒体交互控制会话，然后通过媒体控制消息的交互获取媒体网络 参数信息，然后在会话更改过程中发起建立内容交付通道。
事实上，第二种方式相对于第一种方式存在以下缺陷如导致会话建立 时间延长，大致过程如下在会话初始建立(通常采用SIP消息)后，终端和 网络(媒体服务器)之间还要再发起媒体控制消息(通常是RTSP DESCRIBE 消息)建立媒体控制会话，然后在媒体控制会话消息中交换媒体的内容信息， 最后再通过会话更改过程(又回到SIP消息)来完成^ 某体通道的建立。导致用 户的服务体验降低，因此目前的规范中对采用第二种方式的应用条件有如下 限制只有当网络只提供给了用户媒体控制通道的网络参数信息(没有提供 内容交付通道的网络参数信息)，初始会话建立内容交付通道才是可选的(即 采用第二种方式)。然而，第二种方式需要终端UE和网络侧有更多的交互， 对终端提出更多的需求，并导致会话建立延迟，使得用户的体验变差。
发明内容
本发明实施例提供一种CoD业务实现方法及设备，通过SIP消息获取J 某 体描述信息实现CoD业务的会话建立。
发明实施例提供了 一种获取IPTV业务媒体描述信息的方法，包括以下步
骤
网络侧设备接收用户终端通过核心IMS发送的获取媒体描述信息的SIP请求，所述请求中携带内容标识；
所述网络侧设备将所述内容标识对应的媒体描述信息携带在SIP响应消 息中，通过所述核心IMS发送给所述用户终端。 本发明实施例提供了一种网络侧设备，包括
接收单元，用于接收用户终端通过核心IMS发送的获取J 某体描述信息的 SIP请求，所述请求中携带内容标识；
生成单元，用于生成响应消息，所述响应消息中的SDP携带所述内容标 识对应的媒体描述信息；
发送单元，用于将所述响应消息通过所述核心IMS发送给所述用户终端。
本发明实施例提供了一种媒体控制协商方法，其特征在于，包括以下步
骤
网络侧设备接收用户终端发送的控制模式信息；
所述网络侧设备向所述用户终端返回控制模式信息，所述控制模式信息 通过SIP头域或消息体的SDP属性行携带。
本发明的实施例中，用户终端可以从SCF或MF等相关实体获取控制参数、 网络参数及内容媒体描述等信息，并根据这些参数进行相应操作。
图1是现有技术中对CoD业务的描述流程图； 图2是本发明实施例二中获取媒体描述信息的系统结构图； 图3是本发明实施例三中获取媒体描述信息的方法流程图； 图4是本发明实施例四中获取媒体描述信息的方法流程图； 图5是本发明实施例五中 一种实现媒体控制的方法流程图； 图6是本发明实施例六中一种实现媒体控制的方法流程图； 图7是本发明实施例七中 一种实现媒体控制的系统结构示意图； 图8是本发明实施例八中终端在发起CoD会话请求前一种获取媒体信息 的方法流程图9是本发明实施例九中终端在发起CoD会话请求前另 一种获取媒体信息的方法流程图IO是本发明实施例十中终端在发起CoD会话请求过程中获取媒体信息 的方法流程图11是本发明实施例十一中终端在发起CoD业务请求中另 一种获取媒体
信息的方法流程图12是本发明实施例十二中 一种网络侧设备的结构示意图13是本发明实施例十三中用户终端与网络实体通过协商确定最终使用
的控制模式的流程图。
具体实施例方式
由于现有技术中，RTSP (Real Time Streaming Protocol,实时流协议)的
会话协商和建立过程对上述操作方式有比较好的支持，如建立聚合模式，可 以Nl步控制所有J 某体交付通道，也寸以采用单独模式，可以对每一个媒体交 付通道单独控制。
在IMS的CoD ( Content on Demand,内容点播)业务中，RTSP会话的 相关参数是在SIP会话建立过程中进行协商的，不再有RTSP的会话建立过程 (如，RTSP的Setup消息)，而是在SIP会话建立完成后，直接采用RTSP消 息进行VCR操作控制。由于相关的RTSP参数都是在SIP/SDP (Session Description Protocol,会话描述协议)消息中进行携带并进行协商，因此，在 IMS based IPTV业务环境中，SIP/SDP消息无法指示CoD业务中对内容的单 个或多个媒体交付通道的VCR操作，即当用户通过RTSP消息进行VCR操 作时，无法对内容的某个或者某几个媒体通道进行VCR操作；即现有技术中 的SIP/SDP消息无法将这些信息传递给用户终端。
本发明实施例一提供了 一种媒体控制指示方法，通过SDP中的属性行指 示各媒体流的控制状态，即SDP中标识多个J 某体交付通道是同步控制还是单 独控制，还是混合控制(既存在同步控制，又存在单独控制)，同步控制是指 对多个J 某体流同时进行控制，单独控制是指对单个々某体流进行控制。属性寸
7以通过多种方式表示，下面举几个例子进行说明。
以下所有实施例中，通过属性行关联的媒体交付通道对应的媒体流是需 要相应的媒体控制通道进行控制的，未关联的媒体流是没有相应的媒体控制 通道进行控制；
第一种方式是通过属性行描述媒体交付通道与媒体控制通道的关系，这
两者之间的关系也就是SDP中相应描述信息的关系。 采用a=<attribute〉:<value〉
其中attribute标识i泉体控制属性(如，RTSP会话控制)，可以为字符集 或其它，value标识媒体控制通道信息，可以为字符集、数字，其中字符集可 以为RTSP URL或其它，数字可以为RTSP会话标识Session ID或其它。
该属性行可以放在第一个^;某体行"m="行前作为会话级属性，描述控制
所有媒体交付通道对应的媒体控制通道。
该属性行可以放在媒体行"m="行后作为媒体级属性，描述控制该媒体 交付通道对应的纟某体控制通道。
以下实施例中属性行是以"a=control:<RTSP URL>"为例说明，不排除有 其它描述方式。
会话级属性行示例1如下
a=control: rtsp:〃foo/twister
m=audio 1306 RTP/AVP 0 〃描述音频媒体交付通道的媒体行 m=video 1308 RTP/AVP 26〃描述视频媒体交付通道的媒体行 m=application 9 TCP iptv—rtsp 〃描述+某体控制通道的4某体4亍 a=fmtp:rtsp h-uri= rtsp:〃i'oo/twister
其中，"a二control:"属性行作为会话级属性，表示音频和视频媒体交付 通道对应的媒体流同步控制，媒体控制信息是属性行中RTSP URL为 rtsp://foo/twister对应的媒体控制通道的描述信息，包括媒体控制通道的媒体 行、属性行、RTSP会话属性行、RTSP媒体流标识属性行中的一个或多个， 且不限于这些信息。"m="是々某体行，〈RTSPURL〉可以为rtsp:〃foo/twister, 实际应用中的具体形式不限于此。
8媒体级属性行示例2如下
m-audio 1306 RTP/AVP 0 〃描述音频媒体交付通道的媒体行 a=control: rtsp :〃foo/twi ster
m-video 1308 RTP/AVP 26 〃描述视频媒体交付通道的媒体行 a=control: rtsp :〃foo/twi ster
m-text 1310 RTP/AVP wb 〃描述文本媒体交付通道的媒体行 m-application 9 TCP iptv—rtsp 〃描述媒体控制通道的媒体行 a=fmtp:rtsp h-uri- rtsp :〃foo/twi ster
其中，"a=control:'，属性行作为媒体级属性，表示音频和视频媒体交付 通道对应的媒体控制信息是属性行中RTSP URL为rtsp.7/foo/twister对应的媒 体控制通道的描述信息，包括媒体控制通道的媒体行、属性行、RTSP会话属 性行、RTSP媒体流标识属性行中的一个或多个，且不限于这些信息。文本媒 体交付通道无相应的a=control:"属性行，表示无相应的媒体控制通道进行控 制；"m="是媒体行，< RTSP URL〉可以为rtsp:〃foo/twister，实际应用中的 具体形式不限于此。
媒体级属性行示例3如下
m=audio 1306 RTP/AVP 0 //描述音频媒体交付通道的媒体行 a=control :rtsp :〃foo/twi ster/audi o
m=video 1308 RTP/AVP 26 〃描述视频媒体交付通道的媒体行 a=control:rtsp:〃foo/twister/ video
m=application 9 TCP iptv—rtsp 〃描述媒体控制通道的媒体行 a=fmtp:rtsp h-uri= rtsp:〃r(x)/twister/audi() m=appIication 11 TCP iptv一rtsp 〃描述媒体控制通道的媒体行 a=fmtp:rtsp h-uri= rtsp:〃foo/twister/video
其中，"m=audio，，是音频々某体行，"a=control:rtsp:〃foo/twister/audio，，是 对该音频媒体行对应的音频媒体流进行单独控制的属性行；"m二 video"是视频々某体4亍，"a=control:rtsp:〃foo/twister/ video"是乂十该浮见步贞々某体4亍乂寸应的秒u步贞 媒体流进行单独控制的属性行。表示音频和视频媒体交付通道各自对应的媒 体控制信4是各自属性行中RTSP URL为rtsp:〃foo/twister/audio和 rtsp:〃foo/twister/video对应的媒体控制通道的描述信息，包括媒体控制通道的 媒体行、属性行、RTSP会话属性行、RTSP媒体流标识属性行中的一个或多个， 且不限于这些信息。"a="行和"m="行的描述只是个示例，具体形式不限 于此。
另外，在该种方式下，虽然UE可单独对每个媒体进行控制，而不强制同 步控制下，但实际应用中也可以对多个^/某体的同步控制，例如同时发出多个 控制消息，每个控制消息控制一个媒体通道，以达到对所有媒体流的同步控 制。
第二种方式中，通过组属性行描述媒体交付通道与媒体控制通道的关系， 这两者之间的关系也就是SDP中相应描述信息的关系。
采用纟且属'性4亍a=group:semantics *(space idcntification-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/AVP 0
a=mid: 1
m=video 1308 RTP/AVP 26 a=mid:2
m二text 1310 RTP/AVP wb a=control:rtsp:〃foo/twister/text
10m=application 9 TCP iptv—rtsp 〃描述々某体控制通道的々某体4亍 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 2 ) >，， 为组属性行， 指示少某体流标识为1对应的音频々某体流和i某体流标识为2对应的^L频:樣体流 同步控制，"a=control:rtsp:〃foo/twister"进一步指示两々某体交付通道对应的媒 体控制信息是属性行中的RTSP URL为rtsp:Z/foo/twister对应的媒体控制通道 的描述信息，包括媒体控制通道的媒体行、属性行、RTSP会话属性行、RTSP 媒体流标识属性行中的一个或多个，且不限于这些信息。而对"m=text 1310 RTP/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 〃描述i某体控制通道的々某体4亍 a=fmtp:rtsp h-uri= rtsp:〃fo()/twister/text
其中，"a=group: <控制属性(control)标签标识值(1 ) >" 为组属性行，指示标签标识为l对应的音频媒体流和视频媒体流进行同步控制，
"a=control:rtsp:〃foo/twister"进一步指示两々某体交付通道对应的々某体控制信息
包括媒体控制通道的媒体行、属性行、RTSP会话属性行、RTSP媒体流标识属 性行中的一个或多个，且不限于这些信息。text可采用单独控制，其媒体控制 信息为RTSP URL为rtsp:〃foo/twister/text对应的媒体控制通道的描述信息。其 中"a="行的描述只是个示例，具体形式不限于此。
示例6:
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 〃描ii々某体4空制—通-道的々某体4亍 a=mid:4
其中，"a=group: rtspcontrol 1 2" 为组属性行，指示i某体流标识为1对 应的音频媒体流和媒体流标识为2对应的视频媒体流同步控制，且媒体控制 通道信息是媒体控制通道对应的媒体描述信息，包括媒体行、属性行、RTSP 会话属性行、RTSP媒体流标识属性行中的一个或多个，且不限于这些信息。 J 某体流标识为4对应的文本J 某体流无媒体控制通道对其^ 某体流进行控制。"a=" 和"m="行的描述只是个示例，具体形式不限于此。
媒体流标识采用"a=label:'，流标签属性行的方式与示例6类似，只是用 "a=label:，，属性行替换"a=mid:"属性行，组属性行中的i某体流标识改为 "a二label:"属性行中的标签值。或者采用组属性行a=gr()up:semantics *(space identification-tag)
其中语义semantics用于标识媒体控制属性，可以为字符集或其它， identification-tag用于标识i某体控制通道信息及々某体流标识信息，々某体控制通 道信息可以为字符集、数字，其中字符集可以为RTSP URL或其它，数字可 以为RTSP会话标识Session ID、 RTSP媒体控制流标识或其它；RTSP媒体控 制流标识和媒体流标识信息可以为数字、代号token或其它。RTSP媒体控制 流标识和々某体流标识为"a=mid:"流标识属性4亍中的流标识值或"a=label:，， 流标签属性行中的流标签值。具体示例7如下
a=group: control rtsp:〃foo/twistcr 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 〃描述々某体4空制通-道的々某体^亍 a=mid:3-
a=fmtp:rtsp h-uri= rtsp:〃foo/twister
其中，"a=group: control rtsp:〃foo/twister 1 2" 为组属性行，指示i某体 流标识为1对应的音频々某体流和i某体流标识为2对应的^J贞々某体流同步控制， 其媒体控制信息是RTSP URL为rtsp:〃foo/twister对应的媒体控制通道的描述 信息，包括媒体控制通道的媒体行、属性行、RTSP会话属性行、RTSP媒体 流标识属性行中的一个或多个，且不限于这些信息。"a="和"m="行的描 述只是个示例，具体形式不限于此。
示例8:
a=group: rtspcontrol 3 12
m=audio 1306 RTP/AVP 0 〃描述音频i某体交付通道的々某体行 a=mid: 1
m=video 1308 RTP/AVP 26 〃描述视频媒体交付通道的媒体行a=mid:2
m=application 9 TCP iptv—rtsp 〃描述々某体控制通-道的々某体4亍 a=mid:3
其中，"a=group: rtspcontrol 3 1 2" 为纟且厲/bM亍，才旨示A某体;危才示i只为1 对应的音频媒体流和々某体流标识为2对应的视频i某体流同步控制，且々某体控 制信息是媒体流标识为3对应的媒体描述信息，包括媒体行、属性行、RTSP 会话属性行、-.RTSP媒体流标识属性行中的一个或多个，且不限于这些信息。 "a="和"m="行的描述只是个示例，具体形式不限于此。
媒体流标识采用"a-label:"流标签属性行的方式与示例8类似，只是用 "a-label:"属性行替换"a=mid:，，属性行，组属性行中的々某体流标识改为 "a-label:"属性行中的标签值。
或者采用组属性行a=gr()up:semantics *(space identification-tag)
其中语义semantics用于标识媒体控制通道信息，可以为字符集、数字， 其中字符集可以为RTSP URL或其它，数字可以为RTSP会话标识Session ID、 RTSP媒体控制流标识或其它。
identification-tag为媒体流标识，可以为数字、代号token或其它；表示媒 体流标识为identification-tag取值的媒体流采用统一的媒体控制通道来控制。 i某体流标识为"a-mid:"流标识属性行中的流标识值或"a=labd:"流标签属 性行中的流标签值。具体示例9如下
a=group: rtsp:〃foo/twister 1 2
m=audio 1306 RTP/AVP 0
a=mid:l
m=video 1308 RTP/AVP 26 a=mid:2—
m=application 9 TCP iptv—rtsp 〃描述媒体控制通道的i某体行 a=mid:3
a=fmtp:rtsp h-uri- rtsp:〃foo/twister
14其中，"a二group: rtsp:〃foo/twister 1 2" 为组属性4亍，指示々某体流标识为 1对应的音频媒体流和媒体流标识为2对应的视频媒体流同步控制，其l樣体控 制信息是RTSP URL为rtsp:〃foo/twister对应的媒体控制通道的描述信息，包 括媒体控制通道的媒体行、属性行、RTSP会话属性行、RTSP媒体流标识属 性行中的一个或多个，且不限于这些信息。"a="和"m="行的描述只是个 示例，具体形式不限于此。
媒体流标识采用"a=label:'，流标签属性行的方式与示例9类似，只是用 "a=label:"属性-f亍替换"a=mid:，，属性行，组属性行中的i某体流标识改为 "a=label:，，属性行中的标签值。
第三种方式中，通过属性行描述媒体交付通道媒体行对应的媒体流与相 应媒体控制通道的关系，这两者之间的关系也就是SDP中相应描述信息的关 系。
采用a=<attribute>:<value>
其中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/AVP 0 a=mid: 1
m=video 1308 RTP/AVP 26 a=mid:2—
m=application 9 TCP iptv—rtsp 〃描述媒体控制通道的J 某体行 a=mid:3a二fmtp:rtsp h-uri= rtsp:〃foo/twister
其中a = rtspcontrol: rtsp:〃foo/twister 1 2表示i某体流标识为1和2的4某体 (即音频和视频媒体)需同步控制，且其媒体控制信息是RTSP URL为 rtsp://foo/twister对应的媒体控制通道的描述信息，包括媒体控制通道的媒体 行、属性行、RTSP会话属性行、RTSP媒体流标识属性行中的一个或多个， 且不限于这些信息。其中"a-"行的描述只是个示例，具体形式不限于此。
示例11如下
a = rtspcontrol: rtsp:〃foo/twister 1 m=audio 1306 RTP/AVP 0 a=label:l
m=video 1308 RTP/AVP 26 a=label:l
m=application 9 TCP iptv—rtsp 〃描述媒体控制通道的媒体行 a=fmtp:rtsp h-uri= rtsp:〃fo()/twister
其中a = rtspcontrol: rtsp:〃foo/twister 1表示i某体流标签标识为1的士某体 (即音频和视频媒体)需同步控制，且其媒体控制信息是RTSP URL为 rtsp:/7foo/twister对应的媒体控制通道的描述信息，包括媒体控制通道的媒体 行、属性行、RTSP会话属性行、RTSP J 某体流标识属性行中的一个或多个， 且不限于这些信息。其中"a="行的描述只是个示例，具体形式不限于此。
第四种方式中，通过属性行描述媒体交付通道媒体行对应的媒体流与相 应媒体控制通道的关系，这两者之间的关系也就是SDP中相应描述信息的关 系。
采用 a=<attribute>:<value>
其中attribute标识媒体控制属性，可以为字符集或其它，value标识被控 制的媒体流标识信息。媒体流标识信息可以为数字、代号token或其它。媒体 流标识为"a=mid:，，流才示i只属4生4亍的流标识^f直或"a=label:"流才示签属性-f亍的流标签值。
示例12:
m=audio 1306 RTP/AVP 0 〃描述音频交付通道的々某体行 a=label: 1
m=video 1308 RTP/AVP 26 〃描述视频交付通道的媒体行 a=label: 1
m=application 9 TCP iptv—rtsp 〃描述媒体控制通道的々某体4亍 a= rtspcontrol: 1
其中a = rtspcontrol: 1表示媒体流标签标识为1的媒体由相应的媒体控 制通道控制，a=label:l标签属性行标识音频和视频的标签都为1，两i某体采用 同步控制，直其媒体控制信息是媒体控制通道的描述信息，包括媒体控制通 道的媒体行、属性行、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 9 TCP iptv一rtsp 〃描述媒体控制通道的J 某体4亍描述 a= rtspcontrol: 1 2
其中a = rtspcontrol: 1 2表示媒体流标识为1和2的媒体由相应的i某体控 制通道控制，"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>
其中attribute标识媒体控制属性，可以为字符集或其它，value标识媒体 控制通道信息及媒体流标识信息，其中，媒体控制通道信息可以为字符集、 数字，其中字符集可以为RTSP URL或其它，数字可以为RTSP会话标识 Session ID、 RTSP媒体控制流标识或其它；RTSP媒体控制流标识和媒体流标 识信息可以为数字、代号token或其它。RTSP媒体控制流标识和媒体流标识 为"a=mid:，，流标i只属性行中的流标识值或"a=label:，，流标签属性行中的流 标签值。
示例1 4口下
m=audici 1306 RTP/AVP 0 a=mid:l
m=video 1308 RTP/AVP 26 a=mid:2
m=application 9 TCP iptv—rtsp 〃描述媒体控制通道的媒体行描述 a = rtspcontrol: rtsp:〃foo/twister 1 2
其中a = rtspcontrol: rtsp:〃foo/twister 1 2表示々某体流标识为1和2的i某体 由属性行"a=rtspcontrol"对应的媒体控制通道控制，且其RTSP URL为
18rtsp:〃foo/twister， a-mid:"属性4亍标识音频和移i频的标识分别为1和2,两々某 体采用同步控制，且其媒体控制信息是媒体控制通道的描述信息，包括媒体 控制通道的媒体行、属性行、RTSP会话属性行、RTSP媒体流标识属性行中 的一个或多个，且不限于这些信息。其中a=，，行的描述只是个示例，实际扩 展中可能不是采用rtspcontrol这样的字符来标识，具体形式不限于此。
示例2 ^口下
m=audio 1306 RTP/AVP 0 a二label:l
m=video 1308 RTP/AVP 26 a=label:l
m=application 9 TCP iptv—rtsp 〃描述+某体控制通道的i 某体行描述 a = rtspcontrol: rtsp:〃foo/twister 1
其中a = rtspcontrol: rtsp:〃foo/twister 1表示々某体流标签标识为1的i某体 由属性行"a=rtspcontrol"对应的+某体控制通道控制，且其RTSP URL为 rtsp:〃foo/twister, a=label:'，属性行标识音频和视频的标签标识都为1,两媒体 采用同步控制，且其媒体控制信息是媒体控制通道的描述信息，包括媒体控 制通道的媒体行、属性行、RTSP会话属性行、RTSP媒体流标识属性行中的 一个或多个，且不限于这些信息。其中"a二"行的描述只是个示例，实际扩 展中可能不是采用rtspcontrol这样的字符来标识，具体形式不限于此。
如果有多个媒体控制通道(如，RTSP)的媒体行，和多个媒体交付通道 (如，RTP)-媒体行，则通过多个媒体控制通道(如，RTSP)的媒体行下的 属性(如"a = rtspcontrol:")行中不同的4某体流标识和J 某体交付通道(如， RTP)媒体行下的"a=label:"属性行中的流标签值或"a=mid:"属性行中的流 标识值的属性值的匹配，来指示不同的媒体控制通道(如，RTSP)控制不同 的媒体，如一个媒体控制通道(如，RTSP)用来控制音频媒体，另外一个媒 体控制通道(如，RTSP)用来控制视频媒体和文本媒体等。
上述实施例中，以属性行携带RTSP URL为例，实际上，也可以携带SIPURI， TV UR1或者任何一种可以标识士某体内容的标识。
本实施例通过属性行实现指示媒体控制通道(如，RTSP)所控制的媒体 交付通道(如，RTP),实现方式更为灵活，既可以用来指示只有一个媒体控 制通道的情况下所控制的一个或多个媒体交付通道，也可以用来指示在有多 个媒体控制通道的情况下，每个媒体控制通道所控制的一个或多个媒体通道。
本发明实施例二提供了一种获取媒体控制会话信息的系统，包括用户 终端，用于通过核心IMS向网络侧设备发送请求消息，所述请求消息中携带 内容标识；网络侧设备，用于接收所述用户终端通过核心IMS发送的请求消 息后，将所述内容标识对应的媒体控制会话信息，携带在媒体控制组属性行 中，通过所述核心IMS发送给所述用户终端。内容描述元功能实体，用于给 所述网络侧设备提供媒体控制会话信息。
本发明实施例提供了一种网络侧设备，包括响应消息生成单元，用于
生成响应消息，所述响应消息中的媒体控制组属性行携带不同媒体控制会话
信息；响应消息发送单元，用于将所述响应消息通过所述核心IMS发送给所
述用户终端；描述信息获取单元，用于获取内容标识对应的^^某体控制会话信 台
本发明实施例还提供了一种获取媒体控制会话信息的系统，包括用户 终端，用于通过核心IMS向网络侧设备发送请求消息，所述请求消息中携带 内容标识；网络侧设备，用于接收所述用户终端通过核心IMS发送的请求消 息后，将所述内容标识对应的媒体控制会话信息，携带在媒体控制属性行 a=<attribute〉:<value>t,通过所述核心IMS发送给所述用户终端，其中， attribute标识i某体控制属性，value标识媒体流标识；内容描述元功能实体， 用于给所述网络侧设备提供媒体控制会话信息。
本发明实施例还提供了一种网络侧设备，包括响应消息生成单元，用 于生成响应消息，所述响应消息中的^某体控制属性行a二〈attribute〉:〈value〉携 带媒体控制会话信息，其中，attribute标识媒体控制属性，value标识媒体流 标识；响应消息发送单元，用于将所述响应消息通过所述核心IMS发送给所述用户终端；描述信息获取单元，用于获取内容标识对应的^泉体控制会话信 自
本发明实施例三中的获取媒体描述信息的方法，UE发起CoD业务请求， Offer中同时协商媒体控制通道和媒体交付通道，MF从内容描述元功能实体 中获取内容不同媒体成分的控制描述后，向UE返回SDP Answer。具体过程 如图3所示,包括以下步骤
步骤s301 ， UE向Core IMS发起CoD业务请求，携带内容标识、SDP Offer 等信息，其中业务请求可以为SIP INVITE请求或其它请求。
步骤s302， Core IMS将该Col)业务请求转发给SC1'，。
步骤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业务请求， 该请求中携带内容标识、SDPOffer等信息。其中业务请求可以为SIP INVITE 请求，或其它请求。
步骤s403, SCF通过所述内容标识选才奪适当的MF,并将SDPOffer发送 给该MF。步骤S404，该MF向SCF返回SDP Answer,其中携带内容控制通道和内 容交付通道的描述信息。
步骤s405, SCF从内容描述元功能中获取内容标识对应的内容不同媒体 的控制描述信息，如， 一个内容对应的多个媒体流是采用同步控制，还是单 独控制，还是混合控制方式，其中内容描述元功能可作为SCF的内部功能模 块，或作为独立的功能实体存在。该步骤可选。
步骤s4Q—6和步骤s407, SCF根据得到的内容不同媒体的控制描述信息， 生成相应的SDP Answer,该SDP Answer中包括指示各i某体流的控制会话信 息的属性行(如实施例一中描述)，并通过业务响应返回给UE，其中业务响 应可以为200OK、 183:清求，或其它响应。
如图5所示，本发明实施例五提供了一种实现媒体控制的方法，包括以 下步骤
步骤S501 、用户终端通过Core IMS发送携带媒体控制通道和媒体交付通 道关系信息的请求消息给网络侧设备。
其中，媒体控制通道和媒体交付通道关系信息，可以是从SSF中获取的， 采用实施例一中描述的方式携带在请求消息的SDP中，通过Core IMS发送给 网络侧设备。
为方便说明，对关系信息在请求消息中的携带方式进行举例如下 a=group: rtspcontrol 1 2
m=audio 1306 RTP/AVP 0 〃描述媒体交付通道的媒体行 a=mid:l
m=video 1308 RTP/AVP 26 〃描述媒体交付通道的媒体行 a=mid:2
m=text 1310 RTP/AVP wb a=mid:3
m=application 9 TCP iptv—rtsp 〃描述i某体控制通道的々某体行 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、网络侧设备向用户终端返回响应消息，该响应消息携带关系
信息和媒体描述信息。其中，关系信息具体指媒体控制通道和媒体交付通道关系信息，采用实 施例一中描述的方式携带于响应消息的SI)P中。
为方便说明，对关系信息在请求消息中的携带方式进行举例如下
a=group: rtspcontrol 3 1 2 a=mid:l
m=video 1308 RTP/AVP 26 〃描迷视频媒体交付通道的媒体行 a=mid:2
m=application 9 TCP iptv一rtsp 〃描述i某体控制通道的i某体行 a=mid:3
其中，"a=group: rtspcontrol 3 1 2" 为组属性行，指示i某体流标识为1 对应的音频媒体流和媒体流标识为2对应的视频媒体流同步控制，且媒体控 制信息是媒体流标识为3对应的媒体描述信息，包括媒体行、属性行、RTSP 会话属性行、RTSP媒体流标识属性行中的一个或多个，且不限于这些信息。 "a="和"m="行的描述只是个示例，具体形式不限于此。
媒体流标识采用"a=label:"流标签属性行的方式与示例8类似，只是用 "a-label:，，属性行替换"a=mid:"属性行，组属性行中的媒体流标识改为 "a—abel:"属性行中的标签值。
需要进一步指出的是，上述的携带方式只是本发明的优选实施例，其他 的携带方式参照本发明实施例一中的详细说明，携带方式的变化，并不影响 本发明的保护范围。
步骤S603、用户终端根据关系信息与媒体描述信息，进行媒体控制。
需要进一步指出的是，在本实施例中，网络侧设备，为SCF或MF或其 他可以实现上述网络侧设备功能的网络实体，具体实体的差别不影响本发明 的保护范围。
如图7所示，本发明实施例七提供了一种实现媒体控制的系统，包括 用户终端l，用于获取媒体控制通道和媒体交付通道关系信息，并根据关系信息与媒体描述信息，进行媒体控制；
进一步，用户终端1.还可以用于通过核心IMS向网络侧设备2发送请求 消息，请求消息的SDP中携带关系信息。
进一步，该系统中还可以包括网络侧设备2，用于发送响应消息，响应消 息的SDP中携带媒体控制通道和媒体交付通道关系信息。
进一步，—.该系统中还可以包括业务选择功能SSF 3，用于提供媒体控制通 道和媒体交付通道关系信息给用户终端1。业务选择功能是在IMS-based IPTV 架构下用来提供业务选择信息，如电子节目单1':PG信息等的实体。
在上述系统的实施例中，网络侧设备2可以SCl.'或Ml:或其他。
本发明实施例还提供了一种用户终端1，可以包括
获取单元11，用于获取媒体控制通道和媒体交付通道关系信息；
控制单元12,用于根据关系信息与媒体描述信息，进行媒体控制。
该用户终端，还可以进一步包括，发送单元13,用于发送请求消息，请 求消息的SDP中携带媒体控制通道和媒体交付通道关系信息。
本发明实施例还提供了一种网络侧设备2，包括
接收单元21,用于接收请求消息；
发送单元22，用于发送响应消息，响应消息的SDP中携带媒体控制通道
和媒体交付通道关系信息。
进一步的，SS.F 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 (业务 发现功能实体，即相当于电子节目单功能，通常采用IITTP协议)、或能访问 SSF，但SSF不提供所需要的信息；或用户没有访问SSF，直接发起业务请求， 来动态的获取内容的网络参数和/或媒体信息，从而使得用户UE在没有从SSF 获取网络参数的情况下也能采用规范中的第 一种方式，或采用类似规范中的 改进后的第二种方式。UE在发起CoD会话请求前，采用SIP OPTIONS向网络发起请求，请求中 要求获取网络实体(图中的媒体服务器MF )的媒体控制通道(如RTSP )的网 络参数信息和/或所请求内容的网络参数和/或媒体交付通道描述信息，网络在 SIP OPTIONS的请求响应消息中返回々某体控制通道的网络参数信息和/或所请 求内容的网络参数和/或媒体交付通道描述信息，从而UE能在发起会话请求前 获取了媒体控制通道(如RTSP)的网络参数及J/某体交付通道信息，从而可以 按上述第一种方式发起CoD业务请求，建立媒体控制通道和媒体交付通道。
另外，采用第二种方式时，在初始协商建立媒体控制通道(如RTSP)会 话后，需要再重新利用控制消息获取媒体交付通道信息，然后再通过SIP建立 会话，这种方式效率不高。
因此，在第二种方式的初始协商建立4某体控制通道过程中，用户终端UE 可以在会话建立(SIP会话)过程中或建立后，用户终端UE发起采用SIP OPTIONS方法发起请求要求获取所请求的内容的网络参数和/或媒体交付通 道信息(这一步即完成了终端和网络侧通过媒体控制通道来获取内容网络参 数和/或媒体交付通道信息)，在获取所需的信息后，直接采用规范中所描述的 会话更改流程完成媒体交付通道的建立，该方案中获取内容网络参数和/或媒 体交付通道信息步骤可以与媒体控制通道的协商建立同步完成，而现在所描 述方案是先后完成，因此本方案既有利于会话建立过程中UE和网络多个实体 过多交互，也有利于缩短整个会话建立(包括媒体控制通道建立和媒体交付 通道建立)的时间，提升对用户的服务体验。
本发明实施例八，终端在发起CoD会话请求前，请求々某体控制通道的网 络参数信息和/或媒体交付通道的网络参数，如图7所示，包括以下步骤
步骤s801,用户终端UE在发起CoD会话请求前，向Core IMS发起SIP OPTIONS请求。携带的消息参数如下
OPTIONS sip:XXXMoiveID@XXtele.com SIP/2.0
Via: SIP/2.()/UDPpc33.atlanta.com;branch=z9hG4bKhjhs8ass877 Max-Forwards: 70
To: <sip: XXXMoiveID@XXtele.com >
27From: Alice <sip:alice@atlanta.c()m>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 63104 OPTIONS
Contact: <sip:alice@pc33.atlanta.com>
Accept: application/sdp
Content-Length: 0
该步骤中的请求消息的参数描述只是个示例，具体实现时不限于此，还 可以有其它描述形式。消息中携带所请求的点播内容的标识XXXMoiveID,在 Accept头域中指示接收的消息体类型为SDP信息，实现时还可以为XML信息或 其它类型的消息，只需将Accept头域中的"application/sdp "改为 "application/xml"或 "application/xxx"
步骤s802， CoreIMS向提供点播业务的SCF (业务控制功能)转发该请求 消息。
步骤s803， SCF根据所请求内容标识XXXMoiveID，选4奪一个合适的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=l 92.0.2.4
To: <sip: XXXMoiveID@XXtele.com 〉;tag二93810874 From: Alice <sip:alice@atlanta.com>;tag=l928301774 Call-ID: a84b4c76e6671()CSeq: 63104 OPTIONS
Contact: <sip: XXXMoiveID@XXtele.com >
Accept: application/sdp
Content-Type: application/sdp
Content-Length: 164
v=0
o=- 2890844256 2890842807 IN IP4 172.16.2.93——网络地址信息 s二RTSP Session
i=An Example of RTSP Session Usage
a二control:rtsp:〃foo/twister--々某体控制会话信息
t=0 0
m=audio 0 RTP/AVP 0——音频行媒体信息，如音频编码等 a=control:rtsp:〃foo/twister/audio
m二video力RTP/AVP 26——视频行媒体信息，如视频编码等 a=control :rtsp :〃foo/twi ster/vi deo ...一一其它可能的媒体属性信息
该步骤中的响应消息的参数描述只是个示例，具体实现时不限于此，还 可以有其它描述形式。由于请求消息中的Accepl头域中指示接收的消息体类型 为SDP信息，所以响应消息中的消息体类型也为SDP;具体实现时，请求消息 中的Accept头域中指示接收的消息体类型还可以为XML信息或其它类型的消 息，相应地，响应消息中的消息体类型也可以为XML或其它类型，即将 Content-Type头域中的 "application/sdp ，， 改为 "application/xml ，， 或 "application/xxx" , i某体控制会话信息的描述方式还可以为实施例一描述的 其它方式。
若XML方式，具体消息体内容的示例为 <xml description^
Audio/Video/Text——媒体组成Codec——不同媒体的编解码
...一一其它信息，如不同媒体成分是否能独立VCR操作，时长等其 它内容描述信息
<xml description)
步骤s807， SCF向Core IMS返回20()响应消息。 步骤s808， Core IMS向UE返回200响应消息。
UE动态获取所请求内容的媒体交付信息后，终端UE已经从EPG (电子节 目单)上获取所观看的内容的媒体信息，如该内容包括哪些媒体行，如音频、 视频、文本等，即可按目前规范中定义的第一种方式，会话初始建立过程中 即同时建立媒体控制通道和媒体交付通道。
本发明实施例九中，终端在发起CoD会话请求前获取媒体控制通道的网 络参数信息和/或J;某体交付通道信息，如图8所示，包括以下步骤
步骤s901,用户终端UE在发起CoD会话请求前，向Core IMS发起SIP OPTIONS请求。携带的消息参数如下
OPTIONS sip:XXXMoiveID@XXtele.com SIP/2.0
Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKhjhs8ass877 Max-Forwards: 70
To: <sip: XXXMoiveID@XXtele.com >
From: Alice <sip:alice@atlanta.com>;tag=19283()1774
Call-ID: a84b4c76e6671()
CSeq: 63104 OPTIONS
Contact: <sip:alice@pc33.atlanta.com>
Accept: application/xml
Content-Length: 0
该步骤中的请求消息的参数描述只是个示例，具体实现时不限于此，还 可以有其它描述形式。消息中携带所^清求的点^播内容的标识XXXMoiveID,在 Accept头域中指示接收的消息体类型为XML信息，实现时还可以为SDP信息或 其它类型的消息，只需将Accept头域中的 "application/xml "改为步骤s902, CoreIMS向提供点播业务的SCF (业务控制功能)转发该请求 消息。
步骤s903,该SCF才艮据所请求内容标识XXXMoiveID,向内容描述元功能 获取内容的媒体描述信息、媒体控制通道和/或媒体交付通道的网络参数信息。 (注内容描述元功能可能是SCF内部的一个功能、也有可能是一个独立的功 能实体)，该步骤可选。
步骤s904, SCF向CorelMS返回200响应消息，消息中携带参数如下
SIP/2.0 200 OK
Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9h〔〗4bKhjhs8ass877 ;received= 192.0.2.4
To: <sip: XXXMoiveID@XXtele.com >;tag=93810874 From: Alice <sip:alice@atlanta.com>;tag=l928301774
Call-ID: a84b4c76e66710
CSeq: 63104 OPTIONS
Contact: <sip: XXXMoiveID@XXtde.com >
Accept: gpplication/xml
Content-Type: application/xml
Content-Length: 164
<xml description>
Audio/Video/Text——媒体组成
Codec——不同媒体的编解码
其它信息，如不同媒体成分是否能独立VCR操作，时长等其
它内容描述信息
<xml description>
该步骤中的响应消息的参数描述只是个示例，具体实现时不限于此，还 可以有其它描述形式。由于请求消息中的Accept头域中指示接收的消息体类型 为XML信息，所以响应消息中的消息体类型也为XML;具体实现时，请求消息中的Accept头域中指示接收的消息体类型还可以为SDP信息或其它类型的 消息，相应地，响应消息中的消息体类型也可以为SDP或其它类型，即将 Content-Type头域中的 "application/xml " 改为 "application/sdp ，' 或 "application/xxx，，
若SDP方式，具体消息体内容的示例为 v=0
m=audio 0 RTP/AVP 0——音频行4某体信息，如音频编码等-a=control:rtsp :〃foo/twister/audio
m=video—0 RTP/AVP 26——视频行媒体信息，如视频编码等
a=control:rtsp:〃foo/twister/video
... 一 一其它可能的媒体属性信息
其中媒体控制会话信息的描述方式还可以为实施例一描述的其它方式。 步骤s905, Core IMS向UE返回200响应消息。
UE动态获取所请求内容的控制通道网络参数和/或媒体交付通道信息后， 可按目前规范中定义的第一种方式，即会话初始建立过程中即同时建立媒体 控制通道和内容通道。
本发明实施例十中，终端在发起Col)会话请求过程中请求媒体交付通道 信息，如图10所示，包括以下步骤
用户终端先按第二种方式发起初始会话建立，只协商媒体控制通道，在 这个过程中，UE可以同时发起获取+某体交付通道相关信息，如图中sl001 sl007所述步骤，具体如下
步骤sl001， UE向Core IMS发起SIP OPTI()NS请求。携带的消息参数如下
OPTIONS sip:XXXMoiveID@XXtde.com SIP/2.0
Via:SIP/2.0/UDP pc33.atlanta.c()m;branch-z9hG4bKhjhs8ass877—— 这部分参数将与前面所初始会话建立中的SIP消息参数相同，下面参数处理机 制类似
Max-Forwards: 70
To: <sip: XXXMoiveID@XXtele.com >
32From: Alice <sip:alice@atlanta.com>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 63104 OPTIONS
Contact: <sip:alice@pc33.atlanta.com>
Accept: application/sdp
Content-Length: 0
该步骤中的请求消息的参数描述只是个示例，具体实现时不限于此，还 可以有其它描述形式。消息中携带所请求的点播内容的标识XXXMoiveID,在 Accept头域中指示接收的消息体类型为SDP信息，实现时还可以为XML信息或 其它类型的消息，只需将Accept头域中的"application/sdp "改为 "application/xml"或 "application/xxx"
步骤sl002, Core IMS向提供点播业务的SCF (业务控制功能)转发该请 求消息；
步骤sl003， SCF将该请求消息转发给在初始会话建立过程中所选择的
MF;
步骤sl004，该MF根据所请求的内容标识XXXMoiveID,向内容描述元 功能获取内容的媒体描述信息和/或媒体交付通道的网络参数信息(注内容 描述元功能可能是MF内部的一个功能、也有可能是一个独立的功能实体)， 该步骤可选。一
步骤sl005, MF向SCF返回200响应消息，消息中携带参数如下 SIP/2.0 200 OK
Via: SIP/2.0/UDP pc33.atlanta.com;branch二z9hG4bKhjhs8ass877 ;received二192.0.2.4
To: <sip: XXXMoiveID@XXtde.com >;tag=93810874 From: Alice <sip:alice@atlanta.com>;tag=l 928301774
Call-ID: a84b4c76e66710Accept: application/sdpContent-Type: application/sdpContent-Length: 164
o=- 28卯844256 2890842807 IN UM 172.16.2.93——网络地址信息t=0 0
m=audio 0 RTP/AVP 0——音频行媒体信息，如音频编码等a二con加l :rtsp :〃 foo/twister/audio
m=video 0 RTP/AVP 26——视频行媒体信息，如视频编码等a-control:rtsp:〃foo/twister/video...一一其它可能的^^某体属性信息该步骤中的响应消息的参数描述只是个示例，具体实现时不限于此，还可以有其它描述形式。由于请求消息中的Accepl头域中指示接收的消息体类型为SDP信息，所以响应消息中的消息体类型也为SDP;具体实现时，请求消息中的Accept头域中指示接收的消息体类型还可以为XML信息或其它类型的消息，相应地，响应消息中的消息体类型也可以为XML或其它类型，即将Content-Type头域中的 "application/sdp '， 改为 "application/xml " 或"application/xxx"， 媒体控制会话信息的描述方式还可以为实施例一描述的其它方式。- .具体xml消息内容与实施例五类似，这里不重述。步骤sl006, SCF向Core IMS返回200响应消息；步骤sl007, Core IMS向UE返回2()0响应消息；
UE获取所请求内容的媒体交付通道信息后，即可按当前规范中定义的会话修改流程协商建立媒体交付通道，而不需要等到媒体控制通道建立并通过媒体控制通道交互获取所请求内容的媒体交付通道信息后，再发起会话修改建立媒体交付通道，从而提高CoD的会话建立过程。
本实施例中，SIP OPTIONS消息发给MF进行处理，返回媒体交付通道的相关信息，也可以由SCF处理返回，类似实施例六中的处理方式。
本发明实施例十一 中，UE发起CoD业务请求，SDP Offer中携带协商媒体控制通道，——MF从内容描述元功能实体中获取内容交付通道的々某体描述信息后，向UE返回SDP Answer, SDP Answer中通过XML或链接等方式携带内容交付通道的媒体描述信息。具体过程如图ll所示，包括以下步骤
步骤si 101, UE向Core IMS发起CoD业务请求，携带内容标识、SDP Offer
等信息，其中业务请求可以为siPiNvrre请求或其它请求。
步骤si 102， Core IMS将该CoD业务请求转发给SCF。步骤si 103, SCF通过所述内容标识选择适当的MF，并将SDP Offer发送给MF。
步骤sll04， MF从内容描述元功能中获取所述内容标识对应的内容交付通道的媒体描述信息，其中内容描述元功能可作为MF的内部功能模块，或作为独立的功能实体存在。该步骤可选。
步骤s1105至步骤sll07， MF根据得到的内容交付通道的i某体描述信息，在返回的业务响应中生成相应的SDP Answer,该SDP Answer以XML或链接等方式携带内容交付通道的媒体描述信息；其中业务响应可以为200 OK、 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中为空(此时IJE没有获取网络参数，无法发起有效的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属性行携带。
(l)通过SIP头域携带时，可以以终端能力，或者用户偏好的方式体现。如通过Contact 头域,Request-Disposition 头域，Accept-Contact 头域、Reject-Contact头域携带。
a) Contact头域如
Contact: <sip:user@host.example.com>;ControlMode="aggregate"
b) Request-Disposition头i或^口 Request-Disposition: aggregate
其中可以定义ControlMode指示，其值可以是aggregate和non-aggregate.
通过Accept-Contact头域、Reject-Contact头域携带方法类似于Request-Disposition头域。
上述ControiMode只是一个示意，可以是其它的字符串。(2 )该控制模式也可以通过SIP消息体携带。当在SIP消息体中采用SDP时，具体可以通过属性^亍携带，即采用a=<attribute>:<value>
其中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--4空制才莫式属小生4亍
或者，也可以通过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, SC:F转发给媒体服务器。S1304， MF向内容描述元功能获取内容的媒体描述信息(注内容描述元功能可能是MF内部的一个功能、也有可能是一个独立的功能实体)、和/或媒体控制通道、媒体交付通道的网络参数信息，如根据所请求的内容标识XXXMoiveID来获取。该步骤可选。
S1305返回支持，或者确定的模式
媒体服务器MF返回响应，告诉终端MF所支持，或者所选"l奪的控制模式。同步骤S1301对应，具体实现时，该消息可以通过200OK或183等其它响应消息的SIP头域，或者消息体的SDP属性行携带。通过SIP头域返回类似步骤S13(H，不再赘述。
通过消息体，如SI)P携带实例如下，除了携带MF选择的具体模式外，MF还可以进一步携带相关模式的参数，如控制的URL，以及SessionID:m=video 3400 RTP/AVP 98
m=audio 3456 RTP/AVP 97
m=application 10000 TCP/RTSP iptv一rtsp
a=ControlMode:aggregate 〃或者，a=fmtp:ControlMode aggregatea=fmtp:iptv—rtsp h-uri=rtsp:〃 MCF.example.com /video-positiona=fmtp:iptv—rtsp h-session: 123456a=m-stream:l, 2
在单独模式下，可以返回多个参数信息m=video 3400 RTP/AVP 98
m=audio 3456 RTP/AVP 97
m，plication 10000 TCP/RTSP iptv—rtsp
a=ControlMode:non-aggregate 〃或者,a二fmtp:C()ntr()lMode non-aggregatea=fmtp:iptv—rtsp h-uri=rtsp:〃 MCF.example.com /video-position/video 1a=fmtp:rtsp h-session: 123456a= m-stream:l
a=fmtp:iptv_rtsp h-uri=rtsp:〃 MCF.example.com /audio-position/audiola=fmtp:&sp h-session: 234567a= m-stream:2
上述媒体控制通道与媒体传送通道的对应的控制关系描述，即媒体控制
39属性行可以采用上述实施例一方式中的任何一种。
S1306 、 S1307 MF的响应通过SCF 、 Core IMS ，转发给用户终端UE。 本实施例中，请求消息如SIP INVITE或OPTIONS等消息发给MF进行 处理，并由MF查询后在响应中返回支4寺的控制才莫式；也可以由MF返回响应 给SCF后，由SCF查询后在响应中返回支持的控制模式，类似实施例三中的 处理方式。
通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到本 发明可借助l欠件加必需的通用硬件平台的方式来实现，当然也可以通过硬 件，但很多情况下前者是更佳的实施方式。基于这样的理解，本发明的技 术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体 现出来，该计算机软件产品存储在一个存储介质中，包括若千指令用以使 得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行 本发明各个实施例所述的方法。
以上公开的仅为本发明的几个具体实施例，但是，本发明并非局限于此，任 何本领域的技术人员能思之的变化都应落入本发明的保护范围。
权利要求
1、一种获取IPTV业务媒体描述信息的方法，其特征在于，包括以下步骤网络侧设备接收用户终端通过核心IMS发送的获取媒体描述信息的SIP请求，所述请求中携带内容标识；所述网络侧设备将所述内容标识对应的媒体描述信息携带在SIP响应消息中，通过所述核心IMS发送给所述用户终端。
2、 如权利要求1所述获取IPTV业务媒体描述信息的方法，其特征在于， 所述i某体描述信息包括内容控制通道和/或内容交付通道参数。
3、 如权利要求1所述获取IPTV业务媒体描述信息的方法，其特征在于， 所述网络侧设备将所述内容标识对应的媒体描述信息携带在响应消息中之前 还包括所述网络侧设备从内容描述元功能获取媒体描述信息。
4、 如权利要求1至3中任一项所述获取IPTV业务媒体描述信息的方法， 其特征在于，所述网络侧设备为SC1-'或MF。
5、 如权利要求1所述获取IPTV业务媒体描述信息的方法，其特征在于， 所属获取媒体描述信息的SIP请求为OPTIONS或INVITE。
6、 如权利要求1所述获取IPTV业务媒体描述信息的方法，其特征在于， 所述纟某体描述信息通过SDP或XML方式携带在响应消息中。
7、 一种网络侧设备，其特征在于，包括接收单元，用于接收用户终端通过核心IMS发送的获取媒体描述信息的 SIP请求，所述请求中携带内容标识；生成单元，用于生成响应消息，所述响应消息中的SDP携带所述内容标 识对应的+某体描述信息；发送单元，用于将所述响应消息通过所述核心IMS发送给所述用户终端。
8、 如权利要求7所述网络侧设备，其特征在于，还包括 获取单元，用于从内容描述元功能获取媒体描述信息。
9、 如权利要求7所述网络侧设备，其特征在于，具体为 为业务控制功能SCF或媒体功能MF。
10、 一种媒体控制协商方法，其特征在于，包括以下步骤 网络侧设备接收用户终端发送的控制模式信息；所述网络侧设备向所述用户终端返回控制模式信息，所述控制模式信息 通过SIP头域或消息体的SDP属性行携带。
11、 如权利要求10所述控制模式协商方法，其特征在于，所述通过SIP 头域具体包括通过Contact头域携带或通过Request-Disposition头域携带。
12、 如权利要求IO所述控制模式协商方法，其特征在于，所述消息体的 SDP属性行携带包括通过属性行a^〈attribute〉:〈value〉携带，所述attribute 标识媒体控制模式属性，value标识控制模式信息。
全文摘要
本发明公开了一种获取IPTV业务媒体描述信息的方法，包括以下步骤网络侧设备接收用户终端通过核心IMS发送的获取媒体描述信息的SIP请求，所述请求中携带内容标识；所述网络侧设备将所述内容标识对应的媒体描述信息携带在SIP响应消息中，通过所述核心IMS发送给所述用户终端。本发明通过SIP消息获取媒体描述信息实现COD业务的会话建立。
文档编号H04L29/06GK101459664SQ20081009160
公开日2009年6月17日 申请日期2008年4月3日 优先权日2007年10月22日
发明者军 严, 彭招君, 李金成, 丰 王 申请人:华为技术有限公司