王永建　徐楊　王迅　周顯

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

關(guān)鍵詞：SIP；RTP/RTCP；監(jiān)控前端；NAT穿越

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

0 引言

隨著移動互聯(lián)網(wǎng)、云計算、智能終端、Web等技術(shù)的發(fā)展，以及2012年國家智慧城市試點建設(shè)工作的啟動，視頻監(jiān)控系統(tǒng)在構(gòu)建和諧社會中發(fā)揮的作用越來越重要。

2012年6月1日，公安部發(fā)布了《安全防范視頻監(jiān)控聯(lián)網(wǎng)系統(tǒng)信息傳輸、交換、控制技術(shù)要求》（B/T28181-2011）相關(guān)文件，正式啟動了國家平安城市的建設(shè)工作。

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

1 相關(guān)協(xié)議分析

1.1 SIP協(xié)議

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

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

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

SIP消息一起始行

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

CRLF（行）

[息體]

起始行一請求行，狀態(tài)行

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

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

響應(yīng)消息的起始行為狀態(tài)行：

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

1.2 RTP/RTCP協(xié)議

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

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

2 系統(tǒng)結(jié)構(gòu)設(shè)計

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

（1）中央管理系統(tǒng)

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

（2）接入網(wǎng)關(guān)

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

（3）媒體分發(fā)系統(tǒng)

MDS是系統(tǒng)的媒體轉(zhuǎn)發(fā)/分發(fā)單元，負責(zé)平臺側(cè)的媒體傳送，在CMS的媒體調(diào)度模塊控制下完成音視頻傳送功能，可以多級級聯(lián)和分布式部署。

（4）監(jiān)控前端

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

（5）客戶端

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

3 呼叫設(shè)計方案

3.1 設(shè)計思路

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

管理平臺根據(jù)MF上報支持的RTP Over UDP還是RTP Over TCP能力進行選擇確定采用何種方式，默認采用RTP Over UDP方式。MF配置成RTPOverTCP方式下，平臺能夠主動采用RTP Over TCP方式呼叫MF?？蛻舳伺c管理平臺對MF的呼叫原理類似。

3.2 RTP Over UDP

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

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

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

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

（4）AG轉(zhuǎn)發(fā)請求MF實時視頻INVITE消息到MF；

（5）MF分配資源，發(fā)送200 OK響應(yīng)消息給AG，在消息中攜帶MF的SDP消息；

（6）AG轉(zhuǎn)發(fā)請求實時視頻響應(yīng)消息到CMS；

（7）CMS通知MDS媒體協(xié)商成功；

（8）CMS發(fā)送ACK消息到AG；

（9）AG轉(zhuǎn)發(fā)ACK消息到MF；

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

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

（12）CMS發(fā)送BYE消息到AG；

（13）AG轉(zhuǎn)發(fā)BYE消息到MF；

（14）MF終止發(fā)送實時視頻流到平臺并發(fā)送2000K響應(yīng)消息。

3.3 RTP Over TCP

在實時流媒體采用RTP Over TCP方式進行承載時，MF需支持根據(jù)SDP協(xié)商的信息主動與MDS建立TCP鏈路，發(fā)送RECORD消息給MDS，并通過建立的TCP鏈路發(fā)送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主動發(fā)起INVITE消息到AG；

（4）AG轉(zhuǎn)發(fā)請求MF實時視頻INVITE消息到MF；

（5）MF分配資源，發(fā)送200 OK響應(yīng)消息給AG，在消息中攜帶MF的SDP消息；

（6）AG轉(zhuǎn)發(fā)請求實時視頻響應(yīng)消息到CMS；

（7）CMS通知MDS媒體協(xié)商成功；

（8）CMS發(fā)送ACK消息到AG；

（9）AG轉(zhuǎn)發(fā)ACK消息到MF；

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

（11）MDS根據(jù)RECORD包內(nèi)容判斷合法性，并返回響應(yīng)給MF；

（12）MF通過建立的TCP鏈路發(fā)送RTP/RTCP數(shù)據(jù)給MDS；

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

（14）CMS發(fā)送BYE消息到AG；

（15）AG轉(zhuǎn)發(fā)BYE消息到MF；

（16）MF終止發(fā)送實時視頻流到平臺并發(fā)送2000K響應(yīng)消息；

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

3.4 NAT穿越

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

（1）MF的NAT穿越請求包

（2）MF的NAT穿越響應(yīng)包

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

在請求消息中l(wèi)ocal addr=0.6.10.102；local port10000是指發(fā)送NAT請求包的本地IP地址和端口號。

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

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

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

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

4 結(jié)束語

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

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