原文鏈接：
https://zhuanlan.zhihu.com/p/393863592

1、背景介紹
GB28181協(xié)議指的是國(guó)家標(biāo)準(zhǔn)GB/T 28181—2016《公共安全視頻監(jiān)控聯(lián)網(wǎng)系統(tǒng)信息傳輸、交換、控制技術(shù)要求》1，該標(biāo)準(zhǔn)規(guī)定了公共安全視頻監(jiān)控聯(lián)網(wǎng)系統(tǒng)的互聯(lián)結(jié)構(gòu)， 傳輸、交換、控制的基本要求和安全性要求， 以及控制、傳輸流程和協(xié)議接口等技術(shù)要求，是視頻監(jiān)控領(lǐng)域的國(guó)家標(biāo)準(zhǔn)。GB28181協(xié)議信令層面使用的是SIP（Session Initiation Protocol）協(xié)議2，流媒體傳輸層面使用的是實(shí)時(shí)傳輸協(xié)議（Real-time Transport Protocol，RTP）協(xié)議3，因此可以理解為GB28181是在國(guó)際通用標(biāo)準(zhǔn)的基礎(chǔ)之上進(jìn)行了私有化定制以滿(mǎn)足視頻監(jiān)控聯(lián)網(wǎng)系統(tǒng)互聯(lián)傳輸?shù)臉?biāo)準(zhǔn)化需求。本文旨在說(shuō)明在FFmpeg中增加對(duì)GB28181協(xié)議的支持，使其可以與支持GB28181協(xié)議的設(shè)備進(jìn)行通信與控制，實(shí)現(xiàn)設(shè)備的注冊(cè)、保活以及流媒體的傳輸。

2、相關(guān)技術(shù)介紹
2.1 GB28181協(xié)議
GB28181協(xié)議會(huì)話(huà)通道實(shí)際上使用的是SIP協(xié)議，并且在SIP協(xié)議的基礎(chǔ)之上做了些私有化處理。SIP是一個(gè)由IETF MMUSIC工作組開(kāi)發(fā)的協(xié)議，作為標(biāo)準(zhǔn)被提議用于創(chuàng)建，修改和終止包括視頻，語(yǔ)音，即時(shí)通信，在線(xiàn)游戲和虛擬現(xiàn)實(shí)等多種多媒體元素在內(nèi)的交互式用戶(hù)會(huì)話(huà)。SIP中一個(gè)比較重要的概念是用戶(hù)代理（User Agent），指的是一個(gè)SIP邏輯網(wǎng)絡(luò)端點(diǎn)，用于創(chuàng)建、發(fā)送、接收SIP消息并管理一個(gè)SIP會(huì)話(huà)。SIP用戶(hù)代理又可分為用戶(hù)代理客戶(hù)端UAC（User Agent Client）和用戶(hù)代理服務(wù)端UAS（User Agent Server）。UAC創(chuàng)建并發(fā)送SIP請(qǐng)求，UAS接收處理SIP請(qǐng)求，發(fā)送SIP響應(yīng)。SIP協(xié)議會(huì)與許多其它的協(xié)議協(xié)同工作，如SIP報(bào)文內(nèi)容發(fā)送會(huì)話(huà)描述協(xié)議（Session Description Protocol，SDP）4，SDP協(xié)議描述了會(huì)話(huà)所使用流媒體細(xì)節(jié)，如：使用哪個(gè)IP端口，采用哪種編解碼器等等。SIP的一個(gè)典型用途是：SIP會(huì)話(huà)傳輸一些簡(jiǎn)單的經(jīng)過(guò)報(bào)文的實(shí)時(shí)傳輸協(xié)議流，RTP本身才是語(yǔ)音或視頻的載體。在GB28181協(xié)議中，聯(lián)網(wǎng)系統(tǒng)在進(jìn)行視音頻傳輸及控制時(shí)應(yīng)建立兩個(gè)傳輸通道: 會(huì)話(huà)通道和媒體流通道。會(huì)話(huà)通道用于在設(shè)備之間建立會(huì)話(huà)并傳輸系統(tǒng)控制命令; 媒體流通道用于傳輸視音頻數(shù)據(jù)， 經(jīng)過(guò)壓縮編碼的視音頻流采用流媒體協(xié)議RTP/RTCP傳輸。GB28181協(xié)議中具體通信協(xié)議結(jié)構(gòu)圖如下圖1所示：

