面向平安城市的視頻監控前端呼叫設計研究

王永建　徐楊　王迅　周顯

摘要：在平安城市的建設中，管理平臺對視頻監控前端呼叫越來越重要。為了完善對視頻監控前端的呼叫效果，設計了一種視頻監控前端呼叫方案。首先簡析了SIP、RTP/RTCP協議原理；設計了視頻監控系統整體結構，定義了各主要組成部件的功能。然后分析了視頻監控前端呼叫設計思路，設計了RTP Over UDP、RTP Over TCP的呼叫方案，以及NAT穿越方案。本文的設計思路在一些平安城市建設中已開始應用，應用效果良好，具有一定借鑒意義。

關鍵詞：SIP；RTP/RTCP；監控前端；NAT穿越

中圖分類號：TN919.81 文獻標識碼：A DOI：10.3969/j.issn.1003-6970.2016.04.024

0 引言

隨著移動互聯網、云計算、智能終端、Web等技術的發展，以及2012年國家智慧城市試點建設工作的啟動，視頻監控系統在構建和諧社會中發揮的作用越來越重要。

2012年6月1日，公安部發布了《安全防范視頻監控聯網系統信息傳輸、交換、控制技術要求》（B/T28181-2011）相關文件，正式啟動了國家平安城市的建設工作。

平安城市視頻監控系統中的監控前端（像機、傳感器、報警器等）再是傳統的只會數據采集功能，而是能根據管理平臺/客戶端的指令或者請求，進行相應操作或者提供相關服務。如響應平臺云鏡控制、呼叫/警告監控現場可疑人員、提醒人群避開危險場所/歹徒、提供實時圖像服務等，管理平臺/客戶端對監控前端的呼叫控制功能要求越來越豐富和嚴格。目前從管理平臺/客戶端→監控前端的呼叫實現還需要完善，本文設計了一種實現方案，并進行了探究。

1 相關協議分析

1.1 SIP協議

SIP（Session Initiation Protocol，會話初始協議）是基于HTTP（HyperText Transfer Protocol，超文本傳輸協議）和SMTP（Simple Mail Transfer Protocol，簡單郵件傳送協議）的信令協議，屬于一個應用層的控制協議，基于請求/響應的事務處理模型，使用消息方式完成用戶會話的建立和管理。見圖1所示：

SIP具有易擴展，易實現等特點，非常適合用來實現基于互聯網的多媒體通信系統。SIP支持名字映射和重定向服務，將原來請求的地址映射為新地址，只進行重定向，并不參與事務的處理。SIP非常適用于作為客戶唯一的外部標志，而無需關系所在的實際網絡位置。

SIP消息分為兩類：SIP請求和SIP響應；其中請求消息由客戶機發往服務器，響應消息由服務器發往客戶機。請求消息和響應消息格式由一個起始行、若干個頭字段，以及一個可選的消息體組成。請求和響應消息的基本格式如下：

SIP消息一起始行

*消息頭部（個或多個頭部）

CRLF（行）

[息體]

起始行一請求行，狀態行

請求消息的起始行為請求行：

Request-Line=Method SP Request-URI SP SIP-ersion CRLF。

響應消息的起始行為狀態行：

Status-Line=SIP-Version SP Status-Code SP Re-ason-Phrase CRLF。

1.2 RTP/RTCP協議

SIP協議單獨不能完成多媒體呼叫，必須與RTP/RTCP等協議一起配合共同完成多媒體會話過程。

RTP（Realtime Transport Protocol，實時傳輸協議）一種針對多媒體數據流的，運行在UDP（User DatagramProtocol）協議之上的傳輸層協議。RTP協議只負責對媒體數據流的封裝和實時傳輸，但不能為數據提供可靠的傳輸機制，也不提供流量控制或擁塞控制。由RTCP（Realfime Transport Control Protocol）協議根據傳送網絡質量，實現流量控制與擁塞控制。RTCP僅在基于UDP傳送媒體流時使用，基于TCP（Transport Control Protocol）傳送媒體不使用。在UDP中，RTCP與RTP協議配對使用，通常RTP使用偶數號端口號，則相應的RTCP使用緊隨其后的奇數號端口。見圖l所示。

