LearningWebRTC: RTP/RTCP協議

轉自 ：https://xjsxjtu.github.io/2017-06-25/LearningWebRTC-RTP-RTCP/
H264 SVC：從編碼到RTP打包 ： https://xjsxjtu.github.io/2017-06-24/H264-SVC/
參考
總結RTP協議關鍵概念，Header關鍵字段，RTCP常見作用。 對於協議中理解比較模糊的地方，查看WebRTC M59相關實現。

• RTP關鍵概念

  RTP session
  Address+Port確定了一個RTP session,一般RTCP端口號比RTP大1。
  一個session只傳輸一種媒體數據，音頻和視頻應該(SHOULD)在不同的session裏。
  目的（其實不理解…)：
  相比於把音視頻用不同的SSRC在同一個session裏發送的方案，音視頻在不同的session裏，可以”to allow some participants in the conference to receive only one medium if they choose.”
  其他原因可參考RFC3550 section 5.2
  stream(media stream)
  RTP並沒有定義什麼是stream，但是這個概念卻到處都在用，實在煩人。
  我的理解：
  發送攝像頭是一路stream，發送本地視頻文件裏的視頻是一路stream，發送麥克風是一路stream，發送本地mp3文件是一路stream。
  同一種media類型的stream（如：攝像頭和本地視頻文件），在同一個RTP session裏，即共享同一個網絡端口，但兩路stream的SSRC不同。
  遺留問題
  同一種media類型的stream共享網絡端口，需要看WebRTC代碼確認。
  爲什麼WebRTC M59裏，cricket::StreamParams裏有多個SSRC，如primary ssrc，fec ssrc， fec-fr ssrc， sim ssrc？
  RTP Header關鍵字段
  
  rtp_header

• SSRC(Synchronization SouRCe identifier)

作用：在一個session內代表一路media stream，也可以代表視頻stream內的FEC/RTX包。因此，一個participant在一個RTP session內可能有多個SSRC。
誰生成，怎麼生成：當participantA進入房間時，會給自己的每路media stream分配一個SSRC。爲了儘量減少衝突的概率，不應該僅僅使用time作爲隨機數的種子。
衝突了怎麼辦：當已在房間內的participantB發現participantA在使用衝突的SSRC時，ParticipantB會發送RTCP BYE退出房間，然後進入房間並重新分配SSRC。
PT(PayloadType)
作用：告訴接收端如何處理RTP包，即找到正確的解碼器。
SN(Sequence Number)
作用：表示media stream的編碼順序，同時用於接收端QoS的計算。
哪些條件構成獨立的SN空間：每個SSRC下可以有一個獨立的SN空間。
TS(TimeStamp)
作用：表示媒體數據的採集、渲染順序。
單位：音頻TS的單位爲採樣率，視頻TS的單位一般爲90khz。注意這個不是ms或us，。
如何映射成local playout time，將在RTCP裏介紹
遺留問題
一個participant的音頻、視頻在不同session裏，那麼音頻ssrc和視頻ssrc需要保證不衝突嗎？WebRTC如何實現？
音頻和視頻的PT允許用同一個PT嗎？
RTCP
首先，提到何時該發送RTCP包。

其次，RTCP最重要的作用就是接收端把QoS反饋給發送端，這裏主要介紹的就是這個（丟包率，延遲、抖動）。

最後，還需要介紹，如何利用RTCP SR把TS映射成本地時間，這對音視頻同步是至關重要的。

其他作用，包括用SDES發送CNAME，RTCP BYE等，比較簡單，這裏不介紹。

rtcp_packet_directions

由於RTCP在接收端和發送端之間往返，清晰起見，RTP 發送端用Encoder表示，反之爲Decoder。

何時發送RTCP包
目標：RTCP週期性發送。爲了防止RTCP佔用太多帶寬（一般<5%），一種方法是把各種類型的RTCP儘量打成一個UDP包，即compound RTCP；另一種做法是控制RTCP發送頻率，participant越多，RTCP發包間隔越大。
RFC3550: 動態變化，考慮因素有：RTCP帶寬，RTCP包平均大小，session內總人數和總sender人數。
WebRTC M59實現(RTCPSender)
音頻以[2.5 sec, 7.5 sec]均勻分佈的間隔發送
視頻以[0.5 sec, 1.5 sec]均勻分佈的間隔發送，總體帶寬較大時，會適當減小間隔。
QoS：丟包率
WebRTC M59(StreamStatisticianImpl)遵守RFC3550算法: fractionLost = max(0, (expected - received) / expected)
expected: 間隔內最大的SN - 最小SN
received： 間隔內收到的所有包數，包括前一個間隔晚到的包，重傳的包都算。因此，expected 有可能小於received。
QoS：RTT
Encoder如何計算RTT——根據RTCP RR：
WebRTC M59(RTCPReceiver::HandleReportBlock)遵守RFC3550算法： RTT = T - LSR - DLSR
T： 表示Encoder收到RR的NTP時間。
LSR： 爲Encoder上一次發SR的NTP時間，記錄在SR裏，並被Decoder在RR裏發送回來。
DLSR： Decoder收到SR後，發送RR前的延遲。
Decoder如何計算RTT(NACK時需要)
類似，只是LSR記錄在RRTime包裏，DLSR記錄在DLRR包裏。
QoS：Jitter
Jitter表示每個RTP包傳輸時長的抖動，最理想的是用方差計算，但由於是實時計算的，因此RFC3550的計算方法是一個moving average。
WebRTC M59（StreamStatisticianImpl::UpdateJitter)遵守RFC3550算法:
jitter

D(i-1, i)，表示第i、i-1個RTP包傳輸時間的差。由於Encoder/Decoder時鐘不一致，無法準確計算，因此用RTP TS和包到達時間近似表示。
如何把RTP TS映射成NTP時間
根據RTCP SR，把RTP TS映射爲NTP時間（這裏只能映射爲Encoder端的，而非Decoder端），是音視頻同步的基礎。
ts_2_ntp

Tsr, Msr分別表示上一個RTCP SR裏的NTP時間和RTP TS. 一個TS爲M的RTP對應的NTP時間爲T。
參考
RFC3550：RTP: A Transport Protocol for Real-Time Applications
book2004 RTP-Audio and Video for the Internet