會(huì)話(huà)通道中，注冊(cè)、實(shí)時(shí)視音頻點(diǎn)播、歷史視音頻的回放等應(yīng)用的會(huì)話(huà)控制采用SIP協(xié)議IETF RFC3261中規(guī)定的REGISTER、INVITE等請(qǐng)求和響應(yīng)方法實(shí)現(xiàn)， 歷史視音頻回放控制采用SIP擴(kuò)展協(xié)議IETF RFC29765規(guī)定的INFO方法實(shí)現(xiàn)，前端設(shè)備控制、信息查詢(xún)、報(bào)警事件通知和分發(fā)等應(yīng)用的會(huì)話(huà)控制采用SIP擴(kuò)展協(xié)議IETF RFC34287規(guī)定的MESSAGE方法實(shí)現(xiàn)。下面詳細(xì)介紹下注冊(cè)、保活和實(shí)時(shí)視音頻點(diǎn)播的SIP消息結(jié)構(gòu)。

2.1.1 注冊(cè)
注冊(cè)指的是設(shè)備或系統(tǒng)進(jìn)入聯(lián)網(wǎng)系統(tǒng)時(shí)向SIP服務(wù)器（SIP UAS）進(jìn)行注冊(cè)登記的工作模式，在本文中FFmpeg即為一個(gè)SIP服務(wù)器，設(shè)備向FFmpeg發(fā)送注冊(cè)請(qǐng)求，FFmpeg在接收到設(shè)備的注冊(cè)請(qǐng)求后返回相應(yīng)的回復(fù)消息，則完成設(shè)備注冊(cè)流程。GB28181協(xié)議中基于數(shù)字摘要的挑戰(zhàn)應(yīng)答式安全技術(shù)進(jìn)行注冊(cè)流程如下圖2所示：

注冊(cè)流程描述如下:

(a) SIP代理向SIP服務(wù)器發(fā)送Register請(qǐng)求;

(b) SIP服務(wù)器向SIP代理發(fā)送響應(yīng)401，并在響應(yīng)的消息頭WWW_Authenticate字段中給出適合SIP代理的認(rèn)證體制和參數(shù);

? SIP代理重新向SIP服務(wù)器發(fā)送REGISTER請(qǐng)求， 在請(qǐng)求的Authorization字段給出信任書(shū)，包含認(rèn)證信息;

(d) SIP服務(wù)器對(duì)請(qǐng)求進(jìn)行驗(yàn)證，如果檢查出SIP代理身份合法，向SIP代理發(fā)送成功響應(yīng)200OK，如果身份不合法則發(fā)送拒絕服務(wù)應(yīng)答。

注冊(cè)的請(qǐng)求消息內(nèi)容范例如下：

1 REGISTER sip:34020000002000000001@3402000000 SIP/2.0

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

3 From: sip:34020000001320000003@3402000000;tag=2043466181

4 To: sip:34020000001320000003@3402000000

5 Call-ID: 1011047669

6 CSeq: 1 REGISTER

7 Contact: sip:34020000001320000003@192.168.137.11:5060

8 Max-Forwards: 70

9 User-Agent: IP Camera

10 Expires: 3600

11 Content-Length: 0

