[发明专利]网络音视频监控架构及其通信方法

说明书

技术领域

本发明属于安防技术领域，尤其涉及一种网络音视频监控系统及其通信方法。

背景技术

基于IP技术的网络音视频监控的产品和解决方案已经发展成为安防领域内的主要方式。现有的网络音视频产品主要包括网络摄像机，网络音视频录像设备以及相应的管理软件如CMS、SMS等。

如图1所示为现有的网络音视频应用的主要架构方式，主要包括三大部分前端设备A：图像采集和压缩部分、后端设备C：图像录像和管理部分以及传输部分B，其中传输部分B的协议内置于前端设备A和后端设备C部分中进行处理。前端A设备与后端C设备之间的协议主要以传输协议和管理协议为主，其中传输协议以网络公共协议D为主，包括D1：RTSP+RTP组合协议，D2：RTSP+RTP+HTTP组合协议和D3：UDP(TCP)+HTTP组合协议等。而管理协议E主要以E1：厂家私有协议和E2：标准协议，其中以ONVIF和PSIA两大组织的标准为主。

基于此传统的架构，前端设备A的功能主要以图像采集、图像处理、编码压缩和网络传送为主，硬件上主要以网络摄像机为主，或者模拟摄像机配套网络编码器设备实现，后端设备C的功能主要以图像录像、解码以及设备管理为主，结构上主要包括网络音视频录像设备和录像管理软件，而传输部分B是普通网络设备，硬件上以以太网交换机、路由器等设备为主。

上述架构主要是同一平面内的数据流为主，即音视频流主要由A通过B传送给C，而管理数据流则由C通过B传送给A，数据流多为双向数据。这样用户不太能够有效地直接访问到A，而是必须通过C才可以访问。例如音视频等数据源的获取则主要通过用户基于访问C设备来获取，但是由于网络延迟等原因，会出现A的数据经过B到达C之后出现很大的延迟。

上述架构是一个独立的架构，A和C为同一客户使用，而其他客户无法共享一个网络里面的A的数据，或者即使通过客户许可，可以访问C，也无法任意去配置和查询A的数据。导致上述架构存在诸多问题，主要表现在以下两方面：

一、上述架构是一个不灵活的架构，也即存在很大的容量和管理瓶颈。首先在容量方面，配置多少数量的A完全取决于C中的设备容量，而从目前的技术水平来看，现在的C中的设备容量都比较小，一般管理的A的数量不多于200台，难以有更大的突破。另一方面，如果用户需要进行扩充A，就需要配置相应的C设备。这样会给用户带来管理上的问题。

二、上述架构无法支持音视频服务公开的技术和市场要求。一方面现在的设备属于独立的管理系统，无开放的公共接口和协议对外部平台和设备进行有效对接；另外一方面服务支持如计费、流量、存储等方面平台无法在此架构上有效开展。

发明内容

本发明所要解决的第一个技术问题在于提供一种网络音视频监控系统的通信方法，旨在通过全新的音视频架构以及相应的数据传输和管理协议来解决目前在网络音视频监控领域内的存在的数据延迟大、扩展不灵活、管理不简便以及无法提供音视频监控服务公开等技术问题。

本发明是这样实现的，一种网络音视频监控架构的通信方法，包括如下步骤：

步骤A，用户端接入云服务端，向云服务端发送音视频数据订阅需求信息，云服务端在收到订阅需求信息后向用户端发送订阅成功的确认信息：所述用户端为所述云服务端的注册用户；

步骤B，云服务端控制相应的音视频设备端根据用户端的订阅需求向用户端发送所订阅的音视频数据，音视频设备端向云服务端发送收到订阅需求的确认信息；所述音视频设备端为所述云服务端认证的音视频数据提供端；

步骤C，音视频设备端直接向用户端发送订阅的音视频数据。

进一步地，在步骤C之后，所述通信方法还包括下述步骤：

步骤D，音视频设备端在将订阅的音视频数据发送给用户的同时，再将发送的音视频数据通知至云服务端。

进一步地，在步骤C之后，所述通信方法还包括下述步骤：

步骤E，云服务端定期通知用户端实际订阅的音视频数据统计信息，或在接收到用户端的查询请求信息后，及时向用户端反馈实际订阅的音视频数据统计信息。

进一步地，在步骤A之前，所述通信方法还包括下述步骤：

步骤F，用户端向云服务端发送配置音视频设备端的请求信息，云服务端在收到所述请求信息后向目标配置音视频设备端发送配置请求；

步骤G，目标音视频设备端在收到云服务端发送的配置请求后，向云服务端返回确认配置的信息；

步骤H，用户端对目标音视频设备端进行配置。

进一步地，在步骤H之后，所述通信方法还包括：