GB28181协议简介及实践

会话通道中，注册、实时视音频点播、历史视音频的回放等应用的会话控制采用SIP协议IETF RFC3261中规定的REGISTER、INVITE等请求和响应方法实现， 历史视音频回放控制采用SIP扩展协议IETF RFC29765规定的INFO方法实现，前端设备控制、信息查询、报警事件通知和分发等应用的会话控制采用SIP扩展协议IETF RFC34287规定的MESSAGE方法实现。下面详细介绍下注册、保活和实时视音频点播的SIP消息结构。

(a) SIP代理向SIP服务器发送Register请求;

(b) SIP服务器向SIP代理发送响应401，并在响应的消息头WWW_Authenticate字段中给出适合SIP代理的认证体制和参数;

© SIP代理重新向SIP服务器发送REGISTER请求， 在请求的Authorization字段给出信任书，包含认证信息;

(d) SIP服务器对请求进行验证，如果检查出SIP代理身份合法，向SIP代理发送成功响应200OK，如果身份不合法则发送拒绝服务应答。

注册的请求消息内容范例如下：

1 REGISTER sip:000000001@ SIP/2.0

2 Via: SIP/2.0/UDP 192.168.137.11:5060;rport;branch=z9hG4bK

3 From: sip:@;tag=

4 To: sip:@

5 Call-ID:

6 CSeq: 1 REGISTER

7 Contact: sip:@192.168.137.11:5060

8 Max-Forwards: 70

9 User-Agent: IP Camera

10 Expires: 3600

11 Content-Length: 0

1SIP/2.0 200 OK2Via: SIP/2.0/UDP192.168.137.11:5060;rport;branch=z9hG4bKFrom: sip:@To: sip:@CSeq: 1 REGISTER6Call-ID: Contact: sip:@192.168.137.11:50608User-Agent: FFmpeg GB28181 v1.09Expires: Content-Length: 0

(a) 源设备向SIP服务器发送设备状态信息报送命令。设备状态信息报送命令采用MESSAGE方法携带;

(b) SIP服务器收到命令后返回200 OK。

保活消息内容范例如下：

1 MESSAGE sip:000000001@ SIP/2.0

2 Via: SIP/2.0/UDP 192.168.137.11:5060;rport;branch=z9hG4bK

3 From: sip:@;tag=

4 To: sip:000000001@

5 Call-ID:

6 CSeq: 20 MESSAGE

7 Content-Type: Application/MANSCDP+xml

8 Max-Forwards: 70

9 User-Agent: IP Camera

10 Content-Length: 175

11

12

13 Keepalive

14 1

15

16 OK

17

18

19

MESSAGE消息头Content-type头为Content-type: Application/MANSCDP+xml。状态信息报送命令采用MANSCDP（监控报警联网系统控制描述协议，Monitoringand Alarming Network System Control Description Protocol）协议格式定义， 详细描述见GB/T 28181—2016中A.2.5状态信息报送。状态信息报送命令应包括命令类型(CmdType)、设备/系统编码(DeviceID)、是否正常工作(Status)等， 采用MESSAGE方法的消息体携带。Message消息的成功和错误应答均无消息体，Message回复消息内容范例如下：

1 SIP/2.0 200 OK

2 Via: SIP/2.0/UDP 192.168.137.11:5060;rport;branch=z9hG4bK

3 From: sip:@

4 To: sip:000000001@

5 CSeq: 20 MESSAGE

6 Call-ID:

7 User-Agent: FFmpeg GB28181 v1.0

8 Content-Length: 0

其中，信令1、8、9、10、11、12为SIP服务器接收到客户端的呼叫请求后通过B2BUA代理方式建立媒体流接收者与媒体服务器之间的媒体流信令过程，信令2-7为SIP服务器通过三方呼叫控制建立媒体服务器与媒体流发送者之间的媒体流信令过程，信令13-16为媒体流接收者断开与媒体服务器之间的媒体流信令过程，信令17-20为SIP服务器断开媒体服务器与媒体流发送者之间的媒体流信令过程。

