房新彥，張艷霞，崔瑞琳，羅思維

P2P網絡視頻監(jiān)控技術機制解析

房新彥，張艷霞，崔瑞琳，羅思維

（天翼物聯科技有限公司，上海 200122）

當前，民用市場中中小企業(yè)和家庭視頻監(jiān)控規(guī)模呈爆發(fā)式增長，針對上千萬攝像機的監(jiān)控需求，產業(yè)界普遍采用點對點（peer to peer，P2P）網絡視頻監(jiān)控技術，綜合闡述了P2P網絡視頻監(jiān)控技術原理，分析了主流的P2P網絡視頻監(jiān)控所采用的流媒體控制技術、傳輸技術以及私網穿越技術，最后提出了大規(guī)模部署的P2P視頻監(jiān)控解決方案建議。

網絡視頻監(jiān)控；P2P；信令

0 引言

網絡視頻監(jiān)控市場持續(xù)火爆升溫，除了公共安全市場持續(xù)高速增長，民用市場中中小企業(yè)和家庭視頻監(jiān)控也在爆發(fā)式增長，其需求和傳統(tǒng)的公共安全監(jiān)控需求有明顯的不同，一般來說規(guī)模很小，通常是1臺或者幾臺，而且不會多人同時查看一路視頻，最多幾人同時看，且?guī)兹送瑫r觀看的概率較??；多采用移動偵測或者其他告警觸發(fā)錄像和拍照，同時通過郵件、短信提醒。

為滿足這一類用戶需求，一些安防企業(yè)以及運營商普遍采用對等網絡（peer to peer，P2P）視頻監(jiān)控技術，這是一種輕量級平臺架構，平臺只負責設備的注冊認證、遠程管理升級及參數查詢等功能，不再承擔視頻的存儲、轉發(fā)、分發(fā)、轉碼等功能，視頻流為點對點的直連傳輸，不再經平臺轉發(fā)，視頻存儲采用攝像機直存云存儲，平臺也不再提供中心存儲，此種架構無疑大大減少了平臺的軟/硬件投資，有效地節(jié)約了平臺成本，同時點對點直連的流媒體方案緩解了平臺壓力，使平臺具有十萬級甚至百萬路的用戶接入能力，降低了端到端時延，滿足中小企業(yè)和家庭用戶的監(jiān)控需求。

P2P網絡視頻監(jiān)控技術已成為一種發(fā)展趨勢，下面針對業(yè)界關于P2P網絡視頻監(jiān)控方案和技術機制進行分析。

1 P2P網絡視頻監(jiān)控技術原理

目前，P2P網絡視頻監(jiān)控比較有代表性的產品有?？滴炇⒋笕A樂橙、中國電信天翼看家和中國移動千里眼等。其中，安防企業(yè)的P2P網絡監(jiān)控系統(tǒng)一般采用同類設備或同品牌設備，而中國電信等運營商的P2P網絡監(jiān)控系統(tǒng)可支持多家廠商設備。

P2P網絡視頻監(jiān)控通常具備以下特性。

● 標準化：在標準化方面，將多家產品集成在一個系統(tǒng)里面，對標準化和互通性提出的要求非常高，平臺提供標準協(xié)議接口、標準網元結構，架構上支持多域互聯。

● 大容量平臺：支持大容量的前端設備接入、流媒體私網穿越轉發(fā)、客戶接入等。

● 大容量存儲：支持大容量錄像存儲任務，且容量具有高擴展性，滿足長時間大容量視頻圖像存儲的需求。

● 接口開放：監(jiān)控系統(tǒng)與其他相關系統(tǒng)的整合更加靈活和統(tǒng)一，提供可開放、可共享的接口，有利于與多種新技術的融合，如5G、智能識別的應用等。

在功能方面，P2P網絡視頻監(jiān)控普遍支持視頻監(jiān)控、視頻直播、云存儲、音/視頻通話等服務能力。

● 視頻監(jiān)控：支持攝像機、貓眼等智能終端接入，此外，有的平臺還支持模組接入、嵌入式軟件開發(fā)工具包（software development kit，SDK）接入，不同接入方式的設備也可以實現互聯互通等。

● 視頻直播：支持全球廣域網（world wideweb，Web）、第5代HTML（HTML5，H5）直播，可提供RTMP/HLS標準流地址，提供高清、標清、流暢等多種碼率視頻流，支持快速對接實現直播功能，支持云臺機的遠程超控、實時更新視頻、直播時長控制等。

● 云存儲：支持監(jiān)控攝像機將視頻直接上傳云存儲，支持云端錄像下載和在線播放。

