專利名稱：基于視頻監(jiān)控的前端錄像點(diǎn)播穿越nat的方法
技術(shù)領(lǐng)域：
本發(fā)明屬于網(wǎng)絡(luò)通信技術(shù)領(lǐng)域，具體涉及一種基于視頻監(jiān)控的前 端錄像點(diǎn)播穿越NAT的方法。
背景技術(shù)：
隨著internet網(wǎng)絡(luò)的迅速發(fā)展，IP地址短缺已成為一個十分突出 的問題。很多局域網(wǎng)內(nèi)部使用私有IP,私有網(wǎng)絡(luò)的數(shù)量和規(guī)模越來越 大。與此同時，隨著技術(shù)的不斷發(fā)展，基于寬帶技術(shù)的網(wǎng)絡(luò)視頻監(jiān)控 也逐步得到推廣使用，其應(yīng)用領(lǐng)域和應(yīng)用的靈活性也已經(jīng)遠(yuǎn)遠(yuǎn)超出傳 統(tǒng)的安防監(jiān)控所定義的范疇。NAT要求整個服務(wù)的連接是從內(nèi)網(wǎng)向 外網(wǎng)主動發(fā)起的，而外網(wǎng)的用戶無法直接主動向內(nèi)網(wǎng)的服務(wù)發(fā)起連接 請求，大量的客戶端CU和前端PU常常位于NAT之后，為了能夠使 視頻監(jiān)控業(yè)務(wù)正常的開展，穿越NAT成為一個必須待以解決的問題。 NAT影響到網(wǎng)絡(luò)通信主要有兩方面 一方面，私網(wǎng)內(nèi)設(shè)備都采 用內(nèi)部IP地址，雖然經(jīng)過NAT可以將IP層的地址轉(zhuǎn)換為外部地址， 但是對于應(yīng)用層消息中的私有IP地址卻無能為力。
另一方面，私網(wǎng)設(shè)備只有在向外部主動發(fā)起連接時，才會被分配 到合法IP和端口號。若不做特殊處理，設(shè)備對外部網(wǎng)絡(luò)來說是不可 見的，也無法接受外網(wǎng)發(fā)來的呼叫請求，當(dāng)呼叫從外網(wǎng)呼叫內(nèi)網(wǎng)時， 由于內(nèi)網(wǎng)的地址是不可見的，故呼叫無法到達(dá)目的終端。
RTSP協(xié)議是一個應(yīng)用級協(xié)議，控制實(shí)時數(shù)據(jù)的發(fā)送，使實(shí)時數(shù) 據(jù)(如音頻與視頻)的受控、點(diǎn)播成為可能。實(shí)現(xiàn)RTSP的系統(tǒng)必須
RTSP協(xié)議要求終端之間使用IP地址和數(shù)據(jù)端口來建立數(shù)據(jù)通信
通道。NAT工作于IP層，而RTSP協(xié)議是應(yīng)用層協(xié)議，在消息的頭 部中帶有建立呼叫連接及媒體通道必須的IP地址和端口等信息。
這樣所帶來的問題是從信令的角度，處于外網(wǎng)中的用戶不能呼
叫處于內(nèi)網(wǎng)中的用戶；處于內(nèi)網(wǎng)中的用戶呼叫處于外網(wǎng)中的用戶時，
可能收不到響應(yīng)；從媒體的角度，無論是內(nèi)網(wǎng)還是公網(wǎng)用戶發(fā)起的呼 叫，公網(wǎng)用戶的媒體流都不能正確路由至內(nèi)網(wǎng)中SIP終端上。當(dāng)終端 都處于私網(wǎng)時，互相之間無法看到，終端之間發(fā)送的請求和響應(yīng)都不 能正確到達(dá)目的地，無論是信令還是媒體都不能正常通信。

