基于Onvif協議的視頻監控對等網絡庫的設計

姚嚴峰，劉國輝

（武漢郵電科學研究院湖北武漢470030）

基于Onvif協議的視頻監控對等網絡庫的設計

姚嚴峰，劉國輝

（武漢郵電科學研究院湖北武漢470030）

為了實現視頻監控系統中遠程傳輸音頻、視頻更加穩定、流暢的需求，提出了一套更加合理的選擇和實現TCP、UDP連接的設計方案，并完成系統的軟件實現。通過測試工具進行連接方式測試，并將它放在視頻監控系統里試驗遠程傳輸視頻、音頻的畫面，得出了對等網絡庫可以準確選擇連接方式、畫面聲音質量穩定、播放流暢的特點，達到了設計要求。

視頻監控；設計；對等網絡庫；視頻；音頻

隨著流媒體技術、網絡技術的發展以及相關傳輸協議、視頻編碼標準的成熟［1］，視頻監控系統已由最初的模擬視頻監控系統階段發展到了網絡視頻監控系統階段，采用流媒體傳輸技術的網絡視頻監控系統因其具有視頻數字化、監控網絡化和控制智能化等特點而成為當前視頻監控領域研究的熱點。由于流媒體對IP網絡的QoS有較高的要求，而IP網絡的結構特點決定了其不能提供足夠的網絡帶寬、較小的網絡延時和較低的丟包率，所以流媒體和IP網絡在QoS方面的矛盾影響了流媒體在IP網絡上的應用效果［2］。

對等網絡流媒體系統的低消耗和高可擴展性很好的解決了傳統流媒體系統中服務器和網絡的高壓力問題，使得為用戶提供高質量網絡視頻服務成為可能。在隨機的拓撲結構中，由于鄰居選擇的隨機性和不確定性，使得網絡系統中存在主干網絡壓力大、啟動延遲和播放延遲長以及幀丟失率高等問題［3］。

1　NVR中對等連接的設計流程

當IE插件客戶端需要獲取外網設備的數據時，網絡庫模塊會調用對等網絡庫，具體流程如圖1所示。

圖1　客戶端網絡庫對對等網絡庫調用流程圖Fig.1Client network library on peer to peer network library call flow chart

在登錄以太網上的NVR設備時，客戶端需要知道設備的ID標識符和擁有登錄設備的權限，向P2P總服務器發送請求信息，總服務器收到請求信息后，通過查詢數據庫，向客戶端反饋服務器列表信息，客戶端分析服務器列表信息，向設備注冊的服務器發送設備的登錄信息請求，次級服務器收到登錄信息請求后，向客戶端反饋設備的登錄信息，客戶端根據設備反饋的登錄信息選擇合適的連接方式嘗試登錄，登錄成功后，客戶端和設備之間就可以傳輸視頻數據、音頻數據和用戶數據，從而達到用戶在客戶端操控設備的目的。

2　對等網絡庫的具體設計

2.1向服務器請求目標設備的信息

獲取p2p服務器列表，列表服務器：p2pserverlist.dddns.org，端口：6663，該服務器支持tcp和udp連接，tcp和udp端口相同。消息IDP2P_MSG_GET_SERVER_LIST=1015，該消息只有頭部，不帶消息體。服務器回復當前p2p的服務器列表，該回復消息id依舊是1015，回復消息由p2p的頭部和xml數據構成，xml數據中包含當前服務器的數量（server_cnt），每個服務器的域名（server_dn）與端口（server_port）。

獲取目標設備信息，新版本添加了多服務器支持之后，設備會向就近的服務器進行注冊，當服務器出現故障時，設備也會自動切換到工作正常的服務器，在獲取目標設備信息時，需要向第2步獲取到的所有服務器列表發送獲取目標設備信息的請求，服務器的回復可能有3種情況：設備不存在，設備不在線，成功。取返回成功的服務器的數據作為連接設備的信息。服務器都支持tcp和udp連接，獲取目標設備信息可以通過tcp發送，也可以通過udp發送，為了提高連接速度，客戶端應同時向服務器群請求數據，而避免依次請求，導致連接時間過長。

圖2　對等網絡庫通信流程概圖Fig.2Peer to peer network library communication process overview

2.2連接目標設備