● 音/視頻通話：有的平臺還支持一對一、多對多的語音或視頻通話，覆蓋監(jiān)控攝像機、兒童手表、安全帽、電視大屏等設備進行遠程互動等。

某P2P監(jiān)控系統(tǒng)工作流程如圖1所示，展示了某P2P網絡視頻監(jiān)控系統(tǒng)模塊組成和P2P建立連接工作流程，主要包括前端IP攝像機、客戶端和中心服務平臺。其中，中心服務平臺通常由中心信令服務器、私網穿越服務器以及云存儲服務器組成，各部分均接入IP承載網實現通信。

圖1 某P2P監(jiān)控系統(tǒng)工作流程

中心服務平臺負責用戶和設備的接入管理，提供視頻訪問和控制服務以及錄像處理服務等。其中，中心信令服務器功能模塊作為管理中心提供客戶/用戶管理、前端/平臺設備管理、數據庫存儲業(yè)務參數配置數據以及作為門戶提供內容發(fā)布等功能；云存儲服務器作為存儲中心存儲用戶錄像視頻或抓拍圖片；私網穿越服務器為用戶訪問通過網關接入互聯網的IP攝像機提供私網穿越解決方案。

前端IP攝像機是系統(tǒng)的信息采集端，可實現視頻信息、音頻信息、數據信息及告警信息的采集功能，可具有語音信息和數據信息的雙向傳送功能，也可實現音/視頻錄像的存儲功能。

客戶端是系統(tǒng)的客戶應用端，可完成業(yè)務請求/認證等發(fā)起、監(jiān)控列表頁面等解析、視頻流的解碼和播放、發(fā)送云鏡控制消息等功能。類型可包括PC客戶端、手機客戶端、Web客戶端等。

P2P網絡視頻監(jiān)控技術的主要工作原理是：用戶通過電腦終端上的客戶端或者手機客戶端登錄視頻監(jiān)控中心服務平臺訪問攝像機，初始化信息包含描述會話發(fā)起客戶端媒體流的配置與特征，信息發(fā)送至視頻監(jiān)控中心服務平臺信令服務器，信令服務器接收客戶端請求后查詢信息并通知雙方IP地址和端口號，假設攝像機同意通信，即接收信息并反饋至客戶端，從而在客戶端和攝像機之間點到點建立連接傳輸音/視頻。此外，信令服務器還可以為媒體流參數修改以及會話終止消息等提供支持。

2 P2P網絡視頻監(jiān)控主流技術概況

2.1 流媒體傳輸控制技術

流媒體控制協(xié)議是視頻監(jiān)控系統(tǒng)（監(jiān)控平臺、視頻服務器、攝像機等設備）間的控制指令集，是建立視頻監(jiān)控圖像連接的基本指令集；P2P視頻監(jiān)控系統(tǒng)使用流媒體傳輸協(xié)議時需要自行定義信令協(xié)議，以通知攝像機主動向客戶端推送音/視頻流。

流媒體控制協(xié)議包括以下主流協(xié)議。

（1）WebRTC

網頁即時通信（Web real-time communication，WebRTC）是一個支持網頁瀏覽器進行實時語音對話或視頻對話的應用程序接口（application programming interface，API），它提供了視頻的核心技術，包括音/視頻的采集、編/解碼、網絡傳輸、顯示等功能，并且還支持跨平臺。WebRTC協(xié)議棧如圖2所示，WebRTC使用會話起始協(xié)議（session initiation protocol，SIP）進行視頻的呼叫及會話管理機制，使用數據報傳輸層安全與安全實時傳輸協(xié)議相結合的DTLS-SRTP（datagram transport layer security-secure real-time transport protocol）在點對點連接中實現了流媒體數據端到端的加密，使用STUN-TURN-ICE（session traversal utilities for NAT-traversal using relays around NAT-interactive connectivity establishment）實現私網穿越。

圖2 WebRTC協(xié)議棧

此外，一般P2P方案中，各瀏覽器廠商不支持插件，導致P2P不能實現網頁播放，并且一般的P2P方案不支持雙向語音，針對門鈴場景存在短板，所以采用WebRTC可以支持雙向語音、支持瀏覽器且免費，非常適合IP攝像機（IP camera，IPC）直播場景，構建支持超低時延直播流式傳輸和雙向實時通信的應用程序。

● 優(yōu)點：WebRTC客戶端開發(fā)簡單，可借用成熟WebRTC庫；使用用戶數據報協(xié)議（user datagram protocol，UDP）作為流媒體傳輸層協(xié)議，實時通信時延低，一般時延為200 ms～1 s；該技術不使用第三方插件或軟件，可以在不損失質量和不增加時延的情況下通過防火墻。

