可兼容GB28181与Onvif播放媒体流的视频服务器

韩滨旭 沈玉玲 王子萍

1(上海电气集团股份有限公司中央研究院 上海 200070) 2(上海电气自动化设计研究所有限公司 上海 200023)

0 引 言

视频监控技术从最早的模拟视频发展到数字视频直至今天的网络视频技术经历了多个发展阶段。网络视频是结合多媒体、计算机网络、人工智能以及工业控制等多种技术的综合应用[1]。视频监控系统市场的日益扩大也使网络视频技术的需求持续增长，各种网络视频设备也如雨后春笋般出现在各种视频监控系统中。因为不同的厂商使用的通信协议不一致，不同厂商的视频设备接入给网络视频监控系统带来了难题。2011年12月，GB/T 28181 标准正式将SIP 协议作为视频监控联网的整体通信过程与组网架构的标准协议[2]。然而，在很多应用情况下，尤其是国外的视频设备厂家生产的设备并不是全部支持SIP协议。在2008 年由SONY 等多家大型视频行业相关企业创建了ONVIF 组织，该组织制订的协议标准目标是解决视频设备互联互通等问题，重点关注客户端与服务端的接口通信[3]。2012年在视频监控刮起了一股互联互通标准的春风，从公安部推行国家标准GB28181再到各地方、各行业推行DB33等地方标准，强制要求各厂家产品实现对GB28181、ONVIF等标准协议的支持，给各种视频监控系统项目建设提供了互联互通的技术标准[4]。

GB/T 28181与ONVIF协议的结合可以同时发挥两者的优势，在GB/T 28181下发挥ONVIF协议设备发现及设备信息获取的优势。ONVIF 协议和GB28181 标准对媒体流的播放流程都做出了规定，然而两种协议下媒体播放请求的流程并不一致，使得媒体服务器在媒体播放的实现上发生了冲突[5]。ONVIF协议如何与GB28181标准协同合作是在很多应用情景中，例如多级平台或者复杂系统，需要解决的问题。举例说明一种特殊情况，客户端呼叫SIP服务器，请求通过解码器播放视频流而解码器作为设备只支持ONVIF协议。本文通过使用RTSP申请视频流的方式代替媒体流上传的方式解决这一兼容性的问题。

1 GB28181媒体流播放流程分析

GB28181标准下点播视频流的过程通过SIP 协议的INVITE，ACK， INFO，BYE 类型消息来完成。INVITE 消息的内容是一个SDP 消息体，该消息体描述了要请求的媒体发送者信息[5]。GB28181中描述了客户端作为命令发起者与媒体流接收者的信令流程以及第三方呼叫，其他设备作为媒体流接受者的信令流程。可以发现其中并没有对客户端呼叫且其他设备作为媒体流接受者的信令流程进行定义。如图1所示，对客户端呼叫且客户端接受媒体流的实时视频点播流程分析。

图1 GB28181中由客户端发起播放视频流的流程示意图[2]

如图1所示，从第2步到第7步是视频服务器沟通媒体服务器与前端摄像设备的过程，其目的是使媒体服务器与前端设备交换信息，之后建立前端设备向媒体服务器发送实时媒体流的通道。而媒体流发送者与媒体流接受者设备在引言中所述的情况下均不支持GB28181，第4步到第5步就无法实现从前端设备获取信息，同时视频服务器也无法获取媒体流接收者即解码器信息，媒体服务器也就无法从视频服务器获取对应的解码器信息。

2 ONVIF媒体流播放流程分析

如前所述，ONVIF与GB28181的结合主要需要突出两者的优势，而ONVIF的优势之一就在于发现设备与获得设备信息。ONVIF 很大程度上支持现有的标准，它的目标是实现不同设备的互联互通，而不是定义全新的标准。基于以上原则，ONVIF 的设备发现采用现有的万维网动态发现协议WS-Discovery[6]。通过ONVIF的发现设备和获得设备信息取得支持ONVIF协议的设备信息，且因为ONVIF与GB28181都是通过XML在服务器中进行解析则可以很好的定义两者之间XML的转换。具体如何获得ONVIF设备的设备信息如图2所示。

图2 ONVIF中客户端发起实时媒体流播放的流程示意图[3]

