1.引言

　　國家標準GB/T 28181-2022《公共安全視頻監(jiān)控聯(lián)網(wǎng)系統(tǒng)信息傳輸、交換、控制技術要求》已于2022年12月30日發(fā)布，將于2023年7月1日實施。該標準規(guī)定了視頻聯(lián)網(wǎng)系統(tǒng)的聯(lián)網(wǎng)結構、信令流程、協(xié)議接口以及相關安全性要求，適用于公共安全視頻聯(lián)網(wǎng)系統(tǒng)的方案設計、系統(tǒng)檢測、驗收以及與之相關的設備研發(fā)、生產(chǎn)。

　　標準定位于視頻資源聯(lián)網(wǎng)共享，2011年首次發(fā)布，并很快得到了廣泛應用落地，2016年發(fā)布了更新版。隨著業(yè)務實踐的深入和新場景、新應用的需求驅動，2022年再次進行更新。下面介紹一下標準的基本框架和2022版主要技術改進點。

　　2.基本框架

　　2.1.資源編碼

　　標準從設計之初就充分考慮了全國統(tǒng)一大規(guī)模聯(lián)網(wǎng)的需求，制定了一套全局統(tǒng)一的資源編碼規(guī)范，對聯(lián)網(wǎng)系統(tǒng)里面的設備、客戶端、服務器、用戶等實體進行統(tǒng)一編碼。編碼結構中包含省、市、區(qū)等行政區(qū)劃信息，以及行業(yè)編碼、類型編碼等，因此能夠做到各自獨立編碼且全局唯一不沖突，同時通過編碼本身也能直接獲取到對應實體的所屬區(qū)域和類型等基本信息。

　　早期的視頻聯(lián)網(wǎng)系統(tǒng)往往是從各自獨立且小規(guī)模進行建設，然后慢慢擴容升級，正是有了這樣前瞻性的全局統(tǒng)一的編碼規(guī)范，使得后面這些獨立系統(tǒng)能夠順利進行大規(guī)模聯(lián)網(wǎng)。

　　標準中對設備進行了簡化抽象，摒棄了通道概念的復雜性，將通道本身看作一個子設備，同樣有唯一的設備編碼。為了更好的進行大規(guī)模聯(lián)網(wǎng)時資源的描述，標準中定義了統(tǒng)一的目錄結構，將系統(tǒng)、設備、子設備等實體按照行政區(qū)劃目錄項、系統(tǒng)目錄項、業(yè)務分組目錄項、虛擬組織目錄項等進行層次劃分，形成樹狀結構的目錄樹，通過聯(lián)網(wǎng)系統(tǒng)之間的目錄推送進行視頻匯聚。

　　2.2.聯(lián)網(wǎng)方式

　　聯(lián)網(wǎng)系統(tǒng)的信息傳輸、交換、控制方面的SIP監(jiān)控域聯(lián)網(wǎng)結構如圖1所示。

圖1：SIP監(jiān)控域聯(lián)網(wǎng)結構

　　在SIP監(jiān)控域中，SIP客戶端和SIP設備接入到中心信令控制服務器，通過中心信令控制服務器進行信令交互，通過流媒體服務器進行媒體交互。SIP監(jiān)控域之間業(yè)務交互，通過不同監(jiān)控域的中心信令控制服務器進行信令中轉，以及流媒體服務器之間的媒體中轉來完成。由于涉及到外部的IP傳輸網(wǎng)絡，因此在中心信令控制服務器與外部IP傳輸網(wǎng)絡的出口處，分別都增加信令安全路由網(wǎng)關來進行安全傳輸。

　　SIP監(jiān)控域可以通過網(wǎng)關和非SIP監(jiān)控域進行聯(lián)網(wǎng)，SIP監(jiān)控域之間也可以進行級聯(lián)聯(lián)網(wǎng)，下級SIP監(jiān)控域將自己下級的SIP監(jiān)控域的目錄資源和自身的目錄資源進行整合，統(tǒng)一往上級進行匯聚。級聯(lián)方式聯(lián)網(wǎng)時，信令流逐級轉發(fā)，媒體流推薦逐級轉發(fā)，也可以跨媒體服務器傳輸。經(jīng)過多級的級聯(lián)匯聚和互聯(lián)，最終可以形成全國大規(guī)模聯(lián)網(wǎng)系統(tǒng)。