● 缺點：在非Web/Android平臺上開發(fā)難度較大，需要自行從WebRTC開源框架中剝離自己需要的代碼；默認不支持H.265編碼。

（2）RTSP

實時流協(xié)議（real-time streaming protocol，RTSP）是一種傳統(tǒng)的流媒體控制協(xié)議，屬于應用層協(xié)議，RTSP傳輸一般需要2～3個通道，其中命令和數據通道分離。RTSP在服務端和客戶端之間建立連接之后，服務器開始持續(xù)不斷地發(fā)送媒體數據包，媒體數據包采用RTP進行封裝，客戶端通過RTSP向服務器傳達控制命令，如播放、暫?；蛑袛嗟瓤蛻舳丝刂菩畔⑼ㄟ^RTSP信息包以UDP或傳輸控制協(xié)議（transmission control protocol，TCP）的方式傳送。

RTSP協(xié)議棧如圖3所示，RTSP位于TCP之上，RTSP負責建立和控制會話，使用TCP完成數據傳輸；RTP數據協(xié)議負責對流媒體數據進行封包并實現媒體流的實時傳輸，RTCP配合RTP做控制和流量統(tǒng)計，RTP/RTCP使用TCP或UDP完成數據傳輸。

圖3 RTSP協(xié)議棧

● 優(yōu)點：傳輸媒體數據可以使用UDP，在網絡環(huán)境比較穩(wěn)定的情況下，傳輸效率比較高；RTSP協(xié)議族可以控制到視頻幀，因此可以承載實時性很高的應用，一般時延為500 ms～1 s；倍速播放功能是RTSP獨有的，其他視頻協(xié)議都無法支持。

● 缺點：服務器端的復雜度比較高，實現起來也比較復雜；RTSP沒有自適應視頻播放的技術。

（3）SRT

安全可靠傳輸（secure reliable transport，SRT）協(xié)議是新一代低時延視頻傳輸協(xié)議，是能夠在復雜網絡環(huán)境下實時、準確地傳輸數據流的開源網絡傳輸技術，它在傳輸層使用UDP，實現了安全、穩(wěn)定、快速的傳輸效果。

SRT協(xié)議發(fā)送支持多個并發(fā)流、多個不同的媒體流（如多個攝像機角度或可選音頻軌道），可以通過在一個點對點鏈接上共享相同UDP端口和地址并行SRT流發(fā)送。安全方面，SRT支持高級加密標準（advanced encryption standard，AES）加密，保障端到端的視頻傳輸安全。可靠性方面，SRT通過前向糾正技術保證傳輸的穩(wěn)定性。

● 優(yōu)點：SRT相關開源庫比較成熟，VLC/OBS/FFmpeg客戶端均已支持；實時通信時延低，使用可靠的UDP作為傳輸層協(xié)議，一般時延為500 ms～1 s。

● 缺點：在瀏覽器上不支持直接播放使用，需要開發(fā)專業(yè)的C/S客戶端。

（4）RTMP

實時消息傳輸協(xié)議（real time messaging protocol，RTMP）是基于TCP的應用層協(xié)議，RTMP主要用來在Flash/AIR平臺和支持RTMP的流媒體/交互服務器之間進行音/視頻和數據通信，一般在一個TCP通道上傳輸命令和數據。RTMP是一個協(xié)議族，包括RTMP基本協(xié)議及RTMPT/RTMPS/RTMPE等多種變種。協(xié)議中的基本數據單元成為消息，傳輸的過程中消息會被拆分為更小的消息塊單元。最后將分割后的消息塊通過TCP傳輸，接收端再反解接收的消息塊并將其恢復成流媒體數據。RTMP一般時延為1～3 s。

● 優(yōu)點：RTMP是專為流媒體開發(fā)的協(xié)議，對底層的優(yōu)化比其他協(xié)議更加優(yōu)秀，基本上所有的編碼器（攝像機之類）都支持RTMP輸出；穩(wěn)定性好，因為使用的是TCP傳輸，在互聯網環(huán)境相對較差的情況下，采用RTMP保證了視頻的傳輸質量，適合長時間播放。

● 缺點：RTMP不使用標準的HTTP接口傳輸數據，所以在一些特殊的網絡環(huán)境下可能被防火墻屏蔽；RTMP是一種有狀態(tài)協(xié)議，需要為每一個播放視頻流的客戶端維護狀態(tài)，很難對視頻服務器進行平滑擴展。

（5）HLS

