感谢博主OceanStar的学习笔记，ONVIF系列二和系列三中安装操作过程及代码实现参考了这位博主的博客。

        ONVIF系列：

        ONVIF系列一：ONVIF介绍

        ONVIF系列二：Ubuntu安装gSOAP、生成ONVIF代码框架

        ONVIF系列三：ONVIF客户端实现

1、ONVIF是什么

        视频监控领域存在的问题：
        1、厂商定制化：不同厂商的视频设备往往采用不同的通信协议和数据格式，导致设备之间难以互相兼容和集成。例如视频监控都是通过RTSP进行的音视频传输，可是每家厂商摄像头的rtsp地址格式都不一样，这样集成不同厂商之前需要首先知道这家厂商的RTSP地址格式。
        2、功能扩展不统一：尽管RTSP提供了基本的实时流媒体传输功能，但在实际应用中，视频设备可能会扩展一些额外的功能，如事件管理、设备配置等，这些功能的实现方式可能会因厂商而异，导致不同设备之间的功能扩展不统一。
        3、配置和管理不便：在配置和管理摄像头设备的时候，不同厂商会使用不同的应用协议和数据格式，还会对协议和数据格式进行私有化定制，用户可能需要针对不同厂商的设备使用不同的管理工具进行配置和管理，增加了管理的复杂性和成本。

        ONVIF的提出正是为了解决以上问题，ONVIF（Open Network Video Interface Forum）是一个全球性的开放性标准，旨在促进网络视频设备之间的互操作性。它由安迅士、博世、索尼共同创建，在2008年成立，后来一些领先的视频设备制造商、软件开发商和系统集成商也加入了进来。ONVIF致力于推动IP视频监控技术的发展，通过制定统一的网络视频接口标准，促进视频设备之间的互联互通。
        ONVIF协议对设备发现、设备配置、事件、PTZ控制、视频分析、实时流媒体直播功能(RTSP拉流)、搜索、回放、录像录音管理等功能进行了规范。

2、ONVIF Profile：

        ONVIF提供了很多的Profile，每个Profile都定义了一组特定的功能集合，支持ONVIF不需要考虑ONVIF版本只需要保持Profile一致即可互通。

        目前以下几种Profile
        Profile S应用于网络视频系统
        Profile G应用于边缘存储与检索
        Profile C应用于网络电子门禁系统
        Profile Q应用于快速安装
        Profile A应用于更广泛的访问控制配置
        Profile T应用于高级视频流
        IPC摄像头(网络摄像头)有关的主要是Profile S技术规格。

3、ONVIF开发技术框架

        ONVIF规范中设备管理和控制部分所定义的接口均以Web Services的形式提供。每一个支持ONVIF规范的终端设备均须提供与功能相应的Web Service。ONVIF中的其他部分比如音视频流则通过RTSP进行。
ONVIF = 服务端 + 客户端 =（Web Services + RTSP）+ 客户端 = （（WSDL + SOAP） + RTSP） + 客户端

        视频监控中：IPC摄像头就是一个服务端，它对外提供接口服务(Web Services)，并使用RTSP协议传输流媒体；客户端通过ONVIF协议规定的Web Services接口可以获取摄像头的RTSP地址，并通过RTSP地址拉取视频流观看视频监控、还可以根据ONVIF协议规范的Web Services接口管理摄像头。

4、Web Services

        网上对Web Services描述的很专业、很绕口，其实Web Services就是对外提供接口的一个http服务，客户端通过调用Web Services提供的接口满足自己的需求，使用的协议都是基于http的，只不过在http请求和响应报文中的负载(payload)不一样(当然我们也可以自己制定私有数据格式，只不过不被业界认可，一般都是内部使用)。

        ONVIF就是把各个功能定义出来，并且把功能对应的Web Services接口固定下来，包括数据格式，参数等，这样就形成了一套规范，各个厂商都遵循这套规范就可以互通了。

        Web Services框架有很多：REST、SOAP、JavaScript、XML-PRC等。不管哪种方式，都是基于的http协议，ONVIF中的Web Service使用的就是SOAP协议。
        SOAP协议 = RPC机制 + HTTP传输协议 + XML数据格式

4.1 RPC

        RPC 全称 Remote Procedure Call——远程过程调用。以前我们写一个函数都是在本地调用就行了。但是在项目中，大多服务都是部署在不同服务器上的分布式系统，服务之间如何调用呢？ 答案就是RPC。
        RPC技术简单说就是为了解决远程调用服务的一种技术，使得调用者像调用本地函数一样方便透明，就是让远端服务帮我们干活，并且把结果返回给我们。 下图是客户端调用远端服务的过程：

        1、客户端client发起服务调用请求。

        2、client stub 可以理解成一个代理，会将调用方法、参数按照一定格式进行封装，通过服务提供的地址，发起网络请求。

        3、消息通过网络传输到服务端。

        4、server stub接受来自socket的消息

        5、server stub将消息进行解包、告诉服务端调用的哪个服务，参数是什么

        6、结果返回给server stub。

        7、sever stub把结果进行打包交给socket

        8、socket通过网络传输消息

        9、client slub 从socket拿到消息。

        10、client stub解包消息将结果返回给client。

        在RPC框架中，client调用stub函数就和调用本地函数一样，stub函数会帮我们实现具体细节(http封包-步骤2、socket数据发送-步骤3、socker数据接收-步骤8、http解包-步骤9)，这个stub(存根)函数也不需要我们自己写，都有开源框架帮我们实现，不必造轮子。同理server只需要实现server functions实现功能即可，其他的由RPC框架完成。

