onvif简介

onvif介绍

标题1.1 onvif背景

网络摄像机是网络设备，需要有通讯协议，早期的网络摄像机硬件提供商都采用私有协议。
随着视频监控的网络化应用，产业链的分工将越来越细。有些厂商专门做摄像头，有些厂商专门做视频服务器，有些厂商则可能专门做平台等，然后通过集成商进行集成，提供给最终客户。私有协议无法胜任这种产业合作模式，行业标准化的接口由此应运而生。
目前，网络摄像机的标准协议，国际标准上有三大类：ONVIF、PSIA和HDCCTV，国内标准有国标GB/T28181。ONVIF阵营日益壮大，与PSIA、HDCCTV相比，无论是支持厂商的数目、厂商的知名度，还是市场占有率都遥遥领先。ONVIF标准的厂商覆盖芯片、视频前端设备、存储设备、系统平台、智能分析设备、门禁、传感设备等各个安防相关领域。我们说的IPC摄像头只是ONVIF标准里的一个分支而已，可见ONVIF的强大。

标题1.2 什么是ONVIF

ONVIF（Open Network Video Interface Forum，开放型网络视频接口论坛）以公开、开放的原则共同制定开放性行业标准。
从ONVIF官网上可以了解到（https://www.onvif.org/about/member-list/），为适应各种不同的参与级别，ONVIF提供了不同等级的会员企业资格，其中不乏国内外著名的设备制造商与集成商，国内的华为、海康威视、浙江大华、波粒科技和佳信捷也是ONVIF论坛的高级会员。
ONVIF到底是什么，怎么工作的，原来ONVIF协议将终端设备（摄像头）提供Web Service服务，将每一个功能看做一个Web Service，比如，我要探测局域网中的网络摄像头，那么向摄像头提供相应的Web Service 的接口发送请求，我不是做网页的，刚开始这个概念没理解清楚，其实就是每个摄像头提供一个网址，比如淘宝网页，我们都知道，要想访问淘宝，就得在浏览器的地址栏输入淘宝的网址，https://www.taobao.com/，获取到主页后，就可以为所欲为了（只要你有钱）。ONVIF也一样，首先获取摄像头的主地址比如（http://10.0.0.47/onvif/device_service），我的摄像头的IP为10.0.0.47，获得这个地址后，我们就可以向这个地址提供的接口来获取相应的功能，每个接口可以认为一个功能，也就是一个Web Service。

工作是这样子的

客户端（推流盒子）要知道终端设备（摄像头）的拉流地址，那么客户端就向终端设备提供的Web Service地址发送请求，然后终端设备给与回应，一问一答，就把事情做了，
一个流程如下图

标题1.3 onvif技术框架

ONVIF规范中设备管理和控制部分所定义的接口均以Web Services的形式提供。ONVIF规范涵盖了完全的XML及WSDL的定义。每一个支持ONVIF规范的终端设备均须提供与功能相应的Web Service。服务端与客户端的数据交互采用SOAP协议。ONVIF中的其他部分比如音视频流则通过RTP/RTSP进行。

拿IPC摄像头来说，IPC是Web Services服务端，其提供的WEB服务接口需符合ONVIF协议规范（这些接口在ONVIF规定的WSDL文档中），我们开发的客户端通过这些ONVIF规范接口跟IPC通讯，比如：
获取IPC的基本信息（厂家信息、版本信息等）；
修改IPC的系统日期、时间；
修改IPC的网络配置（IP、子网掩码等）；
获取/修改IPC摄像头的各种参数（视频分辨率、码率、帧率、OSD，云台控制等）；
由于SOAP协议不适合传输音视频流，ONVIF规范中的传输音视频流采用的是已经很成熟的RTP/RTSP多媒体传输协议。
简单粗暴的理解：IPC的各种参数获取/配置都是通过ONVIF协议实现，而音视频流多媒体传输采用的是RTP/RTSP协议实现。

标题1.4 onvif靠什么通信

标题1.4.1 SOAP

SOAP是简单对象访问协议（Simple Object Access Protocol）的缩写。他是基于XML的一种协议。一条SOAP消息就是一个普通的XML文档，包含如下元素
• Envelope – 必须元素：可以把XML文档表示为一条SOAP消息
• Header – 可选元素：包含头部信息
• Body – 必须元素：包含所有的调用和响应信息
• Fault – 可选元素，提供有关在处理此消息时候所发生的错误消息

标题1.4.2 在TCP/IP四层模型中展示SOAP

