媒体于2月25日转发了国家广播电视总局科技司在北京讨论的《IPTV技术体系总体要求(初稿)》这也是广电总局第一次就IPTV进行技术标准的相关讨论和制定。

笔者作为行业资深从业人员，曾参与中国电信IPTV 2.0、3.0及工信部IPTV行业标准制定以及实施，基于对IPTV的情结，也第一时间对该技术要求进行了仔细的阅读，并将一些思考与大家分享。

从总体架构来看，该技术体系站在广电角度对采用总分二级架构实现IPTV内容提供、集成播控、业务监测等功能所涉及的系统关系、功能定义、业务流程等进行了简要的说明。

从系统功能来看，再次明确表达了广电希望在EPG制作、播出安全、 “双认证，双计费”等业务关键点加强管控的强烈愿望。

从业务分工来看，占IPTV投资70%以上的CDN（即要求中的“IPTV传输系统”）仍由运营商承担，却要求对其设备、网络、服务质量进行全面的“监管”；涉及用户认证、计费的部分则要求以广电集成播控系统为准，把用户管理纳入怀中。

根据笔者多年IPTV规范及技术方案编写、业务系统实施的经验来看，该技术要求在实施过程中可能会遇到一些困难。在此将逐一分析，希望对提升方案可实施性有所帮助。

1、集成播控总平台EPG服务性能风险

在“4.5 体系架构”最让人感到意外的系统接口是IPTV集成播控总平台的EPG管理系统与用户终端间的连接线（下图红线部分），即集成播控总平台能够直接为机顶盒提供EPG服务。

《IPTV技术体系总体要求（初稿）》 图1 IPTV体系架构图

通过 “6.3.2 EPG管理对接”的详细描述 —— “（Launcher提供入口的软件包）用户终端可直接与总平台EPG系统交互，收视上述主题主线专区等节目。”方案制定者希望总平台能够采用独立APK的方式直接面向用户提供服务，而不是由分平台或运营商提供EPG服务能力，从而摆脱采用Web方式时总平台对分省EPG服务子系统的依赖。

但在实际规划网络时，分平台内部各业务系统均采用内网方式连接，而总平台与分平台间的MSTP专线仅用于直播流、点播视频、内容元数据、EPG分发等功能。也就是说，面向用户服务的EPG部分仅限于本地分平台或运营商提供的EPG系统，用户无法直接访问处于“外网”的总平台资源。

如果希望IPTV终端能直接访问总平台EPG服务，只可能采用两种方式：1）打通用户机顶盒与集中部署的总平台间的路由，并构建完整的封闭网络；2）总平台EPG系统采用分布式部署方式，在分平台机房部署二级平台分省提供服务；

考虑到全国集中式服务对服务器的压力以及对专线带宽的要求，采用分省分布式部署的方式显然更为可行。

2、“双认证”系统故障可能带来的业务投诉压力

“双认证”是广电对IPTV业务的一贯要求。在各省运营商与当地二级播控平台已实施方案来看，二级播控会根据业务的实际情况对“双认证”进行一定程度的调整。

通常有两种做法：1）串行方式：先经运营商系统认证，再由运营商系统与广电认证系统后台交互完成认证；2）并行模式：由终端分别向运营商、广电认证系统分别进行认证。

《IPTV技术体系总体要求（初稿）》 图5 IPTV集成播控分平台与IPTV传输系统的认证流程图

从个人观点来看，在“7.4.1 双认证流程”中选择并行方式能有效降低运营商、广电认证系统间的耦合性，当某一系统出现问题时不至于影响到另一个正常工作的系统对业务流程的参与。

但在后续描述中提出的“只有IPTV集成播控分平台和传输系统双方都认证通过后才向用户返回认证成功结果；其中任何一方认证失败，都将向用户返回认证失败结果。”却又将一个“松耦合”的业务流程在业务要求层面做了“紧耦合”。

如果在各系统运行正常的情况下，这个流程自然没问题。但同样也需要考虑系统故障时对业务的影响：如果分平台认证系统出现了故障造成用户认证失败，那么按照“双认证”都要通过才可使用业务的要求，用户将无法正常使用业务。一旦出现这样的情况，运营商的客服电话10000%会被打爆，但此时运营商既无法参与故障系统的处理，也无法启动应急流程，从而造成重大运维故障。

考虑到类似情况曾在现网出现，此处建议更改为：广电认证流程一旦因系统故障导致认证失败，也应允许用户使用业务。可以在故障恢复后从运营商处同步相关认证信息。但广电认证系统仍然需要额外定义系统故障时候的“认证全通过”应急流程。

3、业务鉴权结果未通知运营商系统导致无法获取视频播放地址

