专利名称：一种实现媒体控制的方法、系统及设备的制作方法
技术领域：
本发明涉及通信技术领域，尤其涉及一种实现媒体控制的方法、系统及 设备。
背景技术：
IMS (IP Multimedia Subsystem, IP多媒体子系统)是最初在3GPP (3rd Generation Partnership Project,第三代移动通信标准化伙伴项目)R5阶—度增 加的WCDMA ( Wideband Code Division Multiple Access，宽带码分多址接入) 网络中叠加在已有分组域上的一个子系统，采用分组域为其上层控制信令和 々某体交付的7 义载通-道，引入SIP ( Session Initiation Protocol,会话初始协i义) 作为业务控制协议，利用SIP简单、易扩展、媒体组合方便的特点，通过将业 务控制与承载控制分离，提供丰富的多媒体业务。对IMS进行标准化的国际标 准组织主要有3GPP禾口TISPAN (Telecommunications and Internet converged Services 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已有的会话控制机制完 成，在建立会话过程中，需要为媒体流的传送预留承载资源。
在目前TISPAN定义的IMS based IPTV系统中对CoD (或称为VOD )业 务的描述如图l所示，包括以下步骤
5步骤sl01, UE (UserEquipment,用户终端)向Core IMS发送会话初始请 求消息Session Initiation Request,初始化CoD业务会"i舌。
步骤sl02, Core IMS将该初始请求消息Session Initiation RequesW各由到 SCF ( Service Control Function,业务控制功能)。
步骤sl03, SCF执行业务授权，如果用户终端被允许接入该内容，贝'j SCF 向被选的MF( Media Function,々某体功能)转发该初始请求消息Session Initiation Request 。
步骤sl04， UE和MF之间建立内容控制通道，并可以选择建立内容交付通 道。特别是协议实现时，支持该步骤的消息可以嵌入支持会话初始的消息中。 当网络只有内容控制通道建立信息的情况下，会话初始时建立内容交付通道， 在这种情况下内容交付通道在会话修改期间建立。
步骤sl05, MF向SCF发送会话初始响应消息Session Initiation Response, 确认与UE建立会话已建立。
步骤s106 ， SCF向Core IMS转发该初始响应消息Session Initiation Response 。
步骤sl07, Core IMS中的P-CSCF ( Proxy Call Session Control Functions, 代理呼叫会话控制功能)与RACS ( Resource and Admission Control Subsystem,
资源控制与接入子系统)交互消息，传递预先保留的所有资源。
步骤sl08， P-CSCF向UE转发该初始响应消息Session Initiation Response。 内容通常包括多个媒体交付通道，视频、音频、文本(用于字幕)，CoD 业务中可以在内容观看过程中进行VCR ( Video Cassette Recorder ，播放控制 操作)，如暂停、快进、后退等，这个VCR操作只能针对整个内容的，即当 快进时，所有媒体交付通道(视频、音频、文本等)同时快进，而在实际应 用中，可能同时存在只针对某些媒体交付通道进行VCR控制，而其它媒体通 道正常播放的情况，也可能针对某些媒体交付通道通过一个^ 某体控制通道进 行VCR控制，而另外一些媒体交付通道通过另一个媒体控制通道进行VCR 控制。如对一部电影，可同时对视频、音频进行VCR控制、字幕需通过另一 个媒体控制通道快进或快退；对一个新闻短片，视频可能在快进，但音频作为解说词可能在正常播放。内容控制通道又称为媒体控制通道，内容交付通 道又称为媒体交付通道。现有技术不能针对所有内容交付通道中的某些进行 同步VCR操作，不能满足业务的灵活控制需求。本发明就是为了解决该问题。
发明内容
本发明实施例提供一种实现媒体控制方法、系统及设备，通过SDP中描 述媒体控制通道和媒体交付通道关系信息，并结合媒体描述信息实现了媒体 控制。
本发明实施例提供了 一种实现媒体控制的方法，包括以下步骤
获取媒体控制通道和媒体交付通道关系信息；
根据所述关系信息与媒体描述信息，进行媒体控制。
本发明实施例4是供了 一种实现4某体控制的系统，包括用户终端
所述用户终端，用于获取媒体控制通道和媒体交付通道关系信息；
所述用户终端，还用于根据所述关系信息与媒体描述信息，进行媒体控制。
本发明实施例提供了一种用户终端，包括
获取单元，用于获取媒体控制通道和媒体交付通道关系信息；
控制单元，用于根据所述关系信息与媒体描述信息，进行媒体控制。
本发明实施例提供了 一种网络侧设备，包括
接收单元，用于接收请求消息；
发送单元，发送响应消息，所述响应消息中携带媒体控制通道和媒体交 付通道关系信息。
本发明的实施例中，用户终端可以从SCF或MF等相关实体获取控制参数、 网络参数及内容媒体描述等信息，并根据这些参数进行相应搡作。
图1是现有技术中对CoD业务的描述流程图2是本发明实施例二中获取媒体描述信息的系统结构图；图3是本发明实施例三中获取媒体描述信息的方法流程图； 图4是本发明实施例四中获取媒体描述信息的方法流程图； 图5是冬发明实施例五中一种实现媒体控制的方法流程图； 图6是本发明实施例六中 一种实现媒体控制的方法流程图； 图7是本发明实施例七中 一种实现媒体控制的系统结构示意图； 图8是本发明实施例八中终端在发起Col)会话请求前一种获取J泉体信息 的方法流程图9是本发明实施例九中终端在发起CoD会话请求前另 一种获取媒体信 息的方法流程图IO是本发明实施例十中终端在发起CoD会话请求过程中获取媒体信息 的方法流程图11是本发明实施例十 一 中终端在发起CoD业务请求中另 一种获取媒体 信息的方法流程图12是本发明实施例十二中用户终端与网络实体通过协商确定最终使用 的控制模式的流程图。
具体实施例方式
由于现有技术中，RTSP ( Real Time Streaming Protocol，实时流协议)的 会话协商和建立过程对上述操作方式有比较好的支持，如建立聚合模式，可 以同步控制所有媒体交付通道，也可以采用单独模式，可以对每一个媒体交 付通道单独控制。
在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操的SIP/SDP消息无法将这些信息传递给用户终端。
本发明实施例一4是供了 一种々某体控制指示方法，通过SDP中的属性行指
示各媒体流的控制状态，即SDP中标识多个媒体交付通道是同步控制还是单
独控制，还是混合控制(既存在同步控制，又存在单独控制)，同步控制是指 对多个媒体流同时进行控制，单独控制是指对单个媒体流进行控制。属性可 以通过多种方式表示，下面举几个例子进行i兑明。
以下所有实施例中，通过属性行关联的媒体交付通道对应的媒体流是需 要相应的媒体控制通道进行控制的，未关联的媒体流是没有相应的媒体控制
通道进行控制；
第一种方式是通过属性行描述媒体交付通道与媒体控制通道的关系，这 两者之间的关系也就是SDP中相应描述信息的关系。 采用a=<attribute>:<value>
其中attribute标识媒体控制属性(如，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 〃描述媒体控制通道的媒体行a二fmtp:rtsp h-uri二 rtsp:〃foo/twister
其中，"a=control:，，属性行作为会话级属性，表示音频和视频J^某体交付 通道对应的媒体流同步控制，媒体控制信息是属性行中RTSP URL为 rtsp://foo/twister对应的媒体控制通道的描述信息，包括媒体控制通道的媒体 行、属性行、RTSP会话属性行、RTSP^ 某体流标识属性行中的一个或多个， 且不限于这些信息。"m=，，是i某体行，< RTSP URL〉可以为rtsp:〃foo/twister， 实际应用中的具体形式不限于此。
媒体级属性行示例2如下
m=audio 1306 RTP/AVP 0 〃描述音频i某体交付通道的々某体行 a=control:rtsp:〃foo/twister
m=video 1308 RTP/AVP 26 〃描述视频媒体交付通道的媒体行 a=control: rtsp: 〃foo/twi ster
m=text 1310 RTP/AVP wb 〃描述文本媒体交付通道的媒体行 m=application 9 TCP iptv—rtsp 〃描述媒体控制通道的i某体行 a=fmtp:rtsp h-uri= rtsp:〃foo/twister
其中，"a=control:"属性行作为媒体级属性，表示音频和视频媒体交付 通道对应的媒体控制信息是属性行中RTSP URL为rtsp:〃foo/twister对应的媒 体控制通道的描述信息，包括媒体控制通道的媒体行、属性行、RTSP会话属 性行、RTSP媒体流标识属性行中的一个或多个，且不限于这些信息。文本媒 体交付通道无相应的a=control:，，属性行，表示无相应的々某体控制通道进行控 制；"m=，，是媒体行，< RTSP URL〉可以为rtsp:〃foo/twister,实际应用中的 具体形式不限于此。
i某体级属性行示例3如下
m=audio 1306 RTP/AVP 0 〃描述音频J/某体交付通道的媒体行 a=control :rtsp :〃 foo/twister/audio
m=video 1308 RTP/AVP 26 //描述视频媒体交付通道的媒体行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，，是音频i某体行，"a=control:rtsp:〃foo/twister/audio"是 对该音频媒体行对应的音频媒体流进行单独控制的属性行；"m= video"是视 频々某体4亍，"a=control:rtsp:〃foo/twister/ video"是，于该一见频士某体4亍》十应的^见频 媒体流进行单独控制的属性行。表示音频和视频媒体交付通道各自对应的媒 体控制信息是各自属性行中RTSP URL为rtsp:〃foo/twister/audio和 rtsp:〃foo/twister/video对应的+某体控制通道的描述信息，包括媒体控制通道的 媒体行、属性行、RTSP会话属性行、RTSP媒体流标识属性行中的一个或多个， 且不限于这些信息。"a="行和"m=，，行的描述只是个示例，具体形式不限 于此。
另外，在该种方式下，虽然UE可单独对每个媒体进行控制，而不强制同 步控制下，但实际应用中也可以对多个媒体的同步控制，例如同时发出多个 控制消息，每个控制消息控制一个媒体通道，以达到对所有媒体流的同步控制。
第二种方式中，通过组属性行描述媒体交付通道与媒体控制通道的关系， 这两者之间的关系也就是SDP中相应描述信息的关系。
采用纟且属'f生4亍a=group:semantics * (space identification-tag)
其中语义semantics用于标识媒体控制属性，可以为字符集或其它， identification-tag为媒体流标识，可以为数字、代号token或其它；表示媒体流 标识为identification-tag取值的媒体流采用统一的媒体控制通道来控制。媒体 流标识为"a=mid:，，流标识属性4亍中的流标识〗直或"a=label:'，流标签属性4亍 中的流标签值。具体示例4如下
a=group: <控制属性(control) 流标识(1 2 ) >a=control :rtsp :〃foo/twi ster 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
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 2 ) >" 为组属性行， 指示媒体流标识为1对应的音频媒体流和媒体流标识为2对应的视频媒体流 同步控制，"a=control:rtsp:〃foo/twister"进一步指示两々某体交付通道对应的力某 体控制信息是属性行中的RTSP URL为rtsp:〃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: 1m=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 ) >" 为组属性行, 指示标签标识为l对应的音频媒体流和视频媒体流进行同步控制，
"a=control:rtsp:〃foo/twister"进一步指示两:樣体交付通道对应的力某体控制信息 是属性行中的RTSP 1^为1^口://!>00/1 13&1"对应的媒体控制通道的描述信息， 包括媒体控制通道的媒体行、属性行、RTSP会话属性行、RTSP媒体流标识属 性行中的一个或多个，且不限于这些信息。text可采用单独控制，其J;某体控制 信息为RTSP URL为rtsp:〃foo/twister/text对应的媒体控制通道的描述信息。其 中"a="行的描述只是个示例，具体形式不限于此。
示例6:
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 〃描述士某体控制通道的J 某体4亍 a=mid:4
其中，"a=group: rtspcontrol 1 2" 为组属性行，指示々某体流标识为1对 应的音频媒体流和媒体流标识为2对应的视频媒体流同步控制，且4某体控制 通道信息是媒体控制通道对应的媒体描述信息，包括媒体行、属性行、RTSP
13会话属性行、RTSP媒体流标识属性行中的一个或多个，且不限于这些信息。
媒体流标识为4对应的文本媒体流无媒体控制通道对其媒体流进行控制。"a=" 和"m="行的描述只是个示例，具体形式不限于此。
媒体流标识采用"a=label:"流标签属性行的方式与示例6类似，只是用
"a=label:，，属性行替换"a=mid:"属性行，组属性行中的々某体流标识改为
"a—abel:"属性行中的标签值。
或者采用组属性行a=group:semantics *(space identification-tag)
其中语义semantics用于标识i某体控制属性，可以为字符集或其它， identification-tag用于标识媒体控制通道信息及媒体流标识信息，媒体控制通 道信息可以为字符集、数字，其中字符集可以为RTSP URL或其它，数字可 以为RTSP会话标识Session ID、 RTSP媒体控制流标识或其它；RTSP媒体控 制流标识和i某体流标识信息可以为数字、代号token或其它。RTSP媒体控制 流标识和J 某体流标识为"a=mid:'，流标识属性4亍中的流标识il或"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" 为组属性行，指示i某体 流标识为1对应的音频i某体流和i某体流标识为2对应的视频J 某体流同步控制， 其媒体控制信息是RTSP URL为rtsp:Z/foo/twister对应的媒体控制通道的描述 信息，包括媒体控制通道的媒体行、属性行、RTSP会话属性行、RTSP媒体 流标识属性行中的一个或多个，且不限于这些信息。"a="和"m="行的描
14说明书第ll/37页
述只是个示例，具体形式不限于此。
示例8:-
a二group: rtspcontrol 3 12
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" 为组属性4亍，指示i某体流标识为1 对应的音频媒体流和媒体流标识为2对应的视频媒体流同步控制，且媒体控 制信息是媒体流标识为3对应的媒体描述信息，包括媒体行、属性行、RTSP 会话属性行、RTSP^ 某体流标识属性行中的一个或多个，且不限于这些信息。 "a="和"m="行的描述只是个示例，具体形式不限于此。
媒体流标识采用"a=label:"流标签属性行的方式与示例8类似，只是用 "a—abel:"属性行替换"a=mid:"属性行，组属性行中的i某体流标识改为 "a=label:"属性行中的标签值。
或者釆用组属性行a=group:semantics *(space identification-tag)
其中语义semantics用于标识媒体控制通道信息，可以为字符集、数字， 其中字符集可以为RTSP URL或其它，数字可以为RTSP会话标识Session ID、 RTSP媒体控制流标识或其它。
identification-tag为媒体流标识，可以为数字、代号token或其它；表示媒 体流标识为identification-tag取值的媒体流采用统一的i某体控制通道来控制。 i某体流标识为"a=mid:"流标识属性行中的流标识值或"a=label:，，流标签属 性行中的流标签值。具体示例9如下
a=group: rtsp:〃foo/twister 1 2m=audio 1306 RTP/AVP 0 a=mid:l
m=video 1308 RTP/AVP 26 a=mid:2—
m=application 9 TCP iptv—rtsp 〃描述i某体控制通道的J 某体行 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="行的描述只是个 示例，具体形式不限于此。
J)某体流标识采用"a=4abel:，，流标签属性行的方式与示例9类似，只是用 "a=label:，，属性行替换"a=mid:"属性行，组属性行中的媒体流标识改为 "a=label:，，属性行中的标签值。
第三种方式中，通过属性行描述媒体交付通道媒体行对应的媒体流与相 应媒体控制通道的关系，这两者之间的关系也就是SDP中相应描述信息的关 系。
釆用a=<attribute>:<value〉
其中attribute标识々某体控制属性，可以为字符集或其它，value标识士某体 控制通道信息及媒体流标识信息，媒体控制通道信息可以为字符集、数字， 其中字符集可以为RTSP URL或其它，数字可以为RTSP会话标识Session ID、 RTSP i某体控制流标识或其它；RTSP媒体控制流标识和纟某体流标识信息可以 为数字、代号token或其它。RTSP媒体控制流标识和媒体流标识为"a=mid:" 流标识属性行中的流标识值或"a=label:，，流标签属性行中的流标签值。
示例10如下a = rtspcontrol: 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 〃描述士某体控制通道的J 某体行 a=mid:3
a=fmtp:rtsp h-uri= rtsp:〃fo()/twister
其中a = rtspcontrol: rtsp:〃fo()/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:l
m=video 1308 RTP/AVP 26 a=label:l
m=application 9 TCP iptv—rtsp 〃描述4某体控制通道的々某体行 a=fmtp:rtsp h-uri= rtsp:〃foo/twister
其中a = rtspcontrol: rtsp:〃foo/twister 1表示J 某体流标签标识为1的媒体 (即音频和视频媒体)需同步控制，且其媒体控制信息是RTSP URL为 rtsp://foo/twister对应的媒体控制通道的描述信息，包括媒体控制通道的媒体 行、属性行、RTSP会话属性行、RTSP媒体流标识属性行中的一个或多个， 且不限于这些信息。其中"a-"行的描述只是个示例，具体形式不限于此。
17第四种方式中，通过属性行描述媒体交付通道媒体行对应的媒体流与相 应媒体控制通道的关系，这两者之间的关系也就是SDP中相应描述信息的关 系。
采用 a=<attribute>:<value>
其中attribute标识J 某体控制属性，可以为字符集或其它，value标识被控 制的媒体流标识信息。媒体流标识信息可以为数字、代号token或其它。媒体 流标识为"a=mid:，，流标识属性行的流标识值或"a=label:，，流标签属性行的 流标签值。
示例12:
m=audio 1306 RTP/AVP 0 〃描述音步贞交付通道的媒体行 a=label: 1
m=video 1308 RTP/AVP 26 〃描述视频交付通道的媒体行 a=4abel: 1
m=application 9 TCP iptv—rtsp 〃描述媒体控制通道的媒体行 a= rtspcontrol: 1
其中a-rtspcontrol: 1表示媒体流标签标识为1的媒体由相应的媒体控 制通道控制，a=label:l标签属性行标识音频和视频的标签都为1,两媒体采用 同步控制，且其媒体控制信息是媒体控制通道的描述信息，包括媒体控制通 道的媒体行、属性行、RTSP会话属性衧、RTSP々某体流标识属性行中的一个 或多个，且不限于这些信息。其中a二"行的描述只是个示例，实际扩展中可 能不是采用rtspcontrol这样的字符来标识，具体形式不限于此。
示例13:
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 〃描述媒体控制通道的汷某体行描述a= rtspcontrol: 1 2
其中a = rtspcontrol: 1 2表示J 某体流标识为1和2的々某体由相应的i某体控 制通道控制，"a二mid:"属性行标识音频和视频的标识分别为1和2,两々某体 采用同步控制，且其媒体控制信息是媒体控制通道的描述信息，包括媒体控 制通道的媒体行、属性行、RTSP会话属性行、RTSP媒体流标识属性行中的 一个或多个，且不限于这些信息。其中行的描述只是个示例，实际扩展 中可能不是采用rtspco加rol这样的字符来标识，具体形式不限于此。
如果有多个媒体控制通道(如，RTSP )的媒体行，和多个媒体交付通道
(如，RTP)媒体行，则通过多个媒体控制通道(如，RTSP)的媒体行下的 属性(如"a = rtspcontrol:")行中不同的J 某体流标识和*某体交付通道(如， RTP)々某体^f亍下的"a=label:"属性行中的流标签值或"a=mid:'，属性行中的流 标识值匹配，来指示不同的媒体控制通道(如，RTSP)控制不同的媒体，如 一个媒体控制通道(如，RTSP)用来控制音频媒体，另外一个媒体控制通道
(如，RTSP)用来控制视频媒体和文本媒体等。
第五种方式中，通过媒体控制通道(如，RTSP)的媒体行下的属性行， 描述媒体交付通道々某体行对应的媒体流与相应媒体控制通道的关系，这两者 之间的关系也就是SDP中相应描述信息的关系。
采用a=《attribute〉<value>
其中attribute标识媒体控制属性，可以为字符集或其它，value标识媒体 控制通道信息及媒体流标识信息，其中，媒体控制通道信息可以为字符集、 数字，其中字符集可以为RTSP URL或其它，数字可以为RTSP会话标识 Session ID、 RTSP々某体控制流标识或其它；RTSP i某体控制流标识和+某体流标 识信息可以为数字、代号token或其它。RTSP々某体控制流标识和:樣体流标识 为"a=mid:"流标识属性行中的流标识值或"a=label:，，流标签属性行中的流 标签值。
示例1 ^口下
m=audio 1306 RTP/AVP 0
19a=mid: 1
m=video 1308 RTP/AVP 26 a=mid:2
m二application 9 TCP iptv_rtsp //描述媒体控制通道的媒体行描述 a = rtspcontrol: rtsp:〃fo()/twister 1 2
其中a = rtspcontrol: rtsp:〃fo()/twister2表示々某体流标识为1和2的々某体 由属性行"a=rtspcontrol"对应的媒体控制通道控制，且其RTSP URL为 rtsp:〃foo/twister， a=mid:"属性行标识音频和移i频的标识分别为1和2,两力某 体采用同步控制，且其媒体控制信息是媒体控制通道的描述信息，包括媒体 控制通道的J 某体行、属性行、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表示i某体流标签标识为1的々某体 由属性行"a=rtspcontrol"对应的々某体控制通道控制，且其RTSP URL为 rtsp:〃foo/twister， a=label:，，属性行标识音频和视频的标签标识都为1,两i某体 采用同步控制，且其媒体控制信息是媒体控制通道的描述信息，包括媒体控 制通道的媒体行、属性行、RTSP会话属性行、RTSP i某体流标识属性行中的 一个或多个，且不限于这些信息。其中"a="行的描述只是个示例，实际扩 展中可能不是采用rtspcontrol这样的字符来标识，具体形式不限于此。
如果有多个媒体控制通道(如，RTSP)的媒体行，和多个媒体交付通道(如，RTP)媒体行，则通过多个媒体控制通道(如，RTSP)的媒体行下的 属性(如"a = rtspcontrol:")行中不同的々某体流标识和i某体交付通道(如， RTP)媒体行下的"a=label:'，属性行中的流标签值或"a二mid:"属性行中的流 标识值的属性值的匹配，来指示不同的媒体控制通道(如，RTSP)控制不同 的媒体，如一个媒体控制通道(如，RTSP)用来控制音频媒体，另外一个媒 体控制通道(如，RTSP)用来控制视频媒体和文本媒体等。
上述实施例中，以属性行携带RTSP URL为例，实际上，也可以携带SIP URI， TV URI或者任何一种可以标识4某体内容的标识。
本实施例通过属性行实现指示媒体控制通道(如，RTSP)所控制的媒体 交付通道(如，RTP),实现方式更为灵活，既可以用来指示只有一个i某体控 制通道的情况下所控制的一个或多个媒体交付通道，也可以用来指示在有多 个媒体控制通道的情况下，每个媒体控制通道所控制的一个或多个媒体通道。
本发明实施例二提供了一种获取媒体控制会话信息的系统，包括用户 终端，用于通过核心IMS向网络侧设备发送请求消息，所述请求消息中携带 内容标识；网络侧设备，用于接收所述用户终端通过核心IMS发送的请求消 息后，将所述内容标识对应的媒体控制会话信息，携带在媒体控制组属性行 中，通过所述核心IMS发送给所述用户终端。内容描述元功能实体，用于给 所述网络侧设备提供媒体控制会话信息。
本发明实施例提供了一种网络侧设备，包括响应消息生成单元，用于 生成响应消息，所述响应消息中的媒体控制组属性行携带不同媒体控制会话 信息；响应消息发送单元，用于将所述响应消息通过所述核心IMS发送给所 述用户终端；描述信息获取单元，用于获取内容标识对应的媒体控制会话信 白、
("、o
本发明实施例还提供了一种获取媒体控制会话信息的系统，包括用户 终端，用于通过核心IMS向网络侧设备发送请求消息，所述请求消息中携带 内容标识；网络侧设备，用于接收所述用户终端通过核心IMS发送的请求消 息后，将所述内容标识对应的媒体控制会话信息，携带在媒体控制属性行
21a=<attribute>:<value>t,通过所述核心IMS发送主会所述用户终端，其中， attribute标识i某体控制属性，value标识士某体流标识；内容描述元功能实体， 用于给所述网络侧设备提供媒体控制会话信息。
本发明实施例还提供了一种网络侧设备，包括响应消息生成单元，用 于生成响应消息，所述响应消息中的々某体控制属性4亍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将该CoD业务请求转发给SC1'，。
步骤s303, SCF通过所述内容标识选择适当的MF，并将SDPOffer发送 给MF。
步骤s304, MF从内容描述元功能中获取所述内容标识对应的内容不同々某 体的控制描述信息，如一个内容对应的多个媒体流是采用同步控制，还是单 独控制，还是混合控制方式，其中内容描述元功能可作为MF的内部功能模 块，或作为独立的功能实体存在。该步骤可选。
步骤s305至步骤s307, MF根据得到的内容不同媒体的控制描述信息， 生成相应的SDP Answer,该SDP Answer中包括指示各J 某体流的控制会话信 息的属性行(如实施例一中描述)；并通过业务响应返回给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的内部功能模 块，或作为独立的功能实体存在。该步骤可选。
.步骤s406和步骤s407, SCF根据得到的内容不同媒体的控制描述信息， 生成相应的SDP Answer,该SDP Answer中包括指示各媒体流的控制会话信 息的属性行(如实施例一中描述)，并通过业务响应返回给UE,其中业务响 应可以为200 OK、 183^"求，或其它响应。
如图5所示，本发明实施例五提供了一种实现媒体控制的方法，包括以 下步骤
步骤S501 、用户终端通过Core IMS发送携带媒体控制通道和媒体交付通 道关系信息的请求消息给网络侧设备。
其中，媒体控制通道和J;某体交付通道关系信息，可以是从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 〃描述々某体控制通道的々某体4亍 a=mid:4
其中，"a=group: rtspcontrol 1 2" 为组属性行，指示i某体流标识为1对 应的音频媒体流和媒体流标识为2对应的视频媒体流同步控制，且媒体控制 通道信息是媒体控制通道对应的媒体描述信息，包括媒体行、属性行、RTSP 会话属性行、RTSP々某体流标识属性行中的一个或多个，且不限于这些信息。 媒体流标识为4对应的文本媒体流无媒体控制通道对其媒体流进行控制。"a=" 和"m二"行的描述只是个示例，具体形式不限于此。
媒体流标识采用"a=label:，，流标签属性行的方式与示例6类似，只是用 "a=label:，，属性行替换"a=mid:，，属性行，组属性行中的士某体流标识改为 "a=label:，，属性行中的标签值。
需要进一步指出的是，上述的携带方式只是本发明的优选实施例，其他 的携带方式参照本发明实施例一中的详细说明，携带方式的变化，并不影响 本发明的保护范围。
步骤S502、网络侧设备向用户终端返回响应消息，该响应消息携带媒体 描述信息。
其中，媒体描述信息具体为媒体交付通道信息和/或媒体控制通道信息，
可以携带在响应消息的SDP中。
步骤S503、用户终端根据关系信息与媒体描述信息，进行媒体控制。 需要进一步指出的是，在本实施例中，网络侧设备，为SCF或MF或其
他可以实现上述网络侧设备功能的网络实体，具体实体的差别不影响本发明
的保护范围。
24如图6所示，本发明实施例六提供了一种实现媒体控制的方法，包括以
下步骤
步骤S601 、用户终端通过Core IMS向网络侧设备发送业务请求消息。
用户终端向Core IMS发起CoD业务请求，携带内容标识等信息，其中业 务请求可以为SIP INVITE请求或其它请求。
步骤S602、网络侧设备向用户终端返回响应消息，该响应消息携带关系 信息和媒体描述信息。
其中，关系信息具体指媒体控制通道和媒体交付通道关系信息，釆用实 施例一中描述的方式携带于响应消息的SDP中。
为方便说明，对关系信息在请求消息中的携带方式进行举例如下
a=group: rtspcontrol 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" 为组属性行，指示4某体流标识为1 对应的音频媒体流和媒体流标识为2对应的视频媒体流同步控制，且媒体控 制信息是媒体流标识为3对应的媒体描述信息，包括媒体行、属性行、RTSP 会话属性行、RTSP媒体流标识属性行中的一个或多个，且不限于这些信息。 "a二"和"m="行的描述只是个示例，具体形式不限于此。
媒体流标识采用"a二label:，，流标签属性行的方式与示例8类似，只是用 "a=label:，，属性行替二狭"a=mid:"属性行，组属性4亍中的士某体流标识改为 "a二label:"属性行中的标签值。
需要进一步指出的是，上述的携带方式只是本发明的优选实施例，其他 的携带方式参照本发明实施例一中的详细说明，携带方式的变化，并不影响 本发明的保护范围。
25步骤S603、用户终端根据关系信息与媒体描述信息，进行媒体控制。 需要进一步指出的是，在本实施例中，网络侧设备，为SCF或MF或其
他可以实现上述网络侧设备功能的网络实体，具体实体的差别不影响本发明
的保护范围。
如图7所示，本发明实施例七提供了一种实现媒体控制的系统，包括 用户终端l，用于获取媒体控制通道和媒体交付通道关系信息，并根据关
系信息与媒体描述信息，进行媒体控制。
进一步，用户终端1还可以用于通过核心IMS向网络侧i殳备2发送请求
消息，请求消息的SDP中携带关系信息。
进一步，该系统中还可以包括网络侧设备2，用于发送响应消息，响应消
息的SDP中携带媒体控制通道和媒体交付通道关系信息。
进一步，该系统中还可以包括业务选择功能SSF3，用于提供媒体控制通
道和媒体交付通道关系信息给用户终端1 。业务选择功能是在IMS-based IPTV
架构下用来提供业务选择信息，如电子节目单EPG信息等的实体。 在上述系统的实施例中，网络侧设备2可以SCF或MF或其他。 本发明实施例还提供了 一种用户终端1，可以包括 获取单元11,用于获取媒体控制通道和媒体交付通道关系信息； 控制单元12,用于根据关系信息与媒体描述信息，进行媒体控制。 该用户终端，还可以进一步包括，发送单元13，用于发送请求消息，请
求消息的SDP中携带媒体控制通道和媒体交付通道关系信息。 本发明实施例还提供了 一种网络侧设备2，包括 接收单元21,用于接收请求消息；
发送单元22,用于发送响应消息，响应消息的SDP中携带媒体控制通道
和媒体交付通道关系信息。
进一步的，SSF3，还用于提供业务选择信息，如电子节目单EPG信息等。 需要进一步指出的是，在本实施例中，网络侧设备2可以SCF或MF或其他。本发明的实施例中，通过SIP/SDP消息属性行描述^某体控制通道(如，
RTSP)所控制的媒体交付通道(如，RTP),可以实现CoD业务中对内容的 所有媒体交付通道进行同步VCR操作或对单个媒体交付通道进行VCR操作。
现有技术中，CoD流程会话建立过程的主要特点是由于在CoD业务过程 中用户能对所看的内容进行VCR控制(如前进、后退、暂停等)，因此该业 务需要建立媒体控制通道(用于VCR操作)和媒体交付通道(用于传送所看 的内容)。根据媒体控制通道和媒体交付通道建立方式的不同，TISPAN中定 义的CoD业务流程，主要可以分为两种第一种方式是媒体控制通道和媒体交 付通道在SIP会话建立过程中同时建立；第二种方式是在会话建立初始过程中 先建立媒体控制通道，然后再通过会话更改建立媒体交付通道。
采用第一种方式的情况是终端UE已经从HPG (电子节目单)上获取所观 看的内容的媒体信息，如该内容包括哪些媒体行，如音频、视频、文本等， 因此可以协商和建立该々某体交付通道。采用第二种方式，即先通过SIP会话建 立过程协商建立媒体控制通道(通常是RTSP通道)，然后在终端和媒体服务 器之间建立媒体交互控制会话，然后通过媒体控制消息的交互获取媒体网络 参数信息，然后在会话更改过程中发起建立内容交付通道。
事实上，第二种方式相对于第一种方式存在以下缺陷如导致会话建立 时间延长，大致过程如下在会话初始建立(通常采用SIP消息)后，终端和 网络(媒体服务器)之间还要再发起媒体控制消息(通常是RTSP DESCRIBE 消息)建立媒体控制会话，然后在媒体控制会话消息中交换媒体的内容信息， 最后再通过会话更改过程(又回到SIP消息)来完成媒体通道的建立。导致用 户的服务体验降低，因此目前的规范中对采用第二种方式的应用条件有如下 限制只有当网络只提供给了用户媒体控制通道的网络参数信息(没有提供 内容交付通道的网络参数信息)，初始会话建立内容交付通道才是可选的(即 釆用第二种方式)。然而，第二种方式需要终端UE和网络侧有更多的交互，对 终端提出更多的需求，并导致会话建立延迟，使得用户的体验变差。
本发明实施例利用SIP会话消息中的OPTIONS方法，在无法或没有通过SSF获取内容的网络参数或内容媒体信息时，例如用户没法访问SSF(业务 发现功能实体，即相当于电子节目单功能，通常采用HTTP协议)、或能访问 SSF,但SSF不提供所需要的信息；或用户没有访问SSF,直接发起业务请求， 来动态的获取内容的网络参数和/或媒体信息，从而使得用户UE在没有从SSF 获取网络参数的情况下也能采用规范中的第 一种方式，或采用类似规范中的 改进后的第二种方式。
UE在发起CoD会话请求前，采用SIP OPTK)NS向网络发起请求，请求中 要求获取网络实体(图中的媒体服务器MF )的媒体控制通道(如RTSP )的网 络参数信息和/或所请求内容的网络参数和/或媒体交付通道描述信息，网络在 SIP OPTIONS的请求响应消息中返回媒体控制通道的网络参数信息和/或所请 求内容的网络参数和/或媒体交付通道描述信息，从而UE能在发起会话请求前 获取了媒体控制通道(如RTSP)的网络参数及媒体交付通道信息，从而可以 按上述第一种方式发起CoD业务请求，建立媒体控制通道和:樣体交付通道。
另外，采用第二种方式时，在初始协商建立媒体控制通道(如RTSP)会 话后，需要再重新利用控制消息获取媒体交付通道信息，然后再通过SIP建立 会话，这种方式效率不高。
因此，在第二种方式的初始协商建立4某体控制通道过程中，用户终端UE 可以在会话建立(SIP会话)过程中或建立后，用户终端UE发起采用SIP OPTIONS方法发起请求要求获取所请求的内容的网络参数和/或媒体交付通 道信息(这一步即完成了终端和网络侧通过媒体控制通道来获取内容网络参 数和/或媒体交付通道信息)，在获取所需的信息后，直接采用规范中所描迷的 会话更改流程完成媒体交付通道的建立，该方案中获取内容网络参数和/或媒 体交付通道信息步骤可以与媒体控制通道的协商建立同步完成，而现在所描 述方案是先后完成，因此本方案既有利于会话建立过程中UE和网络多个实体 过多交互，也有利于缩短整个会话建立(包括媒体控制通道建立和媒体交付 通道建立)的时间，提升对用户的服务体验。
本发明实施例八，终端在发起CoD会话请求前，请求々某体控制通道的网 络参数信息和/或媒体交付通道的网络参数，如图7所示，包括以下步骤步骤s801,用户终端UE在发起CoD会话请求前，向Core IMS发起SIPOPTIONS请求。携带的消息参数如下
OPTIONS sip:XXXMoiveID@XXtele.com SIP/2.0
Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKhjhs8ass877Max-Forwards: 70
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 ，，改为
步骤s802, CoreIMS向提供点播业务的SCF (业务控制功能)转发该请求消息。
步骤s803， SCF根据所请求内容标识XXXMoiveID,选择一个合适的MF,该选择功能也可以在MF上完成，由MF完成选择其它合适的MF并转发请求，或其它独立的功能实体完成，具体方式不是本发明的关注点。
步骤s804 ， SCF向所选择的MF转发此请求消息。
步骤s805, MF才艮据所请求的内容标识XXXMoiveID，向内容描述元功能获取内容的媒体描述信息、媒体控制通道和/或媒体交付通道的网络参数信息。其中，内容描述元功能可能是MF内部的一个功能、也有可能是一个独立的功能实体。该步骤可选。
步骤s806, MF向SCF返回200OK响应消息，消息中携带参数如下
29SIP/2.0 200 OK
Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKhjhs8ass877;received= 192.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@XXtelc.com >
Accept: application/sdp
Content-Type: application/sdp
Content-Length: 164
v=0
o=- 2890844256 2890842807 INIP4 172.16.2.93——网纟各地址信息s=RTSP Session
i=An Example of RTSP Session Usage
a=control :rtsp:〃foo/twister——々某体4空制会i舌4言息
t=0 0
m=audio 0 RTP/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或其它类型，即将
30Content-Type头域中的 "application/sdp " 改为 "application/xml " 或"application/xxx",々某体控制会话信息的描述方式还可以为实施例一描述的其它方式。
若XML方式，具体消息体内容的示例为<xml description>
Audio/Video/Text——J 某体组成
Codec — 一不同媒体的编解码
...一一其它信息，如不同媒体成分是否能独立VCR操作，时长等其它内容描述信息
<xml description)
步骤s807, SCF向Core IMS返回20()响应消息。步骤s808, Core IMS向UE返回200响应消息。
UE动态获取所请求内容的媒体交付信息后，终端UE已经从EPG (电子节目单)上获取所观看的内容的媒体信息，如该内容包括哪些媒体行，如音频、视频、文本等，即可按目前规范中定义的第一种方式，会话初始建立过程中即同时建立媒体控制通道和媒体交付通道。
本发明实施例九中，终端在发起CoD会话请求前获取媒体控制通道的网络参数信息和/或媒体交付通道信息，如图8所示，包括以下步骤
步骤s901,用户终端UE在发起CoD会话请求前，向Core IMS发起SIPOPTIONS请求。携带的消息参数如下
OPTIONS sip:XXXMoiveID@XXtele.com SIP/2.0
Via: SIP/2.0/UDP pc33.atlanta,com;branch=z9hG4bKhjhs8ass877Max-Forwards: 70
To: <sip: XXXMoiveID@XXtele.com >
From: Alice <sip:alice@atlanta.com>;t'dg=1928301774
Call-ID: a84b4c76e6671()
CSeq: 63104 OPTIONS
Contact: <sip:alice@pc33.atlanta.com>Accept: application/xmlContent-Length: 0
该步骤中的请求消息的参数描述只是个示例，具体实现时不限于此，还可以有其它描述形式。消息中携带所请求的点播内容的标识XXXMoiveID,在Accept头域中指示接收的消息体类型为XML信息，实现时还可以为SDP信息或其它类型的消息，只需将Acc印t头域中的 "application/xml "改为"application/sdp，，或 "application/xxx'，
步骤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=z9hG4bKhjhs8ass877;received=192.0.2.4
To: <sip: XXXMoiveID@XXtelexom >;tag=93810874
From: Alice <sip:alice@atlanta.com>;tag=19283()1774
Call-ID: a84b4c76e6671()
CSeq: 63104 OPTIONS
Contact: <sip: XXXMoiveID@XXtele.com >
Accept: application/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方式，具体消息体内容的示例为
m=audio 0 RTP/AVP 0——音频行媒体信息，如音频编码等 a二control :rtsp:〃foo/twister/audio
m=video 0 RTP/AVP 26——视频行媒体信息，如视频编码等 a二control :rtsp :〃foo/twister/video ...一一其它可能的媒体属性信息
其中媒体控制会话信息的描述方式还可以为实施例一描述的其它方式。 步骤s905, Core IMS向UE返回2()0响应消息。
UE动态获取所请求内容的控制通道网络参数和/或媒体交付通道信息后， 可按目前规范中定义的第一种方式，即会话初始建立过程中即同时建立媒体 控制通道和内容通道。
本发明实施例十中，终端在发起CoD会话请求过程中请求^ 某体交付通道 信息，如图10所示，包括以下步骤
用户终端先按第二种方式发起初始会话建立，只协商媒体控制通道，在 这个过程中，UE可以同时发起获取媒体交付通道相关信息，如图中s1001 ~ sl007所述步骤，具体如下
步骤sl001， UE向Core IMS发起SIP OPTIONS请求。携带的消息参数如下OPTIONS sip:XXXMoiveID@XXtele.com SIP/2.0
Via:SIP/2.0/UDPpc33.atlanta.com;branch=z9hG4bKhjhs8ass877—— 这部分参数将与前面所初始会话建立中的SIP消息参数相同，下面参数处理机 制类似
Max-Forwards: 70
To: <sip: XXXMoiveID@XXtele.com >
From: Alice <sip:alice@atlanta.com>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 63104 OPTIONS
Contact: <sip:alice@pc33.atlanta.c()m>
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.atl肌ta.com;branch二z9hG4bKhjhs8ass877
34;received=192.0.2.4
To: <sip: XXXMoiveID@XXtele.com >;tag=93810874
From: Alice <sip:alice@atlanta.com>;tag=l 928301774
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 28卯8428()7 IN IP4 172.16.2.93——网络地址信息 t=0 0
m=audio 0 RTP/AVP 0——音频行媒体信息，如音频编码等 a=control:rtsp:〃foo/twister/audi()
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消息内容与实施例五类似，这里不重述。 步骤sl006, SCF向Core IMS返回200响应消息；
35步骤sl007, Core IMS向UE返回20()响应消息；
UE获取所请求内容的媒体交付通道信息后，即可按当前规范中定义的会 话修改流程协商建立媒体交付通道，而不需要等到媒体控制通道建立并通过 媒体控制通道交互获取所请求内容的媒体交付通道信息后，再发起会话修改 建立媒体交付通道，从而提高CoD的会话建立过程。
本实施例中，SIP OPTIONS消息发给MF进行处理，返回媒体交付通道 的相关信息，也可以由SCF处理返回，类似实施例六中的处理方式。
本发明实施例十一中，UE发起CoD业务请求，SDPOffer中携带协商媒 体控制通道，MF从内容描述元功能实体中获取内容交付通道的媒体描述信息 后，向UE返回SDP Answer, SDP Answer中通过XML或链接等方式携带内 容交付通道的々某体描述信息。具体过程如图ll所示，包括以下步骤
步骤s 1101 ， UE向Core IMS发起CoD业务请求，携带内容标识、SDP Offer 等信息，其中业务请求可以为SIP INVITE请求或其它请求。
步骤sll02, Core IMS将该CoD业务请求转发给SC1''。
步骤sl103, SCF通过所述内容标识选择适当的MF,并将SDPOffer发 送给MF。
步骤s1104， MF从内容描述元功能中获取所述内容标识对应的内容交付 通道的媒体描述信息，其中内容描述元功能可作为MF的内部功能模块，或 作为独立的功能实体存在。该步骤可选。
步骤s 1105至步骤s 1107, MF根据得到的内容交付通道的媒体描述信息， 在返回的业务响应中生成相应的SDP Answer,该SDP Answer以XML或链接 等方式携带内容交付通道的媒体描述信息；其中业务响应可以为200 OK、 183 请求，或其它响应。具体xml描述与上述实施例的描述类似，这里不重述。
UE获取所请求内容的媒体交付通道信息后，即可按当前规范中定义的会 话修改流程协商建立媒体交付通道，而不需要等到媒体控制通道建立并通过 媒体控制通道交互获取所请求内容的媒体交付通道信息后，再发起会话修改 建立媒体交付通道，从而提高CoD的会话建立过程。
本实施例中，请求消息如SIP INVITE消息发给MF进行处理，并由MF
36查询后在响应中通过XML或链接等方式返回内容交付通道的媒体描述信息； 也可以由MF返回响应给SCF后，由SCF查询后在响应中通过XML或链接 等方式返回内容交付通道的媒体描述信息，类似实施例六中的处理方式。
上述实施例八、九、十、十一只是本发明方案在几种场景下的典型示例， 由于SIP协议应用的灵活性，上述使用方式是可以在多个场景下进行应用的。 同时，可以通过扩展Accept头域中指示特定的能力信息，来获取内容特定的 描述信息，如目前SIP协议中已定义Accept-Encoding和Accept-Language,来 分别指示媒体的编码类型以及语言等信息。本发明中的技术方案采用的是SIP OPTIONS方法(该方法在SIP协议中的本意就是获取能力信息)，也有可能 采取其它SIP Method,如Subscribe/Notify, Refer等方式来进行，SIP方法符 合SIP协议规范，应用方法与本发明中的实施例类似。
还有一种可选的方法是用户在初始会话请求(如Invite消息)中携带的 SDP Offer中为空(此时UE没有获取网络参数，无法发起有效的SDP Offer )， 网络实体SCF或MF返回的响应消息中SDP Answer中也为空，同时在响应消 息中携带针对所请求的内容标识的媒体控制通道和/或媒体交付通道信息、网 络参数的描述，该描述可以采用在SIP消息体中xml语言进行描述的方式， 也可以是一个描述所请求内容媒体控制通道和/或媒体交付通道信息和/或网 络参数信息的地址链接或SDP描述。
本发明实施例十二中，在会话建立过程中，对控制方式的协商。终端可 以在会话建立过程中，和网络侧(以下实施例以媒体服务器为例进行说明， 具体实现不限于此)协商对不同媒体支持的控制模式(如，同步、单独控制 模式)。终端可以选择自己希望或支持使用的模式，通知给媒体服务器；媒体 服务器根据自己支持的模式，确定最终使用的控制模式。具体控制模式的表 示，可以采用上面叙述的实施例一中的任意一种方法。该方式在IMS系统下 的实施例如下所述
s1201， UE通知Core IMS它对不同媒体所支持，或者选择的模式。其中， 用户终端通知媒体服务器MF自己所支持的模式，可能为支持同步控制模式 和/或单独控制模式。或者通知MF用户终端所偏好的模式，如用户终端倾向于采用单独控制模式，或者同步控制模式。具体实现时，该消息可以通过业
务请求SIP Invite请求实现，或者通过Options请求实现。具体关于控制模式 的具体携带方法，可以通过SIP头域，或者消息体的SDP属性行携带。
(1) 通过SIP头域携带时，可以以终端能力，或者用户偏好的方式体现。 如通过Contact 头域,Request-Disposition头域，Accept-Contact头域、 Reject-Contact头域携带。
a) Contact头域如 Contact: <sip:user@h()st.example.c()m>;ControlMode="aggregate" b ) Request-Disposition头域如 Request-Disposition: aggregate
其中可以定义ControlMode4旨示，其{直可以是aggregate禾口non-aggregate. 通过Accept-Contact头域、Reject-Contact头域携带方法类似于 Request-Disposition头域。
上述ControlMode只是一个示意，可以是其它的字符串。
(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 rt邻
a:ControlMode: aggregate--4空制才莫式属性ft或者，也可以通过a-fmtp属性表示，如； a=fmtp:rtsp ControlMode:aggregate
上述SDP表示终端支持同步和单独控制模式的协商，同时，希望本次协 商采用同步控制模式。
本发明的实施例中，UE和MF通过协商过程，彼此或者对方是否支持同 步控制、单独控制模式，以及彼此所希望采用的方式。为实现该思想，属性 行可能存在除了上述方式外的其它构造方式，都在本专利的保护范围之内， 如
a=aggregate-control :TRUE/False ， 或者 a=fmtp:rtsp aggregate-control TRIJE/False
S1202、 S1203终端UE的请求通过Core IMS, SCF转发给媒体服务器。 S1204, MF向内容描述元功能获取内容的媒体描述信息(注内容描述 元功能可能是MF内部的一个功能、也有可能是一个独立的功能实体)、和/ 或媒体控制通道、媒体交付通道的网络参数信息，如根据所请求的内容标识 XXXMoiveID来获取。该步骤可选。
S1205返回支持，或者确定的模式
媒体服务器MF返回响应，告诉终端MF所支持，或者所选择的控制模式。 同步骤S1201对应，具体实现时，该消息可以通过200()K或183等其它响 应消息的SIP头域，或者消息体的SDP属性行携带。 通过SIP头域返回类似步骤S1201,不再赘述。
通过消息体，如SDP携带实例如下，除了携带MF选择的具体模式外，MF 还可以进一步携带相关4莫式的参数，如控制的URL,以及SessionID: m=video 3400 RTP/AVP 98
m=audio 3456 RTP/AVP 97
m=applicatk)n 10000 TCP/RTSP iptv一rtspa=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 3456 RTP/AVP 97
m=application 10000 TCP/RTSP iptv rtsp
a=ControlMode:non-aggregate 〃或者，a=fmtp:ControlMode non-aggregate a=fmtp:iptv—rtsp h-uri=rtsp:〃 MCF.example.com /video-position/video 1 a=fmtp:rtsp h-session: 123456 a= m-stream: 1
a=fmtp:iptv—rtsp h-uri=rtsp:〃 MCF.examplc.com /audio-position/audiol a=fmtp:rtsp h-session: 234567 a= m-stream :2
上述媒体控制通道与媒体传送通道的对应的控制关系描述，即媒体控制
属性行可以采用上述实施例 一 方式中的任何一种。
SI206、 S1207MF的响应通过SCF、 Core IMS,转发纟会用户终端UE。 本实施例中，请求消息如SIP INVITE或OPTIONS等消息发给MF进行
处理，并由MF查询后在响应中返回支持的控制模式；也可以由MF返回响应
给SCF后，由SCF查询后在响应中返回支持的控制模式，类似实施例三中的
处理方式。通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到本 发明可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬 件，但很多情况下前者是更佳的实施方式。基于这样的理解，本发明的技 术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体
现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使 得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行
本发明各个实施例所述的方法。
任何本领域的技术人员能思之的变化都应落入本发明的保护范围。
权利要求
1、一种实现媒体控制的方法，其特征在于，包括以下步骤获取媒体控制通道和媒体交付通道关系信息；根据所述关系信息与媒体描述信息，进行媒体控制。
2、 如权利要求1所述实现媒体控制的方法，其特征在于，还包括 通过核心IMS向网络侧设备发送请求消息，所述请求消息的SDP中携带所述关系信息。
3、 如权利要求1所述实现媒体控制的方法，其特征在于，所述媒体描述 信息至少包括如下信息之一或其组合媒体交付通道信息、媒体控制通道信 息。
4、 如权利要求1所述实现媒体控制的方法，其特征在于，所述获取媒体 控制通道和媒体交付通道关系信息具体包括接收所述网络侧设备发送的响应消息，所述响应消息的SDP中携带所述 媒体控制通道和媒体交付通道关系信息；或，从业务选择功能SSF获取所述媒体控制通道和媒体交付通道关系信息。
5、 如权利要求4所述实现媒体控制的方法，其特征在于，所述网络侧设 备，为业务控制功能SCF或媒体功能MF。
6、 如权利要求2或4中任意一项所述实现媒体控制的方法，其特征在于， 所述SDP中携带所述媒体控制通道和媒体交付通道关系信息，具体为携带在组属性行中；或， 携带在属性行中。
7、 如权利要求6所述实现媒体控制的方法，其特征在于，所述组属性行， 具体为a=group: semantics * (space identification-tag)，其中，semantics用于标识々某体控制属性，identification-tag为4某体流标识。
8、 如权利要求6所述实现媒体控制的方法，其特征在于，所述组属性行， 具体为a=group:semantics * ( space identification-tag )，其中，semantics用于标识々某体控制通道信息；identification-tag为々某体流 标识。
9、 如权利要求7所述实现媒体控制的方法，其特征在于，所述 identification-tag,还包括所述+某体控制通道信息。
10、 如权利要求6所述实现媒体控制的方法，其特征在于，所述属性行， 具体为a=<attribute>: <value>;其中，attribute用于标识媒体控制属性，value标识媒体控制通道信息。
11、 如权利要求IO所述实现媒体控制的古法，其特征在于，所述value, 还包括纟某体流标识信息。
12、 如权利要求8、 9、 10中任意一项所述实现媒体控制的方法，其特征 在于，所述々某体控制通道信息为RTSPURL、 RTSP会话标识Session ID、 RTSP 媒体控制流标识中的一个或多个。
13、 如权利要求7、 8、 11或12中任意一项所述实现媒体控制的方法， 其特征在于，所述流标识包括流标识属性行中的流标识值或流标签属性行中 的流标签值。
14、 一种实现媒体控制的系统，其特征在于，所述系统中包括用户终端 所述用户终端，用于获取媒体控制通道和媒体交付通道关系信息； 所述用户终端，还用于根据所述关系信息与媒体描述信息，进行媒体控制。
15、 如权利要求14所述实现媒体控制的系统，其特征在于， 所述用户终端，还用于通过核心IMS向网络侧设备发送请求消息，所述请求消息的SDP中携带关系信息。
16、 如权利要求14所述实现媒体控制的系统，其特征在于，所述系统还 包括网络侧设备所述网络侧设备，用于发送响应消息，所述响应消息的SDP中携带所述 媒体控制通道和媒体交付通道关系信息。
17、 如权利要求14所述实现媒体控制的方法，其特征在于，所述系统，还包括业务选择功能SSF,用于提供所述媒体控制通道和媒体交付通道关系信 息给所述用户终端。
18、 如权利要求16所述实现媒体控制的系统，其特征在于，所述网络侧 设备，为SCF或MF。
19、 一种用户终端，其特征在于，包括获取单元，用于获取媒体控制通道和媒体交付通道关系信息； 控制单元，用于根据所述关系信息与媒体描述信息，进行媒体控制。
20、 如权利要求19所述用户终端，其特征在于，还包括发送单元，用于发送请求消息，所述请求消息的SDP中携带所述+某体控 制通道和媒体交付通道关系信息。
21、 如权利要求19所述用户终端，其特征在于，所述获取单元，用于获 取媒体控制通道和媒体交付通道关系信息，具体为从网络侧设备发送的响应消息的SDP中获取的；或者， 从业务选择功能SSF获取所述媒体控制通道和媒体交付通道关系信息。
22、 一种网络侧设备，其特征在于，包括 接收单元，用于接收请求消息；发送单元，用于发送响应消息，所述响应消息的SDP中携带媒体控制通 道和i某体交付通道关系信息。
23、 如权利要求22所述网络侧设备，其特征在于，具体为 SCF或MF。
全文摘要
本发明公开了一种实现媒体控制的方法、系统和设备，所述方法包括以下步骤获取媒体控制通道和媒体交付通道关系信息；根据所述关系信息与媒体描述信息，进行媒体控制。本发明通过SDP中描述媒体控制通道和媒体交付通道关系信息，并结合媒体描述信息实现了媒体控制。
文档编号H04L12/14GK101459525SQ200810091608
公开日2009年6月17日 申请日期2008年4月3日 优先权日2007年10月22日
发明者军 严, 彭招君, 丰 王 申请人:华为技术有限公司