HLS（HTTP live streaming）是Apple公司開放的基于HTTP的流媒體網絡傳輸協(xié)議，它的工作原理是把整個流分成一個個小的基于HTTP的文件下載，每次只下載一些。HLS可以在任何瀏覽器或移動應用程序上直播和點播從設備提取的視頻，還可持久地存儲視頻流并對其進行加密和編制索引。

● 優(yōu)點：HLS可以穿過任何允許HTTP數據通過的防火墻或者代理服務器；HLS基于無狀態(tài)協(xié)議（HTTP），客戶端只是按照順序使用下載存儲在服務器的普通TS文件，做負載均衡如同普通的HTTP文件服務器的負載均衡一樣簡單。HLS協(xié)議本身實現了碼率自適應，不同帶寬的設備可以自動切換到最適合自己碼率的視頻播放。

● 缺點：采用HLS協(xié)議直播的視頻時延無法降低到10 s以下，所以對直播時延比較敏感的服務不太適用。

（6）DASH

基于HTTP的動態(tài)自適應多媒體流（dynamic adaptive streaming over HTTP，DASH）是國際標準組動態(tài)圖像專家組（Moving Picture Experts Group，MPEG）2014年推出的技術標準，是基于HTTP的動態(tài)自適應的比特率流技術，使用的傳輸協(xié)議是TCP。DASH和HLS技術類似，都是把視頻分割成一小段一小段后，通過HTTP進行傳輸，客戶端得到之后進行播放；不同的是MPEG-DASH支持MPEG-2 TS、MP4等多種格式，可以將視頻按照多種編碼切割，下載下來的媒體格式既可以是TS文件也可以是MP4文件，所以當客戶端加載視頻時，按照當前的網速和支持的編碼加載相應的視頻片段進行播放。

● 優(yōu)點：媒體服務器攝取單個視頻源，并將其轉碼為十幾種不同的格式，可以在各種設備和連接速度上實現無緩沖播放，解決多制式傳輸方案并存格局下的存儲與服務能力浪費、運營成本與復雜度高、系統(tǒng)間互操作弱等問題。

● 缺點：iOS或Apple TV不支持；在傳遞速度方面滯后，時延為6～30 s，只有通過分塊傳輸編碼進行調整或傳遞時，才有可能降低時延。

2.2 安全傳輸技術

為保證P2P視頻監(jiān)控通信中指令集不包含網絡攻擊指令、其他非法字符集嵌入或機密數據向外泄露，系統(tǒng)應具備視頻協(xié)議安全控制功能，對所有視頻監(jiān)控交互指令進行嚴格安全保護，阻斷非法數據傳輸和網絡攻擊的入侵。

（1）SSL/TLS

安全套接層（secure socketslayer，SSL）和傳輸層安全（transport layer security，TLS）簡單理解就是同一件東西的兩個演進階段，同樣都是在應用層和傳輸層之間加入的安全層，最早的時候這個安全層叫做SSL，由Netscape公司推出，后來被IETF組織標準化并稱為TLS。

SSL/TLS體系結構中包含兩個協(xié)議子層，即記錄協(xié)議層和握手協(xié)議層。記錄協(xié)議建立在可靠的傳輸（如TCP）之上，為高層協(xié)議提供數據封裝、壓縮、加密等基本功能；握手協(xié)議建立在記錄協(xié)議之上，用于在實際的數據傳輸開始之前，通信雙方進行身份認證、協(xié)商加密算法、交換加密密鑰等。

● 優(yōu)點：SSL/TLS實施起來比較簡單，對現有網絡系統(tǒng)的修改不大，并且它具有速度快、成本低等優(yōu)點，目前已得到廣泛的應用；運用密鑰技術保證了數據的完整性和機密性。

● 缺點：SSL/TLS要求對每個數據進行加密和解密操作，因而在帶來高性能的同時，也要求系統(tǒng)高資源開銷；SSL/TLS協(xié)議不能保證信息的不可抵賴性。

（2）DTLS

由于SSL/TLS不能用來保證UDP上傳輸的數據的安全，因此數據包傳輸層安全性（datagram transport layer security，DTLS）協(xié)議在現存的TLS協(xié)議架構上提出擴展使之支持UDP，成為TLS的一個支持數據包傳輸的版本。SSL/TLS基于TCP，因此不需要擔心重放、亂序、丟包的問題，可靠傳輸由TCP做保證；而DTLS基于UDP，UDP是一種盡力而為的協(xié)議，因此DTLS需要自己處理重放、亂序、丟包的問題。

● 優(yōu)點：DTLS可以保證UDP上傳輸的數據的安全。