“7.4.2 业务鉴权流程”中定义了的由用户发起的鉴权请求，但鉴权结果并未通知运营商业务系统。

从现有IPTV业务场景来看，用户直接与单个系统完成的鉴权仅适用于“产品包鉴权”的业务场景。一旦鉴权结果涉及视频播放，则需要在鉴权成功时将视频播放地址随鉴权信息一并返回用户终端。

《IPTV技术体系总体要求（初稿）》 图6 IPTV集成播控分平台与IPTV传输系统的鉴权流程图

同时，在流程设计上还需要考虑：如果用户通过线下营业厅完成产品包订购，由于现有方案中未定义订购关系同步流程，会导致一个问题：用户明明在营业厅订购了业务，但线上使用业务的时候却提示需要再次订购。

考虑实际业务实现的情况，此处建议：先在运营商业务系统进行鉴权，再由运营商系统通过后台SOAP/RESTful接口与分平台业务系统完成“二次鉴权”，只有两个系统均鉴权通过的情况下才能使用业务。如果出现两个系统订购数据不一致的情况，以运营商业务系统为准进行在线订购关系同步。

4、“双计费”电子支付模式在业务结算中难以操作

"7.4.3 双计费流程"中首先确认了当前IPTV由运营商面向用户收费的模式 —— “根据当前业务开展情况，IPTV集成播控平台可以采用委托IPTV传输系统代扣费，并对账结算进行IPTV业务收费。”但针对在线支付的方式，希望由集成播控分平台完成此部分费用的收取。

《IPTV技术体系总体要求（初稿）》 图7 IPTV用户业务订购流程图

姑且不提系统设计上的一些原则问题，仅从财务的角度来说：账单结算“代扣费”方式是由运营商分钱给广电，在线“电子支付”方式是由广电分钱给运营商。那么双方同时既是支付方又是收款方，在财务审计上是通不过的……

因此，此处建议：即使是在线支付方式，也还有由运营商统一收取后结算给广电吧……

5、IPTV监管平台定位需明确，部分监管方案无法实施

对于“IPTV监管系统”的系统定位与功能定位是技术方案中较为不明确的地方，更像是一个功能的“大杂烩”。根据“8.1 要求”中的描述，系统承担的主要功能包括：

a）技术质量监测：IPTV技术质量监测的目标是保障IPTV用户收看的EPG信息、直播节目、增值服务等满足管理机构规定的质量指标。

b）节目内容监管：IPTV节目内容监管的目标是保障用户收到的EPG信息、直播节目、点播节目、增值服务等业务包含的内容没有违反国家的相关法律和规定。

c）安全播出监管：IPTV安全播出监管的目标是保障全平台直播节目完整、信号安全、技术安全，通过不同来源采集节目一致性比对实现安全播出监管。

d）网络安全监管：IPTV网络安全监管目标是通过采集汇总监管对象的安全信息掌握各平台设备及网络安全现状。

《IPTV技术体系总体要求（初稿）》 图8 IPTV监管平台对接架构图

但从实际业务实施的角度来说，各监测内容分属于不同的运维维度：

•技术质量监测：EPG、增值服务质量是Web服务或接口响应的质量，属于系统性能方面；直播、点播服务质量是网络传输过程中对丢包、抖动、时延的监测，是运营商用于改善网络质量的传统领域；

•节目内容监管：对于EPG、直播、点播等的监控属于内容安全领域，理论上在封闭的网络中只要是经过播控的内容都是安全的。如果是希望获取业务的运营数据，那么在集成播控平台负责EPG运营的情况下，直接部署EPG探针即可完成此功能；

•安全播出监管：从内容源、CDN服务到用户终端的多级监控是从“三网融合”之初广电就希望实现的，但经过将近10年的发展仍未能完全实施。特别是对于终端侧“移动监控点”的部署更是难以实现。要实现用户侧观看视频内容的实时监看需要有足够的接入网上行带宽，实际上行带宽远小于下行带宽。但如果只是定时截屏监测，又如何保证终端侧内容播出的“实时”安全？

•网络安全监管：姑且不提网络安全是运营商的传统领域，单单运营商经过几十年的时间才建立了复杂的服务器、网络设备运维监控体系，就需要几乎同等量级的“监测系统”来实施，因此实际操作的可行性并不大。

总结

从个人观点来看，《IPTV技术体系总体要求（征求意见稿）》的目的除了进一步强调集成播控平台二级架构、广电在IPTV业务中的监管地位外，也希望在新出现的业务场景中争取争取更多的主动权。

但就技术方案本身来看，还需要进一步结合实际的业务、技术情况具备更好的兼容性和适用性，建议可以考虑组织各省广电、运营商展开更大范围的讨论，为后续IPTV业务发展提供帮助。