iT邦幫忙

2019 iT 邦幫忙鐵人賽

DAY 12
2
Software Development

30天之即時網路影音開發攻略(小白本)系列 第 12

30-12之 RTP/RTCP 傳輸協議

黑色好看版 - 傳送門


https://ithelp.ithome.com.tw/upload/images/20181027/20089358g2vH5LnW2k.png

正文開始

在前一篇學習完了 TCP 與 UDP 協議以後,咱們要介紹另一個傳輸層協議:

RTP 協議 (RTCP 後來會提到)

本篇文章將會分成幾個章節來理解 RTP 協議:

  • RTP 協議是要用來完成什麼事情呢 ?
  • RTP 協議如何完成它想做的事情呢 ?
  • RTP 協議的基本概念與封包組成。
  • RTP 要如何進行 Qos 的保證呢 ?

RTP 協議是要用來完成什麼事情呢 ?


RTP 協議想可以完成『 端點到端點的串流媒體傳輸 』 (ex. 聲音、影像)

它目前廣泛的使用於流通訊領域,例如 VOIP、網路會議,網路電視等。

這裡問個問題,為什麼 RTP 是傳輸層的呢 ?

因為它只是專門用來傳輸串流媒體的協議,而不管實際如何應用。你列出幾個傳輸層應用想完成的事情,大概就可以理解為啥它是傳輸層的。

傳輸層
UDP:傳輸資料
TCP:可靠的傳輸資料
RTP:傳輸多媒體資料

應用層
HTTP:HTTP server 與客戶端的表準應答

RTP 協議如何完成它想做的事情呢 ?


它定義了要傳輸串流媒體的參數標準 (封包標準)

RTP 協議它定議好了多媒體傳輸的參數標準,咱們來思考一下,如果直接使用 UDP 或 TCP 來傳送媒體資料會發生什麼事情。

先以簡單的 UDP 為例子,它的封包大約會長的如下:

標頭
來源端 port: 5555
目的端 port: 7777 

標身
一堆聲音的二進位編碼

這樣的話我要如何知道這個聲音編碼要用什麼解碼器來解 ?

那這時有人就說,那不就在標頭多加一個編碼類型就好了麻 ? 嗯對沒錯,說實話就是這樣,但這就已經不能算是 UDP 標準了,因為你多了一個標頭欄位,而且這不是所有類型傳輸都需要,例如我只是要傳普通的資料。

因此後來就產生了 RTP 協議。

那為什麼它可以處理串流傳輸呢 ?

前面的文章中有提到,所謂的串流傳輸就是將聲音一段一段的傳,然後一邊傳就可以一邊聽。

然後在筆者這篇文章『30-09之別人要如何聽到我的聲音呢 ?』中有提到,要進行串流傳輸,要執行的流程如下:

採集 -> 編碼 -> 轉換成流容器 -> 網路 -> 聽眾可以邊下載邊聽

而剛剛上面有說到,它是直接傳輸聲音編碼的,那它為何不用轉成流容容呢 ?

答案是 RTP 本身就算是一種流容器,不過它有個前提,那就是編碼為無損編碼,因為這樣代表每次傳進來的聲音都可以直接解碼,而如果是有損的就無法,因為會依賴前後的資料。

RTP 協議的基本概念與封包組成


RTP 的基本概念

RTP 基本上可以選擇 UDP 或 TCP 來進行傳輸,但奇怪這它們三個不是都是在傳輸層嗎 ?

嗯對的,但只是因為他們處理的層級是相同的,不代表不能一起使用。

基本上你可以將它的封包想成:

RTP 表頭 + UDP/TCP 表頭 + 表身(就是資料)

這也代表在使用 RTP 時你有兩種選擇:

  • RTP over UDP:這樣類型的多媒體傳輸效能較優,但品質比較不優。 ( 但如果是在專線上,就不一定了 )
  • RTP over TCP:這樣類型的多媒體傳輸效能差,但品質較優。

不過現階段 RTP 大部份都還是使用 UDP。

RTP 的封包組成

咱們來簡單的看一下它定義好的封包表頭結構。

