随着视频监控的网络化应用，产业链的分工将越来越细。有些厂商专门做摄像头，有些厂商专门做DVS，有些厂商则可能专门做平台等，然后通过集成商进行集成，提供给最终客户。这种产业合作模式，已经迫切的需要行业提供越来越标准化的接口平台。2008年5月，由安讯士联合博世及索尼公司三方宣布将携手共同成立一个国际开放型网络视频产品标准网络接口开发论坛，取名为ONVIF（Open Network Video Interface Forum，开放型网络视频接口论坛），并以公开、开放的原则共同制定开放性行业标准。

2008年11月，论坛正式发布了ONVIF第一版规范——ONVIF核心规范1.0。

2、Onvif协议概述及优势

2.1 协议概述

ONVIF标准将为网络视频设备之间的信息交换定义通用协议，包括装置搜寻、实时视频、音频、元数据和控制信息等。网络视频产品由此所能提供的多种可能性，使终端用户，集成商，顾问和生产厂商能够轻松地从中获益，并获得高性价比、更灵活的解决方案、市场扩张的机会以及更低的风险。

ONVIF规范描述了网络视频的模型、接口、数据类型以及数据交互的模式。并复用了一些现有的标准，如WS系列标准等。ONVIF规范的目标是实现一个网络视频框架协议，使不同厂商所生产的网络视频产品（包括摄录前端、录像设备等）完全互通。

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

2.2、规范优势

协同性：不同厂商所提供的产品，均可以通过一个统一的“语言”来进行交流。方便了系统的集成。
灵活性：终端用户和集成用户不需要被某些设备的固有解决方案所束缚。大大降低了开发成本。
质量保证：不断扩展的规范将由市场来导向，遵循规范的同时也满足主流的用户需求。

2.3、Onvif模块构成及描述

2.4、协议结构和功能

Onvif是一个协议族，采用了很多成熟的技术。如下图所示：

协议分为控制面、媒体面两大部分。

媒体面，主要负责视频、音频码流的传输，协议采用了标准的RTP/RTCP协议。为了适应不同的网络环境，RTP/RTCP下层，可以采用UDP、TCP、RTSP等。

控制面，主要分成两部分：

1）媒体会话的控制，这部分采用标准的RTSP协议；
2）设备控制、媒体配置部分，这是Onvif协议中最复杂的部分，是Onvif协议的精髓所在。采用了web service，采用http+soap传输协议。

基于web service协议带来了以下的优点：

1）方便部署。http协议是使用最广泛的协议，对于存在NAT、防火墙的场所，可以使用http相关已经很成熟的技术；
2）模块化。Web service是一个协议框架，它特别的优点是模块快、可扩展。Onvif选择基于web service，可以利用其中很多已经定义好的协议，无需再单独定义新的协议。例如Onvif中：用户登录就采用了WS-Security协议、设备搜索使用了WS-Discovery协议、事件通知使用了WS-BaseNotification协议。
3）可扩展。Web servce广泛采用了XML的namespace技术，从设计开始，就将可扩展作为其核心的需求。
4）方便开发。业界已经有很多的工具，只要提供wsdl描述文件，就可以利用工具，自动生成对应的客户端访问接口、服务端框架。下图是基于Web service开发的示意图：

Onvif协议的具体功能有：

1）设备搜索；
2）设备管理：
a）能力集
b）系统管理
c）网络管理
d）安全性
e）输入、输出
3）图像配置
4）媒体配置
5）媒体流管理
6）事件管理
7）PTZ控制
8）视频分析

3、Onvif协议请求的基本流程

下面举一个简单例子，从一个Onvif IPC上电，到能看到视频图像的基本流程，来描述Onvif的基本流程：

1）搜索设备，获取设备的IP地址；
2）获取设备的能力集，通过能力集可以得知设备支持的功能，以及一些能力参数；
3）查询设备所有的profile，找到我们感兴趣的profile；
4）获取目标profile对应的rtsp URL；
5）发起rtsp链接，并请求对应的码流；
6）建立rtp链接，接受码流。

上述步骤中，1-4是采用web service完成。与我们现在流程有一个很大的不同，我们VSIP协议，是前端主动登录监控系统，而在Onvif协议中，是监控系统主动登录IPC。

4、Onvif测试工具的使用方法

4.1、Onvif device manager工具的使用方法

ONVIF Device Manage工具主要用来验证设备是否支持onvif，实时预览、PTZ控制及远程配置IPC参数等功能。

4.1.1、ONVIF Device Manage安装：

