GB28181学习总结

GB28181学习总结

前言

我认为，学习一个新东西可以分成两步：

1. 作用是什么？

2. 原理是什么？

所以本文将从两个问题出发，对GB28181进行总结：

1. GB28181是什么？

2. GB28181原理是什么？

GB28181是什么？

我们可以从海康产品的设备出发，看看他们是怎么在设备上配置GB28181的。进而可以了解到GB28181的作用。参考文章

总结下来核心有四步：

1. 给IPC配置一个能访问互联网的IP地址。

2. 获取设备在访问SIP服务器时所需的必要参数，包括：SIP服务器ID、SIP服务器地址、SIP服务器端口、SIP用户名、SIP用户密码等。

3. 将在第二步当中获取的参数填进IPC，并配置IPC开启GB28181适配。

4. 如果设备和SIP服务器之间网络是通的，几秒内就会注册到SIP服务器，这时NTVGBS的管理界面上，这个设备是点亮状态，表示已连接，就可以观看监控视频了。

从第4点我们可以猜测到：GB28181能让IPC摆脱局域网的限制，在互联网任何位置都能被访问。

那么GB28181和SIP关系是什么？经过了解，SIP和HTTP都是由国际互联网协会（IETF）制定，SIP同属于应用层协议，报文格式和HTTP非常类似，由三部分组成：起始行(start line) + 二是消息头部(message head) + 消息体（message body）。所不同的是，SIP支持两种传输方式：TCP、UDP。

而所谓GB28181，其实就是在监控领域，建立、管理和控制视频监控设备和系统的SIP协议交互的规范。

GB28181原理是什么？

本小节参考博客如下：

零基础玩转IPC之——浅析GB28181协议

GB28181协议总结（含详细报文解析）

要谈GB28181的原理，其实就是分析SIP交互流程。

协议基本框架如下图：

GB28181联网系统在进行视音频传输及控制时会建立两个传输通道:会话通道和媒体流通道

会话通道用于在设备之间建立会话并传输系统控制命令，会话基于SIP协议。

媒体流通道用于传输视音频数据,经过压缩编码的视音频流采用流媒体协议RTP/RTCP传输。

上面提到过，SIP报文格式和HTTP很像，如果不了解HTTP报文格式，可自行学习，这里不过多赘述。HTTP由GET、POST、PUT等方法，SIP同样有自己的一些特有的方法，如下：

REGISTER    # 注册联系信息。
INVITE      # 初始化一个会话。
ACK         # 对INVITE消息的最终响应。
CANCEL      # 终止一个等待处理或正在处理的请求。
BYE         # 终止一个会话。
OPTIONS     # 查询服务器的性能。

SUBSCRIBE   # 订阅方法
NOTIFY      # 事件通知方法
MESSAGE     # 即时消息方法

本文解析的报文所使用的方法主要包括：REGISTER、INVITE、ACK、BYE、MESSAGE。

下面将介绍三种常见类型的SIP报文交互流程。

注册和注销

一个开启GB28181协议支持的设备在开机后第一件事就是向SIP服务器注册一下自身，以表示设备的存在。在注册完成后，在互联网的另一端的用户能通过SIP服务器的管理页面看到设备处于在线状态，这样，用户才能去或通过SIP服务器控制IPC，或通过SIP服务器拿到RTP、RTCP协议所需参数来远程查看IPC的实时画面。

详细的注册流程如下图：

忽略认证的细节，整体交互框架如下：

1. 设备发送方法为REGISTER的SIP报文。

2. 设备收到SIP服务端发来的401 Unauthorized回复。

3. 设备带认证参数再次发送REGISTER SIP报文。

4. 设备收到SIP服务端发来的200 OK报文。

第一轮 注册-回复 抓包如下（红色字体报文代表请求，蓝色字体报文代表回复）：

第二轮 注册-回复 抓包如下（红色字体报文代表请求，蓝色字体报文代表回复）：

图片取自：GB28181协议总结（含详细报文解析），在分析报文时，可以先忽略认证相关的内容！另外，从报文当中可以了解的REGISTER类型的SIP报文是不带消息体的（message body）。

注销流程参考如下：

交互流程以及报文格式和注册的报文格式其实类似，唯一的区别是首部的Expires字段值为0，以区分注册报文，来表示注销。

查询和控制

因为查询和控制报文交互流程是一样的，所以这里主要介绍查询的报文交互流程。如下：

要理解上面交互流程，首先需要明确的是查询的发起方是谁？我的答案是用户，对应于源设备。SIP服务器在查询流程当中扮演源设备代理的角色。而最终查询的数据是来源于IPC。

1. 用户向SIP服务器发起设备查询命令。

   1. SIP服务器向用户回复OK。

   2. SIP服务器向IPC发起设备查询命令。

      1. 设备向SIP服务器回复OK。

      2. 设备向SIP服务器回复查询信息。

   3. SIP服务器向设备回复OK。

   4. SIP服务器向用户回复查询信息。

2. 用户向SIP服务器回复OK。

从用户角度来看好像SIP服务器就是IPC，从IPC角度来看，SIP服务器好像就是用户。

SIP服务器向IPC发起设备查询请求报文：

设备向SIP服务器回复OK。并且设备向SIP服务器回复查询信息：

注意：上面这两段报文主要是SIP服务器和IPC设备之间的报文交互流程。

视频点播

所谓视频点播，就是客户端能拿到IPC的RTP/RTCP相关参数，实现跨网段远程播放IPC实时画面。和查询/控制交互过程类似，点播纯在三个部分：客户、SIP服务器、IPC。

具体交互过程如下图：

这张图片的描述有些许复杂，我们可以大胆简化一下它的流程，假设上图流媒体服务器和流媒体发送者为一体（IPC），这样可以参考查询/控制小结。点播整体交互流程如下：

1. 客户向SIP服务器发送INVITE请求。

   1. SIP服务器得到INVITE请求后，反手向IPC发送INVITE请求。

      1. IPC回复OK以及SDP消息体（码流url等参数信息）。

   2. SIP获取到IPC回复的OK和带有码流url等参数后，向客户回复OK消息以及SDP消息体（码流参数信息）。

2. 得到SIP服务器回复的OK以及其SDP消息体（当中通往IPC的码流url参数）。

3. 客户向SIP服务器回复ACK。

   3. SIP服务器向IPC回复ACK。

4. IPC-客户的视频码流实时传输中。。。

5. 客户向SIP服务器发送BYE方法，结束视频点播。

   4. SIP服务器向IPC发送BYTE结束视频点播。

      2. IPC回复OK。点播断开。

   5. SIP收到IPC回复的OK消息，反手向客户回复OK消息。

6. 客户收到SIP服务器发来的OK消息，于此整个点播断开。

上面文字所述的流程其实掺杂着我个人认为理所应当的想法，与GB28181图中所描述的流程有些许出入。但是我认为SIP服务器先断开和IPC的点播再回复客户OK消息才符合逻辑。注意：GB28181当中，因为开头SIP服务器向IPC发送了两次INVITE方法，所以最后发送了两次BYE方法。

从其他博客当中，盗取了几张在点播过程中，比较关键的几个报文，如下所示，读者可以自行分析，（如有侵权，可联系作者删除）。

---

本章完结