一．摘要

本文分析了日益增長的民用級別家庭和個人網(wǎng)絡視頻監(jiān)控市場的需求特點，并給出了一種經(jīng)濟可行易于大規(guī)模部署的P2P解決方案。

由于篇幅有限，本文只給出了方案的思路，未對更深入的技術細節(jié)做詳細的論述，有興趣的朋友可以繼續(xù)深入研究。

二．關鍵詞

IPCAM, P2P，NAT, STUN, TURN, ICE, PJSIP, OPENSIPS, UDT， TCP, UDP

三．需求提出

網(wǎng)絡視頻監(jiān)控市場持續(xù)火爆升溫，除了公共安全市場持續(xù)高速增長之外，民用市場中家庭和個人視頻監(jiān)控的需求近年也在逐漸增多。這主要得益于以下幾點：

1. 網(wǎng)絡視頻監(jiān)控產(chǎn)品的價格已經(jīng)降低到個人很容易接受的程度。

2. 家庭寬帶網(wǎng)絡的逐步普及。

3. 3G網(wǎng)絡的逐步普及。

家庭和個人監(jiān)控的需求和傳統(tǒng)的公共安全監(jiān)控需求有明顯的不同，其特點主要體現(xiàn)在以下幾個方面：

1. 規(guī)模很小。通常是1臺或者幾臺。

2. 無需專用的監(jiān)控客戶端，無需長時間監(jiān)控。

3. 監(jiān)控客戶端和網(wǎng)絡攝像機多位于不同的網(wǎng)絡。比如網(wǎng)絡攝像機在家中，用戶通過公司的網(wǎng)絡或者手機查看視頻。

4. 不會多人同時查看一路視頻，最多一兩人同時看，且概率較小。

5. 無需連續(xù)長時間錄像，多采用移動偵測或者其他告警觸發(fā)錄像，拍照，同時通過郵件，短信提醒。

四．技術難點

通過以上分析可以看出，家庭以及個人視頻監(jiān)控的需求和傳統(tǒng)公共安防市場的需求有很大的不同，決定了其必須采用不同的技術路線和方案：

1. 網(wǎng)絡攝像機和監(jiān)控客戶端（PC/手機）位于不同的網(wǎng)絡，中間有防火墻隔離，無法像傳統(tǒng)安防產(chǎn)品一樣采用網(wǎng)絡直連通過IP地址直接訪問的方式。

2. 網(wǎng)絡攝像機數(shù)量龐大（至少以萬為單位），但分屬多個用戶。如果采用中央服務器轉發(fā)的方案，需要互聯(lián)網(wǎng)上部署相當數(shù)量的轉發(fā)服務器，成本相當高。

3. 必須實現(xiàn)即插即用，不能讓用戶進行復雜的安裝配置。否則售后服務的代價太高。

要實現(xiàn)位于不同網(wǎng)絡里的大量網(wǎng)絡攝像機和客戶端點對點的訪問，比較可行而且比較經(jīng)濟的方法是實現(xiàn)防火墻的穿透（NAT），讓客戶端和網(wǎng)絡攝像機之間建立一個直接的數(shù)據(jù)傳輸通道，傳輸視頻流和信令。

要實現(xiàn)NAT穿越，需要有一套機制，能夠輕松的讓客戶端和網(wǎng)絡攝像機之間能建立起聯(lián)系，簡單的說，就是讓客戶端能找到自己要訪問的攝像機，然后去實現(xiàn)NAT穿越，進而可以訪問視頻和進行其他操作。

只有解決了上述兩個技術難點，大規(guī)模部署P2P網(wǎng)絡視頻監(jiān)控系統(tǒng)，才有可能實現(xiàn)。

五．解決方案

筆者經(jīng)過深入的研究和分析，給出以下解決方案。

1. NAT的穿越

NAT的穿越并非安防監(jiān)控領域的技術，是目前VOIP以及即時通信等產(chǎn)品的基礎性技術，目前來講已經(jīng)比較成熟，且有完整的技術標準RFC，同時也有眾多的實現(xiàn)方案，包括許多已經(jīng)得到廣泛應用的開源項目。

簡單來講，實現(xiàn)NAT的穿越是可能的，成功的概率也比較高。UDP的協(xié)議進行數(shù)據(jù)傳輸穿透NAT的成功率比較高，接近100%，TCP則存在一些情況無法實現(xiàn)穿越，主要受限路由器的端口映射機制。

要實現(xiàn)NAT穿越，需要有穿越控制服務器部署在互聯(lián)網(wǎng)（有固定的域名或者IP），由該服務器來協(xié)助網(wǎng)絡攝像機和客戶端來實現(xiàn)NAT穿越。有些服務器還能在TCP不能穿越的情況下，實現(xiàn)RELAY(數(shù)據(jù)中繼轉發(fā))的功能，以確保二者之間能實現(xiàn)數(shù)據(jù)通信。