1）PC安装环境要求：装有Microsoft .Net Framework 4.0版本
2）安装源文件请见：ONVIF Device Manage.rar
注：Microsoft .Net Framework 4.0安装不成功的解决方式，见备注。

4.1.2、ONVIF Device Manage的使用：
1）运行工具
双击ONVIF Device Manage快捷方式，运行工具。当前局域网内，支持onvif协议的IPC可以自动显示出来，见下图。Device List列表即检索到的IPC列表

2）基本功能介绍

a.登录
此时输入的用户名和密码为设备自身的用户名和密码，有的厂家设备不需要。输入正确的用户名和密码，即可实时预览IPC及参数配置。
b.实时预览
在设备列表选择一个IPC（单击即可），点击Live video即可预览该IPC画面，main stream是主码流预览，sub stream是子码流预览：

c.检索
在Device List区域的文本框输入IP地址，即可过滤其它IPC，留下符合条件的设备。

d.手动增加
点击Add按钮，输入url，例如http://192.168.1.123/onvif/device_service，点击Apply，即可手动增加IPC：

e.rtsp路径

实时预览画面的下方，会显示rtsp路径。如下：
rtsp://192.168.1.166:5504/channel=0;stream=0;user=system;pass=system
192.168.1.166为IPC的地址
5504为IPC的端口
channel为通道
stream为码流，0默认是主码流，1为子码流
user和pass：用户名和密码

f.视频编码配置

选择子码流预览，可以配置子码流的编码参数

g.码流选择

点击Profiles，进入码流切换界面：

Create为创建码流；Edit为编辑码流用；

h.PTZ控制
点击方向键：

4.1.3、测试结果

如果通过上述工具可以搜到该设备，说明此设备支持ONVIF。

如果说明书或厂家说是该设备支持ONVIF，但是搜索不到。可以通过IE或厂家自己的配置工具登陆该设备，看ONVIF支持是否开启，有些厂家的设备ONVIF支持是可选的。

备注：
1.Microsoft .Net Framework 4.0安装不成功的解决方式

安装失败和windows update有关系
按如下操作，即可安装成功：
1.按组合键win+R，打开运行，输入cmd，回车，在输入net stop wuauserv，回车，即停止了update的服务；
2.打开C盘根目录下的“Windows”文件夹，找到SoftwareDistribution文件夹，将其重命名为SDold；
3.按组合键win+R，打开运行，输入cmd，回车，在输入net start wuauserv，回车，即启动了update的服务；
4.现在安装.net framework 4.0就会成功了。

4.2、VLC测试工具的使用

1）打开VLC软件，并点击首选项：

2）更改为RTP，保存后关闭VLC播放器，重新打开：

3）打开网络串流

4）输入RTSP码流的地址，比如我们摄像机的RTSP码流地址为rtsp://10.75.7.123/id=0
10.75.7.123这里是举例，具体IP地址为现场使用的实际IP地址。
id=0 是为主流视频码流，id=1是为辅流视频码流。

5、Onvif常见问题排查

5.1、DeviceManager异常分析和处理

举例：手动时间同步问题
现象：更改时区信息，无法同步IPC时间
协议接口: GetSystemDateAndTime和SetSystemDateAndTime

一般处理流程：
1、登入WEB IPC设置IPC的时区为东8区，使用测试工具GetSystemDateAndTime获取到IPC时间信息。

2、报文解析：

1）DateTimeType->Manual:手动设置时间同步(和NTP设置互斥，协议有规约)；
2）DaylightSavings->false:不支持夏日制，如支持hour+1;
3）TZ->GTM+8：东八区，此处是经常出问题的地方，因为各个ipc厂家的时区采用的标识不同，往往会出现设置时区下去，IPC回复200 OK，但是时间并无法生效的问题。此时需要将此部分通过测试工具的SetSystemDateAndTime接口设置给IPC，查看最终是否可以在IPC上看到时间生效；如果使用相同的时区信息设置下去，无法使IPC时间生效，可以直接断定是IPC的问题。
4）UTCDateTime->UTC时间， UTC时间加上时区偏移，是最终在IPC上显示的时间。
5）LocalDateTime->Local时间，暂时不用关注；

【需要注意的点】在时间同步问题排查时，我们禁止将同一台IPC接入不同的NVR，因为不同的NVR有可能都会给IPC发送时间同步，并且我们无法保证，发送的时机、参数设置上能保证统一，此时往往就会出现时间不断的来回跳变，给排查定位带来困难。

5.2、Media异常分析和处理

