TW201345237A - Ｔｃｐ穿越ｎａｔ於ｒｔｓｐ上應用 - Google Patents

Ｔｃｐ穿越ｎａｔ於ｒｔｓｐ上應用 Download PDF

Info

Publication number
TW201345237A
TW201345237A TW101115178A TW101115178A TW201345237A TW 201345237 A TW201345237 A TW 201345237A TW 101115178 A TW101115178 A TW 101115178A TW 101115178 A TW101115178 A TW 101115178A TW 201345237 A TW201345237 A TW 201345237A
Authority
TW
Taiwan
Prior art keywords
nat
rtsp
client
tcp
media
Prior art date
Application number
TW101115178A
Other languages
English (en)
Inventor
Bing-Chih Yao
chao-ping Chu
Ning-Yun Ku
Shaw-Hwa Hwang
Original Assignee
Univ Nat Taipei Technology
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Univ Nat Taipei Technology filed Critical Univ Nat Taipei Technology
Priority to TW101115178A priority Critical patent/TW201345237A/zh
Priority to US13/651,500 priority patent/US20130290517A1/en
Publication of TW201345237A publication Critical patent/TW201345237A/zh

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/10—Architectures or entities
    • H04L65/1045—Proxies, e.g. for session initiation protocol [SIP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/61—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio
    • H04L65/613—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio for the control of the source by the destination
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/65—Network streaming protocols, e.g. real-time transport protocol [RTP] or real-time control protocol [RTCP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
    • H04N21/643—Communication protocols
    • H04N21/6437—Real-time Transport Protocol [RTP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/83—Generation or processing of protective or descriptive data associated with content; Content structuring
    • H04N21/845—Structuring of content, e.g. decomposing content into time segments
    • H04N21/8456—Structuring of content, e.g. decomposing content into time segments by decomposing the content in the time domain, e.g. in time segments
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/85—Assembly of content; Generation of multimedia applications
    • H04N21/854—Content authoring
    • H04N21/85406—Content authoring involving a specific file format, e.g. MP4 format

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

本發明為一種改良式RTSP通訊協定，並引入類似SIP代理伺服(Proxy Server)的元件及概念至傳統RTSP架構中。除了協助位於NAT防火牆下的RTSP媒體伺服之定位及確保RTSP通道連線註冊的工作外；代理伺服也協助提供NAT(Network Address Translator)埠口預測的服務，並加上一段TCP的NAT穿越法，用以解決客戶端與RTSP媒體伺服同時在NAT防火牆下時，媒體封包無法從媒體伺服穿越客戶端的NAT防火牆而直接達到點對點傳輸的問題。

Description

TCP穿越NAT於RTSP上應用
本發明有關於一種NAT(Network Address Translator)穿越法，尤指一種RTSP通訊協定之NAT穿越法，以改善RTSP媒體伺服與客戶端同時在NAT防火牆下時，無法將多媒體語音或影像直接對傳之困擾。
媒體伺服中IP Camera(網路攝影機)為現今熱門的物聯網科技之一。網路攝影機所使用的通訊協定中以標準RTSP(Real Time Streaming Protocol)為協定占大多數，因為其架構符合單向影音通訊和串流實況的特性，故常以該標準作為其通訊協定。在目前標準RTSP的網路環境中，傳輸多媒體資料多半以TCP協定為主，但也愈來愈多的人架設NAT(Network Address Translator，俗稱IP分享器)，造成網路攝影機與客戶端同時在NAT下情形常常發生，導致雙方無法交換彼此RTSP訊令，甚至無法使影音RTP封包在TCP協定上直接傳送。
一個傳統完整RTSP協定，以瀏覽器應用為例的基本流程可以如圖1所示，在正式RTSP流程以前客戶端2178網頁瀏覽器會向媒體伺服端2167的網頁請求一份呈現描述檔案，並參考到數個連續媒體檔案，而每份連續媒體檔案的參照，都會以URL方法rtsp://開頭。此時瀏覽器會依據訊息中的內容類型呼叫媒體播放程式，緊接著就是RTSP協定流程。
但傳統的RTSP協定與架構要求至少媒體伺服端必須是實體IP，才能進行上述的基本流程，然而如果媒體伺服端是類似網路攝影機這種可移動性的小型媒體伺服，是有機會位在IP分享器(NAT)的底下，也就是媒體伺服可位於虛擬IP位置，當客戶端也位於IP分享器底下時，就會發生雙方的RTSP溝通問題，因互不知道對方的真實IP與埠口位置，甚至媒體封包也未能達到點對點傳輸。
本發明的目的在提出一種改良式RTSP通訊協定，使處於NAT下的媒體伺服與客戶端，能正常交換RTSP訊令，且媒體封包也能順利達到穿越NAT而直接點對點傳輸。
本發明TCP穿越NAT於RTSP上應用包含：一種改良式RTSP通訊協定定分成註冊階段、準備階段、媒體階段、結束階段，包含一第一NAT、一第二NAT、一RTSP代理伺服器與一RTP-Relay，一IE瀏覽器(客戶端)在第一NAT之下，一網路攝影機(媒體伺服端)在第二NAT之下，能達成下述維持攝影機之RTSP通道和執行TCP穿越法：
a.　網路攝影機(媒體伺服端)利用OPTIONS訊令，定期不斷向RTSP代理伺服器註冊發送該訊令，以要求訂位服務，讓IE瀏覽器(客戶端)在訪問RTSP代理伺服器後，能找到媒體伺服正確的位置，此為註冊階段。
b.　在準備階段中，IE瀏覽器(客戶端)發出一SETUP訊息前，向RTSP代理伺服器作多次的偵測程序，以偵知客戶端的NAT(第一NAT)之分配通訊埠的規律變化；
c.　做完多次偵測程序後，依據分配通訊埠的規律變化，預測出第一NAT所將分配的通訊埠號碼，並將第一NAT的真實IP及即將分配給IE瀏覽器(客戶端)傳送影音封包的通訊埠號碼填入SETUP訊息內；
d. SETUP訊息經過第一NAT傳送給RTSP代理伺服器，再經第二NAT傳送給網路攝影機(媒體伺服端)；
e.　網路攝影機(媒體伺服端)接收到SETUP訊息後，向RTSP代理伺服器作多次的偵測程序，以偵知媒體伺服端的NAT(第二NAT)之分配通訊埠的規律變化；
f.　做完多次偵測程序後，依據分配通訊埠的規律變化，預測出第二NAT所將分配的通訊埠號碼，並將第二NAT的真實IP及即將分配給網路攝影機(媒體伺服端)傳送影音封包的通訊埠號碼填入200 OK訊息內；
g.　網路攝影機(媒體伺服端)透過第二NAT傳送200 OK訊息給RTSP代理伺服器，再經第一NAT傳送給IE瀏覽器(客戶端)；
h. IE瀏覽器(客戶端)收到200 OK訊息後，啟動TCP主動連線的API直接連線至第二NAT，此時TCP三方交握的過程會失敗，失敗後客戶端立即關閉該TCP連線，然後再重起TCP等待連線的API；
i.　接著網路攝影機(媒體伺服端)啟動TCP主動連線的API直接連線至第一NAT，此時TCP三方交握有很大的機會能夠成功穿越第一NAT，進而與IE瀏覽器(客戶端)TCP等待連線的API正式建立TCP點對點通道；
j.　緊接著客戶端透過RTSP代理伺服器傳送PLAY訊息給網路攝影機，而網路攝影機也透過RTSP代理伺服器傳送200 OK回應訊息，完成準備階段。到了RTSP媒體階段時就利用上述建立TCP點對點通道，達成點對點的影音傳送。
k.　當上述TCP穿越NAT方法失敗時，採用RTP-Relay的方式。藉由第三方RTSP代理伺服的多台RTP-Relay(RTP中繼站)來協助穿越NAT，但會大量消耗RTSP代理伺服的頻寬，非點對點傳輸，此法只能為備案處理。
 RTSP簡介
許多網際網路多媒體使用者，尤其是喜歡將電視遙控器拿在手中的人們，都會想要控制連續媒體的播放，例如暫停播放、往前或往後跳轉、邊看邊快轉、邊看邊倒轉、諸如此類等。這種功能類似於使用者使用DVD撥放器觀看影片，或是用CD撥放器聆聽音樂CD時，所能使用的功能。為了讓使用者能夠控制播放，媒體播放程式與伺服器之間需要使用某種協定來交換播放控制的訊息。即時串流協定(RTSP)就是這種協定，而封包可分為請求(Request)與回應(Response)兩種。請求是由客戶端(Client)發送至伺服端(Server)之RTSP訊息，並表達客戶端的目的；回應為伺服端發送至客戶端之RTSP訊息，用以回覆客戶端之請求。
RTSP定義了常見六種請求方法，包括SETUP、PLAY、PAUSE、TEARDOWN、OPTIONS與DESCRIBE，如表1所示。
表1　RTSP之常見六種基本請求
RTSP回應訊息為伺服端回覆客戶端請求之訊息，如表2所示。
表2　RTSP回應訊息類別
RTSP通訊協定簡介
請見圖1，傳統的RTSP通訊協定分成準備階段(CallSetup Session)、媒體階段(Media Session)、結束階段(Cancel Session)，並沒有註冊階段(Login Session)，網路攝影機(媒體伺服端)2167也並沒安裝NAT，必須使用的是實體IP。
首先是準備階段，IE瀏覽器(客戶端)2178發出SETUP訊息，至網路攝影機(媒體伺服端)2167，並回應200 OK訊息，回傳到客戶端2178，當客戶端要開始播放媒體時，2178則送出PLAY至網路攝影機2167表示想要播放媒體，隨後回應200 OK告知客戶端2178表示收到訊息。
此後客戶端2178與網路攝影機2167即進入媒體階段，網路攝影機2167直接將影音媒體送達至IE瀏覽器(客戶端)2178手中。
當客戶端2178不想再收看來自網路攝影機2167的影音媒體時，客戶端2178會發送TEARDOWN至網路攝影機2167，隨後回應200 OK告知客戶端2178表示收到訊息，結束媒體階段，此為結束階段。
TCP三方交握基本簡介
請見圖5，當客戶使用TCP欲連線至伺服端時，TCP就會進行三方交握(Three-way Handshaking)。首先伺服器會先啟動API(Application Programming Interface/應用程序介面)中的Start TCP Server，建立「接待socket」(welcome socket)，換句話說伺服器會建立一道開啟的門，等待客戶端連線進來；當客戶端欲連線至伺服端時，客戶端必須啟動API中的Start TCP Client，並把欲連線至伺服器的資訊告訴Start TCP Client，此時客戶端在該API底層便會發起三方交握。
客戶端向伺服器發送一個「SYN」訊息，告訴伺服器「欲連線」，伺服器準備好後，就會回傳一個「SYNACK」訊息，告訴客戶端「準備完畢，可以連線」。客戶端準備好以後，會再向伺服器發送一個「ACK」訊號，告訴伺服器「要開始傳送資料」，與此三方交握完成，一個TCP通道便建立完畢。
由於TCP連線過程是公定的標準流程，所以有相關TCP的API並不會提供任何界面給程序設計者來篡改三方交握的流程或內容，三方交握的一切動作將由底層(作業系統本身)來完成。
改良式RTSP通訊協定之實施例說明
請見圖2，示出本發明在傳統RTSP協定擴充RTSP代理伺服器3與一多台RTP-Relay 4兩種元件。
請見圖3，示出本發明在傳統RTSP三段階段外，並增加註冊階段(Login Session)，客戶端2178與網路攝影機2167，利用利用OPTIONS擴充訊令，定期不斷向RTSP代理伺服器3發送該註冊訊令，以要求訂位服務。而此時RTSP代理伺服器3，雖說主要扮演提供媒體伺服(網路攝影機)2167長時間定位的需求，但客戶端(IE瀏覽器)2178也會有需求，差別在於當客戶端2178不需要隨時隨地需要註冊的程序，只有客戶端2178使用IE瀏覽器欲連線至媒體伺服(網路攝影機)2167時，才會開始定時發送註冊請求至RTSP代理伺服器。
請見圖6，說明TCP穿越NAT於RTSP上應用。客戶端2178與網路攝影機2167，此時都有使用註冊階段，請求定位服務，以便RTSP協定能交換彼此的訊息。
當使用者2178準備播放網路攝影機2167之影音時，會進行預測客戶端裝設的NAT 1的埠口。然後發送SETUP封包至RTSP代理伺服器3，該封包的請求對象是填上使用者2178(自己)，其封包內容開頭將會是SETUP 2178 RTSP/1.0，當RTSP代理伺服器3收到此類請求對象是自己的封包時，便檢查與紀錄該封包的來源IP及埠口號，而此IP便會是客戶端裝設的NAT 1的真實IP位置140.124.40.155，來源埠口號便是客戶端裝設的NAT 1的埠口號。
之後RTSP代理伺服器3會給予寄送該SETUP封包的人(2178)200 OK回應，把剛剛所紀錄到客戶端裝設的NAT 1實體IP及埠口號資訊也將被夾帶至200 OK中，以下為200 OK該封包範例內容：
收到該回應封包的使用者2178，便能得知本次的NAT 1埠口值，緊接著使用者2178會依以上步驟做多次的SETUP自偵測程序，以偵測分配通訊埠的規律變化。
當預測出通訊埠號碼後，並將客戶端裝設的NAT 1的實體IP(140.124.40.155)及將分配給網路攝影機2167傳送媒體封包的通訊埠號碼填入寄送給2167的SETUP之Transport標頭中。
該SETUP訊息經過第一NAT 1傳送給RTSP代理伺服器3，再經第二NAT 2傳送給網路攝影機。待網路攝影機2167接收到訊息後，也會進行與使用者2178相同的SETUP自偵測程序，以偵測網路攝影機端裝設的NAT 2分配通訊埠的規律變化。
當預測出通訊埠號碼後，網路攝影機2167並將NAT 2的實體IP(126.16.64.4)及將分配給使用者2178傳送封包的通訊埠號碼填入寄送給2178的200 OK回應封包中的Transport標頭中。
而該回應封包透過NAT 2傳送訊息給RTSP代理伺服器3，再經NAT 1傳送給客戶端2178。
在之後收到200 OK回應封包的使用者2178，會依照200 OK回應裡的Transport內容，啟動Start TCP Client的API連線至 126.16.64.4 : (NAT 2預測埠口) ，依據三方交握的過程，SYN封包會打到NAT 2預測埠口上，但因為NAT 2內網封包尚未從該埠口出境，所以此三方交握會失敗(得到ICMP封包)，連線失敗的使用者2178，API中的Start TCP Client會回報錯誤訊息，此時使用者2178馬上將這筆連線socket關閉，再關閉socket後又馬上啟動Start TCP Server，此筆與上筆使用相同的本地埠口號，產生「接待socket」。
此時網路攝影機2167，會依照SETUP 2167中的Transport內容，Start TCP Client的API連線至 140.124.40.155 : (NAT 1預測埠口) ，依據三方交握的過程，SYN封包會通過使用者2178端的NAT 1預測埠口，因為上次由2178端發啟的TCP連線SYN封包已經從2178端的NAT 1埠口出境，所以在該NAT的表(Table)上已經留下紀錄，故此網路攝影機2167發啟的TCP連線SYN封包能過穿越，以至到達2178端的「接待socket」，進而順利完成三方交握。
此時一個點對點的TCP通道建立完畢，再經過先前敘述的基本PLAY訓令交換過程，網路攝影機2167的媒體封包便可以使用該通道，達到穿越NAT的效果。
TCP穿越NAT失敗備案之RTP-Relay應用說明
上述方法是首選使用，但有可能會預測或穿透失敗的情形，若穿透失敗的話我們便可採用最後手段，即是RTP-Relay的方法和控制流量來實現。
請見圖4，雙方一樣首先都利用OPTION當作註冊請求，請求定位服務，以便RTSP協定能交換彼此的訊息。當使用者2178準備播放網路攝影機2167之影音時，會發送SETUP封包，使用者2178會在SETUP封包內的Transport標頭中紀錄自己的IP位置(此為虛擬IP)以及待會要接收媒體連線的埠口號，以下為SETUP該封包範例內容：
該SETUP封包經過NAT 1再傳至RTSP代理伺服器3，此時RTSP代理伺服器3會修改SETUP封包內容，將Transport標頭中的描述改用RTP-Relay 4的資訊，以下為修改後的SETUP該封包範例內容：
修改後的SETUP封包遞送位於網路攝影機端的NAT 2、最後到達網路攝影機2167，收到SETUP後給予200 OK的回應，此時200 OK的Transport標頭內容也會被網路攝影機2167填入自己的IP位置(此也是虛擬IP)以及待會要傳送媒體連線的埠口號，以下為200 OK該封包範例內容：
該回應封包經過網路攝影機端的NAT 2再傳至RTSP代理伺服器3，此時RTSP代理伺服器3也會修改該回應封包內容，將Transport標頭中的描述改用RTP-Relay 4的資訊，以下為修改後的200 OK該封包範例內容：
修改後的200 OK回應封包遞送至使用者2178的NAT 1、最後到達使用者2178的位置上。
當使用者2178播放媒體時，會透過RTSP代理伺服器3發送PLAY封包至網路攝影機2167，收到PLAY的網路攝影機2167給予200 OK的回應，收到該回應的使用者2178會依照SETUP過程中的回應封包裡的Transport內容，啟動TCP連線至RTP-Relay 4，也就是連線至202.145.2.1: 1201，此目的是在2178的NAT 1與RTP-Relay 4之間預先建立媒體TCP通道。
當網路攝影機2167開始傳送串流媒體資料時，也會依照準備階段過程中SETUP封包裡的Transport內容，啟動TCP連線至RTP-Relay 4，並將串流媒體資料封包一一送至202.145.2.1:1200，此時RTP-Relay 4就開始將媒體資料送至2178的NAT 1與RTP-Relay 4之間建立的媒體TCP通道中，最後串流媒體資料便可送至使用者2178位置上。
不過若只使用RTP-Relay方法是有缺點的，因為假設其傳播媒體只使用聲音的頻寬約需2Mb/秒，每月所需費用約NT$2萬，若有100萬用戶同時想從媒體伺服下載串流媒體資料，則RTP-Relay的頻寬費用將達NT$200億/月，所以該方法只使用於TCP穿越失敗時的備案，主要還是先使用TCP穿越NAT法。藉由該方法能大幅改善RTP-Relay頻寬使用。
本發明改良式RTSP通訊協定的特色如下：
1.將代理伺服的概念引入傳統RTSP架構中；
2.RTSP代理伺服器提供預測NAT埠口的服務；
3.在不改變TCP協定下，使用NAT穿透法；
4.上述TCP穿越失敗時，使用RTP-Relay機制。
本發明的精神與範圍決定於下面的申請專利範圍，不受限於上述實施例。
1．．．客戶端裝設的NAT
2．．．媒體伺服端裝設的NAT
3．．．RTSP代理伺服器
2178．．．IE瀏覽器(客戶端)
2167．．．網路攝影機(媒體伺服端)
4．．．RTP-Relay
圖1為一傳統RTSP通訊協定的現行網路環境示意圖。
圖2為改良式RTSP通訊協定的架構示意圖。
圖3為改良式RTSP通訊協定中的註冊階段示意圖。
圖4為改良式RTSP之RTP-Relay穿越NAT法說明圖。
圖5為TCP基本三方交握示意圖。
圖6為TCP穿越NAT於RTSP上應用說明圖。
3．．．RTSP代理伺服器
2178．．．IE瀏覽器(客戶端)
2167．．．網路攝影機(媒體伺服端)
1．．．客戶端裝設的NAT
2．．．媒體伺服端裝設的NAT

Claims (2)

  1. 一種改良式RTSP通訊協定定分成註冊階段、準備階段、媒體階段、結束階段，包含一第一NAT、一第二NAT、一RTSP代理伺服器與一RTP-Relay，一IE瀏覽器(客戶端)在第一NAT之下，一網路攝影機(媒體伺服端)在第二NAT之下，能達成下述維持攝影機之RTSP通道和執行TCP穿越法：a.　網路攝影機(媒體伺服端)利用OPTIONS訊令，定期不斷向RTSP代理伺服器註冊發送該訊令，以要求訂位服務，讓IE瀏覽器(客戶端)在訪問RTSP代理伺服器後，能找到媒體伺服正確的位置，此為註冊階段。b.　在準備階段中，IE瀏覽器(客戶端)發出一SETUP訊息前，向RTSP代理伺服器作多次的偵測程序，以偵知客戶端的NAT(第一NAT)之分配通訊埠的規律變化；c.　做完多次偵測程序後，依據分配通訊埠的規律變化，預測出第一NAT所將分配的通訊埠號碼，並將第一NAT的真實IP及即將分配給IE瀏覽器(客戶端)傳送影音封包的通訊埠號碼填入SETUP訊息內；d. SETUP訊息經過第一NAT傳送給RTSP代理伺服器，再經第二NAT傳送給網路攝影機(媒體伺服端)；e.　網路攝影機(媒體伺服端)接收到SETUP訊息後，向RTSP代理伺服器作多次的偵測程序，以偵知媒體伺服端的NAT(第二NAT)之分配通訊埠的規律變化；f.　做完多次偵測程序後，依據分配通訊埠的規律變化，預測出第二NAT所將分配的通訊埠號碼，並將第二NAT的真實IP及即將分配給網路攝影機(媒體伺服端)傳送影音封包的通訊埠號碼填入200 OK訊息內；g.　網路攝影機(媒體伺服端)透過第二NAT傳送200 OK訊息給RTSP代理伺服器，再經第一NAT傳送給客戶端；h. IE瀏覽器(客戶端)收到200 OK訊息後，啟動TCP主動連線的API直接連線至第二NAT，此時TCP三方交握的過程會失敗，失敗後客戶端立即關閉該TCP連線，然後再重起TCP等待連線的API；i.　接著網路攝影機(媒體伺服端)啟動TCP主動連線的API直接連線至第一NAT，此時TCP三方交握有很大的機會能夠成功穿越第一NAT，進而與IE瀏覽器(客戶端)TCP等待連線的API正式建立TCP點對點通道；j.　緊接著客戶端透過RTSP代理伺服器傳送PLAY訊息給網路攝影機，而網路攝影機也透過RTSP代理伺服器傳送200 OK回應訊息，完成準備階段。到了RTSP媒體階段時就利用上述建立TCP點對點通道，達成點對點的影音傳送。
  2. 當上述TCP穿越NAT方法失敗時，採用RTP-Relay的方式。藉由第三方RTSP代理伺服的多台RTP-Relay(RTP中繼站)來協助穿越NAT，但會大量消耗RTSP代理伺服的頻寬，非點對點傳輸，此法只能為備案處理。
TW101115178A 2012-04-27 2012-04-27 Ｔｃｐ穿越ｎａｔ於ｒｔｓｐ上應用 TW201345237A (zh)

Priority Applications (2)

Application Number Priority Date Filing Date Title
TW101115178A TW201345237A (zh) 2012-04-27 2012-04-27 Ｔｃｐ穿越ｎａｔ於ｒｔｓｐ上應用
US13/651,500 US20130290517A1 (en) 2012-04-27 2012-10-15 Nat traversal under tcp for real time streaming protocol

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
TW101115178A TW201345237A (zh) 2012-04-27 2012-04-27 Ｔｃｐ穿越ｎａｔ於ｒｔｓｐ上應用

Publications (1)

Publication Number Publication Date
TW201345237A true TW201345237A (zh) 2013-11-01

Family

ID=49478346

Family Applications (1)

Application Number Title Priority Date Filing Date
TW101115178A TW201345237A (zh) 2012-04-27 2012-04-27 Ｔｃｐ穿越ｎａｔ於ｒｔｓｐ上應用

Country Status (2)

Country Link
US (1) US20130290517A1 (zh)
TW (1) TW201345237A (zh)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
TWI512527B (zh) * 2014-02-13 2015-12-11 Univ Nat Taipei Technology 進階域名系統之雙邊防火牆穿越法

Families Citing this family (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9083587B2 (en) * 2009-08-21 2015-07-14 Cisco Technology, Inc. Port chunk allocation in network address translation
US20160088093A1 (en) * 2014-09-24 2016-03-24 V5 Systems, Inc. Dynamic data management
CN106331195B (zh) * 2015-06-23 2020-01-14 中兴通讯股份有限公司 数据接收、发送方法及装置
CN105978926A (zh) * 2015-12-03 2016-09-28 乐视致新电子科技（天津）有限公司 一种数据传输的方法和装置
US10594785B2 (en) * 2016-03-11 2020-03-17 Intel Corporation Transitioning from an infrastructure based wireless connection to a peer to peer (P2P) wireless connection
CN108924088A (zh) * 2018-05-28 2018-11-30 深圳亿维锐创科技股份有限公司 一种4k网络摄像机传输实现方法
CN114244908A (zh) * 2021-11-05 2022-03-25 浙江蓝卓工业互联网信息技术有限公司 一种跨网域的rtsp流媒体传输方法

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7054949B2 (en) * 2001-01-19 2006-05-30 World Streaming Network, Inc. System and method for streaming media
US20080062997A1 (en) * 2006-09-07 2008-03-13 Go2Call.Com, Inc. Intelligent call routing through distributed VoIP networks
TW201002018A (en) * 2008-06-26 2010-01-01 D Link Corp Method for predicting port number of NAT apparatus based on two STUN server inquiry results
TW201029413A (en) * 2009-01-21 2010-08-01 Univ Nat Taipei Technology NAT traversal method in Session Initial Protocol
JP5357707B2 (ja) * 2009-11-11 2013-12-04 株式会社日立製作所 ゲートウェイ装置およびポート番号割当て方法

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
TWI512527B (zh) * 2014-02-13 2015-12-11 Univ Nat Taipei Technology 進階域名系統之雙邊防火牆穿越法

Also Published As

Publication number Publication date
US20130290517A1 (en) 2013-10-31

Similar Documents

Publication Publication Date Title
TW201345237A (zh) Ｔｃｐ穿越ｎａｔ於ｒｔｓｐ上應用
EP2392122B1 (en) Media streaming through a network address translation (nat) device
JP5064414B2 (ja) Ｉｐマルチメディアサブシステムを基盤とする双方向メディアセッション確立システム、方法、および、装置
US7921150B1 (en) Method for viewing videos on distributed networks
RU2552176C2 (ru) Управление сеансом связи для передачи медиапотока
CN102652421B (zh) 用于内容下载和内容上载的策略
KR102506107B1 (ko) 오디오-비주얼 라이브 콘텐츠 전달을 위한 방법 및 시스템
JP2015534311A (ja) クライアントデバイスにオーディオビジュアルコンテンツを配信するためのシステム及び方法
WO2007098703A1 (fr) Procédé, système et dispositif de ressources multimédia permettant d'obtenir un service de programmation tv basé sur un réseau ngn
WO2012174927A1 (zh) 一种视频监控系统及媒体穿越网络地址转换设备的方法
US20110295943A1 (en) Data processing system and method
US20090150945A1 (en) Method and apparatus for providing video-on-demand service based on internet protocol (ip) multimedia subsystem
EP2396946B1 (en) System and method for transferring a session across domains and subscriptions
WO2010075725A1 (zh) 终端、资讯插播系统及方法
WO2009006820A1 (fr) Procédé et système pour fournir un flux multimédia durant une commutation de serveurs multimédias
KR20110000593A (ko) 멀티캐스트 스트림을 이용하여 주문형 스트리밍 콘텐츠의 제공을 촉진하기 위한 방법 및 장치
TWI813120B (zh) 用於串流資料存取之系統、方法及電腦可讀媒體
Shibeshi et al. An RTSP proxy for implementing the IPTV media function using a streaming server
WO2010001491A1 (en) Local area streaming management method
TWI448184B (zh) 改良式ｓｉｐ通訊協定
CN115665500A (zh) 调度处理方法、装置、设备及存储介质
JP2002152256A (ja) アドレス変換装置及びその方法
Abd-Elrahman et al. Open-IPTV Services and Architectures