● 缺點：DTLS是基于UDP的，不可避免地會出現丟包需要重傳的情況，如果處理不當，會導致通信雙方無法建立會話，通話失敗。

（3）HTTPS

安全套接層超文本傳輸協(xié)議（Hyper Text Transfer Protocol over Secure Socket Layer，HTTPS）在HTTP的基礎上通過傳輸加密和身份認證保證了傳輸過程的安全性，HTTPS主要由兩部分組成：HTTP + SSL/TLS，也就是在HTTP上又加了一層處理加密信息的模塊。服務端和客戶端的信息傳輸都會通過TLS進行加密。

● 優(yōu)點：HTTPS可以提供更加優(yōu)質、保密的信息，保證了用戶數據的安全性，此外也在一定程度上保護了服務端，使用惡意攻擊和偽裝數據的成本大大提高。

● 缺點：HTTPS加重了服務端的負擔，與HTTP相比，其需要更多的資源支撐，同時也降低了用戶的訪問速度。

2.3 P2P監(jiān)控中私網穿越技術

在現實Internet環(huán)境中，大多數計算機主機位于防火墻或NAT之后，只有少部分主機能夠直接接入Internet。很多時候，希望網絡中的兩臺主機能夠直接進行通信（即所謂的P2P通信），而不需要其他公共服務器的中轉。由于主機可能位于防火墻或NAT之后，在進行P2P通信之前，需要進行檢測以確認它們之間能否進行P2P通信以及如何通信，這種技術通常被稱為NAT穿透（NAT traversal）。目前采用的私網穿越技術主要有通用即插即用（universal plug and play，UPNP）、NAT的UDP簡單穿越（simple traversal of UDP through NATs，STUN）、使用中繼穿透NAT（traversal using relays around NAT，TURN）和交互式連通建立方式（interactive connectivity establishment，ICE）。

（1）UPNP

UPNP網關自動配置端口映射，將來自NAT外部端口的數據包轉發(fā)到網絡攝像機使用的內部端口上，用戶無須手動映射端口或者進行其他工作。UPNP私網穿越的前提是要求所有網關必須要開啟UPNP服務。

（2）STUN

STUN是一種處理NAT傳輸的協(xié)議，它允許位于NAT（或多重NAT）后的客戶端找出自己綁定的公網地址以及端口，即私網中的終端通過某種機制預先得到公網上的服務地址，然后在報文凈載中所要求的地址信息就直接填寫該公網地址。STUN的缺點是不適用于雙方都位于同一個NAT之后的場景，不適合支持TCP連接的穿越，需要終端支持STUN CLIENT的功能以及不支持對防火墻的穿越等。

（3）TURN

TURN是STUN的一個拓展，主要添加了Relay功能，即在該模式中私網終端發(fā)出的報文都要經過TURN Server進行Relay轉發(fā)。TURN Server控制分配地址和端口，能分配RTP/RTCP地址對（RTCP端口號為RTP端口號加1）作為私網終端用戶的接收地址，避免了STUN方式中出口NAT對RTP/RTCP地址端口號的任意分配，使得客戶端無法收到對端發(fā)來的RTCP報文（對端發(fā)RTCP報文時，目的端口號缺省按RTP端口號加1發(fā)送）。TURN與STUN的共同點都是通過修改應用層中的私網地址達到NAT穿透的效果。與STUN的不同點包括：STUN得到的地址為出口NAT上的外部地址；TURN得到的地址為TURN Server上的公網地址，且支持基于TCP的應用等。TURN的主要缺點是需要終端支持TURN CLIENT的功能、所有報文都必須經過TURN Server轉發(fā)，增大了包的時延和丟包的可能性等。

（4）ICE

ICE并非一種新的協(xié)議，它綜合運用STUN、TURN或RSIP（realm specific IP），使之在最適合的情況下工作，以彌補單獨使用其中任何一種所帶來的固有缺陷，它不需要對STUN、TURN或RSIP進行擴展就可適用于各種NAT。ICE原理是通過通信雙方互相發(fā)探測包，首先探測內網地址，再探測STUN提供的反射地址，最后探測TURN協(xié)議的中繼地址，從而找出一種可行路徑。ICE私網穿越技術使用前提是需要每一個客戶端和攝像機支持traversal方。

3 大規(guī)模部署的P2P視頻監(jiān)控技術分析

3.1 大規(guī)模部署P2P監(jiān)控架構

