999精品在线视频,手机成人午夜在线视频,久久不卡国产精品无码,中日无码在线观看,成人av手机在线观看,日韩精品亚洲一区中文字幕,亚洲av无码人妻,四虎国产在线观看 ?

P2P網(wǎng)絡(luò)視頻監(jiān)控技術(shù)機制解析

2023-01-09 03:57:50房新彥張艷霞崔瑞琳羅思維
電信科學(xué) 2022年12期
關(guān)鍵詞:設(shè)備

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

P2P網(wǎng)絡(luò)視頻監(jiān)控技術(shù)機制解析

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

(天翼物聯(lián)科技有限公司,上海 200122)

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

網(wǎng)絡(luò)視頻監(jiān)控;P2P;信令

0 引言

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

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

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

1 P2P網(wǎng)絡(luò)視頻監(jiān)控技術(shù)原理

目前,P2P網(wǎng)絡(luò)視頻監(jiān)控比較有代表性的產(chǎn)品有海康螢石、大華樂橙、中國電信天翼看家和中國移動千里眼等。其中,安防企業(yè)的P2P網(wǎng)絡(luò)監(jiān)控系統(tǒng)一般采用同類設(shè)備或同品牌設(shè)備,而中國電信等運營商的P2P網(wǎng)絡(luò)監(jiān)控系統(tǒng)可支持多家廠商設(shè)備。

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

● 標(biāo)準(zhǔn)化:在標(biāo)準(zhǔn)化方面,將多家產(chǎn)品集成在一個系統(tǒng)里面,對標(biāo)準(zhǔn)化和互通性提出的要求非常高,平臺提供標(biāo)準(zhǔn)協(xié)議接口、標(biāo)準(zhǔn)網(wǎng)元結(jié)構(gòu),架構(gòu)上支持多域互聯(lián)。

● 大容量平臺:支持大容量的前端設(shè)備接入、流媒體私網(wǎng)穿越轉(zhuǎn)發(fā)、客戶接入等。

● 大容量存儲:支持大容量錄像存儲任務(wù),且容量具有高擴展性,滿足長時間大容量視頻圖像存儲的需求。

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

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

● 視頻監(jiān)控:支持?jǐn)z像機、貓眼等智能終端接入,此外,有的平臺還支持模組接入、嵌入式軟件開發(fā)工具包(software development kit,SDK)接入,不同接入方式的設(shè)備也可以實現(xiàn)互聯(lián)互通等。

● 視頻直播:支持全球廣域網(wǎng)(world wideweb,Web)、第5代HTML(HTML5,H5)直播,可提供RTMP/HLS標(biāo)準(zhǔn)流地址,提供高清、標(biāo)清、流暢等多種碼率視頻流,支持快速對接實現(xiàn)直播功能,支持云臺機的遠程超控、實時更新視頻、直播時長控制等。

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

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

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

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

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

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

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

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

2 P2P網(wǎng)絡(luò)視頻監(jiān)控主流技術(shù)概況

2.1 流媒體傳輸控制技術(shù)

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

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

(1)WebRTC

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

圖2 WebRTC協(xié)議棧

此外,一般P2P方案中,各瀏覽器廠商不支持插件,導(dǎo)致P2P不能實現(xiàn)網(wǎng)頁播放,并且一般的P2P方案不支持雙向語音,針對門鈴場景存在短板,所以采用WebRTC可以支持雙向語音、支持瀏覽器且免費,非常適合IP攝像機(IP camera,IPC)直播場景,構(gòu)建支持超低時延直播流式傳輸和雙向?qū)崟r通信的應(yīng)用程序。

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

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

(2)RTSP

實時流協(xié)議(real-time streaming protocol,RTSP)是一種傳統(tǒng)的流媒體控制協(xié)議,屬于應(yīng)用層協(xié)議,RTSP傳輸一般需要2~3個通道,其中命令和數(shù)據(jù)通道分離。RTSP在服務(wù)端和客戶端之間建立連接之后,服務(wù)器開始持續(xù)不斷地發(fā)送媒體數(shù)據(jù)包,媒體數(shù)據(jù)包采用RTP進行封裝,客戶端通過RTSP向服務(wù)器傳達控制命令,如播放、暫停或中斷等客戶端控制信息通過RTSP信息包以UDP或傳輸控制協(xié)議(transmission control protocol,TCP)的方式傳送。

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

圖3 RTSP協(xié)議棧

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

● 缺點:服務(wù)器端的復(fù)雜度比較高,實現(xiàn)起來也比較復(fù)雜;RTSP沒有自適應(yīng)視頻播放的技術(shù)。

(3)SRT

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

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

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

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

(4)RTMP

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

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

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

(5)HLS

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

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

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

(6)DASH

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

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

● 缺點:iOS或Apple TV不支持;在傳遞速度方面滯后,時延為6~30 s,只有通過分塊傳輸編碼進行調(diào)整或傳遞時,才有可能降低時延。