4.2 SOAP消息格式

        SOAP消息以XML格式编码，一个典型的SOAP消息由以下几部分组成：

        Envelope：定义了SOAP消息的开始和结束点。
        Header   ：可选部分，包含一些元数据和扩展信息。
        Body       ：包含实际的消息内容。
        Fault       ：可选部分，用于描述错误信息。

        SOAP请求：

POST /InStock HTTP/1.1
Host: www.example.org
Content-Type: application/soap+xml; charset=utf-8
Content-Length: nnn<?xml version="1.0"?>
<soap:Envelope
xmlns:soap="http://www.w3.org/2001/12/soap-envelope"
soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding"><soap:Body xmlns:m="http://www.example.org/stock"><m:GetStockPrice><m:StockName>IBM</m:StockName></m:GetStockPrice></soap:Body></soap:Envelope>

        SOAP响应：

HTTP/1.1 200 OK
Content-Type: application/soap+xml; charset=utf-8
Content-Length: nnn<?xml version="1.0"?>
<soap:Envelope
xmlns:soap="http://www.w3.org/2001/12/soap-envelope"
soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding"><soap:Body xmlns:m="http://www.example.org/stock"><m:GetStockPriceResponse><m:Price>34.5</m:Price></m:GetStockPriceResponse></soap:Body></soap:Envelope>

        上面SOAP请求中GetStockPrice就是客户端要调用的远程RPC函数(说是服务也可以)，StockName是远程RPC函数参数，SOAP响应中GetStockPriceResponse表示对客户端的响应，也就是客户端调用GetStockPrice RPC函数的响应，SOAP中响应一般是在请求的RPC函数后面加上Response表示响应，Price是GetStockPrice函数的处理结果。由上述过程可见，RPC就是把函数功能放到远端服务器上，由客户端调用，服务器处理完把结果返回，这中间的数据传输都是由HTTP + XML完成的。ONVIF其实就是对服务端(IPC摄像头等)有哪些功能，即RPC函数以及RPC函数参数，还有客户端调用这些RPC函数的http url以及http负载中的xml应该怎么写等进行规范(这些规范都写在了WSDL文档中，将在下面介绍)，实现厂商之间互通。

4.3 WSDL

        ONVIF中的SOAP理解了，下面我们来看WSDL。
        WSDL是一种Web服务描述语言，全称Web Services Description Language，是为描述Web服务发布的XML格式。简单来说WSDL就是一个XML格式的说明文档，这个文档描述了Web Services提供哪些接口，参数是什么，前面我们提到RPC框架，帮我们实现了http数据封包解包、数据发送接收，但是这个框架怎么生成，框架应该按照什么样的格式封包解包，这就需要WSDL文档，把WSDL文档扔给框架生成工具就可以帮我们生成Web Services框架(和上面提到的RPC框架是一样的)，我们只要写好WSDL文档就有工具帮我造轮子，是不是很方便、很神奇，感谢那些在背后默默付出的攻城狮吧。
        我们的目的是学习ONVIF，不需要我们会怎么写WSDL文档，ONVIF组织已经帮我们写好了，我们只需要会用WSDL文档生成Web Services框架，会看WSDL文档中定义了哪些功能，输入及输出参数是什么即可。

        如下图所示，是ONVIF WSDL文档中定义的获取设备信息接口：

        GetDeviceInformation表示接口名字(RPC函数名字)，Description是对接口的描述。

        SOAP Action 是用于标识 SOAP 消息中将要执行的操作的一个 HTTP 头部字段，它在 SOAP 1.1 中被定义为可选的，而在 SOAP 1.2 中则被视为弃用的。通常，SOAP Action 的值是一个 URI，用于唯一地标识 SOAP 消息中的操作。

        Input表示GetDeviceInformation函数参数。

        Output表示输出参数，即GetDeviceInformation返回的结果。

        在ONVIF请求中，会把GetDeviceInformation函数名，GetDeviceInformation函数Input参数都封装到XML中(SOAP格式)，在ONVIF响应中会把Output输出结果封装到XML(SOAP格式)中并返回给ONVIF客户端。

        XML格式这里就不介绍了，相关教程有很多，推荐大家学习一下XML中的命名空间，XML命名空间和C++中的命名空间类似，是为了防止不同服务之间的命名冲突，就是在XML元素的前面加上命名空间：，命名空间是在哪里定义的要在属性中声明出来，例如上面SOAP请求中xmlns:m="http://www.example.org/stock"就是声明这个命名空间是在哪里定义的，并给命名空间起一个别名为m，m:GetStockPrice表示调用http://www.example.org/stock里面定义的GetStockPrice，而不是其他地方定义的GetStockPrice，这样就防止了不同服务之前的命名冲突和歧义。

5、ONVIF WSDL文档

        ONVIF接口被划分为不同模块，包括：设备发现、设备管理、设备输入输出服务、图像配置、媒体配置、实时流媒体、接收端配置、显示服务、事件处理、PTZ控制等(不同的Profile包含了不同的模块)。每个模块都提供一个WSDL文档，我们拿到WSDL文档就可以开发了，ONVIF WSDL文档获取地址：https://www.onvif.org/profiles/specifications/
        ONVIF开发中最常用的Web Services框架生成工具是gSOAP，拿到ONVIF的WSDL文档，gSOAP就可以帮我们生成客户端和服务端的代码框架，gSOAP一种跨平台的开源的C/C++软件开发工具包，可以生成C/C++的SOAP Web Service/Client代码，实现XML数据绑定(不需要我们自己封装XML，苦力活都交给gSOAP生成的代码框架完成)。gSOAP支持大多数平台，包括嵌入式系统和小系统(例如嵌入式Symbian，Palm)。gSOAP安装使用将在ONVIF系列二介绍。

        ONVIF的开发技术栈如下图所示：