P2P服務器返回節點信息，返回信息中包括如下內容：設備是否在線，是否嘗試使用lan連接，通過tcp是直連還是非直連，是否嘗試使用udp連接。連接嘗試的順序為：

1）私網地址局域網直連（如果try_lan==1）；

2）公網地址廣域網tcp直連（如果connect_direct==1）；

3）廣域網udp直連（如果try_udp==1，并且直連udp hello完成）；

4）廣域網udp轉發（如果try_udp==1，并且非直連udp hello完成）；

5）廣域網tcp轉發（如果connect_direct==0）。

根據服務器反饋的信息，客戶端進行不同的處理［1］，如果設備不在線，提示登陸失敗，設備不在線，并向服務器報告連接結果，連接過程終結；否則進入下一步。

如果try_lan的值為1，客戶端應使用局域網地址（target_ip_lan）和p2p端口（target_port）進行tcp連接嘗試，否則跳入下一步。連接流程如下：

1）和目標設備建立tcp連接；

2）發送bind請求進行綁定，bind的請求的to_uid應填目標設備的uid；

3）綁定成功即可使用直接使用p2p協議進行通信，通信時用戶數據應添加p2p頭，然后再通過socket發送給目標設備，p2p頭部中to_uid應填寫目標設備的uid，from_uid應填客戶端的uid，to_port和from_port可以不用填，msg id應填P2P_MSG_ID_USER；

4）當客戶端和目標設備連接成功之后，應向服務器報告連接結果；

5）通信完成之后斷開socket連接；

6）連接過程終結。

如果connect_direct的值為1，客戶端應使用目標設備ip地址（target_ip）和p2p端口（target_port）進行tcp連接嘗試，否則跳入下一步。TCP連接流程如下，本流程和b流程基本一致，不一樣的地方在于b使用的目標設備的私有ip，而本流程使用的是目標設備的外網ip。

2.3與目標設備建立TCP連接

如果connect_direct的值為1，客戶端應使用目標設備IP地址（target_ip）和p2p端口（target_port）進行TCP連接嘗試，否則跳入下一步。TCP連接流程如下，本流程和b流程基本一致，不一樣的地方在于b使用的目標設備的私有IP，而本流程使用的是目標設備的外網IP。

1）和目標設備建立TCP連接；

2）發送bind請求進行綁定，bind的請求的to_uid應填目標設備的uid；

3）綁定成功即可使用直接使用p2p協議進行通信，通信時用戶數據應添加p2p頭，然后再通過socket發送給目標設備，p2p頭部中to_uid應填寫目標設備的uid，from_uid應填客戶端的uid，to_port和from_port可以不用填，msg id應填P2P_MSG_ID_USER；

4）當客戶端和目標設備連接成功之后，應向服務器報告連接結果；

5）通信完成之后斷開socket連接；

6）連接過程終結。

如果try_udp的值為1，客戶端應使用目標設備ip地址（target_ip）和端口（target_port）進行UDP連接嘗試，否則跳入下一步。UDP連接流程如下，整個過程都必須通過UDP協議完成：

1）向服務器發送UDP連接請求（P2P_MSG_UDP_CONNE CT_REQUEST）；

2）服務器返回目標設備的UDP連接信（P2P_MSG_ UDP_CONNECT_RE PLY），同時還會提供最多10個UDP的轉發節點；

3）客戶端向目標設備發送udp hello請求（P2P_MSG_ UDP_HELLO），發送請求應每500 ms發送一個，連續發送5次；發送請求時，除了對目標設備發送以外，還需要同時通過10個轉發節點發送連接請求，請求包p2p的頭部to_uid應填寫目標設備的uid，udp_ip和udp_port應填寫目標設備的外網ip和p2p端口。在接收到目標設備的回復之后，客戶端應記錄是否可以通過UDP直連，哪些轉發節點可以使用等信息；

4）連接請求設置超時時間5 s，如果在這5 s內收到目標設備的直連的udp hello包，則忽略轉發節點，進入UDP直連流程；

5）如果5 s內沒有收到直連回復，依據是否有收到轉發的udp hello消息，判斷能否使用轉發節點進行UDP連接；

6）如果沒有收到任何轉發節點的請求，則進行tcp轉發流程。