在视频服务器启动时，可以通过ONVIF服务组播发送Probe报文发现前端设备，并根据获得的设备列表根据设备类型通过GetProfiles获得设备的媒体信息。那么如何将这些媒体信息交互给媒体服务器，并过视频服务器将这些信息共享到参与媒体流播放的设备就需要GB28181的协同配合。

3 ONVIF与GB28181的协同配合流程

视频服务器通过ONVIF服务获得所有ONVIF设备信息是并行的，即所有GetProfiles是ONVIF协议栈经过处理后启动线程池并行的使用ONVIF服务进行发送。之后并发的接收设备端传回的信息，为方便备份与处理首先应该将信息存储进入数据库与内存中的数据结构相映射的表中。

在视频服务器获取设备信息的同时，媒体服务器发送SIP协议总的Catalog指令到视频服务器获取视频服务器通过ONVIF协议获得的设备信息，设备的URL信息存放在Catalog报文内容中的PlayUrl标签中。ONVIF 的标准接口可以解决非标准化网络摄像机通过RTSP 流媒体协议解决接入问题，也为使用RTSP控制媒体流奠定了基础[7]。

如图3所示，车站的解码器在第7步使用RTSP协议从编码器获取媒体流，而设备信息的获取均是通过ONVIF信息向两个设备获取并通过视频服务器进行交换。如果参考此流程，解码器同样可以使用RTSP从媒体服务器获取媒体流，而媒体服务器同理可以使用RTSP从媒体流发送者获取媒体流。

图3 车站域内视频流通信流程[8]

如图4所示，相关流程说明如下：

1) 客户端向视频信令服务器发送SIP协议中的INVITE命令，请求中附带SDP消息体，里面包含了媒体流发送者也就是前端设备的ID以及地址等信息。

2) 视频服务器通过ONVIF命令ConfigReceiver请求将媒体流发送者信息、媒体服务器信息以及使用的解码器通道信息递送给解码器。

3) 解码器通过得到的媒体流发送者信息及自身信息通过RTSP发送到媒体服务器。

4) 媒体服务器通过媒体流发送者信息在已通过前述Catalog命令得到的设备信息表中查询相关的URL并通过RTSP请求媒体流发送者的媒体流。

5) 解码器收到媒体流发送的媒体流后向视频服务器回复第2步的ONVIF的响应。

6) 视频服务器得到ONVIF响应后回复客户端第1步INVITE请求的SIP响应200OK。

图4 GB28181与ONVIF配合流程

4 视频服务器的内部调度

GB/T 28181-2011通过引入国际多媒体通信SIP协议及通信机制来规划系统整体信令组网架构，在此之上定制了专有系统控制描述协议MANSCDP，从而实现信令的互联互通[9]。

视频服务器使用JAIN SIP及ONVIF-WS-CLIENT的JAVA框架构建GB28181与ONVIF的底层服务。在两个服务之上构建协议栈，之后采用监听者设计模式来实现两者之间的交互。

如图5所示，SIP与ONVIF服务均会有对应的监听者对象，那么在服务判断下一步流程需要另一方的服务时，例如客户端发起实时视频流调用的请求，只要触发Update()方法进入观察者就可以。在观察者内部实现对应协议的转化，并调用相应的另一种服务发出即可，这种模式可以很好地完成两者之间的数据交换。而不是通过内部TCP通信的方式或者进程间通信，这样可以满足视频服务真正兼容两个协议。而RTSP的使用，也避免了GB28181流程中媒体流推送有可能出现卡顿的现象，因为要使媒体流主动推送则会优先选用UDP协议，而当网络传输能力不能满足实时传输要求时，被丢弃的数据包将不被重复传送就会出现卡顿现象[10]。使用RTSP并通过TCP建立连接就可以有效地避免这种数据包丢弃不被重复传送的问题。

图5 视频服务器使用观察者模式内部结构

5 结 语

通过上述的方法可以发挥GB28181与ONVIF两种协议的优势。使用观察者模式的视频服务器可以很好地解决两种服务之间的交互保证了整个流程的一致性与完整性。使用RTSP相比GB28181的点播流程节约了不少沟通过程，更高效地实现了媒体流的播放并且避免了丢弃数据包不被重复传送问题的发生。