簡介
用一句簡單的話總結:RTSP發起/終結流媒體(應用程式層)、RTP傳輸串流媒體資料 (傳輸層)、RTCP對RTP進行控制,同步(傳輸層)。
之所以以前對這幾個有點分不清,是因為CTC標準裡沒有對RTCP進行要求,因此在標準RTSP的代碼中沒有看到相關的部分。而在私人RTSP的代碼中,有關控制、同步等,是在RTP Header中做擴充定義實現的。
另外,RFC3550可以看作是RFC1889的升級文檔,只看RFC3550即可。 RTP
即時傳輸協議(Real-time Transport Protocol)是用於Internet上針對多媒體資料流的一種傳輸層協議。RTP協議詳細說明了在互連網上傳遞音頻和視頻的標準資料包格式。RTP協議常用於流媒體系統(配合RTCP協議),視頻會議和一鍵通(Push to Talk)系統(配合H.323或SIP),使它成為IP電話產業的技術基礎。RTP協議和RTP控制協議(RTCP)一起使用,而且它是建立在UDP協議上的。
RTP 本身並沒有提供按時發送機制或其它服務品質(QoS)保證,它依賴於低層服務去實現這一過程。 RTP 並不保證傳送或防止無序傳送(這句話是指RTP資料包線上路上傳輸時可能是無序的),也不確定底層網路的可靠性。 RTP 中的序號允許接收方重組發送方的包序列,同時序號也能用於決定適當的包位置,例如:在視頻解碼中,就不需要順序解碼。
RTP 由兩個緊密連結部分組成: RTP ——傳送具有即時屬性的資料;RTP 控制協議(RTCP) ―——監控服務品質並傳送進行中的會話參與者的相關資訊。
RTCP 即時傳輸控制通訊協定(Real-time Transport Control Protocol或RTP Control Protocol或簡寫RTCP)是即時傳輸協議(RTP)的一個姐妹協議。RTCP為RTP媒體流提供通道外(out-of-band)控制。RTCP本身並不傳輸資料,但和RTP一起協作將多媒體資料打包和發送。RTCP定期在流多媒體會話參與者之間傳輸控制資料。RTCP的主要功能是為RTP所提供的服務品質(Quality of Service)提供反饋,音視頻的同步。
RTCP收集相關媒體串連的統計資訊,例如:傳輸位元組數,傳輸分組數,丟失分組數,jitter,單向和雙向網路延遲等等。網路應用程式可以利用RTCP所提供的資訊試圖提高服務品質,比如限制資訊流量或改用壓縮比較小的轉碼器。RTCP本身不提供資料加密或身份認證。SRTCP可以用於此類用途。
SRTP & SRTCP 安全即時傳輸協議(Secure Real-time Transport Protocol或SRTP)是在即時傳輸協議(Real-time Transport Protocol或RTP)基礎上所定義的一個協議,旨在為單播和多播應用程式中的即時傳輸協議的資料提供 加密、訊息認證、完整性保證和重放保護 。它是由David Oran(思科)和Rolf Blom(愛立信)開發的,並最早由IETF於2004年3月作為RFC 3711發布。
由於即時傳輸協議和即時傳輸控制通訊協定(RTP Control Protocol或RTCP)有著緊密的聯絡,安全即時傳輸協議同樣也有一個伴生協議,它被稱為安全即時傳輸控制通訊協定(Secure RTCP或SRTCP);安全即時傳輸控制通訊協定為即時傳輸控制通訊協定提供類似的與安全有關的特性,就像安全即時傳輸協議為即時傳輸協議提供的那些一樣。
使不使用安全即時傳輸協議SRTP或安全即時傳輸控制通訊協定SRTCP是可選的;但即使使用了安全即時傳輸協議SRTP或安全即時傳輸控制通訊協定SRTCP,所有它們提供的特性(如加密和認證)也都是可選的,這些特性可以被獨立地使用或禁用。唯一的例外是在使用安全即時傳輸控制通訊協定SRTCP時,必須要用到其訊息認證特性。
RTSP
即時資料流通訊協定RTSP(Real Time Streaming Protocol)是用來控制聲音或影像的多媒體串流協議,並允許同時多個串流需求控制,傳輸時所用的網路通訊協定並不在其定義的範圍內,伺服器端可以自行選擇使用TCP或UDP來傳送串流內容,它的文法和運作跟HTTP 1.1類似,但並不特彆強調時間同步,所以比較能容忍網路延遲。而前面提到的允許同時多個串流需求控制(Multicast),除了可以降低伺服器端的網路用量,更進而支援多方視訊會議(Video Conference)。 因為與HTTP1.1的運作方式相似,所以Proxy 伺服器《Proxy》的快取功能《Cache》也同樣適用於RTSP,並因RTSP具有重新導向功能,可視實際負載情況來轉換提供服務的伺服器,以避免過大的負載集中於同一伺服器而造成延遲。
RTSP的請求主要有DESCRIBE,SETUP,PLAY,PAUSE,TEARDOWN,OPTIONS等,顧名思義可以知道起對話和控製作用。
RTSP的對話過程中SETUP可以確定RTP/RTCP使用的連接埠,PLAY/PAUSE/TEARDOWN可以開始或者停止RTP的發送,等等
RTSP 和RTP的關係
一、RTP資料協議
RTP資料協議負責對流媒體資料進行封包並實現媒體流的即時傳輸,每一個RTP資料報都由頭部(Header)和負載(Payload)兩個部分組成,其中頭部前12個位元組的含義是固定的,負載可以是音頻或者視頻資料。RTP資料報的頭部格式如圖1所示:
其中比較重要的幾個域及其意義如下: CSRC標誌計數(CC):表示提供源標誌(CSRC)標識的數目。CSRC標識緊跟在RTP固定頭部之後,用來表示RTP資料報的來源,RTP協議允許在同一個會話中存在多個資料來源,它們可以通過RTP混合器合并為一個資料來源。例如,可以產生一個CSRC列表來表示一個電話會議,該會議通過一個RTP混合器將所有講話者的語音資料群組合為一個RTP資料來源。
負載類型(PT, payload type):標明RTP負載的格式,包括所採用的編碼演算法、採樣頻率、承載通道等。例如,類型2表明該RTP資料包中承載的是用ITU G.721演算法編碼的語音資料,採樣頻率為8000Hz,並且採用單聲道。
序號:用來為接收方提供探測資料丟失的方法,但如何處理丟失的資料則是應用程式自己的事情,RTP協議本身並不負責資料的重傳。
時間戳記:記錄了負載中第一個位元組的採樣時間,接收方能夠確定資料的到達是否受到了延遲抖動的影響,但具體如何來補償延遲抖動則是應用程式自己的事情。
從RTP資料報的格式不難看出,它包含了傳輸媒體的類型、格式、序號、時間戳記以及是否有附加資料等資訊,這些都為即時的流媒體傳輸提供了相應的基礎。RTP協議的目的是提供即時資料(如互動音頻和視頻)的端到端傳輸服務,因此在RTP中沒有串連的概念,它可以建立在底層的連線導向或面向非串連的傳輸協議之上;RTP也不依賴於特別的網路地址格式,而僅僅只需要底層傳輸協議支援組幀(Framing)和分段(Segmentation)就足夠了;另外RTP本身還不提供任何可靠性機制,這些都要由傳輸協議或者應用程式自己來保證。在典型的應用場合下,RTP一般是在傳輸協議之上作為應用程式的一部分加以實現的,如圖2所示:
二、RTCP控制協議 RTCP控制協議需要與RTP資料協議一起配合使用,當應用程式啟動一個RTP會話時將同時佔用兩個連接埠,分別供RTP和RTCP使用。RTP本身並不能為按序傳輸資料包提供可靠的保證,也不提供流量控制和擁塞控制,這些都由RTCP來負責完成。通常RTCP會採用與RTP相同的分發機制,向會話中的所有成員周期性地發送控制資訊,應用程式通過接收這些資料,從中擷取會話參與者的相關資料,以及網路狀況、分組丟失機率等反饋資訊,從而能夠對服務品質進行控制或者對網路狀況進行診斷。
RTCP協議的功能是通過不同的RTCP資料報來實現的,主要有如下幾種類型:
SR:發送端報告,所謂發送端是指發出RTP資料報的應用程式或者終端,發送端同時也可以是接收端。
RR:接收端報告,所謂接收端是指僅接收但不發送RTP資料報的應用程式或者終端。
SDES:源描述,主要功能是作為會話成員有關標識資訊的載體,如使用者名稱、郵件地址、電話號碼等,此外還具有向會話成員傳達會話控制資訊的功能。
BYE:通知離開,主要功能是指示某一個或者幾個源不再有效,即通知會話中的其他成員自己將退出會話。
APP:由應用程式自己定義,解決了RTCP的擴充性問題,並且為協議的實現者提供了很大的靈活性。
RTCP資料報攜帶有服務品質監控的必要資訊,能夠對服務品質進行動態調整,並能夠對網路擁塞進行有效控制。由於RTCP資料報採用的是多播方式,因此會話中的所有成員都可以通過RTCP資料報返回的控制資訊,來瞭解其他參與者的當前情況。
在一個典型的應用場合下,發送媒體流的應用程式將周期性地產生髮送端報告SR,該RTCP資料報含有不同媒體流間的同步資訊,以及已經發送的資料報和位元組的計數,接收端根據這些資訊可以估計出實際的資料轉送速率。另一方面,接收端會向所有已知的發送端發送接收端報告RR,該RTCP資料報含有已接收資料報的最大序號、丟失的資料報數目、延時抖動和時間戳記等重要訊息,發送端應用根據這些資訊可以估計出往返時延,並且可以根據資料報丟失機率和時延抖動情況動態調整發送速率,以改善網路擁塞狀況,或者根據網路狀況平滑地調整應用程式的服務品質。
三、RTSP即時資料流通訊協定 作為一個應用程式層協議,RTSP提供了一個可供擴充的架構,它的意義在於使得即時資料流媒體資料的受控和點播變得可能。總的說來,RTSP是一個流媒體表示協議,主要用來控制具有即時特性的資料發送,但它本身並不傳輸資料,而是必須依賴於下層傳輸協議所提供的某些服務。RTSP可以對流媒體提供諸如播放、暫停、快進等操作,它負責定義具體的控制訊息、操作方法、狀態代碼等,此外還描述了與RTP間的互動操作(RFC2326)。
RTSP在制定時較多地參考了HTTP/1.1協議,甚至許多描述與HTTP/1.1完全相同。RTSP之所以特意使用與HTTP/1.1類似的文法和操作,在很大程度上是為了相容現有的Web基礎結構,正因如此,HTTP/1.1的擴充機制大都可以直接引入到RTSP中。
由RTSP控制的媒體流集合可以用表示描述(Presentation Description)來定義,所謂表示是指流媒體伺服器提供給客戶機的一個或者多個媒體流的集合,而表示描述則包含了一個表示中各個媒體流的相關資訊,如資料編碼/解碼演算法、網路地址、媒體流的內容等。
雖然RTSP伺服器同樣也使用標識符來區別每一流串連會話(Session),但RTSP串連並沒有被綁定到傳輸層串連(如TCP等),也就是說在整個RTSP串連期間,RTSP使用者可開啟或者關閉多個對RTSP伺服器的可靠傳輸串連以發出RTSP 請求。此外,RTSP串連也可以基於面向不需連線的傳輸協議(如UDP等)。
RTSP協議目前支援以下操作:
檢索媒體:允許使用者通過HTTP或者其它方法向媒體伺服器提交一個表示描述。如表示是組播的,則表示描述就包含用於該媒體流的組播地址和連接埠號碼;如果表示是單播的,為了安全在表示描述中應該只提供目的地址。
邀請加入:媒體伺服器可以被邀請參加進行中的會議,或者在表示中回放媒體,或者在表示中錄製全部媒體或其子集,非常適合於分布式教學。
添加媒體:通知使用者新加入的可利用媒體流,這對現場講座來講顯得尤其有用。與HTTP/1.1類似,RTSP請求也可以交由代理、通道或者緩衝來進行處理。 RTMP VS TCP&UDP
1, TCP為點對點的協議,這意味著各個客戶需要分開客戶機/伺服器串連,因而無法在網路級實現對多個客戶機的資料廣播。如果有一個資料流必須同時被傳送到多個客戶機,伺服器必須傳送資料流的副本到各個客戶機,TCP能夠根據網路頻寬和擁擠程度動態地調節傳送速度並重新發送丟失的資料包,這樣雖然保證了資料轉送的可靠性,但是對伺服器資源耗費較大,在資料流大的場合難以保證資料流傳輸的即時性。
2, UDP為不可靠傳輸協議,在發送端,UDP傳送資料的速度僅僅是受應用程式產生資料的速度,電腦的能力和傳輸頻寬的限制;在接收端,UDP把每個訊息段放在隊列中,應用程式每次從隊列中讀一個訊息段。
UDP協議不需要維護串連狀態,也不認為每個資料包都必須到達接受端,因此網路負荷比TCP小,傳輸速度也要比TCP快;但在網路越擁擠時,越有更多的資料包丟失。
3, RTMP協議(Real Time Messaging Protocol,即時訊息傳送協議)是一個專門為高效傳輸視頻,音頻和資料而設計的協議。它通過建立一個二進位TCP串連或者串連HTTP隧道實現即時的視頻和聲音傳輸。
共用對象是RTMP資料中一種比較重要的資料類型,任何用戶端改變資料時,共用對象能夠及時補救伺服器端的資料,這樣,每個用戶端都能夠及時瞭解到資料的變化。
RTMP比傳統媒介伺服器流出的媒介協議支援更多。它支援可能包含聲音,影像和指令碼資料從伺服器到客戶和從客戶到伺服器多條線路的動態傳輸。RTMP對聲音、影像和指令碼資料分別處理。
聲音和視頻資料被分開地緩衝在伺服器中。如果聲音資料在聲音緩衝器中達到某一極限,所有在緩衝器中的資料將被丟掉,並且最近到達的資料被允許開始收集在緩衝中並被送到各個客戶。視頻資料被以相似的方式處理,不同是當新的主要畫面格到達時,緩衝器中資料才被清除。在丟掉舊的幀資料時,如果發現用戶端的資料有誤,則將新舊兩個不同的幀進行擬合。
RTMP對資料給予不同的優先順序別。在即時交談中,聲音是最重要的,影像給予低優先順序,而指令碼資料被給予的優先權介於聲音和影像中間。
RTMP協議可以建立多個資料流,但是每個資料流只能有一個方向。
使用RTMP可以構建這樣的一個系統,用戶端可以同時與RTMP伺服器和應用伺服器進行互動,使得服務端的負荷得以分散,雖然在這種改進的系統結構中,RTMP伺服器的效能要求比較高。
RTMP:Real Time Messaging Protocol(即時訊息傳送協議)
RTMP(the Real-time Messaging Protocol)協議作為用戶端和伺服器端的傳輸協議,這是一個專門為高效傳輸視頻、音頻和資料而設計的 TCP/IP 協議,使用 RTMP 協議傳輸的資料是未經加密的,包括使用者名稱和密碼等認證資訊。
類別:Adobe
RTP:Real-Time Transport protocol(即時傳輸協議)
即時傳輸協議(RTP)為資料提供了具有即時特徵的端對端傳送服務,如在組播或單播網路服務下的互動式視頻音頻或類比資料。應用程式通常在 UDP 上運行 RTP 以便使用其多路結點和校正服務;這兩種協議都提供了傳輸層協議的功能。但是 RTP 可以與其它適合的底層網路或傳輸協議一起使用。
類別:IETF
來源:RFC 3550
http://blog.csdn.net/frankiewang008/article/details/7665547