客戶端使用伙伴節點ip地址（parter_ip）和端口（parter_port）進行tcp連接嘗試，連接過程如下：

1）和伙伴節點建立TCP連接；

2）發送bind請求進行綁定，bind的請求的to_uid應填伙伴節點的uid；

3）綁定成功即可使用p2p協議進行通信，通信時用戶數據應添加p2p頭，然后再通過socket發送給伙伴節點，p2p頭部中to_uid應填寫目標設備的uid，from_uid應填客戶端的uid，to_port和from_port可以不用填，msg id應填P2P_MSG_ID_USER；

4）當客戶端和目標設備連接成功之后，應向服務器報告連接結果；

5）通信完成之后斷開socket連接；

6）連接過程終結。

2.4UDP連接方式的改進設計

由于UDP連接的不可靠特點，和視頻數據傳輸特點，UDP傳輸一直不能達到理想效果，經過努力對UDP通信方式作出改進，通信流程如下：PC向P2P服務器請求節點信息（P2P_MSG_GET_NODE_INFO），P2P服務器返回節點信息，返回信息中包括如下內容：設備是否在線、是否嘗試使用lan連接、直連還是非直連、是否嘗試使用UDP連接。

根據服務器反饋的信息，客戶端進行不同的處理

1）如果設備不在線，提示登陸失敗，原因是設備不在線

2）如果try_lan=1，客戶端使用服務器返回的私有地址進行連接嘗試，如果成功，則進入正常工作，如果不成功，這進入下一步驟，局域網連接嘗試的超時時間設備2 s；

3）根據connect_direct的值判斷是否可以直連，如果是直連，原有的連接邏輯不變；

4）直接使用TCP進行直連；

5）如果非直連，判斷是否使用UDP連接（try_udp=1），UDP連接流程如下：

向服務器發送UDP連接請求（P2P_MSG_UDP_CONNECT _REQUEST），服務器返回對端設備的UDP連接信息（P2P_MSG_UDP_CONNECT_REPLY），同時還會提供最多10個UDP的轉發節點，同時服務器會通知目標設備，并且會提供相同的UDP轉發節點信息，Pc向目標設備發送UDP連接請求（P2P_MSG_UDP_HELLO），同時目標設備也會向pc發送UDP連接請求，發送請求應每500 ms發送一個，連續發送3次；同時通過10個轉發節點發送連接請求，接收端應記錄可以使用的轉發節點以及連接速度等信息，連接請求設置超時時間5 s，如果在這5 s內收到對端的直連請求，立即中斷連接請求等待，進入UDP直連流程，如果5 s內沒有收到直連回復，看是否有收到轉發連接請求，如果有收到，則使用轉發節點進行UDP連接，如果沒有收到任何轉發節點的請求，則進行TCP轉發流程。

6）如果是try_udp=0，直接進入TCP轉發流程。

當客戶端向服務器發送連接請求之后，服務器會返回對端設備的信息和代理節點的信息，而且服務器會將這些信息通告到目標設備，獲取到這些信息之后，客戶端和目標設備應同時向對端發送連接請求，以完成UDP打洞，同時需要通過代理節點發送連接請求，以確定可用的代理節點和代理節點的速度，以便后續使用UDP轉發時優化連接速度。UDP連接請求總時間設置5 s超時，如果5 s內收到對端設備直連的UDP消息，說明UDP打洞已經成功，可以通過UDP進行直連，這是立即中斷請求流程，直接進入下一環節。從服務器獲取到的代理節點也不再使用。如果5 s內沒有收到直連請求，則只能選擇通過UDP代理的方式進行連接，如果也沒有收到任何UDP代理的請求消息，則跳出UDP連接過程。

進入UDP直連之后，和TCP直連不同之處在于需要處理亂序和丟包，這部分工作需要在p2p模塊中處理完成，以避免影響到上層應用軟件。p2p接收模塊需建立一個收到數據包的隊列，將收到的數據包按照需要放入隊列，上層軟件獲取時，一次從隊列中取出數據。

UDP轉發過程中最核心的內容是最有效的使用UDP的轉發節點，以最大化傳輸效率。每個轉發節點帶寬不同，并且穩定性也不同，如果最有效的利用多個節點來進行轉發。