2.2 安全傳輸技術(shù)

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

(1)SSL/TLS

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

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

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

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

(2)DTLS

由于SSL/TLS不能用來保證UDP上傳輸?shù)臄?shù)據(jù)的安全,因此數(shù)據(jù)包傳輸層安全性(datagram transport layer security,DTLS)協(xié)議在現(xiàn)存的TLS協(xié)議架構(gòu)上提出擴展使之支持UDP,成為TLS的一個支持?jǐn)?shù)據(jù)包傳輸?shù)陌姹尽SL/TLS基于TCP,因此不需要擔(dān)心重放、亂序、丟包的問題,可靠傳輸由TCP做保證;而DTLS基于UDP,UDP是一種盡力而為的協(xié)議,因此DTLS需要自己處理重放、亂序、丟包的問題。

● 優(yōu)點:DTLS可以保證UDP上傳輸?shù)臄?shù)據(jù)的安全。

● 缺點:DTLS是基于UDP的,不可避免地會出現(xiàn)丟包需要重傳的情況,如果處理不當(dāng),會導(dǎo)致通信雙方無法建立會話,通話失敗。

(3)HTTPS

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

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

● 缺點:HTTPS加重了服務(wù)端的負擔(dān),與HTTP相比,其需要更多的資源支撐,同時也降低了用戶的訪問速度。

2.3 P2P監(jiān)控中私網(wǎng)穿越技術(shù)

在現(xiàn)實Internet環(huán)境中,大多數(shù)計算機主機位于防火墻或NAT之后,只有少部分主機能夠直接接入Internet。很多時候,希望網(wǎng)絡(luò)中的兩臺主機能夠直接進行通信(即所謂的P2P通信),而不需要其他公共服務(wù)器的中轉(zhuǎn)。由于主機可能位于防火墻或NAT之后,在進行P2P通信之前,需要進行檢測以確認它們之間能否進行P2P通信以及如何通信,這種技術(shù)通常被稱為NAT穿透(NAT traversal)。目前采用的私網(wǎng)穿越技術(shù)主要有通用即插即用(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網(wǎng)關(guān)自動配置端口映射,將來自NAT外部端口的數(shù)據(jù)包轉(zhuǎn)發(fā)到網(wǎng)絡(luò)攝像機使用的內(nèi)部端口上,用戶無須手動映射端口或者進行其他工作。UPNP私網(wǎng)穿越的前提是要求所有網(wǎng)關(guān)必須要開啟UPNP服務(wù)。

(2)STUN

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

(3)TURN

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

(4)ICE

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

步驟10區(qū)域平臺檢查該設(shè)備是否已經(jīng)入庫,如果是從中心平臺驗證則已經(jīng)入庫并綁定給用戶;否則如果沒有入庫則進行入庫,返回平臺終端接入服務(wù)器地址(支持設(shè)備直接配置接入?yún)^(qū)域平臺,無須首先接入中心平臺)。

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

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

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

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

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

3.3 基于多技術(shù)集成的私網(wǎng)穿透方案分析

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

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

圖5 私網(wǎng)穿越方案流程

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

私網(wǎng)穿越方案流程如圖5所示,集成了多種私網(wǎng)穿越技術(shù)。

步驟1 網(wǎng)絡(luò)攝像機與客戶端在同一局域網(wǎng)內(nèi),客戶端直接訪問網(wǎng)絡(luò)攝像機本地地址,該種情況不需用采用私網(wǎng)穿越技術(shù)。該情況在現(xiàn)實應(yīng)用中僅占1%的情況。

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

步驟3 當(dāng)網(wǎng)絡(luò)攝像機處于多層路由器之后或者UPNP不通的情況下,客戶端與網(wǎng)絡(luò)攝像機分別使用STUN協(xié)議到平臺進行NAT端口映射,然后分別向?qū)Ψ接成涠丝诎l(fā)送UDP穿網(wǎng)包進行P2P打洞。在該情況下,可解決現(xiàn)實情況中90%以上用戶進行P2P視頻傳輸。

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

4 結(jié)束語

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

[1] 梁篤國, 張艷霞, 曹寧, 等. 網(wǎng)絡(luò)視頻監(jiān)控技術(shù)與智能應(yīng)用[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] 楊磊, 張艷霞, 梁篤國, 等. 網(wǎng)絡(luò)視頻監(jiān)控技術(shù)[M]. 北京:中國傳媒大學(xué)出版社, 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架構(gòu)下的移動“全球眼”系統(tǒng)實現(xiàn)及性能分析[D]. 上海: 上海交通大學(xué), 2011.

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