命令流程描述如下:

(a) 媒体流接收者向SIP服务器发送INVITE消息， 消息头域中携带Subject字段， 表明点播的视频源ID、发送方媒体流序列号、媒体流接收者ID、接收端媒体流序列号等参数，SDP消息体中s字段为“Play”代表实时点播。

(b) SIP服务器收到INVITE请求后，通过三方呼叫控制建立媒体服务器和媒体流发送者之间的媒体连接。向媒体服务器发送INVITE消息，此消息不携带SDP消息体。

© 媒体服务器收到SIP服务器的INVITE请求后，回复200 OK响应，携带SDP消息体，消息体中描述了媒体服务器接收媒体流的IP、端口、媒体格式等内容。

(d) SIP服务器收到媒体服务器返回的200 OK响应后，向媒体流发送者发送INVITE请求，请求中携带消息3中媒体服务器回复的200 OK响应消息体，s字段为“Play”代表实时点播， 增加y字段描述SSRC值，f字段描述媒体参数。

(e) 媒体流发送者收到SIP服务器的INVITE请求后，回复200 OK响应，携带SDP消息体，消息体中描述了媒体流发送者发送媒体流的IP、端口、媒体格式、SSRC字段等内容。

(f) SIP服务器收到媒体流发送者返回的200 OK响应后，向媒体服务器发送ACK请求，请求中携带消息5中媒体流发送者回复的200 OK响应消息体， 完成与媒体服务器的INVITE会话建立过程。

(g) SIP服务器收到媒体流发送者返回的200 OK响应后，向媒体流发送者发送ACK请求，请求中不携带消息体，完成与媒体流发送者的INVITE会话建立过程。

(h) 完成三方呼叫控制后，SIP服务器通过B2BUA代理方式建立媒体流接收者和媒体服务器之间的媒体连接。在消息1中增加SSRC值，转发给媒体服务器。

(i) 媒体服务器收到INVITE请求，回复200OK响应，携带SDP消息体，消息体中描述了媒体服务器发送媒体流的IP、端口、媒体格式、SSRC值等内容。

(j) SIP服务器将消息9转发给媒体流接收者。

(k) 媒体流接收者收到200 OK响应后，回复ACK消息，完成与SIP服务器的INVITE会话建立过程。

(l) SIP服务器将消息11转发给媒体服务器，完成与媒体服务器的INVITE会话建立过程。

(m) 媒体流接收者向SIP服务器发送BYE消息，断开消息1、10、11建立的同媒体流接收者的INVITE会话。

(n) SIP服务器收到BYE消息后回复200 OK响应， 会话断开。

(o) SIP服务器收到BYE消息后向媒体服务器发送BYE消息，断开消息8、9、12建立的同媒体服务器的INVITE会话。

§ 媒体服务器收到BYE消息后回复200 OK响应， 会话断开。

(q) SIP服务器向媒体服务器发送BYE消息,断开消息2、3、6建立的同媒体服务器的INVITE会话。

® 媒体服务器收到BYE消息后回复200 OK响应,会话断开。

(s) SIP服务器向媒体流发送者发送BYE消息，断开消息4、5、7建立的同媒体流发送者的INVITE会话。

(t) 媒体流发送者收到BYE消息后回复200 OK响应, 会话断开。

上述流程较为复杂，原因是在实际视频监控系统中，用户不是直接跟前端监控设备交互，而是与监控管理平台交互。媒体流接收者通常是用户的客户端，SIP服务器是单独的服务器，媒体服务器通常是监控系统中的媒体网关，媒体流发送者为前端摄像机。本文中FFmpeg既作为SIP服务器，也作为用户客户端向前端设备发送INVITE请求，因此可以简化为FFmpeg向前端设备发送INVITE请求后，前端设备向FFmpeg回复200OK，然后FFmpeg再向前端设备回复ACK，这样前端设备即开始发送媒体流。

INVITE消息范例如下：