第1行表明這條SIP消息的方法（Method）是REGISTER，34020000002000000001是SIP服務(wù)器的國(guó)標(biāo)ID，國(guó)標(biāo)ID指的是由中心編碼(8位) 、行業(yè)編碼(2位) 、類(lèi)型編碼(3位)和序號(hào)(7位)四個(gè)碼段共20位十進(jìn)制數(shù)字字符構(gòu)成，具體國(guó)標(biāo)ID的編碼方法可以參考GB/T 28181—2016中的附錄D。3402000000指的是SIP服務(wù)器的域國(guó)標(biāo)ID，SIP/2.0指的是SIP協(xié)議版本。
第2行為Via頭，Via頭中包含了發(fā)送請(qǐng)求方的相關(guān)信息，后續(xù)需要使用這些信息進(jìn)行回復(fù)。SIP/2.0/UDP表示使用的是2.0版本的SIP協(xié)議，使用的傳輸協(xié)議是UDP，也可以使用TCP協(xié)議。192.168.137.11:5060為請(qǐng)求發(fā)送方的IP地址和端口號(hào)。Via頭中必須包含branch參數(shù)，具體值是一個(gè)在整個(gè)SIP通信過(guò)程中不重復(fù)的數(shù)值。branch是一個(gè)事務(wù)ID（Transaction ID），用于區(qū)分同一個(gè)UA所發(fā)起的不同Transaction，它不會(huì)對(duì)未來(lái)的request或者是response造成影響，對(duì)于遵循IETF RFC3261規(guī)范的實(shí)現(xiàn)，這個(gè)branch參數(shù)的值必須用”z9hG4bK”打頭. 其它部分是對(duì)To， From, Call-ID頭域和Request-URI按一定的算法加密后得到。rport字段表示使用rport機(jī)制路由響應(yīng)，即發(fā)送的響應(yīng)時(shí)，按照rport中的端口發(fā)送SIP響應(yīng)，也就是說(shuō)IP和端口均完全遵照從哪里來(lái)的，發(fā)回哪里去的原則，如果沒(méi)有rport字段時(shí)，服務(wù)端的策略是IP使用UDP包中的地址，即從哪里來(lái)回哪里去，但是端口使用的是via中的端口，詳情見(jiàn)IETF RFC35818。
第3行為From頭，From頭中包含了請(qǐng)求發(fā)送方的邏輯標(biāo)識(shí)，在GB28181協(xié)議中是發(fā)送請(qǐng)求的設(shè)備國(guó)標(biāo)ID和域國(guó)標(biāo)ID信息。tag參數(shù)是為了身份認(rèn)證的，值為隨機(jī)數(shù)字字符。
第4行為T(mén)o頭，To頭在SIP協(xié)議中是為了標(biāo)明請(qǐng)求接收方的邏輯標(biāo)識(shí)的，在GB28181協(xié)議中填寫(xiě)的是發(fā)送請(qǐng)求的設(shè)備國(guó)標(biāo)ID和域國(guó)標(biāo)ID信息。
第5行為Call-ID頭，Call-ID頭是全局唯一的，在同一個(gè)session中保持一致，在不同session中不同。
第6行為CSeq頭，CSeq頭又叫Command Seqence（命令隊(duì)列），用于標(biāo)識(shí)命令順序，值為序號(hào)+Method，序號(hào)部分為無(wú)符號(hào)整數(shù)，最大值為2^31。序號(hào)起始值是隨機(jī)的，后續(xù)在同一個(gè)session中依次遞增，比如發(fā)1 REGISTER沒(méi)返回—>再發(fā)2 REGISTER—>沒(méi)返回—>再發(fā)3 REGISTER—>這時(shí)返回了2 REGISTER就知道是第2個(gè)請(qǐng)求得到了響應(yīng)。對(duì)于ACK和CANCLE中的CSeq與INVITE中的Cseq保持一致。
第7行為Contact頭，Contact頭包含源的URI信息，用來(lái)給響應(yīng)消息直接和源建立連接用。在GB28181協(xié)議中為SIP設(shè)備編碼@源IP地址端口。
第8行為Max-Forwards頭，Max-Forwards頭用于設(shè)置包最大中轉(zhuǎn)次數(shù)，默認(rèn)是70。
第9行為User-Agent頭，User-Agent頭用于設(shè)置關(guān)于UA的信息，用戶(hù)可以自定義。
第10行為Expires頭，Expires頭表示超時(shí)時(shí)間。
第11行為Content-Length頭，Content-Length頭表示SDP消息的長(zhǎng)度，因?yàn)镽EGISTER消息不需要SDP，因此為0。
注冊(cè)的回復(fù)消息內(nèi)容范例如下，各頭信息含義見(jiàn)上面：

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