2 系統結構設計

本文將視頻監控系統分為中央管理系統CMS（Central Management System），接入網關AG（AccessGateway），媒體分發系統MDS（Media DistributionSystem），監控前端MF（Monitoring Fore-terminal），客戶端MC（Multimedia Client），以及其它模塊。見圖2所示。

（1）中央管理系統

CMS是視頻監控系統的中樞管理系統，直接管理AG與其它模塊。作為管理中心提供客戶端/用戶管理；作為存儲中心存儲客戶端/用戶數據和業務參數配置數據，向Portal提供發布的內容。提供客戶端接人時的呼叫控制功能，接收SIP的呼叫請求。如果被叫是本域的前端，則修改SIP消息中的SDP（Session Description Protocol），根據前端注冊的信令地址發起新的SIP呼叫，失敗則釋放本次呼叫。

（2）接入網關

AG是系統的前端接入網關，以及Web/Wap客戶端的Http Portal，是MF注冊或者會話時的第一個訪問點，部署在MF與CMS之間。AG必須實現本域MF的接人，接收和轉發由MF或CMS發來的SIP信令。實現對MF的接入管理，接收、轉發來自MF的呼叫控制信令給CMS，轉發從CMS接收到的請求或應答消息給MF。

（3）媒體分發系統

MDS是系統的媒體轉發/分發單元，負責平臺側的媒體傳送，在CMS的媒體調度模塊控制下完成音視頻傳送功能，可以多級級聯和分布式部署。

（4）監控前端

MF包括圖像采集設備，如攝像機、智能終端，和其它信息采集設備，如傳感器、射頻識別儀器等，本文默認為攝像機。監控前端主要負責：數據采集、緩存、處理、上傳至管理平臺；響應管理平臺的指令或者Web/WAP客戶端的請求，執行對應操作或者提供相關服務。

（5）客戶端

MC分為PC客戶端、手機客戶端，基于Web/WAP，本文默認為Web。客戶端功能可包括呼叫控制、圖像瀏覽、錄像回放、云鏡控制、快照、解碼、對講等功能。

3 呼叫設計方案

3.1 設計思路

在MF接入到管理平臺之后，平臺根據需要判斷是否呼叫MF。管理平臺錄像或者瀏覽接入MF上的視頻時，平臺主動呼叫MF。

管理平臺根據MF上報支持的RTP Over UDP還是RTP Over TCP能力進行選擇確定采用何種方式，默認采用RTP Over UDP方式。MF配置成RTPOverTCP方式下，平臺能夠主動采用RTP Over TCP方式呼叫MF。客戶端與管理平臺對MF的呼叫原理類似。

3.2 RTP Over UDP

在實時流媒體采用RTP Over UDP方式進行承載時，MF需支持RTCP包的發送和接收。同時MF可能部署在NAT（Network Address Translation）設備之后，在管理平臺與MF呼叫建立成功之后，MF需主動發送RTP/RTCP的NAT穿越包來打通平臺與MF之間的NAT設備。MF根據NAT穿越包響應判斷在MF與MDS之間是否存在NAT設備，如果不存在則后續可不發送NAT穿越包，如果存在N則需要定時發送NAT穿越包。見圖3所示：

（1）CMS判斷是否需要呼叫MF請求實時視頻；

（2）如果需要請求MF實時視頻，CMS向MDS申請媒體資源；

（3）媒體資源申請成功之后，CMS主動發起INVITE消息到AG；

（4）AG轉發請求MF實時視頻INVITE消息到MF；

（5）MF分配資源，發送200 OK響應消息給AG，在消息中攜帶MF的SDP消息；

（6）AG轉發請求實時視頻響應消息到CMS；

（7）CMS通知MDS媒體協商成功；

（8）CMS發送ACK消息到AG；

（9）AG轉發ACK消息到MF；

（10）MF收到ACK消息后，首先發送RTP和RTCP的NAT穿越包，并開始發送碼流到MDS，MDS接收碼流后存儲或者分發到客戶端；

（11）當平臺錄像結束后，或者客戶端都停止觀看實時視頻后，CMS發送請求釋放對應的媒體資源；

（12）CMS發送BYE消息到AG；

（13）AG轉發BYE消息到MF；

