1、GB/T 28181 —2016協議簡介

近年來，國內視頻監控應用發展迅猛，系統接入規模不斷擴大，涌現了大量平臺提供商，平臺提供商的接入協議各不相同，終端制造商需要給每款終端維護提供各種不同平臺的軟件版本，造成了極大的資源浪費。各地視頻大規模建設后，省級、國家級集中調閱，對重特大事件通過視頻掌握現場并進行指揮調度的需求逐步涌現，然而不同平臺間缺乏統一的互通協議。在這樣的產業背景下，基于終端標準化、平臺互聯互通的需求，GB/T28181應運而生。 GB28181標準規定了公共安全視頻監控聯網系統(以下簡稱聯網系統) 的互聯結構, 傳輸、 交換、 控制的基本要求和安全性要求, 以及控制、 傳輸流程和協議接口等技術要求。

2、GB28181框架

SIP 監控域互聯結構示意圖如下圖所示：

GB28181的聯網方式分為級聯和互聯方式，級聯方式可以詳細分為信令級聯和媒體級聯，下圖分別為信令級聯和媒體級聯方式：
信令級聯：

媒體級聯：

互聯：
信令安全路由網關之間是平級關系, 需要共享對方SIP 監控域的監控資源時, 由信令安全路由網關向目的信令安全路由網關發起, 經目的信令安全路由網關鑒權認證后方可進行平級系統間通信。
信令互聯：

媒體互聯：

3、GB28181通信結構

聯網系統內部進行視頻、 音頻、 數據等信息傳輸、 交換、 控制時, 遵循的通信協議的結構如下圖所示：

聯網系統在進行視音頻傳輸及控制時應建立兩個傳輸通道: 會話通道和媒體流通道。 會話通道用于在設備之間建立會話并傳輸系統控制命令; 媒體流通道用于傳輸視音頻數據, 經過壓縮編碼的視音頻流采用流媒體協議 RTP/RTCP 傳輸。
其中使用的具體協議如下所述：
（1）會話初始協議：
安全注冊、 實時視音頻點播、 歷史視音頻的回放等應用的會話控制采用RFC 3261 （SIP協議）規定Register、Invite 等請求和響應方法實現, 歷史視音頻回放控制采用SIP 擴展協議IETF RFC2976 規定的INFO 方法實現, 前端設備控制、 信息查詢、 報警事件通知和分發等應用的會話控制采用 SIP 擴展協議IETF RFC3428 規定的 Message 方法實現。
（2）會話描述協議
聯網系統有關設備之間會話建立過程的會話協商和媒體協商應采用RFC4566 （SDP協議）協議描述, 主要內容包括會話描述、 媒體信息描述、 時間信息描述。 會話協商和媒體協商信息應采用SIP 消息的消息體攜帶傳輸。
（3）控制描述協議
聯網系統有關前端設備控制、 報警信息、 設備目錄信息等控制命令應采用監控報警聯網系統控制描述協議(MANSCDP) 描述， 聯網系統控制命令應采用SIP 消息 Message 的消息體攜帶傳輸。
（4）媒體回放控制協議
歷史視音頻的回放控制命令應采用監控報警聯網系統實時流協議(MANSRTSP) , 實現設備在端到端之間對視音頻流的正常播放、 快速、 暫停、 停止、 隨機拖動播放等遠程控制。 歷史媒體的回放控制命令采用SIP 消息Info 的消息體攜帶傳輸。
（5）媒體傳輸和媒體編解碼協議
媒體流在聯網系統IP 網絡上傳輸時應支持 RTP 傳輸, 媒體流發送源端應支持控制媒體流發送峰值功能。 RTP 的負載應采用如下兩種格式之一: 基于 PS 封裝的視音頻數據或視音頻基本流數據。 媒體流的傳輸應采用RFC3550 規定的 RTP 協議, 提供實時數據傳輸中的時間戳信息及各數據流的同步; 應采用RFC 3550 規定的 RTCP 協議, 為按序傳輸數據包提供可靠保證, 提供流量控制和擁塞控制。

4、GB28181具體功能

GB28181協議規定支持的功能有如下幾項：

（1）注冊和注銷

應支持設備或系統進入聯網系統時向SIP 服務器進行注冊登記的工作模式。如果設備或系統注冊不成功, 宜延遲一定的隨機時間后重新注冊。基本注冊即采用RFC3261 規定的基于數字摘要的挑戰應答式安全技術進行注冊, 基本注冊流程如下圖所示：

注冊流程描述如下:
（a）SIP 代理向SIP 服務器發送 Register 請求;
（b）SIP 服務器向 SIP 代理發送響應401, 并在響應的消息頭 WWW_Authenticate 字段中給出適合SIP 代理的認證體制和參數;
（c）SIP 代理重新向SIP 服務器發送 Register 請求, 在請求的 Authorization 字段給出信任書,包含認證信息;
（d）SIP 服務器對請求進行驗證, 如果檢查出 SIP 代理身份合法, 向 SIP 代理發送成功響應200 OK, 如果身份不合法則發送拒絕服務應答。

基于數字證書的雙向認證注冊：