　　2.3.協(xié)議結構

　　聯(lián)網(wǎng)系統(tǒng)進行視頻、音頻、數(shù)據(jù)等信息傳輸交換控制基于TCP/IP協(xié)議，通信協(xié)議結構分為會話通道和媒體流通道，如圖2所示。

圖2：通信協(xié)議結構

　　會話通道基于SIP協(xié)議進行信令傳輸，在其上面承載的是SDP、MANSCDP和MANSRTSP等業(yè)務命令協(xié)議，其中SDP和MANSRTSP主要用于媒體播放操作，MANSCDP用于設備控制、設備查詢、訂閱通知等信令控制操作。

　　媒體流通道基于RTP/RTCP協(xié)議進行數(shù)據(jù)傳輸，在其上面承載的是H.265、H.264、G.711等格式的媒體數(shù)據(jù)，支持PS OVER RTP和ES OVER RTP封裝格式，傳輸過程中可以通過MANSRTSP協(xié)議來進行播放控制。

　　在進行數(shù)據(jù)交互時，首先建立會話通道，并進行注冊認證。一般是設備向平臺注冊、下級平臺向上級平臺注冊，注冊成功后才可以進行后續(xù)業(yè)務命令。當需要訪問媒體數(shù)據(jù)時，先通過會話通道協(xié)商建立媒體流通道，并交換媒體的格式說明，然后通過媒體流通道進行媒體數(shù)據(jù)的傳輸。

　　標準中提供了基于口令的數(shù)字摘要方式對設備進行身份認證和SIP信令認證，沒有定義業(yè)務數(shù)據(jù)加密、數(shù)據(jù)完整性等相關具體內容，并通過引用方式，描述了在高安全級別情況下，設備身份認證、數(shù)據(jù)加密、SIP信令認證、數(shù)據(jù)完整性保護、訪問控制等應符合GB 35114的規(guī)定。

　　2.4.信令控制

　　設備控制、查詢等通過MANSCDP來實現(xiàn)。MANSCDP基于SIP，對SIP的From、To頭域的URI進行了定義，SIP命令字使用MESSAGE，Body使用XML描述，Control、Query、Notify等元素描述了不同業(yè)務功能。

　　MANSCDP業(yè)務應答并不是直接通過SIP的200 OK回復來承載，而是通過一個新的SIP命令來發(fā)送，業(yè)務應答的SIP命令字同樣是MESSAGE，Body是一個XML，內部通過Response元素來描述不同的業(yè)務應答。協(xié)議中部分命令是沒有應答的，但命令接收方還是要回復一個SIP 200 OK。而對于有應答的命令，命令發(fā)送方除了接收到SIP 200 OK回復外，還會接收到一個業(yè)務應答的命令，此時命令發(fā)送方需要回復一個SIP 200 OK回復進行確認收到業(yè)務應答。

　　MANSCDP的請求和應答中都有一個通用的SN子元素，取值為命令序列號，不同請求必須唯一，實現(xiàn)時一般是遞增的，應答的SN的值必須和請求保持相同，命令請求方接收到應答時，可以通過SN的值將應答和請求關聯(lián)起來。

　　2.4.1.設備控制

　　設備控制命令包括云臺控制、遠程控制、錄像控制、報警布撤防等。命令消息體Body的XML元素是Control，子元素CmdType固定取值為DeviceControl，然后通過PTZCmd、Teleboot、GuardCmd等不同的子元素表示不同的功能。

　　根據(jù)命令的不同含義，設備控制命令有應答和無應答兩類。如果控制命令有應答，那么應答命令消息體Body的XML元素是Response，子元素CmdType固定取值為DeviceControl，通過Result字段來描述命令的執(zhí)行結果。

　　例如錄像控制命令的XML body例子如下：

　　錄像控制命令的應答的XML body例子如下：

　　2.4.2.設備查詢

　　設備查詢命令包括設備目錄查詢、設備信息查詢、設備狀態(tài)查詢等。命令消息體Body的XML元素是Query，通過子元素CmdType的取值Catalog、DeviceInfo、DeviceStatus等來描述不同的查詢內容。設備查詢命令都有應答，應答B(yǎng)ody的XML元素是Response，通過子元素CmdType的取值Catalog、DeviceInfo、DeviceStatus等來描述不同的查詢結果應答，與查詢命令一一對應。