大規(guī)模部署P2P監(jiān)控架構可采用“中心+區(qū)域/邊緣節(jié)點”二級部署方案架構，如圖4所示，管理節(jié)點部署中心信令服務器（包括設備管理、數據庫服務、接口服務、調度服務及節(jié)點管理等），區(qū)域/邊緣節(jié)點部署區(qū)域信令服務器（包括設備接入服務、級聯服務等）和區(qū)域私網穿越服務器（TURN和STUN），攝像機視頻存儲一般直接上聯分布式云存儲系統(tǒng)或第三方云存儲系統(tǒng)。

針對二級架構，攝像機設備注冊時涉及中心平臺和區(qū)域/邊緣節(jié)點，需要處理好設備注冊和管理信息，流程如下。

步驟1 設備向中心平臺發(fā)起請求，主要上報設備編號以及設備驗證碼。

步驟2 中心平臺檢查其數據庫是否已經保存該設備，如果沒有則進行保存入庫；如果已經入庫，則檢查該設備是否已經被某區(qū)域平臺確認使用。

步驟3 如果設備確認沒有被區(qū)域平臺使用，則返回給設備錯誤，后續(xù)設備繼續(xù)向中心平臺發(fā)送重定向請求，直到返回200OK。

步驟4 用戶使用客戶端添加設備，向區(qū)域平臺發(fā)起注冊請求。

步驟5 區(qū)域平臺首先在其自身數據庫進行檢查，如果已被綁定則提示錯誤，如果未被綁定則進行合法性驗證并綁定。

步驟6 如果區(qū)域平臺數據庫沒有該設備記錄，則區(qū)域平臺向中心平臺進行查詢請求，如果查詢到該編號的設備已經向中心平臺申請重定向，則區(qū)域平臺在其數據庫添加該設備記錄，并允許用戶保存。

步驟7 中心平臺在接收到區(qū)域平臺的查詢請求后，首先確認該設備在數據庫內，并且未被其他區(qū)域平臺使用，則設備劃歸該區(qū)域平臺；否則返回錯誤。

步驟8 當中心平臺已將設備劃歸某區(qū)域平臺，則設備注冊請求返回200OK，并攜帶劃歸區(qū)域平臺的接入地址。

步驟9 設備向區(qū)域平臺注冊。

圖4 “中心+區(qū)域/邊緣節(jié)點”二級部署方案架構

步驟10區(qū)域平臺檢查該設備是否已經入庫，如果是從中心平臺驗證則已經入庫并綁定給用戶；否則如果沒有入庫則進行入庫，返回平臺終端接入服務器地址（支持設備直接配置接入區(qū)域平臺，無須首先接入中心平臺）。

3.2 大規(guī)模部署P2P監(jiān)控協(xié)議分析

視頻監(jiān)控系統(tǒng)業(yè)務數據和媒體數據通常采用分離的通道進行操作，其傳輸通道類型可分為信令流和媒體流。由于攝像機是被動接受視頻呼叫請求，故攝像機需要與服務器之間設計一套信令通信協(xié)議，用于進行視頻的呼叫及會話管理機制；而媒體流是指傳輸的視頻、音頻和數據流。

P2P網絡視頻監(jiān)控主流協(xié)議見表1，涉及多種控制、傳輸、視頻編碼、私網穿越等協(xié)議。

表1 P2P網絡視頻監(jiān)控主流協(xié)議

以亞馬遜為例，其視頻監(jiān)控系統(tǒng)支持的多媒體協(xié)議包括HLS、WebRtc、RTSP、DASH，其中采用WebRtc協(xié)議對接攝像機、Web端和移動端，終端和用戶可以利用WebRTC功能進行雙向實時媒體流式傳輸與交互；采用HLS對接Web端和移動端，DASH是動態(tài)適應網絡的媒體協(xié)議，用戶采用基于HLS/DASH主流的協(xié)議播放觀看；采用RTSP支持多種媒體播放器；在私網穿越方面，包含用于TURN的托管終端節(jié)點，以便在應用程序無法流式傳輸對等媒體時通過云啟用媒體中繼；還包含用于STUN的托管終端節(jié)點，以便應用程序在位于NAT或防火墻之后時能夠發(fā)現其公有IP地址。

3.3 基于多技術集成的私網穿透方案分析

在P2P點到點視頻監(jiān)控應用中，IP攝像機連接到網關后使用的是私網地址，NAT會將客戶機私網地址和端口{X:y}轉換成公網地址和端口{A:b}并綁定，當處于公網的用戶訪問位于私網的攝像機時會出現私網穿越的問題。

