ONVIF协议网络摄像机（IPC）客户端程序开发（5）：门外汉理解ONVIF协议

1. 专栏导读
本专栏第一篇文章「专栏开篇」列出了专栏的完整目录，按目录顺序阅读，有助于你的理解，专栏前面文章讲过的知识点（或代码段），后面文章不会赘述。为了节省篇幅，突出重点，在文章中展示的示例代码仅仅是关键代码，你可以在「专栏开篇」中获取完整代码。

如有错误，欢迎你的留言纠正！让我们共同成长！你的「点赞」或「打赏」是对我最大的支持和鼓励！

2. 前言
这次「ONVIF协议网络摄像机（IPC）客户端程序开发」专栏，到了这篇文章，才真正的开始介绍ONVIF，前面的文章都是为了介绍ONVIF做的铺垫，如果前面的文章你还没看过，建议你先去阅读过再来浏览本文。

3. ONVIF背景
网络摄像机是网络设备，需要有通讯协议，早期的网络摄像机硬件提供商都采用私有协议。

随着视频监控的网络化应用，产业链的分工将越来越细。有些厂商专门做摄像头，有些厂商专门做视频服务器，有些厂商则可能专门做平台等，然后通过集成商进行集成，提供给最终客户。私有协议无法胜任这种产业合作模式，行业标准化的接口由此应运而生。

目前，网络摄像机的标准协议，国际标准上有三大类：ONVIF、PSIA和HDCCTV，国内标准有国标GB/T28181。ONVIF阵营日益壮大，与PSIA、HDCCTV相比，无论是支持厂商的数目、厂商的知名度，还是市场占有率都遥遥领先。ONVIF标准的厂商覆盖芯片、视频前端设备、存储设备、系统平台、智能分析设备、门禁、传感设备等各个安防相关领域。我们说的IPC摄像头只是ONVIF标准里的一个分支而已，可见ONVIF的强大。

ONVIF（Open Network Video Interface Forum，开放型网络视频接口论坛）以公开、开放的原则共同制定开放性行业标准。

从ONVIF官网上可以了解到（https://www.onvif.org/about/member-list/），为适应各种不同的参与级别，ONVIF提供了不同等级的会员企业资格，其中不乏国内外著名的设备制造商与集成商，国内的华为、海康威视、浙江大华、波粒科技和佳信捷也是ONVIF论坛的高级会员。

4. 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协议实现。

5. ONVIF技术规格
ONVIF协议中，有一系列Profile的技术规格。ONVIF之所以引入了Profile的概念，使得终端用户能够更容易区分各个Profile所支持的特性，而无需确定ONVIF技术规格不同版本间的兼容性。截止目前，已经发布的Profile包括Profile S/C/G/A/Q五种。

以上截图来源于官网https://www.onvif.org/profiles/中《ONVIF Profile Feature Overview》文档。从这个图能看出，各个Profile技术规格的发布是有时间先后顺序的，并不是一起发布。Profile S作为profile发布系列中的排头兵，于2011年发布，2016年做了一次修订，Profile C于2013年发布，之后再依次发布Profile G/A/Q。

以下是我对这些Profile的理解：

Profile S：「网络摄像机」的技术规格，包括如何发送音视频流，音视频编码器配置，PTZ控制、中继控制等。
Profile C：「门禁控制系统(PACS)设备」的技术规格。
Profile G：「视频储存和录像」的技术规格，包括视频储存，搜索，检索，以及媒体播放功能的技术规格。
Profile A：「常见的例行门禁控制功能」的技术规范，适用于负责授予和撤销员工凭证、创建和更新计划表，以及对系统内门禁控制权限进行更改的安保人员、接待员或人力资源专员等用户。
Profile Q：「传输层安全性(TLS)」的技术规格，该安全通信协议使ONVIF合标设备能够以不受篡改和窃听威胁的方式在网络上与客户通讯。
随着ONVIF的发展，我估计，ONVIF指导委员会（Steering Committee）在未来还会有后续的Profiles发布以规范其他技术规格。

跟IPC摄像头有关的主要是Profile S技术规格。

6. ONVIF接口规范
ONVIF接口被划分为不同模块，包括：设备发现、设备管理、设备输入输出服务、图像配置、媒体配置、实时流媒体、接收端配置、显示服务、事件处理、PTZ控制等。

每个模块的接口都有相对应的WSDL文档进行描述，可以在ONVIF官网「Network Interface Specifications」中查阅，链接如下：
https://www.onvif.org/profiles/specifications/

如果想快速浏览ONVIF所有模块的常用接口，请看这里「ONVIF 2.0 Service Operation Index」，链接如下：
https://www.onvif.org/onvif/ver20/util/operationIndex.html

注意：这里仅仅是列出常用接口，不是全部接口，每个模块的全部接口需要进入每个模块的WSDL中去看，点击任意一个接口就会自动跳转到对应的WSDL文档链接处。

比如说GetServices接口以上页面没有显示，但在http://www.onvif.org/ver10/device/wsdl/devicemgmt.wsdl中是的。所以想看全部的接口，还是得深入每个wsdl才行啊。

想要系统、全面的了解ONVIF的各个模块，可以阅读网上盛传的《ONVIF2.0协议珍藏版》，「点击下载」。

现在你对这些ONVIF模块、接口不熟，没关系，跟着我的专栏一步步往下走，以后就会有体会了。

7. 开发流程（不要自己造轮子）

这里先简要的介绍下IPC客户端开发流程，具体怎么操作在专栏后续文章中会陆续展示。ONVIF协议既然是Web Services框架，那就不需要自己造轮子，ONVIF协议部分由gSOAP工具帮我们自动生成代码框架。

而RTP/RTSP音视频传输部分则采用开源的FFmpge即可，FFmpge在音视频处理方面，那是首屈一指。

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