發(fā)明內(nèi)容
本發(fā)明的目的在于針對視頻監(jiān)控應(yīng)用中現(xiàn)有技術(shù)所存在的上述 問題，提供一種易于實(shí)現(xiàn)的前端錄像點(diǎn)播穿越NAT的方法，該方法 應(yīng)用于客戶端和前端都在私網(wǎng)的情形下。
本發(fā)明的技術(shù)方案如下 一種基于視頻監(jiān)控的前端錄像點(diǎn)播穿越 NAT的方法，包括如下步驟
(1) 中心管理服務(wù)器收到前端的錄像點(diǎn)播響應(yīng)后，將其中攜帶 的URL地址和PUID通知給媒體分發(fā)服務(wù)器，媒體分發(fā)服務(wù)器依據(jù) 這些信息合成一個新的URL返回給中心管理服務(wù)器，中心管理服務(wù) 器再將這個新的URL返回給客戶端；
(2) 客戶端收到點(diǎn)播請求響應(yīng)后，根據(jù)URL的IP地址和RTSP 的知名端口 554發(fā)起TCP連接；
(3) 媒體分發(fā)服務(wù)器根據(jù)客戶端和前端的數(shù)目，定義一個端口
池；
(4) 媒體分發(fā)服務(wù)器收到客戶端RTSP的DESCRIBE請求后， 從該請求的URL中提取出PUID，該P(yáng)UID可以唯一標(biāo)識一個前端，
媒體分發(fā)服務(wù)器為該前端從端口池里取得一個沒有被其它終端占用 的端口，在這個端口上偵聽并設(shè)置定時器，通過中心管理服務(wù)器將該 端口通知給前端；
(5 )媒體分發(fā)服務(wù)器在定時器超時前，在該端口收到前端的TCP 連接，從而將客戶端和所請求的前端對應(yīng)起來，并繼續(xù)完成RTSP的 信令交互；否則釋放之前所分配的資源；
(6) RTSP的信令交互完成后，客戶端向媒體分發(fā)服務(wù)器發(fā)送媒 體探測包，媒體分發(fā)服務(wù)器從該探測包獲得客戶端接收媒體數(shù)據(jù)報(bào)的 真實(shí)IP地址和端口。
如上所述的基于視頻監(jiān)控的前端錄像點(diǎn)播穿越NAT的方法，其 中，所述的客戶端和前端都處于私網(wǎng)，媒體分發(fā)服務(wù)器和中心管理服 務(wù)器處于公網(wǎng)。
如上所述的基于視頻監(jiān)控的前端錄像點(diǎn)播穿越NAT的方法，其 中，在步驟(4)中，媒體分發(fā)服務(wù)器將前端需要連接的端口號和PUID 通知給中心管理服務(wù)器，中心管理服務(wù)器根據(jù)PUID將需要連接的媒 體分發(fā)服務(wù)器的端口號和地址轉(zhuǎn)發(fā)給前端，通知前端連接媒體分發(fā)服 務(wù)器。
如上所述的基于視頻監(jiān)控的前端錄像點(diǎn)播穿越NAT的方法，其 中，在步驟(5)中，媒體分發(fā)服務(wù)器將客戶端請求的URL轉(zhuǎn)成前端 對應(yīng)的URL，轉(zhuǎn)發(fā)DESCRIBE請求給前端，前端發(fā)送DESCRIBE回 應(yīng)給媒體分發(fā)服務(wù)器，媒體分發(fā)服務(wù)器轉(zhuǎn)發(fā)DESCRIBE回應(yīng)給客戶 端，客戶端發(fā)起SETUP請求，媒體分發(fā)服務(wù)器轉(zhuǎn)發(fā)SETUP請求給前 端，前端發(fā)送SETUP回應(yīng)給媒體分發(fā)服務(wù)器，媒體分發(fā)服務(wù)器轉(zhuǎn)發(fā) SETUP回應(yīng)給客戶端。
如上所述的基于視頻監(jiān)控的前端錄像點(diǎn)播穿越NAT的方法，其 中，在步驟(6)中，客戶端向媒體分發(fā)服務(wù)器的發(fā)送端口號發(fā)送探
測包，客戶端發(fā)起PLAY請求，媒體分發(fā)服務(wù)器轉(zhuǎn)發(fā)PLAY請求給前 端，前端發(fā)送PLAY回應(yīng)給媒體分發(fā)服務(wù)器，媒體分發(fā)服務(wù)器轉(zhuǎn)發(fā) PLAY回應(yīng)給客戶端，前端發(fā)送媒體數(shù)據(jù)包到媒體分發(fā)服務(wù)器，媒體 分發(fā)服務(wù)器將接收到的媒體數(shù)據(jù)轉(zhuǎn)發(fā)給探測包實(shí)際遠(yuǎn)端地址，客戶端 發(fā)起TEARDOWN請求，媒體分發(fā)服務(wù)器轉(zhuǎn)發(fā)TEARDOWN請求給 前端，前端發(fā)送TEARDOWN回應(yīng)給媒體分發(fā)服務(wù)器，媒體分發(fā)服 務(wù)器轉(zhuǎn)發(fā)TEARDOWN回應(yīng)給客戶端，結(jié)束點(diǎn)播。
本發(fā)明的媒體分發(fā)服務(wù)器通過增加一個獨(dú)立的點(diǎn)播服務(wù)器模塊， 對前端分配不同的TCP監(jiān)聽端口，并通過中心管理服務(wù)器通知前端， 由客戶端和前端主動連接建立TCP連接，以傳送RTSP信令消息。媒 體分發(fā)服務(wù)器接收到客戶端的RTSP信令通過必要的簡單修改轉(zhuǎn)發(fā)到 前端完成RTSP信令的建立；RTP數(shù)據(jù)包的傳送，只需客戶端主動定 時的向媒體分發(fā)服務(wù)器發(fā)送探測包即可。本發(fā)明所提供的方法簡單方 便、具有可行性?？蛻舳瞬恍韪淖冊袖浵顸c(diǎn)播流程即可輕松穿越 NAT，服務(wù)器端在客戶端建立RTSP流程前無需分配任何資源，高效 并易于擴(kuò)展。