2.1.2 保活
當(dāng)UA發(fā)現(xiàn)工作異常時(shí)， 應(yīng)立即向本SIP監(jiān)控域的SIP服務(wù)器發(fā)送狀態(tài)信息; 無(wú)異常時(shí)，應(yīng)定時(shí)向本SIP監(jiān)控域的SIP服務(wù)器發(fā)送狀態(tài)信息。狀態(tài)信息報(bào)送采用IETF RFC3427中定義的方法MESSAGE實(shí)現(xiàn)。通過(guò)周期性的狀態(tài)信息報(bào)送，實(shí)現(xiàn)注冊(cè)服務(wù)器與源設(shè)備之間的狀態(tài)檢測(cè)即心跳機(jī)制。心跳發(fā)送方、接收方需統(tǒng)一配置“心跳間隔”參數(shù)，按照“心跳間隔”定時(shí)發(fā)送心跳消息，默認(rèn)心跳間隔60s。心跳發(fā)送方、接收方需統(tǒng)一配置“心跳超時(shí)次數(shù)”參數(shù)，心跳消息連續(xù)超時(shí)達(dá)到“心跳超時(shí)次數(shù)”則認(rèn)為對(duì)方下線(xiàn)，默認(rèn)心跳超時(shí)次數(shù)3次。心跳接收方在心跳發(fā)送方上線(xiàn)狀態(tài)下檢測(cè)到心跳消息連續(xù)超時(shí)達(dá)到商定次數(shù)則認(rèn)為心跳發(fā)送方離線(xiàn); 心跳發(fā)送方在心跳接收方上線(xiàn)狀態(tài)下檢測(cè)到心跳消息響應(yīng)消息連續(xù)超時(shí)達(dá)到商定次數(shù)則認(rèn)為心跳接收方離線(xiàn)。具體命令流程如圖3：

命令流程描述如下:

(a) 源設(shè)備向SIP服務(wù)器發(fā)送設(shè)備狀態(tài)信息報(bào)送命令。設(shè)備狀態(tài)信息報(bào)送命令采用MESSAGE方法攜帶;

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

保活消息內(nèi)容范例如下：

1 MESSAGE sip:34020000002000000001@3402000000 SIP/2.0

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

3 From: sip:34020000001320000003@3402000000;tag=1925919231

4 To: sip:34020000002000000001@3402000000

5 Call-ID: 1185236415

6 CSeq: 20 MESSAGE

7 Content-Type: Application/MANSCDP+xml

8 Max-Forwards: 70

9 User-Agent: IP Camera

10 Content-Length: 175

11 <?xml version="1.0" encoding="UTF-8"?>

12

13 Keepalive

14 1

15 34020000001320000003

16 OK

17

18

19

MESSAGE消息頭Content-type頭為Content-type: Application/MANSCDP+xml。狀態(tài)信息報(bào)送命令采用MANSCDP（監(jiān)控報(bào)警聯(lián)網(wǎng)系統(tǒng)控制描述協(xié)議，Monitoringand Alarming Network System Control Description Protocol）協(xié)議格式定義， 詳細(xì)描述見(jiàn)GB/T 28181—2016中A.2.5狀態(tài)信息報(bào)送。狀態(tài)信息報(bào)送命令應(yīng)包括命令類(lèi)型(CmdType)、設(shè)備/系統(tǒng)編碼(DeviceID)、是否正常工作(Status)等， 采用MESSAGE方法的消息體攜帶。Message消息的成功和錯(cuò)誤應(yīng)答均無(wú)消息體，Message回復(fù)消息內(nèi)容范例如下：

1 SIP/2.0 200 OK

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

3 From: sip:34020000001320000003@3402000000

4 To: sip:34020000002000000001@3402000000

5 CSeq: 20 MESSAGE

6 Call-ID: 1185236415

7 User-Agent: FFmpeg GB28181 v1.0

8 Content-Length: 0

2.1.3 實(shí)時(shí)音視頻播放
實(shí)時(shí)視音頻點(diǎn)播采用SIP協(xié)議中的INVITE方法實(shí)現(xiàn)會(huì)話(huà)連接，采用RTP/RTCP協(xié)議(IETF RFC3550)實(shí)現(xiàn)媒體傳輸。需要注意的是，實(shí)時(shí)視音頻點(diǎn)播需要上述的媒體流保活機(jī)制。客戶(hù)端主動(dòng)發(fā)起的實(shí)時(shí)視音頻點(diǎn)播流程見(jiàn)圖4:

