目录
这篇文章是对ONVIF规范的一些重要知识点进行总结，便于快速的对ONVIF规范有一个整体的理解， 文中参考、引用了许多专业的博客，在此特别感谢。
ONVIF规范介绍
ONVIF：Open Network Video Interface Forum，开放型网络视频接口论坛
ONVIF规范的目标是实现一个网络视频框架协议，使不同厂商所生产的网络视频产品（包括摄录前端、录像设备等）完全互通，这一定位和笔者曾经实现的国际标准协议IEC62056是一致的， 只不过IEC62056是针对电力行业，用于统一电力行业各种表计的设计规范，使得不同厂家产品做到互联互通， 二者在产品互联互通方面的设计思路是很相近的，其中ONVIF基于web service，以WSDL语言描述对象操作接口，IEC62056则采用ASN语言统一描述设备对象，并提供协议接口对对象进行操作，二者同样提供了设备能力发现的接口。
ONVIF规范描述了网络视频的模型、接口、数据类型以及数据交互的模式，并复用了一些现有的标准，如WS系列标准等。ONVIF接口被划分为不同模块，包括：设备发现、设备管理、设备输入输出服务、图像配置、媒体配置、实时流媒体、接收端配置、显示服务、事件处理、PTZ控制等。
ONVIF网络视频协议的出现，解决了不同厂商之间开发的各类设备不能融合使用的难题，提供了统一的网络视频开发标准，即最终能够通过ONVIF这个标准化的平台实现不同产品之间的集成。在安防监控行业，ONVIF协议将会在较长时间内成为网络视频领域的首选。
ONVIF规范中的设备管理和控制部分所定义的接口均以Web service形式提供， 音视频流采用成熟的RTSP协议进行管理，如下图所示：
类似蓝牙协议， ONVIF规范也划分了很多种profile，每一种profile针对一类特定的设备品类。各个Profile技术规格也不是一起发布的。Profile S作为profile发布系列中的排头兵，于2011年发布，2016年做了一次修订，Profile C于2013年发布，之后再依次发布Profile G/A/Q。
Profile S：「网络摄像机」的技术规格，包括如何发送音视频流，音视频编码器配置，PTZ控制、中继控制等。
Profile C：「门禁控制系统(PACS)设备」的技术规格。
Profile G：「视频储存和录像」的技术规格，包括视频储存，搜索，检索，以及媒体播放功能的技术规格。
Profile A：「常见的例行门禁控制功能」的技术规范，适用于负责授予和撤销员工凭证、创建和更新计划表，以及对系统内门禁控制权限进行更改的安保人员、接待员或人力资源专员等用户。
Profile Q：「传输层安全性(TLS)」的技术规格，该安全通信协议使ONVIF合标设备能够以不受篡改和窃听威胁的方式在网络上与客户通讯。
随着ONVIF的发展，ONVIF指导委员会（Steering Committee）在未来也许还会有后续的Profiles发布以规范其他技术规格。
其中，跟IPC摄像头有关的主要是Profile S技术规格。
ONVIF 2.0 Service Operation Index
接下来，重点介绍Web service与RTSP。
Web Service
Web service介绍
WebService是一种跨编程语言和跨操作系统平台的远程调用技术。彻底理解web service
web service常用的框架(也就是实现web service的方式)：
ONVIF标准中的Web Service采用的是SOAP方式
WSDL
WSDL（网络服务描述语言，Web Services Description Language）是一门基于 XML 的语言，用于描述 Web Services 以及如何对它们进行访问 的语言。
事实上， WSDL只是一种基于xml的语言。使用WSDL语言描述Web service的一个优势是，我们可以使用编译工具gSOAP将直接编译为C/C++代码，对开发者而言，避免重复造轮子。
SOAP
SOAP是web service的一种实现方式。
SOAP（Simple Object Access Protoco，简单对象访问协议），是TCP/IP协议体系中的一个应用层协议，它是在HTTP基础之上实现的。
SOAP协议 = RPC机制 + HTTP传输协议 + XML数据格式
SOAP的两个主要设计目标是「简单性」和「可扩展性」，SOAP的设计正是围绕这两点展开的。
SOAP使用RPC机制，体现了「简单性」。让客户端调用Web Service的接口看起来像本地调用一样，确实很简单。
SOAP 使用 HTTP 传送 XML，体现了「可扩展性」。尽管HTTP 不是有效率的通讯协议，而且 XML 还需要额外的文件解析（parse），两者使得交易的速度大大低于其它方案。但是XML 是一个开放、健全、有语义的讯息机制，而 HTTP 成熟、稳定、又能避免许多关于防火墙的问题，从而使SOAP得到了广泛的应用。
RTSP
网上关于rtsp介绍的文章非常多，这里仅概要介绍RTSP。
RTSP是基于tcp/udp的应用层协议，在开发过程中，需要我们将数据打包成RTSP格式，然后交给tcp/udp传输(类似http)
RTSP消息格式
RTSP的消息有两大类 --- 请求消息(request), 回应消息(response)。
请求消息：
方法 URI RTSP版本 CR LF
消息头 CR LF CR LF
消息体 CR LF 其中方法包括OPTION回应中所有的命令,URI是接受方的地址,例如:rtsp://192.168.1.111。RTSP版本一般都是 RTSP/1.0。每行后面的CR LF表示回车换行，需要接受端有相应的解析，最后一个消息头需要有两个CR LF
回应消息：
RTSP版本 状态码 解释 CR LF
消息头 CR LF CR LF
消息体 CR LF 其中RTSP版本一般都是RTSP/1.0, 状态码是一个数值, 200表示成功, 解释是与状态码对应的文本解释.
状态码由三位数组成，表示方法执行的结果，定义如下：
1XX：保留，将来使用；
2XX：成功，操作被接收、理解、接受（received,understand,accepted）；
3XX：重定向，要完成操作必须进行进一步操作；
4XX：客户端出错，请求有语法错误或无法实现；
5XX：服务器出错，服务器无法实现合法的请求。
rtsp交互过程
C表示rtsp客户端, S表示rtsp服务端
rtsp中定义的方法有：OPTIONS, DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE, SCALE, GET_PARAMETER ，SET_PARAMETER
一次交互过程可以包括：
1. OPTION
C->S:OPTION request //询问S有哪些方法可用
S->C:OPTION response //S回应信息中包括提供的所有可用方法2. DESCRIBE
C->S:DESCRIBE request //要求得到S提供的媒体初始化描述信息
S->C:DESCRIBE response //S回应媒体初始化描述信息，主要是sdp3. SETUP
C->S:SETUP request //设置会话的属性，以及传输模式，提醒S建立会话
S->C:SETUP response //S建立会话，返回会话标识符，以及会话相关信息4. PLAY
C->S:PLAY request //C请求播放
S->C:PLAY response //S回应该请求的信息
S->C:经过以上步骤， 服务器会向客户端发送流媒体数据5. TEARDOWN
C->S:TEARDOWN request //C请求关闭会话
S->C:TEARDOWN response //S回应该请求上述的过程是标准的、友好的rtsp流程，但实际的需求中并不一定按部就班来。 其 中第3和4步是必需的！第一步，只要服务器客户端约定好，有哪些方法可用，则option请求可以不要。第二步，如果我们有其他途径得到媒体初始化描述信 息（比如http请求等等），则我们也不需要通过rtsp中的describe请求来完成。第五步，可以根据系统需求的设计来决定是否需要。
ONVIF项目开发流程
基于ONVIF规范的项目的基本开发流程：
1. 获取wsdl文件
2. 通过gSOAP编译为c/c++文件：ONVIF框架代码生成
3. 业务逻辑开发，音视频流可以采用ffmpeg开发
4. 发布
致谢
特别感谢无私奉献的博主们:
2万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