圖1為本發(fā)明的方法流程圖。
圖2為本發(fā)明所采用的系統(tǒng)結(jié)構(gòu)圖。
具體實(shí)施例方式
下面結(jié)合附圖和實(shí)施例對本發(fā)明進(jìn)行詳細(xì)的描述。 本發(fā)明主要在視頻監(jiān)控應(yīng)用中，提供一種易于實(shí)現(xiàn)的前端錄像點(diǎn) 播穿越NAT的方法，該方法用于客戶端和前端都在私網(wǎng)的情形下。
錄像點(diǎn)播通過采用RTSP協(xié)議來實(shí)現(xiàn)，實(shí)現(xiàn)RTSP的系統(tǒng)必須支持通 過TCP傳輸RTSP。當(dāng)客戶端CU和前端PU都在NAT內(nèi)時，沒有辦 法直接在CU和PU之間建立TCP連接以傳送RTSP信令以及媒體通 道來進(jìn)行錄像點(diǎn)播，必須有一個處于公網(wǎng)的服務(wù)器來完成私網(wǎng)和公網(wǎng) 地址的轉(zhuǎn)換，本發(fā)明在視頻點(diǎn)播系統(tǒng)中，采用媒體分發(fā)服務(wù)器VTDU 來實(shí)現(xiàn)該服務(wù)器。由于客戶端CU和前端PU在私網(wǎng)，建立TCP連接 時，只能讓客戶端和前端充當(dāng)TCP的CLIENT,媒體分發(fā)服務(wù)器作為 TCP的SERVER。
在介紹本發(fā)明的方法之前，首先對系統(tǒng)組成進(jìn)行說明 客戶端單元CU:用于瀏覽和控制遠(yuǎn)端視頻及系統(tǒng)。 前端單元PU:用于媒體流信息、告警信息、控制信息的獲取、 緩存、編碼、轉(zhuǎn)發(fā)以及可能需要存儲的所有設(shè)備組成的子系統(tǒng)。它包 括攝像機(jī)，云臺，視頻服務(wù)器，報(bào)警輸入輸出裝置，本地?cái)?shù)字視頻 錄像機(jī)等。
媒體分發(fā)服務(wù)器VTDU:是網(wǎng)絡(luò)視頻監(jiān)控中心平臺系統(tǒng)的媒體處 理單元，實(shí)現(xiàn)媒體流請求、媒體流接收、媒體流分發(fā)等功能。
中心管理服務(wù)器CMS:是網(wǎng)絡(luò)視頻監(jiān)控中心平臺系統(tǒng)核心調(diào)度 服務(wù)器單元，是中心服務(wù)平臺的核心單元，負(fù)責(zé)實(shí)現(xiàn)前端、客戶端的 接入、各單元的信令轉(zhuǎn)發(fā)控制處理、報(bào)警信息的接收與處理以及業(yè)務(wù) 支撐信息管理。
前端錄像點(diǎn)播穿越NAT的過程如下
一、 錄像査詢信令(步驟1 4):査詢錄像文件列表。
二、 錄像點(diǎn)播信令(步驟5~10):獲得某一個錄像文件的URL
地址。在這一步中，服務(wù)器實(shí)際上沒有分配任何的資源。
三、 RTSP錄像點(diǎn)播(步驟11~35): RTSP點(diǎn)播流程。 第二步和第三步分開的好處在于，獲得URL以后，可以有多次
的點(diǎn)播動作，每個點(diǎn)播動作之間互不影響。并且第二步?jīng)]有分配服務(wù) 器資源，這樣可以極大的提高服務(wù)器的效率。 具體流程說明如下，參見圖l。
1) 客戶端向中心管理服務(wù)器發(fā)起錄像査詢請求(攜帶要查詢的
PUID) 。
2) 中心管理服務(wù)器向PU轉(zhuǎn)發(fā)查詢請求。
3) PU回應(yīng)錄像査詢請求給中心管理服務(wù)器(返回文件列表)。
4) 中心管理服務(wù)器回應(yīng)錄像查詢請求給CU。
5) CU向中心管理服務(wù)器發(fā)起錄像點(diǎn)播請求(攜帶要點(diǎn)播的PUID和 文件信息)。
6) 中心管理服務(wù)器向PU轉(zhuǎn)發(fā)點(diǎn)播請求。
7) PU回應(yīng)點(diǎn)播請求給中心管理服務(wù)器(返回依據(jù)文件信息生成的 URL)。
8) 中心管理服務(wù)器向媒體分發(fā)服務(wù)器發(fā)起通知需要訪問的URL (攜 帶步驟7返回的URL和PUID)。
9) 媒體分發(fā)服務(wù)器根據(jù)內(nèi)部規(guī)則生成新的URL返回給中心管理服 務(wù)器。
10) 中心管理服務(wù)器回應(yīng)點(diǎn)播請求給CU (返回步驟9中VTDU返回 的新URL)。
11) CU建立根據(jù)URL中的服務(wù)器地址建立TCP連接。
12) CU發(fā)送DESCRIBE請求給媒體分發(fā)服務(wù)器。
13) 媒體分發(fā)服務(wù)器從DESCRIBE的URL中獲得PUID,準(zhǔn)備好接受 PU的TCP連接。將PU需要連接的端口號，和PUID通知給中心 管理服務(wù)器。
14) 中心管理服務(wù)器根據(jù)PUID將需要連接的媒體分發(fā)服務(wù)器的端口 號和地址轉(zhuǎn)發(fā)給PU，通知PU連接媒體分發(fā)服務(wù)器。
15) PU發(fā)送點(diǎn)播通知回應(yīng)。
16) 中心管理服務(wù)器向媒體分發(fā)服務(wù)器轉(zhuǎn)發(fā)點(diǎn)播通知回應(yīng)。
17) PU向媒體分發(fā)服務(wù)器發(fā)起TCP連接(使用步驟14中獲得的媒 體分發(fā)服務(wù)器的地址和端口號)。
18) 媒體分發(fā)服務(wù)器將CU請求的URL轉(zhuǎn)成PU對應(yīng)的URL (后續(xù) 的轉(zhuǎn)發(fā)RTSP請求都需要這個轉(zhuǎn)換，不再重復(fù))，轉(zhuǎn)發(fā)DESCRIBE 請求給PU。
19) PU發(fā)送DESCRIBE回應(yīng)給媒體分發(fā)服務(wù)器。
20) 媒體分發(fā)服務(wù)器轉(zhuǎn)發(fā)DESCRIBE回應(yīng)給CU。
21) CU發(fā)起SETUP請求(攜帶CU的數(shù)據(jù)接收端口號)。
22) 媒體分發(fā)服務(wù)器轉(zhuǎn)發(fā)SETUP請求給PU(將接收端口號改成媒體 分發(fā)服務(wù)器的接收端口號)。
23) PU發(fā)送SETUP回應(yīng)給媒體分發(fā)服務(wù)器(攜帶PU的數(shù)據(jù)發(fā)送端 口號)。
24) 媒體分發(fā)服務(wù)器轉(zhuǎn)發(fā)SETUP回應(yīng)給CU (將發(fā)送端口號改為媒 體分發(fā)服務(wù)器的發(fā)送端口號)。
25) CU向媒體分發(fā)服務(wù)器的發(fā)送端口號發(fā)送探測包(這一步驟是針 對CU也處于NAT內(nèi))。
26) CU發(fā)起PLAY請求。
27) 媒體分發(fā)服務(wù)器轉(zhuǎn)發(fā)PLAY請求給PU。
28) PU發(fā)送PLAY回應(yīng)給媒體分發(fā)服務(wù)器。
29) 媒體分發(fā)服務(wù)器轉(zhuǎn)發(fā)PLAY回應(yīng)給CU。
30) PU發(fā)送媒體數(shù)據(jù)包到媒體分發(fā)服務(wù)器。
31) 媒體分發(fā)服務(wù)器將接收到的媒體數(shù)據(jù)轉(zhuǎn)發(fā)給步驟25中，探測包 實(shí)際遠(yuǎn)端地址。如果沒有收到探測包，就發(fā)送到步驟21中CU提 供的接收端口號。
32) CU發(fā)起TEARDOWN請求。
33) 媒體分發(fā)服務(wù)器轉(zhuǎn)發(fā)TEARDOWN請求給PU。
34) PU發(fā)送TEARDOWN回應(yīng)給媒體分發(fā)服務(wù)器。
35) 媒體分發(fā)服務(wù)器轉(zhuǎn)發(fā)TEARDOWN回應(yīng)給CU，結(jié)束點(diǎn)播。 上述方法在流程設(shè)計(jì)中所考慮的關(guān)鍵點(diǎn)如下
1. 客戶端的行為只需要查詢得到對應(yīng)的URL (步驟5)(這個 URL應(yīng)該由平臺組織好了返回給客戶端，不要由客戶端去拼裝，這 樣擴(kuò)展性會更好，因?yàn)閷?shí)際上客戶端不需要知道任何URL的細(xì)節(jié)， 只要用這個URL可以請求到點(diǎn)播的視頻就行了)，然后用這個URL 發(fā)起標(biāo)準(zhǔn)的RTSP請求(步驟ll， 12， 21， 26)，就可以得到錄像的 視頻。
2. 因?yàn)榍岸颂幱贜AT內(nèi)，客戶端不可能連接到前端進(jìn)行點(diǎn)播。 這樣借助一個中間的公網(wǎng)服務(wù)器(本發(fā)明由媒體分發(fā)服務(wù)器VTDU 來完成)。將應(yīng)該發(fā)給PU的請求發(fā)給媒體分發(fā)服務(wù)器，然后由媒體 分發(fā)服務(wù)器轉(zhuǎn)發(fā)給PU。同樣的因?yàn)镻U在NAT內(nèi)，媒體分發(fā)服務(wù)器 也沒有辦法直接連接到PU。這就需要PU主動的向媒體分發(fā)服務(wù)器 發(fā)起tcp連接(步驟17)。而后媒體分發(fā)服務(wù)器在這個已經(jīng)建立好的 連接上，發(fā)送RTSP信令(步驟18， 22， 27)。因?yàn)槊襟w分發(fā)服務(wù)器 也沒有辦法直接通知PU來主動建立TCP連接，所以在媒體分發(fā)服務(wù) 器在收到CU的RTSP請求時，需要通過中心管理服務(wù)器來間接告訴 PU (步驟13， 14)。
3. 對于CU查詢時獲得的URL地址應(yīng)該是訪問媒體分發(fā)服務(wù)器 的地址，而原本由PU返回的是訪問PU的URL地址，這樣需要在 這兩個地址之間做一個轉(zhuǎn)換。當(dāng)中心管理服務(wù)器收到PU返回的錄像 點(diǎn)播請求回應(yīng)時，將其中攜帶的URL地址和PUID通知給媒體分發(fā) 服務(wù)器(步驟8)，媒體分發(fā)服務(wù)器依據(jù)這些信息合成一個新的URL
(步驟9中的ur11)返回給中心管理服務(wù)器(步驟9)。中心管理服務(wù) 器再將這個新的URL返回給CU (步驟10)。這里之所以要添加9、 10兩步，在于媒體分發(fā)服務(wù)器可以根據(jù)自己的映射方式來生成URL， 只需要媒體分發(fā)服務(wù)器能夠依據(jù)新的URL獲得原始的URL和PUID。 這樣可以有更好的擴(kuò)展性。
4.當(dāng)CU也在NAT內(nèi)時，因?yàn)橐邮罩虚g服務(wù)器轉(zhuǎn)發(fā)來的點(diǎn)播 流，需要主動定時的向中間服務(wù)器發(fā)送探測包(步驟25)。
本發(fā)明所采用系統(tǒng)的結(jié)構(gòu)圖，如圖2所示。 本發(fā)明在視頻點(diǎn)播系統(tǒng)中，采用媒體分發(fā)服務(wù)器VTDU來實(shí)現(xiàn) 該服務(wù)器，主要能體現(xiàn)出設(shè)計(jì)的模塊化、獨(dú)立性和易實(shí)現(xiàn)性。 l.模塊化
由圖2可以看出，媒體分發(fā)服務(wù)器的信令模塊和媒體模塊之間采 用TCP通信，實(shí)現(xiàn)錄像點(diǎn)播穿越NAT功能時，只需加入一個獨(dú)立的 模塊(圖中黃色模塊)，該模塊與信令模塊仍采用TCP通信。
2獨(dú)立性
如上所述，Vod服務(wù)器模塊只與媒體分發(fā)服務(wù)器的信令模塊有簡 單通信，與媒體模塊完全獨(dú)立，易于維護(hù)和擴(kuò)展。 3易實(shí)現(xiàn)性
Vod服務(wù)器模塊對RTSP消息基本上只需要透傳，無需解析即可 實(shí)現(xiàn)。
權(quán)利要求
1.一種基于視頻監(jiān)控的前端錄像點(diǎn)播穿越NAT的方法，包括如下步驟(1)中心管理服務(wù)器收到前端的錄像點(diǎn)播響應(yīng)后，將其中攜帶的URL地址和PUID通知給媒體分發(fā)服務(wù)器，媒體分發(fā)服務(wù)器依據(jù)這些信息合成一個新的URL返回給中心管理服務(wù)器，中心管理服務(wù)器再將這個新的URL返回給客戶端；(2)客戶端收到點(diǎn)播請求響應(yīng)后，根據(jù)URL的IP地址和RTSP的知名端口554發(fā)起TCP連接；(3)媒體分發(fā)服務(wù)器根據(jù)客戶端和前端的數(shù)目，定義一個端口池；(4)媒體分發(fā)服務(wù)器收到客戶端RTSP的DESCRIBE請求后，從該請求的URL中提取出PUID，該P(yáng)UID可以唯一標(biāo)識一個前端，媒體分發(fā)服務(wù)器為該前端從端口池里取得一個沒有被其它終端占用的端口，在這個端口上偵聽并設(shè)置定時器，通過中心管理服務(wù)器將該端口通知給前端；(5)媒體分發(fā)服務(wù)器在定時器超時前，在該端口收到前端的TCP連接，從而將客戶端和所請求的前端對應(yīng)起來，并繼續(xù)完成RTSP的信令交互；否則釋放之前所分配的資源；(6)RTSP的信令交互完成后，客戶端向媒體分發(fā)服務(wù)器發(fā)送媒體探測包，媒體分發(fā)服務(wù)器從該探測包獲得客戶端接收媒體數(shù)據(jù)報(bào)的真實(shí)IP地址和端口。
2. 如權(quán)利要求1所述的基于視頻監(jiān)控的前端錄像點(diǎn)播穿越NAT 的方法，其特征在于所述的客戶端OTP^ETW7^^1^ 器和中心管理服務(wù)器處于公網(wǎng)。
3. 如權(quán)利要求1或2所述的基于視頻監(jiān)控的前端錄像點(diǎn)播穿越NAT的方法，其特征在于在步驟(4)中，媒體分發(fā)服務(wù)器將前端 需要連接的端口號和PUID通知給中心管理服務(wù)器，中心管理服務(wù)器 根據(jù)PUID將需要連接的媒體分發(fā)服務(wù)器的端口號和地址轉(zhuǎn)發(fā)給前 端，通知前端連接媒體分發(fā)服務(wù)器。
4. 如權(quán)利要求1或2所述的基于視頻監(jiān)控的前端錄像點(diǎn)播穿越 NAT的方法，其特征在于在步驟(5)中，媒體分發(fā)服務(wù)器將客戶 端請求的URL轉(zhuǎn)成前端對應(yīng)的URL，轉(zhuǎn)發(fā)DESCRIBE請求給前端， 前端發(fā)送DESCRIBE回應(yīng)給媒體分發(fā)服務(wù)器，媒體分發(fā)服務(wù)器轉(zhuǎn)發(fā) DESCRIBE回應(yīng)給客戶端，客戶端發(fā)起SETUP請求，媒體分發(fā)服務(wù) 器轉(zhuǎn)發(fā)SETUP請求給前端，前端發(fā)送SETUP回應(yīng)給媒體分發(fā)服務(wù)器， 媒體分發(fā)服務(wù)器轉(zhuǎn)發(fā)SETUP回應(yīng)給客戶端。
5. 如權(quán)利要求1或2所述的基于視頻監(jiān)控的前端錄像點(diǎn)播穿越 NAT的方法，其特征在于在步驟(6)中，客戶端向媒體分發(fā)服務(wù) 器的發(fā)送端口號發(fā)送探測包，客戶端發(fā)起PLAY請求，媒體分發(fā)服務(wù) 器轉(zhuǎn)發(fā)PLAY請求給前端，前端發(fā)送PLAY回應(yīng)給媒體分發(fā)服務(wù)器， 媒體分發(fā)服務(wù)器轉(zhuǎn)發(fā)PLAY回應(yīng)給客戶端，前端發(fā)送媒體數(shù)據(jù)包到媒體分發(fā)服務(wù)器，媒體分發(fā)服務(wù)器將接收到的媒體數(shù)據(jù)轉(zhuǎn)發(fā)給探測包實(shí) 際遠(yuǎn)端地址，客戶端發(fā)起TEARDOWN請求，媒體分發(fā)服務(wù)器轉(zhuǎn)發(fā) TEARDOWN請求給前端，前端發(fā)送TEARDOWN回應(yīng)給媒體分發(fā) 服務(wù)器，媒體分發(fā)服務(wù)器轉(zhuǎn)發(fā)TEARDOWN回應(yīng)給客戶端，結(jié)束點(diǎn)
全文摘要
本發(fā)明屬于網(wǎng)絡(luò)通信技術(shù)領(lǐng)域，具體涉及一種基于視頻監(jiān)控的前端錄像點(diǎn)播穿越NAT的方法。該方法通過媒體分發(fā)服務(wù)器來實(shí)現(xiàn)視頻監(jiān)控業(yè)務(wù)中的前端錄像點(diǎn)播穿越NAT的功能。媒體分發(fā)服務(wù)器通過增加一個獨(dú)立的點(diǎn)播服務(wù)器模塊，對前端分配不同的TCP監(jiān)聽端口，并通過中心管理服務(wù)器告訴前端，由客戶端和前端主動連接建立TCP連接，以傳送RTSP信令消息。媒體分發(fā)服務(wù)器接收到客戶端的RTSP信令通過必要的簡單修改轉(zhuǎn)發(fā)到前端完成RTSP信令的建立；RTP數(shù)據(jù)包的傳送，只需客戶端主動定時的向媒體分發(fā)服務(wù)器發(fā)送探測包即可。本發(fā)明實(shí)現(xiàn)簡單方便、具可行性?？蛻舳瞬恍韪淖冊袖浵顸c(diǎn)播流程即可輕松穿越NAT，服務(wù)器端在客戶端建立RTSP流程前無需分配任何資源，高效并易于擴(kuò)展。
文檔編號H04N7/18GK101170687SQ20071019541
公開日2008年4月30日 申請日期2007年11月28日 優(yōu)先權(quán)日2007年11月28日
發(fā)明者萍 楊, 穎 王, 俊 黃 申請人:武漢烽火網(wǎng)絡(luò)有限責(zé)任公司