简单讲，两者都是用于安防行业的视频监控，是可以将不同厂商生产的网络视频相关产品互联互通的一套接口标准。
网络视频相关产品包括：NVR(Network Video Recorder) 网络视频录像机、网络摄像机、网络视频显示设备、等等
目前国内相关安防行业的视频监控设备厂商的产品,基本GB28181和ONVIF都支持。
表格总结
| 组织 | 协议规范实现 | 互联 | 功能 | 规范文档 | 可用工具 | |
|---|---|---|---|---|---|---|
| ONVIF | 全球性： 由安讯士（AXIS）、博世（BOSCH）、索尼（SONY）三家公司联合提出 | 基于 Web Service（XML、SOAP,WSDL）技术实现 | 支持设备之间、系统平台层互联 | 功能完备，兼容性强 | 规范详细，核心规范、profile规范、一致性过程规范、WSDL规范、XML规范等 | GOSP工具可生成框架代码、测试工具 |
| GB28181 | 国内： 由中国国家标准委员会制定 | 基于SIP协议 | 支持设备之间，系统平台层互联，主要还有上下级互联功能 | 相比功能较少 | 仅有一个国标文档可参考 | 无 |
下面对两者分开进行简单介绍：
ONVIF
概述
开放型网络视频接口论坛（Open Network Video Interface Forum）: 由安讯士（AXIS）联合博世（BOSCH）及索尼（SONY）公司三方宣布携手共同成立一个国际开放型网络视频产品标准网络接口开发论坛
适用于局域网和广域网。将网络视频设备之间的信息交换定义为一套通用规范。使不同设备厂商提供的产品，通过统一的接口通信成为可能。
规范所涵盖的阶段 ：从网络视频设备的部署阶段, 配置阶段,实时流阶段等
规范涉及到的主要功能：设备发现、设备配置、事件、PTZ控制、 视频分析，和实时媒体直播功能、以及搜索、回放，录像管理功能 (详细功能可看下图1)
目标：实现一个网络视频框架协议，使不同厂商生产的视频设备完全互通
图1：
协议规范实现（Web Service）
ONVIF所有的管理和配置指令都是基于Web Service技术实现。Web Service 是一种服务导向架构技术，通过标准的web协议提供服务，目的是保证不同平台的应用服务可互操作性。
主要借助几个技术
- XML 用于描述数据
- SOAP （Simple Object Access Protocol）一种轻量的简单的、基于XML的消息传递协议
- WSDL 用于描述服务（是一种XML格式的文档）
- UDDI 统一描述、发现和集成，可以对Web Service进行注册和搜索
简单讲：Web Service是基于XML和HTTP的一种服务，客户端和服务端通信协议为SOAP。客户端根据WSDL描述文档，生成一个SOAP请求消息，此消息以XML的格式嵌在HTTP请求的body体中，发送到服务端。
ONVIF所有的媒体流传输都是借助于RTP/RTSP实现。
具体的协议结构
ONVIF互联方式
由上节可知，ONVIF的两端的信令通过SOAP消息传递， 媒体流通过RTP/RTSP传输。
ONVIF的设备发现方式
借助于WS-Discovery(Web Services Dynamic Discovery) 实现：
两种模式：
- 采用广播形式的Ad-Hoc服务发现模式， 可用的目标服务的范围往往只能局限于一个较小的网络
- Managed模式。在Managed模式下，一个维护所有可用目标服务的中心发现代理（Discovery Proxy）被建立起来，客户端只需要将探测消息发送到该发现代理就可以得到相应的目标服务信息
Ad-Hoc服务发现模式
1.目标服务在上线和离线的时候以广播的形式分别发送一个Hello和Bye消息
2. 如果客户端需要通过获取当前可用的目标服务，需要以广播的形式发送一个Probe消息，该消息包含用以探测的目标服务所满足的条件
3. 接受该广播的目标服务，如果自身满足包含Probe消息中的条件，则可以单播的形式回复给客户端一个Probe Mtach(简称PM)消息
4. 如果客户端从PM消息中获取的关于目标服务的相关的信息足以对其进行调用，则不需要进行后续的信息交换 ,否则（比如获取的PM消息中没有包含目标服务的地址）还需要进行一次旨在实现最终服务调用的服务解析（Resolution）的信息交换。具体来说，客户端以广播的形式发送Resolve请求
5. 真正的目标服务（包含在Resolve消息中用以解析的服务）将包含自身地址在内的信息以Resolve Match(简称PM)消息的形式回复给客户端
Managed模式
Discovery Proxy：
由于可用的服务都注册到发现代理中，客户端只需要和发现代理交互就可以进行可用服务的探测和解析，而目标服务只需要和直接和发现代理交换就能实现自身的注册
好处：
可以解除广播对网络的限制，扩大可用服务的范围。
ONVIF实时流过程简述
媒体配置是通过SOAP/HTTP协议完成的。
媒体控制通过在RFC 2326中定义的RTSP协议完成，这个标准利用了RTP，RTCP和RTSP协议分析，以及基于RTP扩展的JPEG和组播控制机制 .
ONVIF 协议所定义的媒体流播放 遵循RTSP协议通信协议过程，主要由RTSP协议所定义的OPTIONS, DESCRBIE, SETUP, PLAY, GET_PARMETER/TEARDOWN几个命令完成
服务开发的基本原则
服务供应者（设备）实现ONVIF的服务或者其它服务，这些服务采用基于XML的WSDL语言进行描述， 然后，由WSDL描述的文档将作为服务请求（客户端）实现或者整合的基础。
WSDL编译工具WSDL Compiler的使用简化了客户端的整合过程，WSDL编译工具能生成与平台相关的代码，也就是说，客户端开发者可以通过这些代码把web服务整合到应用程序中。
以上仅对ONVIF相关内容进行了简单概述，具体详情可参考官网
参考连接：
https://www.onvif.org/
https://www.onvif.org/profiles/specifications/
https://www.onvif.org/specs/stream/ONVIF-Streaming-Spec.pdf
https://www.cnblogs.com/zhijianliutang/archive/2011/12/22/2297537.html
GB28181
概述
全称：公共安全视频监控联网系统信息传输、交换、控制技术要求
规范内容： 规定了公共安全视频监控联网系统的互联结构，传输、交换、控制的基本要求和安全要求，以及控制、传输流程、和协议接口等技术要求
发布单位： 中华人民共和国国家质量监督检验检疫总局、中国国家标准化管理委员会
主管单位： 公安部（设备等平台的接入，需要去公安部相关部门调试）
提出的背景：各地建设平安城市，为了将各地的不同监控系统统一整合，统一管理而提出
目前有两个版本：GB/T 28181-2016 和 GB/T 28181-2011（已废止）
规范涉及的内容：
协议规范实现
所有的管理和配置指令基于SIP（session initiation protocol）协议， 会话初始协议实现.
SIP(Session Initiation Protocol)是一个应用层的信令控制协议。用于创建、修改和释放一个或多个参与者的会话。这些会话可以是Internet多媒体会议 [3] 、IP电话或多媒体分发。会话的参与者可以通过组播（multicast）、网状单播（unicast）或两者的混合体进行通信.
SIP协议是一个Client/Sever协议，从HTTP协议以及SMTP(简单邮件传输协议)演变而来，因此SIP消息分两种：请求消息和响应消息。请求消息是SIP客户端为了激活特定操作而发给服务器端的消息。常用的SIP请求消息如下：
Method Request-URI SIP-VERSION
field-name1: field-value1
field-name2: field-value2
其中Method有:
INVITE：表示主叫用户发起会话请求，邀请其他用户加入一个会话。也可以用在呼叫建立后用于更新会话（此时该INVITE又称为Re-invite）。
ACK：客户端向服务器端证实它已经收到了对INVITE请求的最终响应。
PRACK：表示对1xx响应消息的确认请求消息。
BYE：表示终止一个已经建立的呼叫。
CANCEL：表示在收到对请求的最终响应之前取消该请求，对于已完成的请求则无影响。
REGISTER：表示客户端向SIP服务器端注册列在To字段中的地址信息。
MESSAGE: 消息控制
OPTIONS：表示查询被叫的相关信息和功能。
应答消息也类似于http，有具体的状态码定义，详情可看rfc3261
SIP 会话使用多达四个主要组件：SIP 用户代理、SIP 注册服务器、SIP 代理服务器和 SIP 重定向服务器。这些系统通过传输包括了 SDP 协议（用于定义消息的内容和特点）的消息来完成 SIP 会话.
用户代理
SIP 用户代理(UA) 是终端用户设备，如用于创建和管理 SIP 会话的移动电话、多媒体手持设备、PC、PDA 等。用户代理客户机（UAC）发出消息。用户代理服务器对消息进行响应。
注册服务器
SIP 注册服务器是包含域中所有用户代理的位置的数据库。在 SIP 通信中，这些服务器会检索出对方的 IP 地址和其他相关信息，并将其发送到 SIP 代理服务器。
代理服务器
SIP 代理服务器接受 SIP UA 的会话请求并查询 SIP 注册服务器，获取收件方 UA 的地址信息。然后，它将会话邀请信息直接转发给收件方 UA（如果它位于同一域中）或代理服务器（如果 UA 位于另一域中）。
重定向服务器
SIP 重定向服务器允许 SIP 代理服务器将 SIP 会话邀请信息定向到外部域。SIP 重定向服务器可以与 SIP 注册服务器和 SIP 代理服务器同在一个硬件
简单讲：GB28181借助SIP协议完成信令控制，sip协议中有注册、会话邀请、消息控制，SDP会话描述协议等可以完成设备的注册，实时流请求，PTZ控制等
GB28181的媒体流传输借助于RTP/RTSP实现
具体的协议结构
互联方式及结构
GB28181有级联结构，支持国标的小区或者工厂 -> 县级国标平台 ->省级国标平台，可逐及接入。
各平台的监控域大致角色及互联方式如下：
其中：
中心信令服务器：每个监控域都会有一个中心信令服务器，负责监控域中的设备的注册，以及信令的控制处理
流媒体服务器: 支持SIP信令并接受前端设备IPC等视频流数据处理。外部查看视频流都是通过媒体服务器。
SIP设备：一般为支持SIP协议的前端设备，IPC、NVR等
SIP客户端：支持SIP协议的控制端，解码设备等，可发起设备控制、视频流拉取等
信令安全路由网关: 两个GB28181平台间认证等处理。
说明：如果是GB28181平台与非GB28181平台互联，还需要信令转换网关、流媒体网关。
设备注册
图中：
SIP服务器：即为中心信令服务器
SIP代理: 可为IPC、NVR、媒体服务器、下级信令服务器等
SIP代理设备或者系统进入联网系统时需要先向sip服务器注册，每个设备都有个全局唯一性编码
注册过程简述：
所有设备上线时，先向配置好的注册服务器发起注册，注册服务器记录下来相关设备的ID，ip等相关信息。存储下来以供查询；所有设备会定期保活，下线后应取消注册等。
相关说明：
- 设备编码： 国标定义每个设备都必须有个全局的20位的10进制数字编码
- SIP URL: sip[s]:username@domain; uri-parameers 其中，username命名应保证同一个SIP监控域内具有唯一性，宜采用6.1.1规定的ID统一编码；domain宜采用ID统一编码的前10位编码扩展支持编码加”spvmn.cn”后缀格式、或者IP格式，port宜采用5060
注册流程的消息示范：
REGISTER sip：SIP服务器编码@目的域名或IP地址端口 SIP/2.0
Via：SIP/2.0/UDP 源域名或IP地址端口
From：<sip：SIP设备编码@源域名>;tag=185326220
To：<sip：SIP设备编码@源域名>
Call-ID：msl214-322164710-6812621-31542511-620107-0@172.18.16.3
CSeq：1 REGISTER
Contact：<sip：SIP设备编码@源IP地址端口>
Max-Forwards：70
Expires：3600
Content-Length：0
SIP/2.0 401 Unauthorized
To：<sip：SIP设备编码@源域名>
Content-Length：0
CSeq：l REGISTER
Call-ID：msl214-322164710-6812621-31542511-620107-0@172.18.16.3
From：<sip：SIP设备编码@源域名>；tag=185326220
Via：SIP/2．0/UDP 源域名或IP地址端口
WWW-Authenticate: Digest realm="64010000",nonce="6fe9ba44a76be22a"
REGISTER sip：SIP服务器编码@目的域名或IP地址端口 SIP/2.0
Via：SIP/2.0/UDP 源域名或IP地址端口
From：<sip：SIP设备编码@源域名>;tag=185326220
To：<sip：SIP设备编码@源域名>
Call-ID：msl214-322164710-6812621-31542511-620107-0@172.18.16.3
CSeq：2 REGlSTER
Contact：<sip：SIP设备编码@源IP地址端口>
Authorization：Digest username="6401000000202000000l",realm="64010000",nonce
="6fe9ba44a76be22a",uri="sip：6401000000200000000l@172.18.16.5：5060",response="9625d92d1bddea7a911926eodb054968",algorithm=MD5
Max Forwards：70
Expires：3600
Content-Length：0
SIP/2.0 200 OK
To：<sip：SIP设备编码@源域名>; tag=69113a2a
Contact：sip：SIP设备编码@源IP地址端口
Content-Length：0
CSeq：2 REGISTER
Call-ID：msl214-322164710-6812621-31542511-620107-0@172.18.16.3
From：<sip：SIP设备编码@源域名>;tag=185326220
Via：SIP/2.0/UDP 源域名或IP地址端口
Date：2010-11-02T15：01：26.115
Expires：3600
实时流请求过程
媒体请求过程通过SIP协议的INVTE, ACK, BYE 类型消息和 SDP协议（描述会话）来实现会话连接，并通过采用RTP/RTCP协议实现媒体传输
SIP服务器(中心信令服务器），会收到媒体接收者的请求，通过请求信息中的设备ID等信息，找到前端IPC设备的ip地址等信息，并通过SIP-B2B代理方式，先与媒体服务器协商端口，编码等信息，再将相关信息通过sdp发给媒体发送者（前端IPC设备等），待媒体发送者将视频流发送给媒体服务器后，再协商建立媒体服务器和媒体接受者之前的会话连接，最终媒体服务器将流推给媒体接收者。 具体过程如下：
以上仅简单介绍GB28181定义的小部分功能。其他详情可看GB28181文档：
参考：
http://c.gb688.cn/bzgk/gb/showGb?type=online&hcno=469659DC56B9B8187671FF08748CEC89
开发与实现
从GB28181相关文档定义，可能需实现的组件包括：
- 设备端SDK支持
- 实现中心信令服务器
- 支持SIP的流媒体服务器
- 若有非国标平台接入，还需实现信令转换网关、流媒体网关等。
以上组件都需要支持SIP相关功能。 SIP相关介绍及相关开源库的调研，后续会专门介绍。