其中，信令1、8、9、10、11、12為SIP服務(wù)器接收到客戶(hù)端的呼叫請(qǐng)求后通過(guò)B2BUA代理方式建立媒體流接收者與媒體服務(wù)器之間的媒體流信令過(guò)程，信令2-7為SIP服務(wù)器通過(guò)三方呼叫控制建立媒體服務(wù)器與媒體流發(fā)送者之間的媒體流信令過(guò)程，信令13-16為媒體流接收者斷開(kāi)與媒體服務(wù)器之間的媒體流信令過(guò)程，信令17-20為SIP服務(wù)器斷開(kāi)媒體服務(wù)器與媒體流發(fā)送者之間的媒體流信令過(guò)程。

命令流程描述如下:

(a) 媒體流接收者向SIP服務(wù)器發(fā)送INVITE消息， 消息頭域中攜帶Subject字段， 表明點(diǎn)播的視頻源ID、發(fā)送方媒體流序列號(hào)、媒體流接收者ID、接收端媒體流序列號(hào)等參數(shù)，SDP消息體中s字段為“Play”代表實(shí)時(shí)點(diǎn)播。

(b) SIP服務(wù)器收到INVITE請(qǐng)求后，通過(guò)三方呼叫控制建立媒體服務(wù)器和媒體流發(fā)送者之間的媒體連接。向媒體服務(wù)器發(fā)送INVITE消息，此消息不攜帶SDP消息體。

? 媒體服務(wù)器收到SIP服務(wù)器的INVITE請(qǐng)求后，回復(fù)200 OK響應(yīng)，攜帶SDP消息體，消息體中描述了媒體服務(wù)器接收媒體流的IP、端口、媒體格式等內(nèi)容。

(d) SIP服務(wù)器收到媒體服務(wù)器返回的200 OK響應(yīng)后，向媒體流發(fā)送者發(fā)送INVITE請(qǐng)求，請(qǐng)求中攜帶消息3中媒體服務(wù)器回復(fù)的200 OK響應(yīng)消息體，s字段為“Play”代表實(shí)時(shí)點(diǎn)播， 增加y字段描述SSRC值，f字段描述媒體參數(shù)。

(e) 媒體流發(fā)送者收到SIP服務(wù)器的INVITE請(qǐng)求后，回復(fù)200 OK響應(yīng)，攜帶SDP消息體，消息體中描述了媒體流發(fā)送者發(fā)送媒體流的IP、端口、媒體格式、SSRC字段等內(nèi)容。

(f) SIP服務(wù)器收到媒體流發(fā)送者返回的200 OK響應(yīng)后，向媒體服務(wù)器發(fā)送ACK請(qǐng)求，請(qǐng)求中攜帶消息5中媒體流發(fā)送者回復(fù)的200 OK響應(yīng)消息體， 完成與媒體服務(wù)器的INVITE會(huì)話(huà)建立過(guò)程。

(g) SIP服務(wù)器收到媒體流發(fā)送者返回的200 OK響應(yīng)后，向媒體流發(fā)送者發(fā)送ACK請(qǐng)求，請(qǐng)求中不攜帶消息體，完成與媒體流發(fā)送者的INVITE會(huì)話(huà)建立過(guò)程。

(h) 完成三方呼叫控制后，SIP服務(wù)器通過(guò)B2BUA代理方式建立媒體流接收者和媒體服務(wù)器之間的媒體連接。在消息1中增加SSRC值，轉(zhuǎn)發(fā)給媒體服務(wù)器。

(i) 媒體服務(wù)器收到INVITE請(qǐng)求，回復(fù)200OK響應(yīng)，攜帶SDP消息體，消息體中描述了媒體服務(wù)器發(fā)送媒體流的IP、端口、媒體格式、SSRC值等內(nèi)容。

(j) SIP服務(wù)器將消息9轉(zhuǎn)發(fā)給媒體流接收者。

(k) 媒體流接收者收到200 OK響應(yīng)后，回復(fù)ACK消息，完成與SIP服務(wù)器的INVITE會(huì)話(huà)建立過(guò)程。

(l) SIP服務(wù)器將消息11轉(zhuǎn)發(fā)給媒體服務(wù)器，完成與媒體服務(wù)器的INVITE會(huì)話(huà)建立過(guò)程。

(m) 媒體流接收者向SIP服務(wù)器發(fā)送BYE消息，斷開(kāi)消息1、10、11建立的同媒體流接收者的INVITE會(huì)話(huà)。

(n) SIP服務(wù)器收到BYE消息后回復(fù)200 OK響應(yīng)， 會(huì)話(huà)斷開(kāi)。