信令流程描述如下:
（a）SIP UA 向 SIP 服務器發送 Register 請求, 消息頭域中攜帶 SIP UA 安全能力。 增加 Authorization頭字段,Authorization 的值為 Capability, 參數algorithm 的值分為三部分, 中間以逗號分割。 第一部分為非對稱算法描述, 取值為 RSA; 第 二 部 分 為 摘 要 算 法 描 述, 取 值 為MD5/SHA-1/SHA-256 中的一個或者多個; 第三部分為對稱算法的描述, 取值為 DES/3DES/SM1 中的一個或者多個。
（b）SIP 服務器向SIP UA 發送一個挑戰響應401, 響應的消息頭域 WWW-Authenticate 取值為Asymmetric, 參數nonce 分為兩部分a 和b 兩部分, algorithm 的值取SIP UA 安全能力中的算法。
（c）IP UA 收到401 響應后, 得到nonce 中的a 和b 兩部分。 首先用SIP UA 私鑰解密b, 得到結果c, 對結果c 用401 響應中algorithm 指定的算法做摘要, 得到結果d, 用sip 服務器公鑰解密a, 得到結果d’ , 與結果d 進行匹配, 如果相匹配則信任該結果, 否則丟棄。 SIP UA 重新向SIP 服務器發送 Register 請求，Authorization 取值為 Asymmetric, 參數nonce 的值與上面（b）中的相同;response 的值為用本消息中algorithm 指明的算法對[c+nonce]做摘要的結果。
（d）SIP 服 務 器 對 請 求 進 行 驗 證, 如 果 檢 查 SIP UA 身 份 合 法, 向 SIP UA 發 送 成 功 響 應 200 OK, 如果身份不合法則發送拒絕服務應答。

注銷流程：

注銷流程描述如下:
（a）SIP 代理向SIP 服務器發送 Register 請求,Expires 字段的值為0, 表示SIP 代理要注銷;
（b）SIP 服務器向 SIP 代理發送響應401, 并在響應的消息頭 WWW_Authenticate 字段中給出適合SIP 代理的認證體制和參數;
（c）SIP 代理重新向SIP 服務器發送 Register 請求, 在請求的 Authorization 字段給出信任書,包含認證信息,Expires 字段的值為0;
（d）SIP 服務器對請求進行驗證, 如果檢查出 SIP 代理身份合法, 向 SIP 代理發送成功響應200 OK, 如果身份不合法則發送拒絕服務應答。

（2）實時視音頻點播

應支持按照指定設備、 指定通道進行圖像的實時點播, 支持多用戶對同一圖像資源的同時點播。
實時視音頻點播的SIP 消息應通過本域或其他域的SIP 服務器進行路由、 轉發, 目標設備的實時視音頻流宜通過本域內的媒體服務器進行轉發。實時視音頻點播采用SIP 協議(IETF RFC3261) 中的Invite 方法實現會話連接, 采用 RTP/RTCP協議(IETF RFC3550) 實現媒體傳輸。實時視音頻點播的信令流程分為客戶端主動發起和第三方呼叫控制兩種方式, 聯網系統可選擇其中一種或兩種結合的實現方式。 第三方呼叫控制的第三方控制者宜采用背靠背用戶代理實現, 有關第三方呼叫控制見IETF RFC3725。

其中, 信令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 消息體。
（c） 媒體服務器收到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 請求, 回復200 OK 響應, 攜帶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 會話。
（p）媒體服務器收到 BYE 消息后回復200 OK 響應, 會話斷開。
（q）SIP 服務器向媒體服務器發送 BYE 消息, 斷開消息2、3、6 建立的同媒體服務器的Invite會話。
（r）媒體服務器收到 BYE 消息后回復200 OK 響應, 會話斷開。
（s）SIP 服務器向媒體流發送者發送 BYE 消息, 斷開消息4、5、7 建立的同媒體流發送者的Invite 會話。
（t） 媒體流發送者收到 BYE 消息后回復200 OK 響應, 會話斷開。

（3）設備控制

應支持向指定設備發送控制信息, 如球機/云臺控制、 錄像控制、 報警設備的布防/撤防等, 實現對設備的各種動作進行遙控。

（4）報警事件通知和分發

應能實時接收報警源發送來的報警信息, 根據報警處置預案將報警信息及時分發給相應的用戶終端或系統、 設備。

（5）設備信息查詢

應支持分級查詢并獲取聯網系統中注冊設備或系統的目錄信息、 狀態信息等, 其中設備目錄信息包括設備ID、 設備名、 設備廠家名稱、 設備型號、 設備地址、 設備口令、 設備類型、 設備狀態、 設備安裝地址、設備歸屬單位、 父設備ID 等信息。

（6）狀態信息報送

應支持以主動報送的方式搜集、 檢測網絡內的監控設備、 報警設備、 相關服務器以及連接的聯網系統的運行情況。

（7）歷史視音頻文件檢索

應支持對指定設備上指定時間段的歷史視音頻文件進行檢索。

（8）歷史視音頻回放

應支持對指定設備或系統上指定時間的歷史視音頻數據進行遠程回放, 回放過程應支持正常播放、快速播放、 慢速播放、 畫面暫停、 隨機拖放等媒體回放控制。

（9）歷史視音頻文件下載

應支持對指定設備指定時間段的歷史視音頻文件進行下載。

（10） 網絡校時

聯網系統內的IP 網絡服務器設備宜支持 NTP(見IETF RFC2030) 協議的網絡統一校時服務。 網絡校時設備分為時鐘源和客戶端, 支持客戶/服務器的工作模式; 時鐘源應支持 TCP/IP、UDP 及 NTP協議, 能將輸入的或自身產生的時間信號以標準的 NTP 信息包格式輸出。

（11）訂閱和通知

宜支持訂閱和通知機制, 支持事件以及目錄訂閱和通知。

（12）語音廣播和語音對講

宜支持語音廣播、 語音對講機制。

建議閱讀：
關于RTP\RTCP，SDP的內容可以參考往期文章：
《 網絡流媒體–SDP會話描述協議 》
《 網絡流媒體–RTP和RTCP協議》
《幾大安防行業標準專業解讀》
參考資料：
《GBT 28181-2016 公共安全視頻監控聯網系統信息傳輸、交換、控制技術要求》

總結

以上是生活随笔為你收集整理的GB28181协议--GB28181协议简介的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。