在整個數據發送過程中，設備端會定期通過所有轉發節點向客戶端發送UDP探測消息（P2P_MSG_UDP_ROUTE_ HEARTBEAT），客戶端收到探測消息，需要回復，設備端更具收到的回復的速度選擇使用的轉發節點。客戶端收到的數據可能是從不同的轉發節點轉發過來的，數據的順序會被打亂，有可能后發的包先收到，也有可能丟包，客戶端需設置一個超時時間，對于媒體數據，超時時間為3s，信令數據，超時時間為5s，如果收到的后面的包并且超時時間到還沒有收到數據，則認為前面發送的數據包已丟失。

3　實驗應用

p2p_tool是在windos環境下使用vc++基于mfc開發的，它以對等網絡庫為基礎，不僅可以對網絡庫的穩定性和實用性進行測試，還可以檢測相關網絡故障。測試工具界面如圖3所示。

為了操作方便測試工具被設計為對話框的形式［4］，操作臺部分用來輸入要連接的NVR設備的設備ID，服務器列表部分顯示從主服務器獲取的服務器列表信息，連接信息部分顯示客戶端從設備注冊服務器獲取的設備連接信息［5］，最后一部分顯示可用的連接方式及連接時間。

圖3　測試工具界面圖Fig.3The testing tool interface diagram

測試登陸的結果如圖4所示。

圖4　測試工具登錄信息圖Fig.4Test tools login information graph

在IE插件客戶端的實際使用過程中，對等網絡庫的其他幾種連接方式，都能很好的完成通信任務，精確的傳輸用戶數據和視頻數據，保證預覽和回放視頻畫面的流暢和穩定。

4　結論

該對等網絡庫采用更為合理的通信模式［6］，軟件設計采用模塊化設計思想，提高了系統的可靠性和維護性。該對等網絡庫已經應用于視頻監控系統進行試用［7］，實際應用表明該對等網絡庫可以準確的選擇連接方式，穩定流暢的遠程傳輸A/V文件，達到了設計的目的。

［1］鄭俊飛.軌道交通車地寬帶視頻監控系統的研究［D］.南昌：南昌航空大學，2012.

［2］何浩.基于H.264的網絡視頻監控系統的設計與實現［D］.長沙：湖南大學，2009.

［3］張秀玲.視頻監控系統研究現狀與發展趨勢［J］.科技信息（學術版），2008（2）：129-133. ZHANG Xiu-ling.Research status and development trend of video surveillance systems［J］.Science and Technology Information（Academic Edition），2008（2）：129-133.

［4］董向化，楊勇.基于網絡的視頻監控系統的設計與實現［J］.通信技術，2013（2）：64-66. DONG Xing-hua，YANG Yong.Design and implementation of network video surveillance system based on ommunication technology，2013（2）：64-66.

［5］秦培龍.基于ARM的嵌入式視頻服務器設計與實現［D］.北京：中國民航大學，2008.

［6］馬留英.基于3G移動通信的視頻監控系統研究［D］.西安：長安大學，2011.

［7］沈傳兵，白文浩，崔海，等.動力系統試驗工藝參數監視系統設計［J］.火箭推進，2014（4）：73-76. SHEN Chuan-bing，BAI Wen-hao，CUI Hai，et al.Design of process parameter monitoring system for rocket propulsion system test［J］.Journal of Rocket Propulsion，2014（4）：73-76.

Design of network video surveillance client's peer to peer network library based on Onvif

YAO Yan-feng，LIU Guo-hui
（Wuhan Research Institute of Posts and Telecommunications，Wuhan 470030，China）

In order to realize the remote transmission of audio and video in Video surveillance system more stable and smooth，put forward a set of more reasonable selection and implementation of TCP and UDP connection design，and implement the software of the system.Test connection style by test tools，and put it in the video monitoring system in the test of remote transmission of video and audio picture，obtained the peer to peer network library can be accurately select the connection mode，signal of video and audio quality is stable，can be smoothly play，and achieve the design requirements.

video surveillance system；design；peer to peer network library；audio；video

TN919.82

A

1674-6236（2015）20-0075-04

2014-12-24稿件編號：201412233

姚嚴峰（1987—），男，河南洛陽人，碩士。研究方向：通信與信息系統、物聯網。