[4] 李永明. 利用UDP穿越P2P網(wǎng)絡(luò)中NAT的技術(shù)研究[J]. 軟件導(dǎo)刊, 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]. 電信技術(shù), 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]. 計算機工程與科學(xué), 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流媒體關(guān)鍵技術(shù)的研究進展[J]. 電子技術(shù)與軟件工程, 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]. 信息通信技術(shù), 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技術(shù)在語音平臺中的應(yīng)用研究[J]. 通信技術(shù), 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]. 西安郵電大學(xué)學(xué)報, 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信令研究與應(yīng)用[J]. 計算機系統(tǒng)應(yī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-),男,天翼物聯(lián)科技有限公司工程師,主要從事視頻監(jiān)控系統(tǒng)產(chǎn)品開發(fā)、技術(shù)標(biāo)準(zhǔn)制定等工作。

張艷霞(1974-),女,天翼物聯(lián)科技有限公司正高級工程師,主要從事視頻監(jiān)控系統(tǒng)產(chǎn)品開發(fā)、技術(shù)標(biāo)準(zhǔn)制定等工作。

崔瑞琳(1973-),女,天翼物聯(lián)科技有限公司工程師,主要從事視頻監(jiān)控系統(tǒng)產(chǎn)品開發(fā)、技術(shù)標(biāo)準(zhǔn)制定等工作。

羅思維(1990-),男,天翼物聯(lián)科技有限公司工程師,主要從事視頻監(jiān)控系統(tǒng)產(chǎn)品開發(fā)、技術(shù)標(biāo)準(zhǔn)制定等工作。

猜你喜歡
設(shè)備
諧響應(yīng)分析在設(shè)備減振中的應(yīng)用
調(diào)試新設(shè)備
基于VB6.0+Access2010開發(fā)的設(shè)備管理信息系統(tǒng)
基于MPU6050簡單控制設(shè)備
電子制作(2018年11期)2018-08-04 03:26:08
廣播發(fā)射設(shè)備中平衡輸入與不平衡輸入的轉(zhuǎn)換
電子制作(2018年10期)2018-08-04 03:24:48
食之無味,棄之可惜 那些槽點滿滿的可穿戴智能設(shè)備
500kV輸變電設(shè)備運行維護探討
HTC斥資千萬美元入股虛擬現(xiàn)實設(shè)備商WEVR
IT時代周刊(2015年8期)2015-11-11 05:50:37
Automechanika Shanghai 2014 之“看” 汽保設(shè)備篇
如何在設(shè)備采購中節(jié)省成本
主站蜘蛛池模板: 国产美女免费网站| 91福利免费| 欧美三級片黃色三級片黃色1| 尤物在线观看乱码| 国产在线八区| 丁香婷婷综合激情| 亚洲日韩在线满18点击进入| 无码人妻热线精品视频| 精品撒尿视频一区二区三区| 国产免费久久精品44| 亚洲无线一二三四区男男| 国模粉嫩小泬视频在线观看| 91福利在线观看视频| 黄色网页在线播放| 天天综合天天综合| 伊人久久大香线蕉综合影视| 欧美一级视频免费| 欧美精品黑人粗大| 亚洲中文字幕av无码区| 亚洲中文字幕无码mv| 亚洲色精品国产一区二区三区| 青青草原国产av福利网站| 国产最新无码专区在线| 九九免费观看全部免费视频| 国产欧美日韩另类| 亚洲天堂日韩av电影| 五月激情综合网| 欧美日韩高清| 成人免费午间影院在线观看| 亚洲午夜福利在线| 久久精品视频一| 久久99国产综合精品1| 欧美成人区| 日韩成人在线一区二区| 欧美日本一区二区三区免费| 欧美国产精品不卡在线观看| 久草中文网| 91精品国产91久无码网站| 久久精品人人做人人爽电影蜜月 | 老司机aⅴ在线精品导航| 亚洲欧美在线看片AI| 色婷婷在线播放| 欧亚日韩Av| 91在线一9|永久视频在线| 无码精品一区二区久久久| 国产美女在线免费观看| 高清久久精品亚洲日韩Av| 国产成人无码久久久久毛片| 欧美精品另类| 国产欧美日韩在线一区| 99激情网| 2020国产精品视频| 免费99精品国产自在现线| 在线国产91| 婷婷六月综合网| 国产微拍一区二区三区四区| 一本一道波多野结衣av黑人在线| 日韩大片免费观看视频播放| 人禽伦免费交视频网页播放| 国产浮力第一页永久地址 | 亚洲第一黄片大全| 亚洲天堂免费观看| 狼友av永久网站免费观看| 亚洲人成网站在线播放2019| 亚洲娇小与黑人巨大交| 国产黑人在线| 日韩美毛片| 国产精品999在线| 亚洲综合亚洲国产尤物| 亚洲国产精品VA在线看黑人| 特级毛片免费视频| 国产精品尹人在线观看| 国产精品hd在线播放| 大学生久久香蕉国产线观看| 日韩欧美国产精品| 99国产精品国产| 永久在线精品免费视频观看| 真实国产乱子伦视频| 麻豆国产精品| 精品国产中文一级毛片在线看| 日本高清有码人妻| 亚洲精品国偷自产在线91正片|