(o) SIP服務(wù)器收到BYE消息后向媒體服務(wù)器發(fā)送BYE消息，斷開(kāi)消息8、9、12建立的同媒體服務(wù)器的INVITE會(huì)話(huà)。

§ 媒體服務(wù)器收到BYE消息后回復(fù)200 OK響應(yīng)， 會(huì)話(huà)斷開(kāi)。

(q) SIP服務(wù)器向媒體服務(wù)器發(fā)送BYE消息,斷開(kāi)消息2、3、6建立的同媒體服務(wù)器的INVITE會(huì)話(huà)。

? 媒體服務(wù)器收到BYE消息后回復(fù)200 OK響應(yīng),會(huì)話(huà)斷開(kāi)。

(s) SIP服務(wù)器向媒體流發(fā)送者發(fā)送BYE消息，斷開(kāi)消息4、5、7建立的同媒體流發(fā)送者的INVITE會(huì)話(huà)。

(t) 媒體流發(fā)送者收到BYE消息后回復(fù)200 OK響應(yīng), 會(huì)話(huà)斷開(kāi)。

上述流程較為復(fù)雜，原因是在實(shí)際視頻監(jiān)控系統(tǒng)中，用戶(hù)不是直接跟前端監(jiān)控設(shè)備交互，而是與監(jiān)控管理平臺(tái)交互。媒體流接收者通常是用戶(hù)的客戶(hù)端，SIP服務(wù)器是單獨(dú)的服務(wù)器，媒體服務(wù)器通常是監(jiān)控系統(tǒng)中的媒體網(wǎng)關(guān)，媒體流發(fā)送者為前端攝像機(jī)。本文中FFmpeg既作為SIP服務(wù)器，也作為用戶(hù)客戶(hù)端向前端設(shè)備發(fā)送INVITE請(qǐng)求，因此可以簡(jiǎn)化為FFmpeg向前端設(shè)備發(fā)送INVITE請(qǐng)求后，前端設(shè)備向FFmpeg回復(fù)200OK，然后FFmpeg再向前端設(shè)備回復(fù)ACK，這樣前端設(shè)備即開(kāi)始發(fā)送媒體流。

INVITE消息范例如下：

1 INVITE sip:34020000001320000003@3402000000 SIP/2.0

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

3 From: sip:34020000002000000001@39.100.155.146:15063;tag=512358805

4 To: sip:34020000001320000003@3402000000

5 Call-ID: 200008805

6 CSeq: 20 INVITE

7 Content-Type: Application/SDP

8 Contact: sip:34020000001320000003@3402000000

9 Max-Forwards: 70

10 User-Agent: FFmpeg GB28181 v1.0

11 Subject: 34020000001320000003:630886,34020000002000000001:0

12 Content-Length: 164

13 v=0

14 o=34020000001320000003 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=630886

SIP消息頭部分上述已經(jīng)解釋過(guò)了，這里解釋下SDP相關(guān)字段含義。

