论文部分内容阅读
摘要：HFC双向网络的全网促进了互动电视的发展，也给互动点播系统提出了更高的要求。为了快速故障定位和系统维护，通过旁路技术基于RTSP协议对有线互动点播业务进行信令级别的监测，以提供互动平台业务的运行情况，使系统维护人员能及时掌握以便快速维护，确保HFC点播业务稳定运营。
关键词：RTSP；点播；互动电视；HFC双向网络
中图分类号：TP319 文献标识码：A 文章编号：1009-3044（2018）22-0045-02
随着HFC双向网络的全网覆盖，互动电视的发展也进入了快速发展阶段，有线互动点播数量的增长对于互动点播系统提出了更高的要求。虽然CDN、多频点技术为互动点播系统提供了硬件保证，但仅依靠传统的抽样点播测试是无法识别系统级的软故障。而等待用户报障才开始进行诊断维护，不仅花费时间长，也影响到用户互动体验。实时有效地提供互动点播的运行数据、告警信息，是为互动点播平台业务提供故障分析参考和定位依据的重要手段，本系统利用RTSP协议读取互动点播信令原始数据计算获取网推推流并发数结合其他信息系统数据得到互动点播的实时运行数据、告警信息以及各类点播详情，从而可以实现有效的管理监视。
1 RTSP协议
实时流传输协议 RTSP（Real Time Streaming Protocol）是基于TCP/IP协议的传输流媒体数据的应用层协议，常用于音视频流媒体数据的点播控制。RTSP协议可以对一个或多个串行流媒体进行控制，控制的命令包括：快进、倒退、暂停等，但RTSP自身并不能传输流媒体数据。换言之，RTSP 只能充当流媒体服务器的远程控制器[1]。
RTSP 消息由客户端到服务器的请求消息和由服务器到客户端的回应消息组成。请求 （Request） 和回应 （Response） 消息报文格式都使用RFC2326文档中定义的格式。
RTSP 的请求消息报文格式如图 1所示。其中，Method字段表示请求的方法，定义的有DESCRIBE、ANNOUNCE、GET_PARAMETER、OPTION、PAUSE、PLAY、RECORD、SETUP、TEARDOWN等。Request-URI字段表示流媒体服务端的地址， 如：rtsp：//192.168.1.11：5005/stream，RTSP-Version字段表示使用协议的版本号，如RTSP/1.0。各字段之间以空格（SP）分隔，每行以回车换行符CR、LF结尾，消息头通常以两个回车换行符结尾。
RTSP的回应消息报文格式如图 2 所示。其中，Status-Code字段由 3 位数字组成，表示回应请求时的主机状态，定义格式为：1XX（预留未来使用）、2XX（成功）、3XX（重定向）、4XX（客户端出错）、5XX（服务器端出错）。Reason-Phrase字段是Status-Code字段的补充，是对Status-Code的文本解释，一般不需要应用来解析。其余参数与请求消息报文格式相同。
2 RTSP数据采集系统
合肥有线的互动业务监测系统是一套基于RTSP协议的有线互动点播业务领域在线监测系统，为系统维护人员提供互动平台业务实时网络、终端、平台及业务的运行情况，以便故障分析参考和定位依据。RTSP数据采集系统是对整个HFC网络互动点播所产生的RTSP交互信令进行监测分析，所以信令采集点的选取原则是采集系统不能影响且不能依赖于业务系统而独立工作，因此整个采集链路都以旁路、光分路为主要技术选择。
RTSP信令抓取部分主要功能如下： （1）支持千兆采集接口，以旁路的方式直接接入路由器，过滤获取平台交互信令数据；（2）统计点播观看用户数、在线并发流数；（3）记录RTSP实时交互信令，实现RTSP信令分析和报警，及时发现信令交互中的响应异常等问题。RTSP信令抓取模型如图3所示。
为了便于业务系统和维护人员维护和排障，利用RTSP信令协议结合实际工作经验，对于RTSP信令的故障告警我们进行了相应的分类：
3 有线互动点播监测系统的设计与实现
3.1 监控系统设计
有线互动点播系统采用三层结构设计模式。如图4所示的系统结构图，系统由信令数据采集层、数据分析应用层、业务信息表示层三部分组成，系统核心是数据分析应用层，采用分布式接口应用的方式，在扩展系统功能时，只需提供相应的接口API，便可实现在线热部署，便捷了开发以及维护。
信息表示层由应用层的WEB服务来实现，包括RTSP信令分析、用户行为分析、故障定位以及系统管理等功能。
数据应用分析层是互动点播监测系统的功能主体，提供数据处理服务、汇聚服务和统计服务三部分功能。数据处理服务完成信息表示层的数据实现以及相应的数据预处理，包括业务数据分析、点播告警管理以及用户行为分析等功能，实现收视点播数据管理、全网推流报警关联管理、实时推流数据缓存、推流数据离线缓存等逻辑；数据汇聚服务是应用层与采集层的纽带，实现RTSP采集数据的收集、处理、数据分析等功能；数据统计服务用以定期的全网点播数据统计分析以及各类报表业务功能。
数据采集层是高清互动业务监测系统的数据来源，用来完成信令信号和业务系统运行数据的采集与分析。
3.2 系统实现
3.2.1 VOD并发趋势
系统的运行分析功能能够对各个节点并发数、各个节目的访问数以及在线流等进行集中分析，最终形成针对点播业务的统计趋势报告。如图5在线流以及告警曲线图。
3.2.2 用户点播信息表
通过列表的方式展示当前用户在线点播的信令详情，显示在线用户数、开始点播时间、点播类型、点播片名以及流分组等信息，如图6所示。
4 总结
本系统是通过RTSP协议的解析实现了互动点播信令的实时分析，为有线互动点播业务提供了有效监测，其实现主要包括两部分，其一，通过RTSP协议的解析获取互动点播信令用以监控全网点播流；其二，对监控结果设置告警。实践证明，该系统不仅可以有效再现全网互动点播业务的运行状态，还为系统维护提供了有效的数据分析。
参考文献：
[1]RFC.RFC2326.[EB/OL] https：//tools.ietf.org/pdf/rfc2326.pdf.
[2]張军. 基于SNMP的HFC双向网络设备的监测[M]. 电脑知识与技术，2013（9）.
[3]美 Bruce Eckel. Java编程思想[M]. 陈昊鹏，译.2007-06-01.
[4]美Craig Walls. Spring实战[M]. 张卫滨，译.2016.
[5]美Kirk Knoernschild.Java应用架构设计：模块化模式与OSGi[M].张卫滨，译.机械工业出版社，2013.
【通联编辑：王力】
关键词：RTSP；点播；互动电视；HFC双向网络
中图分类号：TP319 文献标识码：A 文章编号：1009-3044（2018）22-0045-02
随着HFC双向网络的全网覆盖，互动电视的发展也进入了快速发展阶段，有线互动点播数量的增长对于互动点播系统提出了更高的要求。虽然CDN、多频点技术为互动点播系统提供了硬件保证，但仅依靠传统的抽样点播测试是无法识别系统级的软故障。而等待用户报障才开始进行诊断维护，不仅花费时间长，也影响到用户互动体验。实时有效地提供互动点播的运行数据、告警信息，是为互动点播平台业务提供故障分析参考和定位依据的重要手段，本系统利用RTSP协议读取互动点播信令原始数据计算获取网推推流并发数结合其他信息系统数据得到互动点播的实时运行数据、告警信息以及各类点播详情，从而可以实现有效的管理监视。
1 RTSP协议
实时流传输协议 RTSP（Real Time Streaming Protocol）是基于TCP/IP协议的传输流媒体数据的应用层协议，常用于音视频流媒体数据的点播控制。RTSP协议可以对一个或多个串行流媒体进行控制，控制的命令包括：快进、倒退、暂停等，但RTSP自身并不能传输流媒体数据。换言之，RTSP 只能充当流媒体服务器的远程控制器[1]。
RTSP 消息由客户端到服务器的请求消息和由服务器到客户端的回应消息组成。请求 （Request） 和回应 （Response） 消息报文格式都使用RFC2326文档中定义的格式。
RTSP 的请求消息报文格式如图 1所示。其中，Method字段表示请求的方法，定义的有DESCRIBE、ANNOUNCE、GET_PARAMETER、OPTION、PAUSE、PLAY、RECORD、SETUP、TEARDOWN等。Request-URI字段表示流媒体服务端的地址， 如：rtsp：//192.168.1.11：5005/stream，RTSP-Version字段表示使用协议的版本号，如RTSP/1.0。各字段之间以空格（SP）分隔，每行以回车换行符CR、LF结尾，消息头通常以两个回车换行符结尾。
RTSP的回应消息报文格式如图 2 所示。其中，Status-Code字段由 3 位数字组成，表示回应请求时的主机状态，定义格式为：1XX（预留未来使用）、2XX（成功）、3XX（重定向）、4XX（客户端出错）、5XX（服务器端出错）。Reason-Phrase字段是Status-Code字段的补充，是对Status-Code的文本解释，一般不需要应用来解析。其余参数与请求消息报文格式相同。
2 RTSP数据采集系统
合肥有线的互动业务监测系统是一套基于RTSP协议的有线互动点播业务领域在线监测系统，为系统维护人员提供互动平台业务实时网络、终端、平台及业务的运行情况，以便故障分析参考和定位依据。RTSP数据采集系统是对整个HFC网络互动点播所产生的RTSP交互信令进行监测分析，所以信令采集点的选取原则是采集系统不能影响且不能依赖于业务系统而独立工作，因此整个采集链路都以旁路、光分路为主要技术选择。
RTSP信令抓取部分主要功能如下： （1）支持千兆采集接口，以旁路的方式直接接入路由器，过滤获取平台交互信令数据；（2）统计点播观看用户数、在线并发流数；（3）记录RTSP实时交互信令，实现RTSP信令分析和报警，及时发现信令交互中的响应异常等问题。RTSP信令抓取模型如图3所示。
为了便于业务系统和维护人员维护和排障，利用RTSP信令协议结合实际工作经验，对于RTSP信令的故障告警我们进行了相应的分类：
3 有线互动点播监测系统的设计与实现
3.1 监控系统设计
有线互动点播系统采用三层结构设计模式。如图4所示的系统结构图，系统由信令数据采集层、数据分析应用层、业务信息表示层三部分组成，系统核心是数据分析应用层，采用分布式接口应用的方式，在扩展系统功能时，只需提供相应的接口API，便可实现在线热部署，便捷了开发以及维护。
信息表示层由应用层的WEB服务来实现，包括RTSP信令分析、用户行为分析、故障定位以及系统管理等功能。
数据应用分析层是互动点播监测系统的功能主体，提供数据处理服务、汇聚服务和统计服务三部分功能。数据处理服务完成信息表示层的数据实现以及相应的数据预处理，包括业务数据分析、点播告警管理以及用户行为分析等功能，实现收视点播数据管理、全网推流报警关联管理、实时推流数据缓存、推流数据离线缓存等逻辑；数据汇聚服务是应用层与采集层的纽带，实现RTSP采集数据的收集、处理、数据分析等功能；数据统计服务用以定期的全网点播数据统计分析以及各类报表业务功能。
数据采集层是高清互动业务监测系统的数据来源，用来完成信令信号和业务系统运行数据的采集与分析。
3.2 系统实现
3.2.1 VOD并发趋势
系统的运行分析功能能够对各个节点并发数、各个节目的访问数以及在线流等进行集中分析，最终形成针对点播业务的统计趋势报告。如图5在线流以及告警曲线图。
3.2.2 用户点播信息表
通过列表的方式展示当前用户在线点播的信令详情，显示在线用户数、开始点播时间、点播类型、点播片名以及流分组等信息，如图6所示。
4 总结
本系统是通过RTSP协议的解析实现了互动点播信令的实时分析，为有线互动点播业务提供了有效监测，其实现主要包括两部分，其一，通过RTSP协议的解析获取互动点播信令用以监控全网点播流；其二，对监控结果设置告警。实践证明，该系统不仅可以有效再现全网互动点播业务的运行状态，还为系统维护提供了有效的数据分析。
参考文献：
[1]RFC.RFC2326.[EB/OL] https：//tools.ietf.org/pdf/rfc2326.pdf.
[2]張军. 基于SNMP的HFC双向网络设备的监测[M]. 电脑知识与技术，2013（9）.
[3]美 Bruce Eckel. Java编程思想[M]. 陈昊鹏，译.2007-06-01.
[4]美Craig Walls. Spring实战[M]. 张卫滨，译.2016.
[5]美Kirk Knoernschild.Java应用架构设计：模块化模式与OSGi[M].张卫滨，译.机械工业出版社，2013.
【通联编辑：王力】