針對采用SIP/RTSP信令協(xié)議的P2P點到點視頻監(jiān)控，SIP/RTSP協(xié)議無法穿過NAT回送信令，因為SIP/RTSP信令中的From和Contact頭域記錄的是私網地址和端口{X:y}，NAT無法識別和轉換，所以針對UPNP私網穿越技術，平臺側信令服務器通過與攝像機的Socket連接獲取其公網接入地址，從協(xié)議中獲取其網關映射端口和終端本地網絡端口并保存。但如果僅采用UPNP或者DDNS技術，至多可解決20%左右的視頻P2P傳輸（而且上門安裝配置復雜，無法實現即插即用）。此外，中小企業(yè)的適用場景比家庭復雜，如會涉及網絡設備的級聯，且其網關設備往往不是定制的，因此要網關都配置支持UPNP也不現實，而如果采用STUN技術又不適用于對稱型NAT，采用TURN又增大了包的時延和丟包的可能性，因此，適用于各種類型的NAT的集成多種私網穿越技術的方案是較好的技術選擇。

圖5 私網穿越方案流程

由于媒體流穿透NAT的過程是獨立于具體的信令協(xié)議的，所以平臺側需要部署STUN和TURN服務器提供媒體流轉發(fā)服務。

私網穿越方案流程如圖5所示，集成了多種私網穿越技術。

步驟1 網絡攝像機與客戶端在同一局域網內，客戶端直接訪問網絡攝像機本地地址，該種情況不需用采用私網穿越技術。該情況在現實應用中僅占1%的情況。

步驟2 當網絡攝像機在一層路由器下，并且UPNP自動端口映射成功，則客戶端在非局域網情況下優(yōu)先使用該協(xié)議進行P2P視頻流請求。該情況在實際使用時，可覆蓋20%左右的用戶。

步驟3 當網絡攝像機處于多層路由器之后或者UPNP不通的情況下，客戶端與網絡攝像機分別使用STUN協(xié)議到平臺進行NAT端口映射，然后分別向對方映射端口發(fā)送UDP穿網包進行P2P打洞。在該情況下，可解決現實情況中90%以上用戶進行P2P視頻傳輸。

步驟4 以上3種情況結合使用，可對現實環(huán)境的98%以上用戶進行P2P視頻傳輸。其余2%無法進行P2P傳輸視頻的情況，采用TURN國際標準協(xié)議進行視頻轉發(fā)。

4 結束語

本文綜合闡述了P2P網絡視頻監(jiān)控技術原理，分析了主流的P2P網絡視頻監(jiān)控所采用的流媒體控制技術、傳輸技術以及私網穿越技術。此外，隨著P2P視頻監(jiān)控涵蓋越來越多的業(yè)務場景，相應的技術也在向標準化、智能化、開放化和規(guī)模化等方向發(fā)展。例如，在實際應用中平臺側往往支持多種標準協(xié)議，以支持多種終端廠商產品的統(tǒng)一接入和全協(xié)議播放能力。平臺既能針對標準化的應用場景提供即插即用的標準化產品，也可通過能力開放支持定制化場景需求。在規(guī)?；矫?，通常采用云存儲技術保障大規(guī)模視頻存儲的需求。智能算法部署在云AI算力服務上，可與云存儲節(jié)點、區(qū)域節(jié)點同址部署，以減少AI能力獲取視頻/圖片時的機房公網/專線帶寬資源等，多種技術的發(fā)展和融合應用保障了P2P視頻監(jiān)控支持上千萬個視頻監(jiān)控終端，支撐跨用戶群融合場景和應用。

[1] 梁篤國, 張艷霞, 曹寧, 等. 網絡視頻監(jiān)控技術與智能應用[M].北京: 人民郵電出版社, 2013.

LIANG D G, ZHANG Y X, CAO N, et al. Network video surveillance technology and intelligent application[M]. Beijing: Posts and Telecommunications Press, 2013.

[2] 楊磊, 張艷霞, 梁篤國, 等. 網絡視頻監(jiān)控技術[M]. 北京:中國傳媒大學出版社, 2017.

YANG L, ZHANG Y X, LIANG D G, et al. Network video surveillance technology[M]. Beijing: Communication University of China Press, 2017.

[3] 蔡彥. 基于P2P架構下的移動“全球眼”系統(tǒng)實現及性能分析[D]. 上海: 上海交通大學, 2011.

CAI Y. Video surveillance system called mobiling “global eyes” over P2P[D]. Shanghai: Shanghai Jiao Tong University, 2011.

[4] 李永明. 利用UDP穿越P2P網絡中NAT的技術研究[J]. 軟件導刊, 2012, 11(9): 126-128.

LI Y M. Research on traversing NAT in P2P network using UDP[J]. Software Guide, 2012, 11(9): 126-128.

[5] 黃輝, 張濤, 孫菲. “全球眼”系統(tǒng)云化演進思路分析[J]. 電信技術, 2012(3): 9-11.