v=表示的SDP版本，固定值，為0。
o=表示INVITE發(fā)起者的相關(guān)信息，后面的內(nèi)容依次為設(shè)備國(guó)標(biāo)ID、session ID、session版本、網(wǎng)絡(luò)類(lèi)型（IN/OUT）、地址類(lèi)型（IPV4/IPV6）、發(fā)起者IP。
s=表示session名稱(chēng)，GB28181協(xié)議中規(guī)定實(shí)時(shí)點(diǎn)播必須填“Play”。
c=表示連接數(shù)據(jù)，依次是網(wǎng)絡(luò)類(lèi)型（IN/OUT）、地址類(lèi)型（IPV4/IPV6）、發(fā)起者IP。
t=表示起始時(shí)間和終止時(shí)間，由于是實(shí)時(shí)點(diǎn)播，沒(méi)有起始時(shí)間和終止時(shí)間，因此均為0.
m=表示的媒體流參數(shù)，m字段描述媒體的媒體類(lèi)型、端口、傳輸層協(xié)議、負(fù)載類(lèi)型等內(nèi)容。媒體類(lèi)型采用“video”標(biāo)識(shí)傳輸視頻或視音頻混合內(nèi)容,采用“audio”標(biāo)識(shí)傳輸音頻內(nèi)容; 傳輸方式采用“RTP/AVP”標(biāo)識(shí)傳輸層協(xié)議為RTP over UDP,采用“TCP/RTP/AVP”標(biāo)識(shí)傳輸層協(xié)議為RTP over TCP。例如:“m=video 6000 RTP/AVP 96”標(biāo)識(shí)媒體類(lèi)型為視頻或視音頻, 傳輸端口為6000,采用RTP over UDP傳輸方式,負(fù)載類(lèi)型為96。“m=video 6000 TCP/RTP/AVP 96”標(biāo)識(shí)媒體類(lèi)型為視頻或視音頻,傳輸端口為6000,采用RTP over TCP傳輸方式, 負(fù)載類(lèi)型為96。
a=可以用于表示媒體相關(guān)的參數(shù)，如啟用IETF RFC 4566中對(duì)a字段的定義a=rtpmap: / [/]中的， 利用該屬性攜帶編碼器廠商名稱(chēng)(如:企業(yè)1或企業(yè)2編碼名稱(chēng)DAHUA或HIKVISION)。該屬性表明該流為某廠商編碼器編碼且是不符合本標(biāo)準(zhǔn)規(guī)定的媒體流， 符合本標(biāo)準(zhǔn)規(guī)定的媒體流無(wú)需該屬性。recvonly表示僅接收媒體流，sendonly表示僅發(fā)送。
y=表示SSRC，可以在端口復(fù)用模式情況下區(qū)分不同路的媒體流，SSRC值全局唯一，用戶(hù)可以自定義。
INVITE回復(fù)消息范例如下：

1SIP/2.0 200 OK2Via: SIP/2.0/UDP39.100.155.146:15063;rport=15063;branch=z9hG4bK342088053From: sip:34020000002000000001@39.100.155.146:15063;tag=5123588054To: sip:34020000001320000003@3402000000;tag=10831113115Call-ID: 2000088056CSeq: 20 INVITE7Contact: sip:34020000001320000003@192.168.137.11:50608Content-Type: application/sdp9User-Agent: IP Camera10Content-Length: 26311v=012o=34020000001320000003 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/9000020y=0000630886

ACK消息范例如下：

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

BYE消息范例如下：

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

2.2 RTP協(xié)議

RTP是一個(gè)網(wǎng)絡(luò)傳輸協(xié)議，IETF RFC3550詳細(xì)描述了RTP協(xié)議內(nèi)容。GB28181協(xié)議中規(guī)定了兩種方式傳輸媒體流，一種是將音視頻數(shù)據(jù)打包成MPEG2-PS流然后再通過(guò)RTP協(xié)議傳輸，另外一種是直接使用RTP傳輸裸的音視頻流，在實(shí)際應(yīng)用中主要以第一種方式為主，因此本文著重介紹下第一種方式。基于RTP的PS封裝首先按照ISO/IEC13818-1:20008將視音頻流封裝成PES包，然后再將PES包封裝成PS包， 再將PS包以負(fù)載的方式封裝成RTP包。進(jìn)行PS封裝時(shí)，應(yīng)將每個(gè)視頻幀封裝為一個(gè)PS包，且每個(gè)關(guān)鍵幀的PS包中應(yīng)包含系統(tǒng)頭(System Header)和PSM(Program Stream Map)，系統(tǒng)頭和PSM放置于PS包頭之后、第一個(gè)PES包之前。典型的視頻關(guān)鍵幀PS包結(jié)構(gòu)如圖6所示，其中PESV為視頻PES包，PESA為音頻PES包，視頻非關(guān)鍵幀的PS包結(jié)構(gòu)中一般不包含系統(tǒng)頭和PSM。PS包中各部分的具體數(shù)據(jù)結(jié)構(gòu)參見(jiàn)ISO/IEC13818-1:2000中的相關(guān)描述。

系統(tǒng)頭應(yīng)包含對(duì)PS包中碼流種類(lèi)的描述, 其中視頻和音頻的流ID(stream_id)取值如下:

(a) 視頻流ID:0xE0;

(b) 音頻流ID:0xC0。