（14）MF終止發送實時視頻流到平臺并發送2000K響應消息。

3.3 RTP Over TCP

在實時流媒體采用RTP Over TCP方式進行承載時，MF需支持根據SDP協商的信息主動與MDS建立TCP鏈路，發送RECORD消息給MDS，并通過建立的TCP鏈路發送RTP和RTCP給MDS。RECORD消息定義與NAT穿越包定義保持一致，RTPOver TCP打包格式參考REC2326中的10.12 Em-bedded（Interleaved）Binary Data定義方式。見圖4所示。

（1）cMS判斷是否需要呼叫MF請求實時視頻；

（2）如果需要請求MF實時視頻，CMS向MDS申請媒體資源；

（3）媒體資源申請成功之后，CMS主動發起INVITE消息到AG；

（4）AG轉發請求MF實時視頻INVITE消息到MF；

（5）MF分配資源，發送200 OK響應消息給AG，在消息中攜帶MF的SDP消息；

（6）AG轉發請求實時視頻響應消息到CMS；

（7）CMS通知MDS媒體協商成功；

（8）CMS發送ACK消息到AG；

（9）AG轉發ACK消息到MF；

（10）MF收到ACK消息后，MF根據SDP協商中的TCP連接，向MDS建立TCP鏈路，并通過建立的連接發送RECORD消息（這個RECORD消息包的格式與RTP Over UDP中發送的NAT穿越包格式保持一致，支持消息承載發送的方式從UDP變成TCP）；

（11）MDS根據RECORD包內容判斷合法性，并返回響應給MF；

（12）MF通過建立的TCP鏈路發送RTP/RTCP數據給MDS；

（13）當平臺錄像結束后，或者客戶端停止觀看實時視頻后，CMS發送請求釋放對應的媒體資源；

（14）CMS發送BYE消息到AG；

（15）AG轉發BYE消息到MF；

（16）MF終止發送實時視頻流到平臺并發送2000K響應消息；

（17）MF主動釋放建立的TCP鏈路。

3.4 NAT穿越

實際應用中，由于網絡安全、管理、IP地址資源等因素，MF、CMS、MDS等往往位于不同的子網之內，不允許跨子網直接通信。NAT（NetworkAddress Translation）技術是一種邊緣網絡過渡的常用解決方案，主要用于解決跨IPv4/IPv6子網之間的直接通信問題。不過NAT會破壞源地址與目的地址之間的連續性，因此RTP/RTCP數據包的NAT穿越至關重要。NAT穿越包完全采用文本格式，采用類RTSP（Real Time Streaming Protocol）的PLAY和RECORD方法，其PLAY用于MF發送NAT穿越包，NAT穿越數據包分為請求包與響應包，具體格式定義如下。

（1）MF的NAT穿越請求包

（2）MF的NAT穿越響應包

請求和響應通過Session和CSeq進行配對，請求和響應的Session與CSeq都是相同的。

在請求消息中local addr=0.6.10.102；local port10000是指發送NAT請求包的本地IP地址和端口號。

在響應消息中src addr=202.103.10.12；src port=5673是對端檢測到的NAT請求設備的源IP地址和端口號（也就是NAT之后的IP地址和端口號），localaddr=10.6.10.102；local port=10000是本地發送RTP包的IP地址和端口號。

RTCP的NAT穿越包和上面的類似，只是CSeq、type和port內容的值不同。

NAT請求發送方檢測到local addr=src_addr并且local port=src port時，可停止發送NAT穿越包，否則定時發送NAT穿越包。

MC直連MF時，NAT包中的URL（UniformResoureLocator）陽Session統一采用MF的SDP中指定的URL和Session ID。

4 結束語

本文基于SIP、RTP/RTCP等協議，設計了平安城市中管理平臺/客戶端->監控前端的呼叫實現方案，NAT穿越方案。本文的思路在一些項目中已開始運用，效果良好。

隨著大數據、智能分析、RFID（Radio FrequencyIdentification）、臉譜識別、虹膜識別等技術的發展，以及Web/Wap、APP客戶端的廣泛應用，對監控前端的呼叫控制提出了更高的要求，將會有新的實現技術與方案，該領域的研究還有很多工作要做。