举例： ONVIF接入分辨率列表显示比VSIP接入分辨率列表要少。
现象：同一款IPC使用vsip协议接入和onvif协议接入同一台NVR会出现，上报的分辨率不同(不提倡使用不同协议接入同一台NVR，因协议对通不同，此处支持排查时作为参考)。
协议接口: GetProfiles -> GetVideoEncoderConfigurationOptions
一般处理流程：

获取到信息：有2路码流,取其中一路

获取到的信息：
视/音频源、视/音频编码、视频分析、ptz配置token；因为处理的是视频编码参数分辨率异常，需要取VideoEncoderConfiguration的token 000

处理方法：使用OnvifTestTool的接口，GetVideoEncoderConfigurationOptions

得到报文：

将上述报文中h264的编码格式分辨率和WEB IPC上对比下，如果WEB IPC有的，但是报
文中又没有上报，认为是IPC的问题，如果有上报，但是在NVR上显示异常，则是NVR的。

5.3、Event异常分析和处理

举例：对接hik ipc无法收到告警内容
现象：使用pullmsg方式获取海康ipc告警内容失败，前端本身有产生告警信息
协议接口:PullMessages

处理方式：
1、使用测试工具得到标准报文：

2、我司NVR发送报文格式：

翻看Onvif协议标准未对此处pullmsg的post对象部分有详细的报文格式描述，post消息时需要携带subscribe的endpoint部分信息。此时，我们采用OnvifTestTool的诊断功能(见下文，OnvifTestTool的标准报文获取中提到操作方式)，获取到详细的参考报文。采用此种报文格式进行拼写，即可以正常接入。

一般，当我们遇到一些不明白的问题，首先想到的是翻看标准协议文档，当协议文档也未进行详细的描述时，往往就采用测试工具的参考报文。比较参考报文后，找出不同点，进行修正。通过这种方式，也可以直接发现报文在格式、请求方式、交互内容上，有个比较全面的把握。当然，如果测试工具诊断在IPC的某个功能上，无法进行有效的交互时，我们会认为此种情况下，IPC是不支持此种功能的。

5.4、Imaging异常分析和处理

Imaging参数异常定位比较简单，此部分仅列出相关接口，使用测试工具进行验证，目前外部
有遇到的问题，只有设置回复200 OK，但是前端参数不生效的问题，仅需要使用测试工具即可支持验证；

协议接口: GetImagingSettings和SetImagingSettings

5.5、PTZ异常分析和处理

举例：onvif bosch球机，ptz控制出现无法控制八个方向移动的问题，控制其他厂家的ipc是可控的。协议中规定，八个方向移动是使用ContinuousMove接口实现，所以，我们只需要分析这个接口即可。

处理方式：
NVR->IPC请求报文：

从请求报文中，我们可以获取到的信息一个是操作的PorfileToken，一个是设置的参数超时时间30s，这两个参数是我们设置给IPC的，还有400错误提示。

IPC->NVR回复报文：

从中，我们可以获取到的信息，参数有异常，具体为时间参数异常，即NVR设置给IPC的，超时
时间参数30s，IPC认为参数不合理。此时，我们需要使用测试工具，进行修改延时参数，达到
控制效果，对bosch的IPC进行特殊处理，达到控制的目的。

以下是延时参数修正为60s后的报文：

在PTZ控制中报文中的：

简要描述如下：

PanTilt和Zoom中的space后面的字符串是相对比较重要的，这个是ipc进行ptz控制的坐标系，后面传的x,y,z分别对应着水平，偏移，聚焦参数，如果对应的坐标系不同，往往得到的控制效果是不同的。

在测试工具中,使用GetServices可以获取到所有的能力集，其中ptz部分包含，relativemove和absolutemove的坐标系，如下截图所示：

协议规约上，需要坐标系对应控制，当然，因IPC具体实现的情况不同，有时候也仅仅识别continuesmove的坐标系，因为需要对接，也只能特殊处理，进行接入控制。

5.6、使用user name token方式验证不通过

表现：服务器返回400错误（ter:NotAuthorized）。
解决：检查用户名和密码是否正确，客户端和服务器端的时间是否一致。

5.7、Digest 验证不通过

表现：目前只是在Onvifstack里实现了digest的验证方式。在服务器返回401错误的时候，
Onvifstack会用401头部WWW-Authenticate携带的参数和密码来计算出response.但是当计算出的response不正确的时候服务器还会返回401错误。
解决：后续我会提供一个标准的我计算出response的工具来排查这种问题，最后的解决需要修改相应的代码。