bit field describe
2 V (Version) 用來說明使用的 RTP 版本 (default 為 2)。
1 P (Padding) 為 1 的話,就會在最後面的 payload 後面加填充位置。
1 X (Extenstion) 為 1 的話,就代表存在 header 的擴展。
4 CC (CSRC count) 用來記錄 CSRC 的數量。(csrc 後面會說)。
1 M (Marker) 配置文件定義。
7 PT (payload type) 就是說明你要傳輸的語音視頻的編碼是啥 (ex. H.264, PCM)。
16 Sequence Number 每發送一個封包就 + 1 ,接受端可以用它來判斷封包順序。
32 Timestamp 時間戳,用來記錄採樣第一個 bit 資料(音視頻)的時間。
32 SSRC (Synchronization source) 記錄封包的發送方,它只是隨機的從 md5 隨機演算法中選取,然後在同一個視頻會議中,不會有相同的 ssrc 值。
(0~15) X 32 CSRC (Contributing source) 記錄這所有參於方的來源之 ssrc。

其中有兩個比較重要的我們拉出來說明一下。

首先是 SSRC 它的中文為同步來源,而其中來源就是建立這個媒體的來源,例如麥克風、攝影機等,然後就算是同一個 IP 位置,但是不同的兩個麥克風說話,還是會有不同的 SSRC 值。

然後另一個為 CSRC,它裡面存放了組成這個 RTP 流的所有同步來源,也就是說這個 RTP 可以是有多個麥克風或攝影機所共同組成的一個 RTP,然後 CSRC 就是存放所有這些來源的 SSRC。

事實上概念上就如下圖:

https://ithelp.ithome.com.tw/upload/images/20181027/20089358u4AJuWTKK8.png

RTP 要如何進行 Qos (Quality of Service 服務品質) 的保證呢 ?


使用 RTCP 協議 ( 它是 RTP 的姐妹協議 )

RTP 是用來傳送串流媒體的東西,但它並且沒提供Qos (Quality of Service)也就是服務品質,也就是傳 RTP 它不保證這個串流中間有沒有掉封包或是有沒有傳送到,它只負責丟就對了。

而 RTCP 就是專門用來處理服務品質這件事情,它會在來源端與目的端定時的交換統計資訊,例如送出封包數與遺失封包數,並且根據這些數字,那改善 RTP 的傳輸率之類的事情,使得 RTP 傳輸更有品質。

接下來咱們來看看它的封包結構。

bit field describe
2 Version RTP 的版本號,預設為 2 。
3 P (padding) 在最後的位置增加空間,大部份都是給加密使用的地方。
8 RC 接受方報告的數量。
16 Packet Type 用來判斷這個封包是那一種 RTCP 類型。

上面的表頭中,我們有看到每個 packet 都有分類型,然後下面是類型種類。

code type describe
200 SR(Sender Report) 發送方的報告
201 RR(Receiver Roport) 接受方的報告
202 SDES(Source Descripition Items) 來源端
203 BYE 結束
204 APP(Application) 特定應用

接受方每收到一次 RTP 封包時,就產生一次接受方的報告 RR。(內容為 RTP 流的 SSRC、丟失率)

發送端每發送一次 RTP 封包時,就會發送一次 SR。用來給接受方知道發送端的資訊。

SEDS 會給出會議的參於者的描述,它包含了參於者的CNAME(Canonical NAME),CNAME 被稱規範名稱,也就給一台機器設定別名的概念,用戶使用別名就可以找到你,然後一台機器可以設定多個別名。

結論


本篇文章中咱們學習到了以下幾個重點:

RTP 協議是要用來完成什麼事情呢 ?

RTP 協議想可以完成『 端點到端點的串流媒體傳輸 』 (ex. 聲音、影像)

RTP 協議如何完成它想做的事情呢 ?

它定義好了要傳輸封包的參數標準。

BTW RTP 本身可以算是個流容器。

RTP 協議的基本概念與封包組成

RTP 本身是基於 TCP 與 UDP 來進行傳輸,其它它的封包裡面的參數大部份是在描述這個媒體流的相關資訊,例如從那裡來,編碼又是啥之類的。

RTP 要如何進行 Qos 的保證呢 ?

使用 RTCP 協議,它會在來源端與目的端定時的發送 RTCP 封包,內容包含傳輸品質資訊,然後在依據這些資訊來優化 RTP 傳輸。

參考資料



上一篇
30-11之 TCP 與 UDP 協議
下一篇
30-13之 RTSP 傳輸協議
系列文
30天之即時網路影音開發攻略(小白本)30

尚未有邦友留言

立即登入留言