　　2.4.3.設備配置

　　設備配置命令包括基本參數(shù)配置、SVAC編解碼配置等。命令消息體Body的XML元素是Control，而子元素CmdType固定取值為DeviceConfig，然后通過不同的子元素來描述具體的配置，例如基本參數(shù)配置通過BasicParam元素描述。設備配置的設置都是有應答的，應答B(yǎng)ody的XML元素是Response，子元素CmdType的取值DeviceConfig，通過Result元素描述設備配置的設置結果。

　　設備配置的查詢命令Body的XML元素是Query，子元素CmdType固定取值為ConfigDownload，然后通過ConfigType子元素的值來描述具體需要讀取的配置內容，例如基本參數(shù)配置通過取值BasicParam來指定。設備配置的讀取都是有應答的，應答B(yǎng)ody的XML元素是Response，子元素CmdType的取值ConfigDownload，然后通過不同的子元素來描述具體的配置，例如基本參數(shù)配置通過BasicParam子元素來指定。

　　2.4.4.訂閱通知

　　訂閱和通知命令是平臺對設備進行事件或者目錄進行訂閱，當設備產(chǎn)生相應事件或者目錄變化時，將相應的事件或者目錄的數(shù)據(jù)通過通知命令的方式向平臺進行推送，其中事件主要包括報警事件、移動設備位置通知事件等。

　　訂閱命令通過SIP命令SUBSCRIBE進行，通過命令Body中的Query元素的子元素CmdType描述具體的訂閱內容。通知命令通過SIP的NOTIFY命令進行，通過命令Body中的Notify元素的子元素CmdType描述具體的通知內容。

　　另外，設備中產(chǎn)生重要報警或者異常時，應主動上報報警或者狀態(tài)，此時不需要訂閱，而是設備通過SIP的MESSAGE命令直接發(fā)送，命令Body中同樣是Notify元素，通過子元素CmdType描述具體的報警或者狀態(tài)等通知內容。

　　2.5.媒體傳輸

　　媒體傳輸命令包括實時視音頻點播、歷史視音頻回放/下載、語音廣播、語音對講等功能。媒體傳輸功能需要通過會話通道和媒體流通道配合來完成，首先通過會話通道發(fā)送SIP的INVITE命令來創(chuàng)建媒體會話，命令的Body體是SDP文本，里面描述了媒體數(shù)據(jù)的基本信息、媒體編碼格式和傳輸方式等。然后根據(jù)SDP中描述的傳輸方式建立媒體流通道，在媒體流通道上通過基于RTP的ES或者基于RTP的PS等封裝方式傳輸媒體數(shù)據(jù)。

　　對于歷史視音頻回放，可以通過MANSRTSP協(xié)議進行播放、暫停、快進快退、隨機定位等播放控制操作。MANSRTSP協(xié)議并不是直接使用標準的RTSP命令，而是復用了會話通道，使用基于SIP的協(xié)議，SIP命令是INFO命令，命令的Body體中承載的是RTSP命令，通過RTSP的PLAY、PAUSE、TEARDOWN等命令以及相應的Header參數(shù)來描述具體的控制操作要求。

　　語音對講并不是一個獨立的命令，而是通過組合實時音視頻播放和語音廣播的方式來進行的。例如中心用戶要和前端設備用戶進行語音對講，需要中心用戶向前端設備發(fā)起實時視音頻點播，這樣中心用戶就能聽到前端設備用戶的聲音。同時中心用戶向前端設備發(fā)起語音廣播請求，將本地語音傳輸?shù)角岸嗽O備用戶，這樣前端設備用戶就能聽到中心用戶的聲音，從而完成語音對講的過程。業(yè)務上是單一的，但底層的兩個方向的媒體傳輸是通過不同的命令實現(xiàn)的，而且命令之前是相互獨立，互不影響的。

　　3.主要改進

　　3.1.注冊重定向