HUANG H, ZHANG T, SUN F. Analysis on cloud evolution of “global eye” system[J]. Telecommunications Technology, 2012(3): 9-11.

[6] 季一木, 袁永閣, 張?zhí)K銳. 一種新型P2P流媒體協(xié)議及其流量模型研究[J]. 計算機工程與科學, 2014, 36(11): 2100-2105.

JI Y M, YUAN Y G, ZHANG S R. A noval P2P streaming protocol and its traffic model[J]. Computer Engineering & Science, 2014, 36(11): 2100-2105.

[7] 劉沛釗. P2P流媒體關鍵技術的研究進展[J]. 電子技術與軟件工程, 2014(3): 21.

LIU P Z. Research progress on key technologies of P2P streaming media[J]. Electronic Technology & Software Engineering, 2014(3): 21.

[8] 霍龍社, 甘震. 移動流媒體協(xié)議綜述[J]. 信息通信技術, 2010, 4(4):6-13.

HUO L S, GAN Z. Review on streaming media protocols over the mobile Internet[J]. Information and Communications Technologies, 2010, 4(4): 6-13.

[9] 趙宇. WebRTC技術在語音平臺中的應用研究[J]. 通信技術, 2018, 51(2): 506-510.

ZHAO Y. Exploration on IVR solutions of WebRTC technology[J]. Communications Technology, 2018, 51(2): 506-510.

[10] 李波, 李雪夢, 王彥本. 基于RTP的WebRTC音視頻傳輸優(yōu)化方法[J]. 西安郵電大學學報, 2019, 24(1): 26-30.

LI B, LI X M, WANG Y B. WebRTC audio and video transmission optimization method based on RTP[J]. Journal of Xi’an University of Posts and Telecommunications, 2019, 24(1): 26-30.

[11] 孫建偉, 陳立, 王衛(wèi). 基于SIP協(xié)議的WebRTC信令研究與應用[J]. 計算機系統(tǒng)應用, 2018, 27(9): 273-277.

SUN J W, CHEN L, WANG W. Research and application of WebRTC signaling based on SIP protocol[J]. Computer Systems & Applications, 2018, 27(9): 273-277.

[12] LO W T, CHANGY S, SHEU R K, et al. Implementation and evaluation of large-scale video surveillance system based on P2P architecture and cloud computing[J]. International Journal of Distributed Sensor Networks, 2014, 10(4): 375871.

[13] KIM S, JEONG J. Design and performance analysis of a novel P2P-SIP architecture for network-based mobility support in intelligent home networks[C]//Proceedings of 2013 IEEE 9th International Conference on Mobile Ad-hoc and Sensor Networks. Piscataway: IEEE Press, 2013: 310-317.

[14] HOUNGUE P, DAMIANI E, GLITHO R. Overcoming NAT traversal issue for SIP-based communication in P2P networks[C]//Proceedings of 2011 4th Joint IFIP Wireless and Mobile Networking Conference (WMNC 2011). Piscataway: IEEE Press, 2011: 1-8.

Research on technology mechanism used in P2P network video surveillance system

FANG Xinyan, ZHANG Yanxia, CUI Ruilin, LUO Siwei

E-Surfing Internet of Things Technology Co., Ltd., Shanghai 200122, China

At present, the scale of video monitoring of small and medium-sized enterprises and families in the civil market is growing explosively. In view of the monitoring demand of tens of millions of cameras, peer to peer (P2P) network video monitoring technology was widely used in the industry. The principle of P2P network video monitoring technology was expounded comprehensively, and the streaming media control technology, transmission technology and private network crossing technology adopted by the mainstream P2P network video monitoring were analyzed. Finally, a large-scale deployment of P2P video surveillance solution was proposed.

network video surveillance, P2P, signaling

TP393

A

10.11959/j.issn.1000–0801.2022295

2022-07-28；

2022-12-07

房新彥（1982-），男，天翼物聯科技有限公司工程師，主要從事視頻監(jiān)控系統(tǒng)產品開發(fā)、技術標準制定等工作。

張艷霞（1974-），女，天翼物聯科技有限公司正高級工程師，主要從事視頻監(jiān)控系統(tǒng)產品開發(fā)、技術標準制定等工作。

崔瑞琳（1973-），女，天翼物聯科技有限公司工程師，主要從事視頻監(jiān)控系統(tǒng)產品開發(fā)、技術標準制定等工作。

羅思維（1990-），男，天翼物聯科技有限公司工程師，主要從事視頻監(jiān)控系統(tǒng)產品開發(fā)、技術標準制定等工作。