由于NAT穿越控制服務器不同于安防監(jiān)控系統(tǒng)中的媒體轉發(fā)服務器，主要進行信令交互，不轉發(fā)媒體數(shù)據(jù)，在協(xié)助打通數(shù)據(jù)通道之后，對應的網(wǎng)絡攝像機和客戶端就不會再占用服務器帶寬和處理能力了，因此一臺穿越控制服務器可以接入數(shù)量龐大的網(wǎng)絡攝像機和客戶端。

2. 網(wǎng)絡攝像機和客戶端之間的訪問機制

通常網(wǎng)絡攝像機都有唯一ID，并通過該ID注冊到穿越控制服務器?？蛻舳艘L問對應的網(wǎng)絡攝像機時，也需要先注冊到穿越控制服務器，并提交對應 網(wǎng)絡攝像機的ID，由穿越控制服務器查找對應的網(wǎng)絡攝像機，并協(xié)助網(wǎng)絡攝像機和客戶端之間進行NAT穿越，最后打通一個點對點的數(shù)據(jù)傳輸通道。之后，二者 即可進行正常的媒體和信令交互了。

為實現(xiàn)更加有效的管理，服務器可對設備接入進行認證。此外，如果設備ID過長，也可以為設備建立別名，客戶端訪問時用設備別名作為參數(shù)，服務器來查找對應設備。

3. 數(shù)據(jù)傳輸機制

網(wǎng)絡攝像機和客戶端之間的數(shù)據(jù)傳遞包括有媒體流，信令流等。信令流數(shù)據(jù)量較小，媒體流數(shù)據(jù)量加大，而且需要有較好的實時性。

如果媒體流和信令流分開傳輸，需要打通多個通道，增加了復雜性和出錯可能，同時增加了服務器的負擔。

前面也講過，UDP協(xié)議能有比較好的NAT穿透性，也比較適合媒體流的傳輸，但可靠性較差，不宜傳輸信令。為減輕服務器負擔（避免TCP無法穿 透需要轉發(fā)），提高穿透成功率，筆者建議只打通一個UDP通道，利用該UDP通道封裝媒體和信令流，在應用層加以區(qū)分，哪些是媒體流，那些是信令流。

由于UDP傳輸信令可靠性極差，即使是傳輸媒體數(shù)據(jù)，在互聯(lián)網(wǎng)環(huán)境下肯定會出現(xiàn)丟包的情況，仍然會出現(xiàn)圖像花屏或者解碼出錯的情況，因此必須要解決此問題。

好在此問題并非我們第一個提出，利用UDP協(xié)議進行可靠的數(shù)據(jù)傳輸?shù)男枨笤缇痛嬖冢⒂辛吮容^好的解決方案，那就是通過UDP協(xié)議在應用層實現(xiàn)數(shù)據(jù)的緩沖，序列化，重傳，可靠性控制和擁塞控制。

如果上述三個問題都已解決，則網(wǎng)絡視頻監(jiān)控的P2P方案已經(jīng)基本實現(xiàn)，剩下的就是產(chǎn)品化的問題。以下筆者針對PC訪問和手機訪問分別給出簡要的實現(xiàn)說明：

1. PC訪問網(wǎng)絡攝像機。

PC訪問網(wǎng)絡攝像機，可以先訪問一個網(wǎng)頁，傳入網(wǎng)絡攝像機的序列號。

網(wǎng)頁加載一個控件，該控件通過NAT穿越控制服務器和該序列號對應的網(wǎng)絡攝像機實現(xiàn)NAT穿透后，通過可靠的UDP傳輸信令和媒體數(shù)據(jù)?？丶峁┮曨l瀏覽，對講，云臺控制，參數(shù)查詢設置等功能。

2. 手機訪問網(wǎng)絡攝像機。

手機由于平臺的不同，需要單獨開發(fā)對應的客戶端或者插件以實現(xiàn)和PC訪問類似功能。但原理是一樣的，都需要通過NAT穿越控制服務器和該序列號 對應的網(wǎng)絡攝像機實現(xiàn)NAT穿透后，通過可靠的UDP傳輸信令和媒體數(shù)據(jù)。由于開源的NAT穿越庫是可以移植的，在LINUX，WINCE，IOS, Android，Sbrian等都可以實現(xiàn)同樣的NAT穿越功能。

六．實現(xiàn)建議

最后筆者給出幾個技術方案的建議，有興趣的朋友可以自己再去做深入研究，歡迎探討。

1. NAT穿越庫的選擇，筆者推薦PJSIP，網(wǎng)路攝像機以及客戶端都可以采用。

2. NAT穿越控制服務器的選擇，筆者推薦OPENSIPS。

3. 可靠UDP傳輸方案的選擇，推薦UDT。