　　隨著聯(lián)網(wǎng)系統(tǒng)的規(guī)模化建設，單一的SIP信令服務器在應對海量設備命令交互時容易成為性能瓶頸，需要增加多個SIP信令服務器，若不支持注冊重定向，只能通過人工綁定的方式對設備在平臺的SIP信令服務分布式集群節(jié)點間進行負載均衡，并為每個設備配置不同的注冊接入節(jié)點IP和端口，綁定和配置過程復雜繁瑣且工作量大。除此之外，當設備接入的SIP信令服務節(jié)點發(fā)生故障時，因為設備不支持注冊重定向，總是嘗試向故障節(jié)點發(fā)起重新注冊，無法實現(xiàn)自動故障轉移，需要人工發(fā)現(xiàn)并重新進行配置，耗時較長，在此過程中平臺業(yè)務會中斷，數(shù)據(jù)會丟失，對用戶的業(yè)務應用會造成較大影響。

　　為了解決這個問題，2022版增加了注冊重定向功能，對注冊信令的應答格式進行擴展，增加了重定向應答，同時也增加了重定向方式的注冊流程的交互過程說明。有了注冊重定向之后，設備向平臺的SIP信令服務注冊流程更加靈活，設備注冊的相關配置可以大大簡化。平臺系統(tǒng)中增加一個全局SIP注冊服務，由于此服務只進行重定向，不處理具體的業(yè)務信令，因此其負載很輕，也不需要維護設備連接狀態(tài)，容易實現(xiàn)高可用。維護人員可以對所有設備都統(tǒng)一配置同一個全局SIP注冊服務IP和端口。設備首先向全局SIP注冊服務發(fā)起注冊，由全局SIP注冊服務根據(jù)平臺的各個SIP信令服務的負載情況，按照一定的負載均衡策略對設備進行負載均衡調度，將設備調度到合適的SIP信令服務節(jié)點，并向設備回復注冊請求響應302，在響應消息中攜帶對應的SIP信令服務節(jié)點的地址和端口。設備收到302重定向響應后，向重定向的SIP信令服務節(jié)點發(fā)起注冊并完成重定向注冊流程。

　　當設備注冊重定向后，與具體的SIP信令服務節(jié)點通信時，如果按照心跳要求判定SIP信令服務節(jié)點離線，設備會重新執(zhí)行注冊重定向流程，向全局SIP注冊服務發(fā)起新的注冊請求，全局SIP注冊服務會對設備重新進行負載均衡調度，將設備重定向到正常的SIP信令服務節(jié)點，實現(xiàn)了SIP信令服務節(jié)點的故障轉移，保證了業(yè)務連續(xù)可用，提升了用戶使用體驗。

　　3.2.圖像抓拍

　　2022版增加了圖像抓拍功能，通過設備配置的方式來實現(xiàn)，消息體Body的XML元素是Control元素，而子元素CmdType固定取值為DeviceConfig，通過SnapShotConfig元素描述具體的抓拍請求。當設備完成抓拍后，需要發(fā)送一個通知命令，消息體Body的XML元素是Notify，子元素CmdType取值UploadSnapShotFinished，通知中包含抓拍到的圖像的唯一標識。

　　圖像抓拍雖然是通過配置命令來實現(xiàn)，但實際上不像一個持久的配置，反而更像是一個命令，設備收到配置命令后，應該馬上按照配置內容進行抓圖，完成后發(fā)送通知，之后配置就相當于失效了。當需要再次進行抓圖時，即使參數(shù)相同，也需要再次下發(fā)圖像抓拍配置的命令。

　　標準規(guī)范了抓圖的張數(shù)、每張圖之間的間隔時間、抓圖上傳的URL和SessionID，并沒有對如何上傳圖片進行細化。在實際項目應用中，需要進行細化規(guī)范，一般抓圖上傳的URL是一個Http的URL，通過HTTP協(xié)議進行上傳，URL中一般都應該帶token或者其他字段來進行鑒權認證，同時一般也要求在上傳每個圖片時，在URL上附加上SessionID和圖像唯一標識SnapShotFileID，方便圖像服務器進行存儲和索引，在后續(xù)下載時進行關聯(lián)。

　　下面是一個參考實現(xiàn)，下發(fā)圖像抓拍配置的SIP命令的Body如下：

　　然后設備抓拍到一張圖片后，通過Http協(xié)議進行圖片上傳，Http命令報文如下：

　　設備圖像抓拍完成后，發(fā)送抓拍完成通知，相應SIP命令的Body如下：

　　3.3.高清編碼傳輸

