网络电视的业务控制方法、 ***以及装置
技术领域
本发明涉及 IPTV技术领域, 尤其涉及一种网络电视的业务控制方 法、 ***以及装置。 发明背景
因特网协议电视 ( IPTV, Internet Protocol Television ), 或者又称网 络电视, 其***的结构示意图可以如图 1所示。 该***包括用户终端和 网络侧, 网络侧包括会话处理模块和应用处理模块, 其中:
会话处理模块用于为接入网络的用户终端提供呼叫控制、 路由接续 等功能, 其既可以将呼叫路由到被叫用户终端, 也可以将呼叫路由到应 用处理模块;
应用处理模块用于处理用户的请求。
图 1中所示的 E1为用户终端和会话处理模块的接口, E2为会话处 理模块和应用处理模块的接口。
目前,在实现 IPTV业务时,用户使用 IPTV业务前需要获得频道的 相关信息, 即频道信息。 频道信息可能包括频道组播地址、 端口、 频道 加密密钥等信息。 用户获得频道信息后就可以加入相应的组播组, 进行 不同频道节目的接收。 当然, 至于频道信息究竟包括哪些具体的信息则 可以由用户自行定义, 只要用户终端可以根据频道信息收看节目即可。
现有技术中, 当用户终端的 IPTV软件启动, 用户终端可以自动使 用超文本传送协议(HTTP, Hypertext Transfer Protocol )或者文件传送 协议(FTP, File Transfer Protocol, )从指定地址获取频道信息的文本文 件。 具体可以一次性获取全部频道标识信息对应的频道信息, 或者分多
次获取全部的频道标识信息对应的频道信息, 在终端的请求中并不明确 指出所请求的频道, 而是指定包含描述信息的文件名或者处理请求的脚 本文件名, 如:
http://iptv.example.com/ch/ch-des.txt
表示访问指定频道列表描述文件, 该文件中提供了频道信息。 或者
http://epg.example.com/epg/jsp/getChannelList.jsp?lang=en
表示访问指定脚本后, 其返回的的信息就是频道信息。
采用上述方法获得的频道信息编码和格式一般由开发应用的开发 者定义, 属于私有定义; 通过这种方式获得的频道信息在终端侧被终端 软件解析并将相关信息保存在终端侧, 用户可以通过终端界面进行频道 选择, 终端则根据用户的选择情况根据所获得的信息自动的发起组播加 入请求。
4艮明显, 采用上述方法时, 如果用户在终端开机后每次仅选择几个 频道收看, 则一次性下发所有频道信息对于终端来讲提出了存储空间的 需求, 这对于手机等存储空间较 d、的终端来讲是一种比较明显的资源浪 费。 因此, 用户终端只获取用户指定的频道是十分有意义的。 发明内容
本发明实施例提供一种网络电视的业务控制方法, 用以解决现有技 术中存在用户终端无法获取指定频道信息的问题。
针对上述目的, 本发明实施例提出的技术方案为:
一种网络电视的业务控制方法, 包括以下步骤:
终端侧向网络侧发送用户指定频道的频道标识信息, 并接收网络侧 返回所述标识信息对应的频道信息。
本发明实施例还提出一种 SIP网络中提供电视业务的方法, 可以在
SIP网络中标识电视频道, 从而提供电视业务。
针对上述目的, 本发明实施例提出的技术方案为:
一种 SIP网络中提供电视业务的方法, 该方法包括:
网络电视应用服务器接收由网络电视终端功能发起的 SIP会话请 求, 在所述 SIP会话请求中包含指示频道标识信息的 SIP URI;
网络电视应用服务器解析所述 SIP URI以获取所述频道标识信息, 并根据该频道信息确定向网络电视终端功能播放的电视频道。
本发明实施例还提出另外一种 SIP网络中提供电视业务的方法, 可 以在 SIP网络中标识电视频道, 从而提供电视业务。
针对上述目的, 本发明实施例提出的技术方案为:
一种 SIP网络中提供电视业务的方法, 该方法包括:
电视频道标识服务器从终端侧接收包含 TV URI的 SIP URI查询请 求, 电视频道标识服务器根据 TV URI和 SIP URI的对应关系, 将对应 于 TV URI的 SIP URI发送到终端侧, 其中在所述 SIP URI中包含频道 标识信息;
网络电视应用服务器接收由终端侧发起的 SIP会话请求,在所述 SIP 会话请求中包含所述 SIP URI;
网络电视应用服务器解析所述 SIP URI以获取所述频道标识信息, 并根据该频道标识信息确定频道信息。
本发明实施例还提出另外一种 SIP网络中提供电视业务的方法, 可 以在 SIP网络中标识电视频道, 从而提供电视业务。
针对上述目的, 本发明实施例提出的技术方案为:
一种 SIP网络中提供电视业务的方法, 该方法包括:
Core IMS接收由终端侧发送的 SIP会话请求, 在所述 SIP会话请求 中包含 TV URI; Core IMS根据解析到的 TV URI向电视频道标识服务
器发送 SIP URI查询请求;
电视频道标识服务器根据 TV URI和 SIP URI的对应关系, 将对应 于 TV URI的 SIP URI发送到 Core IMS, 在所述 SIP URI中包含频道标 识信息;
Core IMS根据接收到的 SIP URI将所述 SIP会话请求路由到网络电 视应用服务器, 网络电视应用服务器解析所述 SIP URI以获取所述频道 标识信息, 并根据该频道标识信息确定向终端侧发送的频道信息。
本发明实施例还提供一种网络电视***, 用以解决现有技术中存在 用户终端无法获取指定频道信息的问题。
针对上述目的, 本实施例提出的技术方案为:
一种网络电视***, 包括终端侧和网络侧,
所述终端侧包括向网络侧发送用户指定频道的频道标识信息的模 块;
所述网络侧包括向终端侧返回所述标识信息对应的频道信息的模 块。
本发明实施例还提出一种在会话初始协议 SIP网络中提供电视业务 的***, 可以在 SIP网络中标识电视频道, 从而提供电视业务。
针对上述目的, 本发明实施例的技术方案为:
一种在会话初始协议 SIP网络中提供电视业务的***, 包括: 网络电视终端功能,用于向网络电视应用服务器发起 SIP会话请求, 在所述 SIP会话请求中包含指示频道信息的 SIP统一资源指示符 URI; 网络电视应用服务器,用于解析所述 SIP URI以获取所述频道信息, 并根据该频道信息确定向网络电视终端功能播放的电视频道。
本发明实施例还提出一种网络电视终端功能, 可以在 SIP网络中标 识电视频道, 从而实现提供的电视业务。
针对上述目的, 本实施例提出的方案为:
一种网络电视终端功能, 包括 SIP会话请求发起单元和电视信息展 现单元, 其中:
SIP会话请求发起单元, 用于向网络电视应用服务器发起 SIP会话 请求, 在所述 SIP会话请求中包含指示频道信息的 SIP URI;
电视信息展现单元, 用于接收由网络电视应用服务器根据该频道信 息确定的电视频道信息, 并展现所述电视频道信息。
本发明实施例还提出一种网络电视终端功能, 可以在 SIP网络中标 识电视频道, 从而实现提供的电视业务。
针对上述目的, 本实施例提出的方案为:
一种网络电视终端功能, 包括 SIP会话请求发起单元和电视信息展 现单元, 其中:
SIP会话请求发起单元, 用于向电视频道标识服务器发送包含 TV URI的 SIP URI查询请求, 接收由电视频道标识服务器所返回的对应于 该 TV URI的 SIP URI, 并向网络电视应用服务器发起包含 SIP URI的 SIP会话请求, 在所述 SIP URI中包含频道信息;
电视信息展现单元, 用于接收由网络电视应用服务器根据该频道信 息确定的电视频道信息, 并展现所述电视频道信息。
本发明实施例还提供一种网络电视应用服务器, 可以根据 SIP网络 中的频道标识信息, 从而实现提供的电视业务。
针对上述目的, 本实施例提出的方案为:
一种网络电视应用服务器, 包括频道信息获取单元和电视信息提供 单元, 其中:
频道信息获取单元, 用于接收 SIP会话请求, 并解析所述 SIP URI 以获取所述频道信息, 其中在所述在 SIP会话请求中包含指示频道信息
的 SIP URI;
电视信息提供单元, 用于根据该频道信息确定向网络电视终端功能 播放的电视频道, 并向所述网络电视终端功能发送所述电视频道信息。
本发明实施例还提出一种电视频道标识服务器, 其技术方案为: 一种电视频道标识服务器, 包括对应关系保存单元和 SIP URI查询 单元, 其中
对应关系保存单元, 保存有 TV URI和 SIP URI的对应关系; SIP URI查询单元, 用于接收网络电视终端功能或 Core IMS所发送 的包含 TV URI的 SIP URI查询请求,并根据 TV URI和 SIP URI的对应 关系, 将对应于该 TV URI的 SIP URI发送到所述网络电视终端功能或 Core IMS。
本发明实施例还提出一种 Core IMS, 包括 TV URI解析单元和路由 单元, 其中
TV URI解析单元,用于从网络电视终端功能接收包含有 TV URI的 SIP会话请求, 从所述 SIP会话请求中解析出 TV URI, 并向电视频道标 识服务器发送 SIP URI查询请求;
路由单元, 用于将所述 SIP会话请求路由到网络电视应用服务器, 其中在所述 SIP会话请求中包含由电视频道标识服务器响应于所述 SIP URI查询请求而返回的 SIP URL
本发明实施例还提出一种终端, 包括用于接收用户操作指令的指令 接收模块, 所述终端还包括发送所述指令接收模块指定频道的频道标识 信息的模块。
在本发明实施例中, 终端侧向网络侧发送用户指定频道的频道标识 信息, 指定所请求的频道; 网络侧向终端侧返回用户指定频道的频道标 识信息对应的频道信息。 采用本发明技术方案, 终端侧可以获取其指定
的频道的频道信息, 使用户可以根据其需要来指定其需要获取的频道; 并且, 相对于现有技术中终端侧需要获取网络侧所有的频道信息, 明显 地, 采用本发明技术方案节约了终端侧存储频道信息所需的存储空间, 这对于手机等存储空间较 '』、的终端来讲是十分有意义的。
另外,网络电视终端功能向 Core IMS发送的 SIP会话请求中包含指 示频道信息的 SIP URI; Core IMS根据解析到的 TV URI向电视频道标 识服务器发送 SIP URI查询请求, 电视频道标识服务器根据频道信息可 以确定电视频道。可见,本发明的频道标识基于 SIP URI机制,在 SIP URI 中携带有频道信息, 因此能够在 SIP网络中唯一地标识电视频道, 可以 实现在 SIP网络中提供电视业务。 附图简要说明
图 1为现有技术中的 IPTV***框图;
图 2为根据本发明较佳实施例中用户终端从应用处理模块获得频道 信息的流程图;
图 3为根据本发明实施例的 SIP网络中提供电视业务的方法流程示 意图;
图 4为根据本发明实施例的 SIP网络中请求观看缺省直播或时移动 电视频道的流程示意图;
图 5为根据本发明实施例的 SIP网络中请求观看特定频道的流程示 意图;
图 6为根据本发明实施例的 SIP网络中请求观看特定频道组的流程 示意图;
图 7为本发明实施例中的 IPTV***框图;
图 8为根据本发明实施例的 SIP网络中提供电视业务的***结构示
意图;
图 9为根据本发明较佳实施例的 SIP网络中提供电视业务的***结 构示意图;
图 10为根据本发明实施例的网络电视终端结构示意图;
图 11为根据本发明实施例的网络电视应用服务器结构示意图; 图 12为根据本发明实施例的电视频道标识服务器结构示意图; 图 13为根据本发明实施例的 Core IMS结构示意图。 实施本发明的方式
本发明的核心思想是: 终端侧向网络侧发送用户指定频道的频道标 识信息; 网络侧向终端侧返回用户指定频道的频道标识信息对应的频道 信息。
下面结合附图和实施例对本发明作进一步地说明。
在本实施例中, 用户终端和会话处理模块的接口 E1 以及会话处理 模块和应用处理模块的接口 E2可以是会话发起协议( SIP, Session Initial Protocol ), HTTP, 实时传送流媒体协议( RTSP, Real - Time Streaming Protocol ) 的接口。
为了实现 IPTV业务, 用户终端需要从应用处理模块获得必要的频 道信息。 在本发明的一个实施例中, 用户终端从应用处理模块获得频道 信息的流程如图 2所示, 包括以下步骤:
步骤 S101 , 用户终端向会话处理模块发送指定频道的频道标识信 息。
这里, 频道标识信息可以是确定的频道标识, 也可以是确定的频道 标识所对应的编号或其他信息。 比如: CCTV1为一个频道标识, 而 111 为这个频道标识对应的编号, 那么, 步骤 S101 中的频道标识信息既可
以为 CCTV1 , 也可以为 111。
步骤 S102,会话处理模块路由或转发该频道标识信息到应用处理模 块。
步骤 S103 ,应用处理模块接收到该频道标识信息后,根据该频道标 识信息获取其对应的频道信息, 并向会话处理模块返回频道标识信息及 其对应的频道信息;
步骤 S104,会话处理模块路由或转发频道标识信息及其对应的频道 信息到用户终端。
在上述流程中, 用户终端可以在发起业务请求时通过上述流程获取 指定频道的频道信息。 也就是说, 可以利用业务请求消息携带指定频道 的频道标识信息, 利用业务请求响应消息携带频道标识信息及其对应的 频道信息。
业务请求消息可以携带一个或多个频道标识信息。 在业务请求消息 携带一个频道标识信息的情况下, 应用处理模块返回的业务请求响应消 息可以不包括该频道标识信息, 而仅包括该频道标识信息对应的频道信 息。 这样, 用户终端在接收到该频道信息后, 可以明确该频道信息为用 户终端所指定频道的频道信息。 而在业务请求消息中携带多个频道标识 信息的情况下, 在业务请求响应消息中可以携带一组或多组频道标识信 息和频道信息, 从而支持如画中画, 多画面播放等的实现。
频道信息可以携带在业务请求响应消息中返回给用户终端, 比如携 带在现有的会话描述协议(SDP, Session Description Protocol )中。 而在 用户终端请求频道信息、 网络返回频道信息这个过程中; 或者, 进一步 地, 如果用户需要进行频道切换, 在用户终端请求频道切换的过程中, 在业务请求消息和业务请求响应消息中都可能需要携带频道标识信息。
方法一, 扩展 SDP的属性, 定义一个新的 SDP属性行, 并通过该 新定义的 SDP属性行来携带频道标识信息。
当用户终端和会话处理模块的接口 E1 以及会话处理模块和应用处 理模块的接口 E2采用的是 SIP, RTSP, HTTP等可以携带 SDP的协议 时, 可以通过新定义的 SDP属性行来携带频道标识信息。
在本实施例的一个实例中,采用如下语言来定义了一个新的 SDP属 性行:
a=chid:频道标识信息
在一个具体的业务请求响应消息中,使用该新的 SDP属性行携带频 道标识信息并同时在其他属性行携带频道信息以及其他信息, 描述方式 A如下:
v=0
o=ue 2890844730 2890844732 IN IP4 client.example.com
c=IN IP4 client.example.com
m=audio 65421 RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=chid:TVl
m=video 65113 RTP/AVP 31
a=rtpmap:31 MPV/90000
a=chid:TVl
上述语言第 6行通过指定频道属性对第 4、 5行描述的媒体音频加 以限定, 第 9行通过指定频道属性对第 7、 8行描述的媒体视频加以限 定, 表示如第 4行、 第 5行的媒体音频与 TV1相关, 第 7行、 第 8行的 媒体视频也与 TV1频道相关。 这里所述的第 4行、 第 5行、 第 7行、 第 8行等就可以认为是网络侧返回的频道信息。 当然, 业务请求消息中也 可以采用描述方式 A来携带频道信息, 只是不携带频道信息即可。
业务请求响应消息还可以采用描述方式 B, 具体如下:
ν=0
o=ue 2890844730 2890844732 IN IP4 client.example.com
c=IN IP4 client.example.com
a=chid:TVl
m=audio 65421 RTP/AVP 0
a=rtpmap:0 PCMU/8000
m=video 65113 RTP/AVP 31
a=rtpmap:31 MPV/90000
上述语言第 4行通过指定会话级频道属性对媒体的音频和视频加以 限定, 表示第 5行~第 8行属性行与 TV1频道相关。 同样, 这里所述的 第 5行~第 8行等也可以认为是网络侧返回的频道信息。 当然, 业务请 求消息中也可以采用描述方式 B来携带频道信息, 只是不携带频道信息 即可。
在实现 IPTV类业务, 如 LiveTV,、 TsTV等业务时, 终端在 SIP, RTSP, HTTP等协议的业务请求消息中携带包含该属性扩展的 SDP对所 请求频道进行标识; 应用处理模块在业务请求响应消息中同样携带包含 该属性扩展的 SDP对终端所请求的频道进行标识, 同时, 还通过 SDP 对频道标识信息对应的频道信息加以描述, 从而通过频道标识信息结合 SDP媒体描述的频道信息对一个频道进行完整描述。
由于 SDP可以携带在 SIP、 RTSP, HTTP等协议中, 因此方法一并 不限于某一特定协议使用。
由于在一次会话中, SDP的属性行只能增加或修改, 因此采用方法 一进行频道标识信息的携带时, 如果用户在收看某一频道的过程中要求 进行频道切换, 则可以向应用处理模块发送一个业务请求消息, 并通过 增加或修改该业务请求中携带的 SDP来通知应用处理模块,实现频道切 换, 下面描述两种实现频道切换的方式:
方式一、用户终端在业务请求消息携带的 SDP中添加目标频道的频 道标识信息属性行来标明目标频道, 并在 SDP 中标明被切换的频道关 闭, 如设置被切换的频道对应的 SDP媒体接收端口为 0来标明其关闭;
应用处理模块在该业务请求消息相应的业务请求响应消息携带的 SDP 中新增 SDP属性行描述目标频道的频道信息。
以上述描述方式 A为例, 当用户要将频道从 TV1切换到 TV2时, 用户终端发送给应用处理模块的 SDP的具体描述如下:
ν=0
o=ue 2890844730 2890844732 IN IP4 client.example.com
c=IN IP4 client.example.com
m=audio 0 RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=chid:TVl
m=video 0 RTP/AVP 31
a=rtpmap:31 MPV/90000
a=chid:TVl
m=audio 40001 RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=chid:TV2
m=video 40005 RTP/AVP 31
a=rtpmap:31 MPV/90000
a=chid:TV2
应用处理模块返回给用户终端的 SDP如下:
ν=0
o=ue 2890844730 2890844732 IN IP4 client.example.com
m=audio O RTP/AVP 0
c=IN IP4 TV 1.example.com
a=rtpmap:0 PCMU/8000
a=chid:TVl
m=video O RTP/AVP 31
c=IN IP4 TV 1.example.com
a=rtpmap:31 MPV/90000
a=chid:TVl
m=audio 65425 RTP/AVP 0
c=IN IP4 TV2.example.com
a=rtpmap:0 PCMU/8000
a=chid:TV2
m=video 65115 RTP/AVP 31
c=IN IP4 TV2.example.com
a=rtpmap:31 MPV/90000
a=chid:TV2
在采用方式一实现频道切换的情况下, 可能存在用户需要切换的目 标频道已经在 SDP中进行了描述的情况, 例如, 当将频道从 TV1切换 到 TV2后, 又要将频道从 TV2切换回 TV1 , 则用户终端可以直接将上 述 SDP修改为:
v=0
o=ue 2890844730 2890844732 IN IP4 client.example.com
c=IN IP4 client.example.com
m=audio 65421 RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=chid:TVl
m=video 65113 RTP/AVP 31
a=rtpmap:31 MPV/90000
a=chid:TVl
m=audio O RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=chid:TV2
m=video 0 RTP/AVP 31
a=rtpmap:31 MPV/90000
a=chid:TV2
并将该 SDP发送给应用处理模块,则应用处理模块可以根据该 SDP 的描述向用户终端发送 TV1的内容并停止发送 TV2的内容, 实现频道 的切换。
方式二、用户终端通过修改业务请求消息携带的 SDP中现有的频道 标识信息属性行来标明频道的修改, 如可以在业务请求消息中将现有的 a=chid:TV 1修改为 a=chid: TV 2来标明希望从 TV1切换到 TV2, 应用 处理模块在业务请求响应消息携带的 SDP 中修改频道标识信息属性行 对应的频道信息属性行来标明目标频道的频道信息, 如将 TV 1的频道 信息修改为 TV2的频道信息。
仍以上述描述方式 A为例,当用户要将频道从 TV1切换到 TV2时, 具体描述如下:
v=0
o=ue 2890844730 2890844732 IN IP4 client.example.com
c=IN IP4 client.example.com
m=audio 65421 RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=chid:TV2
m=video 65113 RTP/AVP 31
a=rtpmap:31 MPV/90000
a=chid:TV2
在采用方式二实现频道切换的情况下, 也可能存在用户需要切换的 目标频道已经在 SDP中进行了描述的情况, 例如, 用户终端在第一次请 求频道标识信息时, 请求了 TV1和 TV2的频道标识信息, 之后关闭了 TV2, 即只剩下 TV1 , 然后又进行 TV1到 TV2的切换。 此时, 用户终 端只需要根据情况修改 SDP并发送给应用处理模块,则应用处理模块可 以根据该 SDP的描述向用户终端发送 TV2的内容并停止发送 TV1的内 容, 实现频道的切换。
在同时接收多个频道的节目时, 如果用户希望关闭指定频道, 则终 端可以通过在业务请求消息携带的 SDP中标明指定频道关闭,如设置指 定频道对应的 SDP媒体接收端口为 0来标明其关闭。应用处理模块在接 收到该业务请求消息后, 停止向用户终端发送指定频道的内容, 从而实 现指定频道的关闭。
方法二, 定义新的 SIP头域, 并通过该新定义的 SIP头域携带频道 标识信息;
当用户终端和会话处理模块的接口 E1 以及会话处理模块和应用处 理模块的接口 E2采用 SIP协议实现时, 可以定义新的 SIP头域, 并通 过该新定义的 SIP头域携带频道标识信息。
在本实施例的一个实例中, 采用 BNF语法新定义如下 SIP头域:
Channel = "Channel" HCOLON l*(chld) *(SEMI chid_parm)
chid = ["chid" EQUAL] ch-value
ch-value = token I quoted-string
chid_parm = generic-param
在实现 IPTV类业务, 如 LiveTV、 TsTV等业务时, 终端通过在采 用 SIP协议的业务请求消息中携带该头域对所请求频道进行标识; 在应 用处理模块的业务请求响应消息中同样携带该头域, 并且该业务请求响 应消息中还同时在 SIP中携带 SDP对频道信息加以描述,两者结合对一 个频道进行完整描述。
在具体在业务请求消息和业务请求响应消息中使用该新定义的 SIP 头域携带频道标识信息时, 可以采用如下形式:
Channel: chld=cctvl
或者
Channel: cctvl
或者
Channel: "cctvl"
上述各种形式都可以用于指示业务请求消息或者业务请求响应消 息与频道 cctvl相关。
在业务请求响应消息中, 方法二中新定义的 SIP头域可以和方法一 中属性扩展了的 SDP配合使用,也可以和非扩展的 SDP, 即之前没有扩 展属性行的 SDP配合使用, 其中:
当方法二中新定义的 SIP头域和非扩展的 SDP配合使用时,用户终 端在接收到该业务请求响应消息后,将该非扩展的 SDP所包括的全部媒 体描述内容都作为该 SIP头域所指示的频道相关的媒体描述内容;
当方法二中新定义的 SIP头域和方法一中属性扩展了的 SDP配合使 用时, 用户终端在接收到该业务请求响应消息后, 将 SIP头域所包括的
频道标识信息和 SDP所包括的媒体描述内容进行匹配,则 SDP中与 SIP 头域所包括的频道标识信息相匹配的扩展属性行所对应的频道信息为 指定的频道信息, 其它描述信息可以独立于频道信息而存在。 在这种情 况下, 用户终端需要进行频道切换时,在 SDP中可以不标明被切换的频 道关闭, 只需要令 SIP头域中不包括被切换的频道或被关闭的频道的标 识信息即可。 也就是说, 如果终端侧需要频道切换, 终端侧将业务请求 消息发送给网络侧, 业务请求消息中新扩展的 SIP头域不包括被切换频 道的频道标识信息;网络侧将接收到的消息中的新定义的 SDP属性行与 所述新扩展的 SIP头域或 SIP头域中新扩展的参数进行匹配, 将相匹配 的频道标识信息作为用户指定的切换目标频道的频道标识信息。
以 SIP头域中携带的频道标识信息为 TV2,而 SIP携带的 SDP中的 描述如下进行说明:
v=0
o=ue 2890844730 2890844732 IN IP4 client.example.com
c=IN IP4 client.example.com
m=audio 65422 RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=chid:TVl
m=video 65113 RTP/AVP 31
a=rtpmap:32 MPV/90000
a=chid:TVl
m=audio 65425 RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=chid:TV2
m=video 65115 RTP/AVP 31
a=rtpmap:31 MPV/90000
a=chid:TV2
此时, 根据 SIP头域中携带的频道标识信息 TV2和 SDP所包括的 媒体描述内容进行匹配, 则可知 TV2指定的描述信息为:
m=audio 65425 RTP/AVP 0
a=rtpmap:0 PCMU/8000
m=video 65115 RTP/AVP 31
a=rtpmap:31 MPV/90000
方法三, 通过扩展 SIP头域中的参数来携带频道标识信息; 当用户终端和会话处理模块的接口 E1 以及会话处理模块和应用处 理模块的接口 E2采用 SIP协议实现时, 可以通过扩展 SIP头域中的参 数来携带频道标识信息。
在本实施例的一个实例中, 扩展 SIP协议的 Accept-Contact头域中 的通用参数 generic-param来进行频道标识信息。
对 generic-param参数的现有 BNF语法定义 口下:
generic-param = token [ EQUAL gen-value ]
gen-value = token I host I quoted-string
在该实例中, 按照 generic-param参数语法, 在 generic-param参数 中增加频道标识信息的定义, 频道标识信息可以采用形式如下:
chId=TV 1 , chId=TV2, ... , chId=TVn
或者
chld= "TV1", chld= "TV2", ... , chld= "TVn"
或者
TV1, TV2, ... , TVn
或者
"TV1", "TV2", ... , "TVn"
在实现 IPTV类业务, 如 LiveTV、 TsTV等业务时, 终端通过在采 用 SIP协议的业务请求消息中携带 Accept-Contact 头域中的通用参数 generic- param对所请求频道进行标识; 在应用处理模块的业务请求响应 消息中同样携带该 Accept-Contact头域中的通用参数 generic-param , 并 且该业务请求响应消息中还同时在 SIP 中携带 SDP对频道信息加以描 述, 两者结合对一个频道进行完整描述。
在具体在业务请求消息和业务请求响应消息中利用 Accept-Contact
头域中的通用参数 generic-param携带频道标识信息时,可以采用如下形 式:
Accept-Contact: *; chld= "TV1"
或者
Accept-Contact: *; TV1;
上述各种形式都可以用于指示业务请求消息或者业务请求响应消 息与频道 TV1相关。
在业务请求响应消息中, 方法三中扩展了的 SIP头域中的参数可以 和方法一中属性扩展了的 SDP配合使用, 也可以和非扩展的 SDP配合 使用, 其中:
当方法三中 SIP头域中扩展了的参数和非扩展的 SDP配合使用时, 用户终端在接收到该业务请求响应消息后,将该非扩展的 SDP所包括的 全部媒体描述内容都作为该 SIP头域中扩展的参数所指示的频道相关的 媒体描述内容;
当方法三中 SIP头域中扩展了的参数和方法一中属性扩展了的 SDP 配合使用时, 用户终端在接收到该业务请求响应消息后, 将 SIP头域中 扩展了的参数所包括的频道标识信息和 SDP 所包括的媒体描述内容进 行匹配,则 SDP中与 SIP头域中扩展了的参数所包括的频道标识信息相 匹配的扩展属性行所对应的频道信息为指定的频道信息, 其它描述信息 可以独立于频道信息而存在。 与方法二类似, 在这种情况下, 用户终端 需要切换时, 在 SDP中可以不标明被切换的频道关闭, 只需要令 SIP头 域中扩展的参数中不包括被切换的频道或被关闭的频道的标识信息即 可。 也就是说, 如果终端侧需要频道切换, 终端侧将业务请求消息发送 给网络侧, 业务请求消息 SIP头域中新扩展的参数不包括被切换频道的 频道标识信息;网络侧将接收到的消息中的新定义的 SDP属性行与所述
SIP 头域中新扩展的参数进行匹配, 将相匹配的频道标识信息作为用户 指定的切换目标频道的频道标识信息。
方法四, 通过消息体来携带频道标识信息;
当用户终端和会话处理模块的接口 E1 以及会话处理模块和应用处 理模块的接口 E2采用的是 SIP, RTSP, HTTP等协议时, 在业务请求消 息及其业务请求响应消息中, 可以通过 SIP, RTSP, HTTP等消息体来 携带频道标识信息,消息体可以采用文本方式, XML ( extensible Markup Language, 扩展标识语言)编码方式或者其它编码方式。
在本实施例的一个实例中, 在业务请求消息及其业务请求响应消息 中, 采用 XML Schema (模式) 定义频道标识信息, 下面给出其中一种 具体定义频道标识信息的语言, 在具体定义时可能存在多种变化:
<?xml version=" 1.0" encoding="UTF-8"?>
<xs: schema targetNamespace="urn:ietf:params:xml:ns:chid"
xmlns="urn:ietf:params:xml:ns:chid"
xmlns:xs="http://www. w3.org/2001/XMLSchema" elementFormDefault="qualified">
<xs: element name= ' ' chidli st " >
<xs:complexType>
<xs:sequence>
<xs: element name="chid"
minOccurs:" 1 " maxOccurs= ' ' unbounded " />
<xs: attribute name="id" type="xs:string" use="required'7〉
</xs:sequence>
</xs:complexType>
</xs:schema>
在实现 IPTV类业务, 如 LiveTV、 TsTV等业务时, 终端通过在采 用 SIP, RTSP, HTTP等协议的业务请求消息的消息体中通过文本方式, XML 编码方式或者其它编码方式对所请求频道进行标识; 同样地, 在 应用处理模块的业务请求响应消息的消息体中通过文本方式, XML 编
码方式或者其它编码方式对所请求频道进行标识, 并且该业务请求响应 消息中还同时在 SIP, RTSP, HTTP等中携带 SDP对频道信息加以描述, 两者结合对一个频道进行完整描述。
以下给出一个采用 XML编码方式在 SIP消息体携带频道标识信息 的实例。 XML编码的体(Body )使用上述定义规则, 指示业务请求与 TV1频道相关。
<?xml version=" 1.0" encoding="UTF-8"?>
<chidlist xmlns= ' ' urn: ietf: params: xml: ns : chid ' '
xmlns:xsi="http:〃 www.w3.org/2001/XMLSchema-instance"〉
<chid id=TVl/〉
</chidlist>
在业务请求响应消息中, 方法四中携带频道标识信息的消息体可以 和方法一中属性扩展了的 SDP配合使用, 也可以和非扩展的 SDP配合 使用, 其中:
当方法四中携带频道标识信息的消息体和非扩展的 SDP 配合使用 时, 用户终端在接收到该业务请求响应消息后,将该非扩展的 SDP所包 括的全部媒体描述内容都作为该消息体所指示的频道相关的媒体描述 内容;
当方法四中携带频道标识信息的消息体和方法一中属性扩展了的 SDP配合使用时, 用户终端在接收到该业务请求响应消息后, 将消息体 所包括的频道标识信息和 SDP所包括的媒体描述内容进行匹配,则 SDP 中与消息体所包括的频道标识信息相匹配的扩展属性行所对应的频道 信息为指定的频道信息, 其它描述信息可以独立于频道信息而存在。 与 方法二类似, 在这种情况下, 用户终端需要切换时, 在 SDP中可以不标 明被切换的频道关闭, 只需要令消息体中不包括被切换的频道或被关闭 的频道的标识信息即可。
方法五, 通过 SIP消息的事件包携带频道标识信息。
当用户终端和会话处理模块的接口 E1 以及会话处理模块和应用处 理模块的接口 E2采用 SIP协议实现时, 可以在 SIP消息的事件包中定 义一个频道描述信息事件包, 并通过该事件包携带频道标识信息。
在本实施例的一个实例中, 在 SIP消息的事件包中定义一个频道描 述信息事件包, 命名为事件包类型为 "channel information", 并通过事 件包的参数来携带频道标识信息、 和 /或组播地址和端口, 和 /或其他频 道参数。
在实现 IPTV类业务, 如 LiveTV、 TsTV等业务时, 终端可以通过 在订阅 ( subscribe )请求中对所请求频道进行标识, 请求网络侧以通知 ( notify )方式发送指定频道的频道信息; 在该请求中为了指示网络侧返 回特定的频道信息,其中需要携带按频道标识信息 chid进行事件包信息 过滤的过滤条件, 这可以通过现有的过滤条件指示技术或对其进行增强 加以满足。 应用处理模块则以通知(notify )方式响应用户请求, 在其中 携带该事件包对用户所请求的频道进行描述, 相应的事件包中包含明确 的频道指示。
采用本方法来实现频道标识信息的传递时, 用户终端需要关闭频道 时, 通过在退订( unsubscribe )请求中对需要关闭的频道进行标识来关 闭相应的频道; 用户终端需要切换频道时, 通过在退订请求中对被切换 的频道进行标识来关闭被切换的频道, 并在订阅请求中对切换目标频道 进行标识来实现频道的切换。
综上可知, 在采用 SIP协议时, 使用 INVITE, relnvite, INFO, SUBSCRIBER, NOTIFY, MESSAGE, ACK ( Acknowledgement, 确认 应答)等在业务过程中进行业务的更改或者进行中间信息的传递, 可以 采用上述方法一至方法四来进行频道标识信息, 以采用 INVITE进行业
务请求为例, 在 INVITE中携带频道标识信息, 而业务请求响应消息可 以是对 INVITE的 183中间响应, 也可以是 200 Ok, 但其中都携带频道 标识信息及其相应的频道信息。
而业务请求也可以采用 RTSP或 HTTP协议,在采用 RTSP或 HTTP 协议时, 可以使用 RTSP的描述(DESCRIBE ) 消息或者 HTTP的获取 ( GET )消息向应用处理模块请求频道信息, 在 RTSP的 DESCRIBE消 息或者 HTTP的 GET消息中可以采用上述方法一或方法四来进行频道标 识信息。应用处理模块则可以在 RTSP或者 HTTP响应消息中,如 200 ok 中向用户返回频道信息和频道标识信息, 其中同样可以采用上述方法一 或方法四来进行频道标识信息。
方法六, 通过 SIP统一资源指示符 (URI ) 来携带频道标识信息。 实际应用中,可以通过扩展 URI参数或 user类型在 SIP URI中包含 指示频道标识信息。 指示频道标识信息可以包括: 频道 /频道组的名称和 /或频道编号、频道类型、频道组的成员频道信息以及业务提供商等信息。
比如, 可以新增一个 URI参数, 比如" tv", 而且该新增加的 URI参 数形式不限, 用于标识本 SIP URI为电视频道标识, 参考格式( 1 ): 格式 ( 1 ): sip: user@host:port;tv;
或者, 也可以新增一个 user类型, 通过 user类型, SIP实体能够确 定网络电视终端功能正请求的播放电视频道, 参考格式(2 ):
格式 ( 2 ): sip: user@host:port;user=tv。
基于上述定义的格式, 可以采用无频道信息表示缺省频道, 即由网 络确定特定频道。 提供 TV业务的网络电视应用服务器 102根据本地策 略或用户相关数据来决定用户请求的频道。
缺省频道的确定方法包含但不限于以下方式:
A、 采用网络电视应用服务器 102的缺省频道或主频道(即 TV
业务提供商的主频道)作为缺省频道;
B、 采用记录的用户前次观看的频道或用户设置的开机频道
(即用户每次开机都从该频道开始观看)作为缺省频道。 基于上述格式(1 )和格式(2 ), 缺省频道的标识举例如下: sip:wqed.org;tv或者
sip:wqed.org;user=tv
基于上述定义的( 1 )和格式( 2 ), 特定频道或频道组的标识方法可 以: ¾口下:
SIP URI 中所包含的特定频道标识信息可以包含特定频道名称或特 定频道编号、 特定频道组名称或特定频道组编号。 可能包含但不限于以 下几种情况:
( 1 )、 包含特定频道标识信息 (含特定频道编号和 /或特定频道名 称);
( 2 )、 包含特定频道标识信息 (含特定频道编号和 /或特定频道名 称), URI参数包含该特定频道归属的频道组信息;
( 3 )、 包含特定频道组标识信息(包含特定频道组名称和 /或特定频 道组编号)。
比如:网络电视应用服务器 102提供的频道编号为 1023的电视频道 或频道组, 举例如下::
sip: 1023 @ wqed.org; tv或
sip: 1023 @ wqed.org ;user=tv
以上虽然具体描述了通过扩展 URI参数和 user类型来标识电视频道 的方式, 还可以通过扩展其它 URI参数来携带频道其他参数。 所述频道 其他参数包含但不限于业务提供商信息、 频道类型 (如直播频道或时移 频道)和频道属性(如是否支持 TrickMode属性)等其它参数。使用 user
部分描述缺省频道、 特定频道和频道组的方法可以有 ^艮多, 本发明实施 例对具体实施方法不做任何限制。
比如: 标识某频道是否具有 "是否支持 TrickMode操作"属性, 标识 方法举例: ¾口下:
sip: 1023 @ wqed.org ;tv;trickMode ; 或
sip: 1023 @wqed.org;user=tv;trickMode
当前基于 IP互联网的电视***中, 常采用 TV URI格式的频道标识 方法, 在电子节目单( EPG )或 Web页面中包含 TV URI标识的电视频 道(直播频道或时移频道)。
在基于 RFC2838定义的 TV URI机制中, "broadcast"部分为 DNS域 名类型的标识符, 不具有路由功能。 当 tv URI为缺省频道描述格式时, 转化后的标识 TV频道的 SIP URI不包含频道信息。 举例如下:
tv URI为: <tv:wqed.org> (描述 WQED电视频道 )
转化后 SIP URI为:
SIP URI: <sip: wqed.org @example.com;user=tv;>^
<sip: wqed.org @ example. com;tv; >
或者, 在 SIP信令中直接使用 tv URI。 当 ITF发起 SIP会话时, 在 Request-URI/To头域中直接包含 TV URI。 Core IMS收到 SIP会话请求 后, 向电视频道标识服务器查询 TV URI对应的标识电视频道的 SIP URI,然后 IMS Core根据 SIP URI路由 SIP信令到提供电视业务的 IPTV AS。
另外, 还可以采用 SIP协议现有头域或头域参数(或扩展头域或头 域参数)携带缺省 (或当前)频道标识信息。 还可采用 XML消息的方 式携带频道组及成员信息, 如定义一种内容类型:
Content-Type: application/tv-package-list
XML消息体举例为:
<package package-id="sip:packagel @ tvserver.com";
<entry channel^" sip: channel 1 @ tvserver.com"/>
<entry channel="sip: channel2 @ tvserver.com"/>
</package>
针对方法六携带频道标识信息的方案, 假设用户终端为网络电视终 端功能( IPTV Terminal Function, ITF ), 网络侧的应用处理模块为网络 电视应用服务器(IPTV AS )。 在这种情况下, 下面用几个较佳实施例进 一步进行详细描述。
图 3为根据本发明实施例的 SIP网络中提供电视业务的方法流程示 意图。 如图 3所示, 该方法包括:
步骤 301: 网络电视终端功能向网络电视应用服务器发起 SIP会话 请求, 在所述 SIP会话请求中包含指示频道标识信息的 SIP URI;
步骤 302: 网络电视应用服务器解析所述 SIP URI以获取所述频道 标识信息, 并根据该频道标识信息确定向网络电视终端功能播放的电视 频道。
这里所述确定的电视频道其实就是确定了频道信息。 当然, 当网 络电视应用服务器确定了频道信息之后,还可以将频道信息返回给网 络电视终端功能。
基于上述流程, 在一种具体实现方式中, 网络电视终端功能向电 视频道标识服务器发送 SIP URI查询请求, 电视频道标识服务器根据 TV URI和 SIP URI的对应关系,将对应于 TV URI的 SIP URI发送到 网络电视终端功能, 其中在所述 SIP URI中包含频道标识信息; 然后 网络电视终端功能向网络电视应用服务器发起 SIP会话请求,在所述 SIP会话请求中包含所述 SIP URI;网络电视应用服务器解析所述 SIP
URI以获取所述频道标识信息,并根据该频道标识信息确定向网络电 视终端功能播放的电视频道。
在另外一种具体实现方式中, 网络电视终端功能向 Core IMS发 送 SIP会话请求, 在所述 SIP会话请求中包含 TV URI; Core IMS根 据解析到的 TV URI向电视频道标识服务器发送 SIP URI查询请求; 电视频道标识服务器根据 TV URI和 SIP URI的对应关系, 将对应于 TV URI的 SIP URI发送到 Core IMS; Core IMS根据接收到的 SIP URI 将所述 SIP会话请求路由到网络电视应用服务器, 网络电视应用服务 器解析所述 SIP URI以获取所述频道标识信息, 并根据该频道标识信 息确定向网络电视终端功能播放的电视频道。
图 4为根据本发明实施例的 SIP网络中请求观看缺省直播或时移动 电视频道的流程示意图。
如图 4所示, 该方法包括:
步骤 401 : 网络电视终端向 Core IMS 实体发送 INVITE请求, Request-URI为提供 TV业务的 IPTV应用服务器实体的 SIP URI信息, 参数 User为 "tv"类型或包含" tv"参数。
这里所述的 Core IMS实体就是会话处理模块。
步骤 402: Core IMS实体按照现有 SIP协议的路由规则将 INVITE请 求路由到 IPTV应用服务器。
步骤 403: IPTV应用服务器收到 INVITE请求后解析 Request-URI, 判断为缺省频道标识的会话请求, 业务授权通过(200 OK消息), 然后 IPTV应用服务器根据本地策略和 /或用户数据确定用户当前观看的频 道, 并向用户返回该当前频道的媒体描述信息 (SDP offer )、 缺省频道 信息、 缺省频道对应的频道组信息和其他成员频道的相关信息。
步骤 404:Core IMS将 IPTV应用服务器的响应消息转发到网络电视
终端。
步骤 405: 网络电视终端收到响应消息后,保存响应消息中包含的信 息, 并根据终端能力向 Core IMS返回当前频道的媒体描述应答( SDP Answer ) 消息。
步骤 406:Core IMS转发网络电视终端的媒体描述应答消息到 IPTV 应用服务器。
步骤 407: 网络电视终端根据媒体协商结果向多播控制点发送加入 多播组报告。
步骤 408:多播控制点向网络电视终端发送多播媒体流。
图 5为根据本发明实施例的 SIP网络中请求观看特定频道的流程示 意图。 如图 5所示, 该方法包括:
步骤 501: 网络电视终端实体发送 INVITE请求到 Core IMS实体, Request-URI为提供 TV业务的 IPTV应用服务器实体的 SIP URI信息, 参数 User为" tv"类型或包含" tv"参数, 在 User部分包含具体的特定频道 信息, 如特定频道编码或频道名称。
步骤 502:Core IMS实体按照现有 SIP协议的路由规则将 INVITE请 求路由到 IPTV应用服务器。
步骤 503: IPTV应用服务器收到 INVITE请求后,解析 Request-URI, 判断为特定频道标识的会话请求, 业务授权通过, 然后 IPTV应用服务 器确定用户当前观看的频道。 IPTV应用服务器向用户返回当前频道的 媒体描述信息 (SDP offer )、 特定频道标识信息、 特定频道对应的频道 组标识信息和其他成员频道的相关信息。
步骤 504:Core IMS转发 IPTV应用服务器的响应消息到网络电视终 端。
步骤 505: 网络电视终端收到响应后,保存响应中包含的信息,并根
据终端能力返回向 Core IMS当前频道的媒体描述应答( SDP Answer ) 消息。
步骤 506: Core IMS转发网络电视终端的媒体描述应答消息到 IPTV 应用服务器。
图 6为根据本发明实施例的 SIP网络中请求观看特定频道组的流程 示意图。
如图 6所示, 该方法流程包括:
步骤 601: 网络电视终端实体发送 INVITE请求到 Core IMS实体, Request-URI为提供 TV业务的 IPTV应用服务器实体的 SIP URI信息, 参数 User为" tv"类型或包含" tv"参数, 在 User部分包含特定频道组标识 信息, 如特定频道组编码或频道组名称;
步骤 602:Core IMS实体按照现有 SIP协议的路由规则将 INVITE请 求路由到 IPTV应用服务器。
步骤 603: IPTV应用服务器收到 INVITE请求后,解析 Request-URI, 判断为特定频道组标识的会话请求, 业务授权通过, 然后 IPTV应用服 务器确定用户当前观看的频道组。 IPTV应用服务器可采用下述方式中 的任一种确定当前频道: 采用网络电视应用服务器设置的频道组内缺省 频道为当前频道; 或采用用户前次观看的该频道组内的频道为当前频 道; 或采用用户设置的频道组内缺省频道为当前频道。 IPTV应用服务 器向用户返回当前频道的媒体描述信息 (SDP offer )、 特定频道组信息 和其他成员频道的相关信息。
另一种可选方式是 IPTV应用服务器不确定用户初始观看的电视频 道, 由用户根据成员频道信息选择初始观看的电视频道。
步骤 604:Core IMS转发 IPTV应用服务器的响应消息到网络电视终 端。
步骤 605: 网络电视终端收到响应后,保存响应中包含的信息,并根 据终端能力返回向 Core IMS当前频道的媒体描述应答( SDP Answer ) 消息。
步骤 606: Core IMS转发网络电视终端的媒体描述应答消息到 IPTV 应用服务器。
图 2~图 6都是 IPTV业务的方法实施例。 针对这些方法实施例, 本 发明实施例还提供一种 IPTV***。 如图 7所示, IPTV***可以包括终 端侧和网络侧, 其中:
终端侧包括向网络侧发送用户指定频道的频道标识信息的模块; 网络侧包括向终端侧返回用户指定频道的频道标识信息对应的频 道信息的模块。
其中, 作为终端侧的用户终端包括用于接收用户操作指令的指令接 收模块, 还包括以下三个模块:
发送指令接收模块指定频道的频道标识信息的模块;
发送指令接收模块指定关闭的频道对应的频道标识信息的模块; 发送指令接收模块指定的切换目标频道对应的频道标识信息的模 块。
上述三个模块的功能都可以是由如图 7所示的控制模块实现的。 当 然上述三个模块也可以是三个独立的模块或其他组合形式。
如图 7所示, 网络侧包括应用处理模块和会话处理模块, 其中: 会话处理模块在终端侧和应用处理模块之间转发频道标识信息和 频道信息;
应用处理模块, 包括用于接收信息的接收模块, 还包括以下两个模 块:
根据接收模块接收到的频道标识信息发送该标识信息对应的频道
信息的模块;
根据接收模块接收到的切换目标频道对应的频道标识信息, 发送对 应的切换目标频道的频道信息的模块。
上述两个模块的功能都可以是由如图 7所示的处理模块实现的。 当 然上述两个模块也可以是两个独立的模块或其他组合形式。
实际应用中,所述用户终端可以为网络电视终端功能( IPTV Terminal Function , ITF ), 网络侧的应用处理模块可以为网络电视应用服务器 ( IPTVAS )„ 在这种情况下, 该***结构示意图可以用图 8来表示。
如图 8 所示, 该***包括网络电视终端功能 ( IPTV Terminal Function, ITF ) 101和网络电视应用服务器(IPTV AS ) 102。
网络电视终端功能 101 , 用于向网络电视应用服务器 102发起 SIP 会话请求, 在所述 SIP会话请求中包含指示频道信息的 SIP URI;
网络电视应用服务器 102, 用于解析所述 SIP URI以获取所述频道 信息,并根据该频道信息确定向网络电视终端功能 101播放的电视频道。
当然, 在图 8中还应该包括相当于会话处理模块的实体, 这里并没 有画出。 如果会话处理模块为 IMS核心 (Core IMS ), 并进一步增加一 个电视频道标识服务器, 该***的结构示意图可以用图 9表示。
如图 9所示,该***包括 IPTV终端 201、 IPTV应用服务器 202、 IMS 核心 (Core IMS ) 203和电视频道标识服务器 204。
IPTV终端 201为用户观看电视业务的 IPTV终端,它支持 SIP协议, 充当 SIP用户设备角色, 通过 IMS核心 203的路由向提供电视业务的 IPTV应用服务器 202请求电视业务。
通常情况下, 用户可对 IPTV终端 201进行设置, 每次开机后, 自 动观看缺省频道或上一次观看的频道。这种情况下,当用户开机后, IPTV 终端 201 自动发起 SIP会话, 发送的 INVITE请求的 Request-URI头域
中包含指示请求缺省频道式的 SIP URL
当用户观看直播电视节目 (LTV ) 时, 通过电子节目单 (EPG )选 择特定的直播频道或直播频道组并点击, IPTV终端 201发起 SIP会话, 发送的 INVITE请求的 Request-URI头域中包含指示特定频道标识或频 道组标识的 SIP URL
IPTV终端 201收到初始 INVITE请求的可靠临时响应或成功响应 后, 可以加入当前频道对应的 IP多播组。
在电视频道标识服务器 204中, 保存有 TV URI与 SIP URI的对应 关系。 在会话过程中, IPTV终端 201 可以通过与电视频道标识服务器 204的 Q1接口直接向电视频道标识服务器 204查询与 TV URI对应的标 识频道的 SIP URL
IPTV终端 201通过 Q1接口直接查询 SIP URI的过程具体包括: IPTV 终端 201向电视频道标识服务器 204发送 SIP URI查询请求, 电视频道 标识服务器 204根据 TV URI和 SIP URI的对应关系,将对应于 TV URI 的 SIP URI发送到 IPTV终端 201 , 然后 IPTV终端 201通过 IMS核心 所返回的 SIP URI的 SIP会话请求, IPTV应用服务器 202解析该 SIP URI 以获取所述频道标识信息,并根据该频道标识信息确定向 IPTV终端 201 播放的电视频道。 此后, IPTV应用服务器 202可以将确定的频道信息 返回给 IPTV终端 201。
电视频道标识服务器 204还可以通过与 IMS核心 203之间的 Q2接 口向 IMS核心 203或其他实体提供 TV URI的查询接口。 IMS核心 203 提供信令路由、会话控制和业务触发等功能。如果 IMS核心 203从 IPTV 终端 201收到包含 TV URI的 SIP会话请求, 则 IMS核心 203通过 Q2 接口查询该 TV URI对应的 SIP URI, 然后根据查询获得的 SIP URI将
IPTV终端 201发起的 SIP会话请求路由到 IPTV应用服务器 202。
IPTV应用服务器 202为提供电视业务的应用服务器,如提供直播电 视业务( LTV )、 按需内容业务( Content On Demand )等业务。 IPTV应 用服务器 202收到 INVITE请求后, 解析 Request-URI头域中携带的频 道信息。
在图 9所示实施例的 SIP网络中,具体采用 IMS核心 203来路由 SIP 会话请求到 IPTV应用服务器 202。 实际上, 本发明并不局限于此。 本 领域技术人员可以意识到, 只要是在 SIP网络中具有 SIP会话请求路由 功能的实体都适用于本发明, 而且 IPTV终端 201还可以通过 SIP协议 直接与 IPTV应用服务器 202执行交互功能。
如果 Request-URI头域不包含频道标识信息, 则认为 IPTV终端 201 请求缺省频道。 IPTV应用服务器 202根据本地业务规则或策略确定当 前给用户播放的频道。 IPTV应用服务器 202确定缺省频道后, 在 SIP 响应消息 SDP消息体中包含频道对应的媒体描述信息(SDP Offer ), 并 可在 SIP可靠临时响应或成功响应消息中包含该缺省频道对应的频道组 信息、 频道组标识和其它成员频道的信息。
如果 Request-URI头域包含特定频道标识信息或频道组标识信息, IPTV应用服务器 202根据本地策略或业务逻辑解析频道标识信息, 确 定 IPTV终端 201请求的特定频道或频道组。 如果是频道组标识则根据 上述缺省频道确定方法确定当前频道。 IPTV应用服务器 202可以在 SIP 可靠临时响应或成功响应消息中包含当前频道的媒体描述信息、 频道组 标识和其它成员频道信息。
应用本发明实施例以后, 频道标识信息能够在 SIP网络中标识缺省 电视频道、 特定电视频道和电视频道组。 所述 SIP 网络包括但不限于 NGN/IMS/IMS Based IPTV等网络。
基于上述分析, 本发明实施例还提出了一种网络电视终端和网络电 视应用服务器。
图 10为根据本发明实施例的网络电视终端结构示意图。
如图 10所示,该网络电视终端包括 SIP会话请求发起单元 701和电 视信息展现单元 702。 其中:
SIP会话请求发起单元 701 ,用于向网络电视应用服务器发起 SIP会 话请求, 在所述 SIP会话请求中包含指示频道标识信息的 SIP URI; 电视信息展现单元 701 , 用于接收由网络电视应用服务器根据该频 道标识信息确定的电视频道信息, 并展现所述电视频道信息。
可选地, SIP会话请求发起单元 701 ,用于向电视频道标识服务器发 送包含 TV URI的 SIP URI查询请求, 接收由电视频道标识服务器所返 回的对应于该 TV URI的 SIP URI, 并向网络电视应用服务器发起包含 SIP URI的 SIP会话请求, 在所述 SIP URI中包含频道标识信息; 此时 电视信息展现单元 701 , 用于接收由网络电视应用服务器根据该频 道标识信息确定的电视频道信息, 并展现所述电视频道信息。
图 11为根据本发明实施例的网络电视应用服务器结构示意图。 如图 11 所示, 该网络电视应用服务器包括频道标识信息获取单元 801和电视信息提供单元 802, 其中:
频道标识信息获取单元 801 ,用于接收包含指示频道标识信息的 SIP URI的 SIP会话请求, 并解析所述 SIP URI以获取所述频道标识信息; 电视信息提供单元 802, 用于根据该频道标识信息确定向网络电视 终端功能播放的电视频道, 并向所述网络电视终端发送所述电视频道信 息。
本发明实施例还提出了一种电视频道标识服务器。
图 12为根据本发明实施例的电视频道标识服务器结构示意图。 如图
12所示, 电视频道标识服务器包括对应关系保存单元 901和 SIP URI查 询单元 902, 其中
对应关系保存单元 901 , 保存有 TV URI和 SIP URI的对应关系;
SIP URI查询单元 902, 用于接收网络电视终端功能或 Core IMS所 发送的包含 TV URI的 SIP URI查询请求, 并根据 TV URI和 SIP URI 的对应关系, 将对应于该 TV URI的 SIP URI发送到所述网络电视终端 功能或 Core IMS。
本发明实施例还提出了一种 Core IMS。 图 10为根据本发明实施例 的 Core IMS结构示意图。
如图 13所示,该 Core IMS包括 TV URI解析单元 1001和路由单元 1002, 其中
TV URI解析单元 1001 , 用于从网络电视终端功能接收包含有 TV URI的 SIP会话请求,从所述 SIP会话请求中解析出 TV URI, 并向电视 频道标识服务器发送 SIP URI查询请求;
路由单元 1002, 用于将所述 SIP会话请求路由到网络电视应用服务 器, 其中在所述 SIP会话请求中包含由电视频道标识服务器响应于所述 SIP URI查询请求而返回的 SIP URI。
综上所述, 由于网络电视终端功能向应用服务器发送的 SIP会话请 求中包含指示频道标识信息的 SIP URI,应用服务器能够根据该 SIP URI 确定频道标识信息, 因此本发明实施例的频道标识能够在 SIP网络中标 识缺省电视频道、 特定电视频道和电视频道组。 而且本发明实施例的频 道标识能够在广泛的 SIP网络中唯一地标识一个电视频道或一个电视频 道集。 并且 SIP实体能够根据频道标识路由 SIP信令到其他特定的 SIP 实体。
同时本发明还能够在 IMS Based IPTV***中如下直播电视业务中
得到应用:
在目前 TISPAN定义的 IMS based IPTV***中对直播业务的标识采 用业务包的概念进行描述,即用户订阅或签约直播业务时订阅 /签约的是 一个业务包, 请求直播业务时也是向该业务包发起请求, 由于一个业务 包可以包括若干个频道,此时有可能 IMS based IPTV网络侧无法确切知 道用户当前或初始想要观看的频道, 而无法对网络带宽资源进行预留, 或者有可能所预留的网络带宽资源和用户观看的频道所需要的网络资 源不匹配, 结果导致或者用户的带宽需求不能满足, 影响客户体验, 或 者预留带宽过多, 浪费网络带宽资源。
针对上述问题, 可以有如下几种解决方案:
1 )用户向 IPTV***请求观看直播电视, 在请求消息中指明请求的 业务包的同时, 同时携带具体电视频道信息, 该具体电视频道信息可以 是用户从业务选择功能(SSF )上获取的、 也可以是用户终端初始设定 或记录的上次退出时观看的频道信息、 或其它方式获取, 也可以在携带 具体电视频道业务标识信息时,和 /或同时指明频道组(即业务包)标识, 业务建立过程中, IPTV 网络根据业务包的签约信息对用户的访问进行 授权, 根据所携带的具体频道业务标识信息进行资源预留, 业务建立成 功后, 终端加入用户指定的电视频道。 图 5所述的方法能够提供直播电 视业务的本场景。
2 )用户向 IPTV***请求观看直播电视, 如果在请求消息中不指明 具体电视频道但包含频道组信息, 或不指明具体频道和电视频道组, 则 由 IPTV***确定用户初始观看的电视频道, 确定方式可以是根据用户 在签约数据中设置的节目偏好、 或者是根据用户前期的节目观看统计导 出的用户观看习惯等, 确定一个合适的频道作为用户观看直播业务的初 始频道, 然后 IPTV***在请求响应消息中携带初始电视频道信息、 和 /
或频道组信息、 和 /或频道组内的其它成员频道信息, 并根据所携带的初 始频道信息进行资源预留, 业务建立成功后, 终端加入初始电视频道。 图 4所述的方法能够提供请求消息中不指明具体频道和频道组信息的直 播电视业务场景。 图 6所述的方法能够提供请求消息中指明频道组但不 指明具体频道信息的直播电视业务场景。
3 )用户向 IPTV***请求观看直播电视, 如果请求消息中只携带电 视频道组信息, 未指明具体电视频道, 且 IPTV***无法确定用户初始 观看的该频道组内电视频道, 则 IPTV***通知终端频道组内的成员频 道信息(可以是在请求响应消息中携带,也可以是通过其它消息或方式, 如下发一个该频道组的链接地址等), 此时, 在业务建立过程中, 还无 法准确完成网络资源的预留, 只能完成对业务请求的授权(如承载网络 可以接受来自用户的组播加入请求, 并获取该频道组中各频道的网络参 数信息, 组播地址、 带宽需求等), 终端根据获得的频道组成员信息选 择加入初始观看的电视频道,此时承载网络设备 ECF/EFF在收到用户的 Join 消息后, 触发网络(RACS )开始预留资源, 完成该初始频道资源 的预留。 图 6所述的方法能够提供直播电视业务的本场景。 离本发明的精神和范围。 这样, 倘若本发明的这些修改和变型属于本发 明权利要求及其等同技术的范围之内, 则本发明也意图包含这些改动和 变型在内。