1 INVITE sip:@ SIP/2.0

2 Via: SIP/2.0/UDP 39.100.155.146:15063;rport;branch=z9hG4bK

3 From: sip:000000001@39.100.155.146:15063;tag=

4 To: sip:@

5 Call-ID:

6 CSeq: 20 INVITE

7 Content-Type: Application/SDP

8 Contact: sip:@

9 Max-Forwards: 70

10 User-Agent: FFmpeg GB28181 v1.0

11 Subject: :,000000001:0

12 Content-Length: 164

13 v=0

14 o= 0 0 IN IP4 39.100.155.146

15 s=Play

16 c=IN IP4 39.100.155.146

17 t=0 0

18 m=video 9000 RTP/AVP 96

19 a=recvonly

20 a=rtpmap:96 PS/90000

21 y=

SIP消息头部分上述已经解释过了，这里解释下SDP相关字段含义。

1SIP/2.0 200 OK2Via: SIP/2.0/UDP39.100.155.146:15063;rport=15063;branch=z9hG4bKFrom: sip:000000001@39.100.155.146:15063;tag=To: sip:@;tag=Call-ID: CSeq: 20 INVITE7Contact: sip:@192.168.137.11:50608Content-Type: application/sdp9User-Agent: IP Camera10Content-Length: 26311v=012o= 1073 1073 IN IP4 192.168.137.1113s=Play14c=IN IP4 192.168.137.1115t=0 016m=video 15060 RTP/AVP 9617a=setup:active18a=sendonly19a=rtpmap:96 PS/y=0000

ACK消息范例如下：

1ACK sip:@ SIP/2.02Via: SIP/2.0/UDP 39.100.155.146:15063;rport;branch=z9hG4bKFrom: sip:000000001@39.100.155.146:15063;tag=To: sip:@Call-ID: CSeq: 20 ACK7Max-Forwards: 708User-Agent: FFmpeg GB28181 v1.09Content-Length: 0

BYE消息范例如下：

1BYE sip:@ SIP/2.02Via: SIP/2.0/UDP 39.100.155.146:15063;rport;branch=z9hG4bKFrom: sip:000000001@;tag=To: sip:@;tag=Call-ID: CSeq: 79 BYE7Max-Forwards: 708User-Agent: FFmpeg GB28181 v1.09Content-Length: 0

2.2 RTP协议

(a) 视频流ID:0xE0;

(b) 音频流ID:0xC0。

针对几种视音频格式,PSM中流类型(stream_type)的取值如下:

(a) MPEG-4 视频流:0x10;

(b) H.264 视频流:0x1B;

© SVAC 视频流:0x80;

(d) G.711 音频流:0x90;

(e) G.722.1 音频流:0x92;

(f) G.723.1 音频流:0x93;

(g) G.729 音频流:0x99;

(h) SVAC 音频流:0x9B。

PS包的RTP封装格式参照IETF RFC2250,RTP的主要参数设置如下:

(a) 负载类型(payloadtype):96;

(b) 编码名称(encoding_name):PS;

© 时钟频率(clockrate):90 kHz;

(d) SDP描述中“m”字段的“media”项:video。

GB28181 server功能包括：
1、作为SIP server，管理多设备的注册、保活监控、拉流/停止拉流信令交互；
2、作为media server，对外提供HTTP接口，用户可以获取设备信息、对指定设备进行拉流并转推RTMP、停止拉流等操作。
GB28181 server可以使用户不感知GB28181协议的存在，用户只需要对感兴趣的设备进行操作即可。具体实现中，我们对上述GB28181 demuxer进行了功能扩展，使其具备两种工作模式，一种就是上述的单一设备模式，一种就是多设备管理模式。后者将设备状态信息、发送拉流/停止拉流接口暴露出来供GB28181 server调用。因此当GB28181 server运行后，其自动会对发出注册请求的设备进行管理，监控设备是否在线或离线并更新设备信息。同时监听用户请求，当接收到用户的HTTP请求时做相应的拉流/停止拉流等操作。