　　硬件處理能力和網(wǎng)絡傳輸帶寬的提升以及編解碼技術的發(fā)展，為高清音視頻的應用提供了可能性，而業(yè)務應用的需求，特別是人工智能分析處理對音視頻媒體的分辨率、采樣率等的更高要求，使得高清音視頻成為迫切需求。

　　2022版增加H.265和AAC的支持，對編解碼的具體要求包括的檔次和水平的要求、支持的編解碼選項和工具的要求、碼流語法的要求等。在碼流封裝傳輸時，H.265的PSM流類型取值0x24，RTP包負載類型（Payload Type）建議取值100。AAC的PSM流類型取值0x0F，RTP包負載類型建議取值102。

　　2022版中也對SDP描述進行了擴展，支持對高清媒體情況及其他信息的描述。在f字段中，擴展分辨率的表示方式，在原有的QCIF、CIF基礎上，增加了WxH的通用表示方式，其中W表示寬度，H表示高度，例如1920x1080。音頻的碼率和采樣率也增加了高清音頻所需的定義。另外新增"a=streamnumber:碼流編號"的字段來描述碼流標號，例如0表示主碼流，1表示子碼流1，以此類推。

　　3.4.存儲卡管理

　　在視頻監(jiān)控前端設備中，很多時候需要使用存儲卡進行數(shù)據(jù)存儲且遠程對SD卡進行管理，因此在2022版增加了對存儲卡的查詢和格式化等功能。

　　查詢存儲卡通過會話通道進行，消息Body的XML元素是Query，子元素CmdType固定取值為SDCardStatus，設備收到命令后，在應答中返回設備的SD卡列表，以及每個SD卡的總空間和剩余可用空間等信息。

　　如果存儲卡數(shù)據(jù)異常，或者更換新的存儲卡之后，需要對存儲卡進行格式化，消息Body的XML元素是Control，子元素CmdType固定取值為DeviceControl，然后通過子元素FormatSDCard來描述具體的格式化SD卡的信息。格式化的進度可以通過前面提到的查詢存儲卡的命令進行查詢。

　　3.5.配置管理增強

　　2022版進一步完善了配置管理，將各個配置信息的具體數(shù)據(jù)都獨立抽取出來作為公共數(shù)據(jù)結構進行描述，確保了讀取和寫入配置信息的一致性，同時也在原有的基本參數(shù)配置、SVAC編解碼配置的基礎上，增加了一些業(yè)務應用配置。

　　新增視頻相關配置，視頻參數(shù)屬性配置通過VideoParamAttribute元素描述，用于對編解碼格式、分辨率、幀率、碼率等進行配置。視頻畫面遮擋配置通過PictureMask元素描述，用于對視頻中多個特定區(qū)域進行畫面遮擋。在一些涉及隱私的應用中，可以對部分敏感信息區(qū)域進行遮擋。畫面翻轉配置通過FrameMirror元素描述，用于對畫面的上下翻轉、左右翻轉、中心鏡像等翻轉方式的配置，項目實施過程中，由于現(xiàn)場環(huán)境的限制，有時候只能以某個方向某種角度進行設備安裝，通過畫面翻轉配置，將畫面翻轉成適合觀看的正常角度，方便觀看。前端OSD配置通過OSDConfig元素描述，用于對畫面上的OSD信息進行配置，包括OSD的位置、時間顯示方式、文字內容和顯示方式等。

　　新增錄像相關配置，錄像計劃配置通過VideoRecordPlan元素描述，用于對錄像計劃的時間段、碼流類型等進行配置。報警錄像配置通過VideoAlarmRecord元素描述，用于對控制報警錄像是否啟用，啟用時對錄像延時、預錄、碼流類型等進行配置。

　　新增報警相關配置，報警上報開關配置通過AlarmReport元素描述，用于對移動偵測事件、區(qū)域入侵事件等不同的事件進行是否上報的配置，通過控制不同的報警上報，能夠減少不必要的報警信息，聚焦于重要的報警。

　　3.6.云臺控制增強

　　早期版本的云臺控制，提供了上下左右、變倍變焦、拉框放大、看守位、預置點、巡航等功能，部分功能是通過單獨命令進行，還有部分功能是通過PTZCmd命令進行，這個命令采用二進制數(shù)據(jù)格式描述具體的操作，使用不方便，2022版中對云臺的控制命令更加完善，不再對PTZCmd命令進行增補，而是通過單獨命令的方式進行，并且對控制、查詢、數(shù)據(jù)通知等也進行了規(guī)范。