針對(duì)幾種視音頻格式,PSM中流類(lèi)型(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的主要參數(shù)設(shè)置如下:

(a) 負(fù)載類(lèi)型(payloadtype):96;

(b) 編碼名稱(chēng)(encoding_name):PS;

? 時(shí)鐘頻率(clockrate):90 kHz;

(d) SDP描述中“m”字段的“media”項(xiàng):video。

3、方案實(shí)現(xiàn)
3.1 GB28181 demuxer
首先我們?cè)贔Fmpeg中實(shí)現(xiàn)了GB28181協(xié)議的demuxer，方案的框架圖如圖6所示。主要包含兩個(gè)子模塊，一個(gè)是SIP stack模塊，負(fù)責(zé)SIP協(xié)議功能，一個(gè)GB28181 demuxer模塊，負(fù)責(zé)調(diào)用SIP接口與前端設(shè)備IPC進(jìn)行交互，同時(shí)解析IPC通過(guò)RTP發(fā)送過(guò)來(lái)的MPEG2-PS流，得到音視頻數(shù)據(jù)流后以packet的形式返回給lavf上層，再依次往FFmpeg上層傳。SIP stack模塊提供單一功能的SIP接口，比如發(fā)送回復(fù)消息，發(fā)送INVITE/BYE/ACK請(qǐng)求；GB28181 demuxer模塊需要按照FFmpeg上層接口調(diào)用順序與IPC進(jìn)行相關(guān)的交互，同時(shí)創(chuàng)建與設(shè)備之間的RTP鏈接，在拿到MPEG2-PS流后進(jìn)行解析。

由于FFmpeg只有解析PS流封裝的本地視頻demuxer，并沒(méi)有解析PS流的demuxer，因此本文也在本地PS流封裝視頻demuxer的基礎(chǔ)之上實(shí)現(xiàn)了PS流的demuxer。核心思路是從RTP包中解析PS頭信息，再根據(jù)PS頭信息找到PES頭，從PES頭中取出每個(gè)PES包的長(zhǎng)度。由于RTP長(zhǎng)度限制，一個(gè)PES包會(huì)被切分成很多份分成多個(gè)RTP包傳輸過(guò)來(lái)，因此PS demuxer需要緩存這些PES切片，等一個(gè)完整的PES包湊齊后再解析取出音視頻流并以packet格式返回上FFmpeg上層模塊。由于IETF RFC22509并沒(méi)有規(guī)定PS流應(yīng)該如何封裝到RTP中，因此PES頭可能出現(xiàn)在RTP包的任何位置，demuxer也針對(duì)不同的情況做了處理。

3.2 GB28181 Server
上述方案存在局限性，只能對(duì)單一設(shè)備進(jìn)行管理和拉流，但實(shí)際場(chǎng)景中一個(gè)SIP域中存在眾多設(shè)備。因此在上述GB28181 demuxer的基礎(chǔ)之上，我們也實(shí)現(xiàn)了GB28181 server，方案的框架圖如下圖7所示。

GB28181 server功能包括：
1、作為SIP server，管理多設(shè)備的注冊(cè)、保活監(jiān)控、拉流/停止拉流信令交互；
2、作為media server，對(duì)外提供HTTP接口，用戶(hù)可以獲取設(shè)備信息、對(duì)指定設(shè)備進(jìn)行拉流并轉(zhuǎn)推RTMP、停止拉流等操作。
GB28181 server可以使用戶(hù)不感知GB28181協(xié)議的存在，用戶(hù)只需要對(duì)感興趣的設(shè)備進(jìn)行操作即可。具體實(shí)現(xiàn)中，我們對(duì)上述GB28181 demuxer進(jìn)行了功能擴(kuò)展，使其具備兩種工作模式，一種就是上述的單一設(shè)備模式，一種就是多設(shè)備管理模式。后者將設(shè)備狀態(tài)信息、發(fā)送拉流/停止拉流接口暴露出來(lái)供GB28181 server調(diào)用。因此當(dāng)GB28181 server運(yùn)行后，其自動(dòng)會(huì)對(duì)發(fā)出注冊(cè)請(qǐng)求的設(shè)備進(jìn)行管理，監(jiān)控設(shè)備是否在線(xiàn)或離線(xiàn)并更新設(shè)備信息。同時(shí)監(jiān)聽(tīng)用戶(hù)請(qǐng)求，當(dāng)接收到用戶(hù)的HTTP請(qǐng)求時(shí)做相應(yīng)的拉流/停止拉流等操作。

總結(jié)

以上是生活随笔為你收集整理的GB28181协议简介及实践的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。