SOAP（Simple Object Access Protoco，简单对象访问协议），是TCP/IP协议体系中的一个应用层协议，它是在HTTP基础之上实现的。

标题1.4.3 如此理解SOAP

SOAP协议 = RPC机制 + HTTP传输协议 + XML数据格式

SOAP的两个主要设计目标是「简单性」和「可扩展性」，SOAP的设计正是围绕这两点展开的。
SOAP使用RPC机制，体现了「简单性」。让客户端调用Web Service的接口看起来像本地调用一样，确实很简单。
SOAP 使用 HTTP 传送 XML，体现了「可扩展性」。尽管HTTP 不是有效率的通讯协议，而且 XML 还需要额外的文件解析（parse），两者使得交易的速度大大低于其它方案。但是XML 是一个开放、健全、有语义的讯息机制，而 HTTP 成熟、稳定、又能避免许多关于防火墙的问题，从而使SOAP得到了广泛的应用。
套用一副对联加以概括：
上联: 社区活跃框架多
下联: 简单易懂不出错
横批: 省时省力

标题1.4.4 SOAP的局限性

SOAP也有一些局限性，以下场景就不适合 SOAP：

1. 实时数据推送
   HTTP是短连接的，都是客户端请求，服务端应答，这种模式导致服务端无法实时推送数据给客户端，只有像Socket那样的长连接才能保证实时通讯。
2. 省流量、高传输效率的应用
   HTTP有包头，而且XML全部用文本文件来传输数据，效率会比较低，如果你对流量、传输效率要求极高，那么你应该多考虑其它的方式，而不要用 SOAP。

标题1.4.5 SOAP协议看起来长这样

这个一个股票Web Services服务系统，其中GetStockPrice接口适用于查询股票当前价格，图中查询了IBM的股票价格，Web Services返回股票价格为34.5

标题1.4.6 WSDL

WSDL是Web Service的描述语言（Web Service Description Language）的缩写，是一个来描述Web服务器和说明如何与Web 服务器通信的XML语言。为用户提供详细的接口说明书。
注意：只有SOAP方式实现的Web Services才有WSDL文档，其他方式实现的Web Services并没有WSDL文档。
我们可以这么理解WSDL：WSDL是一个使用XML语言书写的文档，这个文档描述了Web Services对外提供了哪些接口，就像动态库的.h文件一样。每个Web Services都有对应的WSDL文档。

标题1.5 开发流程

这里先简要的介绍下IPC客户端开发流程，具体怎么操作在专栏后续文章中会陆续展示。ONVIF协议既然是Web Services框架，那就不需要自己造轮子，ONVIF协议部分由gSOAP工具帮我们自动生成代码框架。
而RTP/RTSP音视频传输部分则采用开源的FFmpge即可，FFmpge在音视频处理方面，那是首屈一指。

IPC客户端程序整个开发流程如下图所示：

标题1.6 netserver

网络服务器是向工作站和计算机网络上的其他服务器提供各种共享资源的计算机。

标题1.7 ipcsrv

创建进程之间的数据传递，理解进程共享变量的进程通信

标题1.8 lighttpd

各个onvif环节的平台和连接插件。
配置文件etc/lighttpd.conf
Lighttpd是一个轻量级的Web 服务器，支持FastCGI, CGI, Auth, 输出压缩(output compress), URL重写, Alias等重要功能。它具有非常低的内存开销，cpu占用率低，效能好，以及丰富的模块等特点。其静态文件的响应能力远高于Apache，可谓Web服务器的后期之秀。
我将lighttpd理解为一个平台，提供了一整套开发流程以及各种高效的工具。使得我们在服务器功能开发时就像使用VC在现有工程中添加模块一样简单。
状态机与插件
二者联系：
事件所处状态机中的各个状态，lighttpd都会对事件进行相应处理。有些是lighttpd自身做的，有些是通过调用插件完成的。插件中那些负责事件处理的接口分布在某几个状态中。
我们只需在插件的各个阶段完成指定工作并返回相应的返回值，就可以促使状态机完成状态切换，完成事件的整套处理流程，并最终由lighttpd完成事件的响应。
例如：
在CON_STATE_REQUEST_END状态，lighttpd对请求进行了解析，并获得了con->request.http_method，con->request.uri，con->request.http_host等重要数据。——lighttpd自身对con的处理。
在CON_STATE_HANDLE_REQUEST状态，lighttpd除了自身对con中数据处理外还调用了插件的接口：handle_uri_raw；handle_uri_clean；handle_docroot；handle_physical；handle_subrequest_start；handle_subrequest。——插件对con的处理。