　　看守位信息查詢命令Query元素的CmdType固定取值HomePositionQuery，返回各個看守位是否啟用、預置位編號、自動歸位時間間隔等。巡航軌跡列表和巡航軌跡查詢命令Query元素的CmdType固定取值CruiseTrackListQuery和CruiseTrackQuery，返回巡航軌跡的列表，以及每個巡航軌跡的編號、名稱、各個預置點的編號、預置點停留時間、云臺速度等信息。

　　PTZ精準控制命令通過子元素PTZPreciseCtrl來描述具體的精準控制參數(shù)，包括云臺水平角度、垂直角度、變焦倍數(shù)等。PTZ精準狀態(tài)查詢命令通過CmdType子元素取值PTZPosition來進行查詢，返回設備PTZ的水平角度、垂直角度、變倍倍數(shù)、水平視場角、垂直視場角、可視距離等信息。PTZ精準狀態(tài)也可以通過訂閱的方式進行查詢，訂閱后，設備會將PTZ精準位置變化的信息通過事件通知的方式進行推送。

　　目標跟蹤控制命令通過子元素TargetTrack來描述具體的目標跟蹤方式，例如自動跟蹤、手動跟蹤等。這個命令主要用于全景攝像機和球機進行目標跟蹤配合，當在全景攝像機中指定具體位置時，聯(lián)動球機跟蹤展示該區(qū)域的特寫圖像。

　　3.7.多路徑級聯(lián)

　　在視頻聯(lián)網(wǎng)平臺發(fā)展過程中，由于業(yè)務流程和網(wǎng)絡拓撲越來越復雜，聯(lián)網(wǎng)結構逐漸從樹狀結構發(fā)展成網(wǎng)狀結構，下級平臺可能會有多個上級平臺或者互聯(lián)平臺，同一目錄可能會被推送到多個不同的平臺，而這些平臺又可能再往上推送到同一個更上級的平臺，從而形成了多個路徑。一個多路徑的例子如圖3所示，這種聯(lián)網(wǎng)結構中，上級域訪問下級域接入的目標設備，存在多種訪問路徑的可能性。圖中平臺A訪問設備M，則存在C→E、B→C→E、B→D→E三種路徑。

圖3 攝像機及平臺推送示例

　　基于全局統(tǒng)一的資源編碼規(guī)范，多個不同路徑匯聚的目錄結構，可以通過全局唯一編碼來識別出相同的設備。為了能獲取到多路徑中每個路徑的具體情況，通過指定使用具體路徑的方式來訪問設備，并且當某個路徑出現(xiàn)故障時，切換使用其他路徑的方式進行設備訪問，減輕局部故障的影響，提高系統(tǒng)的可靠性。

　　在目錄推送的過程中，在設備目錄項和平臺目錄項的XML格式的數(shù)據(jù)中加入ParentID元素，表示此目錄項的父節(jié)點信息，對于多個下級節(jié)點推送上來的目錄項，通過全局統(tǒng)一編碼將相同的目錄項匹配出來。如果他們的ParentID元素的值不一致，則進行值的合并。這樣在上級平臺中，可以通過設備目錄項和平臺目錄項的ParentID元素，從設備開始逐級往上查找到最高節(jié)點，形成完整的路徑。如果中間某個節(jié)點的ParentID因為合并有多個值，也就是有多個上級節(jié)點，就會形成多個路徑。

　　在對設備進行命令控制過程中，上級平臺與設備之間存在多條路徑時，應支持自動路徑選擇，默認選擇的是在線的且最短路徑的下級平臺或設備，下級平臺或設備在返回成功或失敗 SIP 響應時，消息頭部應擴展 X-RoutePath 字段，用于記錄命令過程中經(jīng)過的平臺路徑情況。響應消息從下級逐層轉發(fā)到上級平臺時，轉發(fā)消息的平臺應將本平臺編碼添加至 X-RoutePath字段的最前面，用"-"分隔）。這樣上級平臺就可以得到信令執(zhí)行過程中默認的自動路徑情況。

　　當由于中間平臺出現(xiàn)異常等原因，上級平臺希望換一個路徑向設備發(fā)送命令時，可以通過添加 X-PreferredPath 頭部字段的方式，指定期望的命令請求經(jīng)過的各級平臺路徑。平臺在命令請求時，如果存在 X-PreferredPath 頭字段，且本平臺在路徑之內，則應將本平臺編號從X-PreferredPath中刪除，然后轉發(fā)請求到X-PreferredPath中指定的下一個平臺，從而實現(xiàn)指定路徑方式的訪問。

　　3.8.設備軟件升級

　　新版標準發(fā)布后，一方面新的設備和平臺采用新標準進行開發(fā)需要時間，另一方面已有的設備和平臺在進行升級前可能還將在一段較長時間內維持使用，而且未來還可能有新版標準發(fā)布，因此多版本標準并存將成為常態(tài)。為了使不同協(xié)議版本的設備、平臺之間兼容，2022版增加了協(xié)議版本號的說明，通過在SIP協(xié)議中增加X-GB-Ver頭部來描述具體的版本號，1.0表示2011版，2.0表示2016版，3.0表示2022版。通訊雙方可以通過消息頭部來了解對方支持的協(xié)議版本，然后根據(jù)協(xié)議版本要求進行通信。一般來說，設備只需要支持一種協(xié)議版本即可，由于平臺往往需要同時接入多種協(xié)議版本的設備，因此需要支持多種協(xié)議版本，由平臺來適配設備。

　　在實際項目中經(jīng)常遇到需要設備升級的場景，之前由于沒有定義的設備升級指令，都需要單獨登陸到設備上進行逐個升級，費事費力。2022版增加了設備升級的指令，可以很好的解決設備批量升級的問題。

　　由于不同的廠家的升級包格式與升級方式都有差別，因此2022版只定義了升級命令的下發(fā)和升級結果的通知過程，對于升級包本身只通過一個FileUrl字段來說明，不做過多的限制。設備升級命令通過會話通道進行，消息Body的XML元素是Control，子元素CmdType固定取值為DeviceControl，通過DeviceUpgrade元素描述升級包路徑、升級SessionID等信息，設備收到命令后，獲取升級包進行升級，升級成功后發(fā)送升級結果通知，消息Body的XML元素是Notify，子元素CmdType固定取值DeviceUpgradeResult，通過SessionID、UpgradeResult等子元素描述升級結果。

　　實際實現(xiàn)時，一般是采用Http協(xié)議的FileURL，將設備升級軟件包按照廠商、型號、版本等信息進行分類索引，放在升級軟件包倉庫管理系統(tǒng)中進行管理，提供Http方式的下載服務。當需要對設備進行升級時，先通過設備信息查詢命令獲取設備的廠商、型號、版本信息等，然后在升級軟件包倉庫中按照廠商、型號、版本等信息搜索合適的高版本的升級軟件包下發(fā)給設備進行升級。在升級過程中需記錄升級的結果，檢驗升級后的版本是否和需要升級的版本一致。

　　4.結語與思考

　　從標準的歷次迭代更新，我們可以看到標準和應用之間的相互促進，有效解決了異構視頻聯(lián)網(wǎng)系統(tǒng)的互聯(lián)互通，將不同領域新技術進行多維度、多層次集成創(chuàng)新應用，實現(xiàn)跨區(qū)域、跨部門、跨層級的視頻資源超大規(guī)模聯(lián)網(wǎng)共享。

　　GB/T28181標準在公共安全、社會治理、智慧交通等多個領域中廣泛使用，并逐步延伸到非視頻的物聯(lián)設備聯(lián)網(wǎng)應用。2022版修訂也深入討論了門禁、出入口控制器、停車道閘等相關提案，最終由于種種原因沒有完全采納。

　　隨著AIoT融合創(chuàng)新應用的不斷發(fā)展，越來越多的物聯(lián)設備加入到大聯(lián)網(wǎng)中，必然會對標準提出更多新需求，同時也給標準制定帶來新挑戰(zhàn)。如何統(tǒng)籌兼顧大數(shù)據(jù)量頻繁交互的智能視頻應用和超低功耗的物聯(lián)應用對協(xié)議框架的不同要求，也許是標準未來再次更新時要思考的問題。技術路線經(jīng)過產(chǎn)業(yè)實踐得到了廣泛認可的內容遲早會成為標準，但根據(jù)場景應用等需求，將來是在此標準中增補，還是以獨立標準的形式發(fā)布更合適仍然有待深入研究。