原版英文書鏈接(RTP:Audio and video for the internet.pdf)
RTP協議比較簡單，因此從第5章節RTCP開始。
5.1 RTCP的組件
一個RTCP的應用有3個部分: 報文結構、時間規則，和參與者數據庫。
有幾種類型的RTCP報文。5種標準的報文類型會在5.3 RTCP報文格式中描述，並隨後附有報文集成放入複合報文中被髮送。驗證RTCP報文正確性的算法會在報文有限性的章節中描述。
這樣複合的報文會被週期發送，基於規定的準則，這個會在後面章節Timing rules中描述。發送報文的間隔被叫做"報告間隔"。所有的RTCP活動都是在這些報告間隔中發生。除了報文發送間隔外，基於這個時間間隔，接受者的質量統計也會被計算出來，並且更新源描述和音視頻同步之間的時間也需要計算出來。這些時間間隔根據會話大小或場景中的報文格式而變化。
典型的例子，針對小型的會話，間隔時間可以設置成5秒；而那些大型的會話組，可以把時間間隔設置成幾分鐘。
發送者應該特別考慮設定的報告間隔，因爲source description和音視頻同步信息發送比較頻繁。而接受者的報告就沒有那麼頻繁。
每個會話應用都會維護一個數據庫，數據庫的信息來源於接收到的RTCP報文。這個數據庫被用於填寫週期發送的RR接受者報告報文發，也用於接收音頻、視頻的同步和維護source description信息。
參與者數據庫隱私安全部分會在後面的安全與隱私章節描述。
5.2 RTCP報文的傳輸
每個RTP的會話是由一個IP地址和一對UDP port組成:
- 一個爲rtp
- 一個爲rtcp
rtp的數據端口號是偶數，rtcp的端口號爲rtp端口號+1。舉例，如果媒體數據發送到udp port 5004，那麼rtcp就會發送到5005. 所有會話中的參與者都應該發送組合的RTCP報文，相反的，也將接收到其他參與者發送的RTCP組合報文。既然所有的反饋都會在多方會話中被髮送給所有參與者:單播就發送給中轉服務器，它會中轉數據，或者可以直接通過組播。RTCP的點到點性質讓每個會話中的參與者都能得到其他參與者的信息: 是否在線、接收質量、個人信息，比如姓名、email、地址和電話號碼。
5.3 RTCP報文格式
在RTP規範中，定義了5種RTCP報文:
- SR: 發送者報告, type-200
- RR: 接受者報告, type-201
- SDES: source description 源信息報告, type-202
- BYE: 成員管理報告, type-203
- APP: 自定義報告, type-204
- RTP_Feedback: RTCP Transport Layer Feedback Packet, type-205
- PS_Feedback: RTCP Payload Specific Feedback Packet, type-206
RTP fmt:
- RTCP_PLI_FMT(1): picture重傳, type-206
- RTCP_SLI_FMT(2): Slice重傳, type-206
- RTCP_FIR_FMT(4): 關鍵幀重傳, type-206
- RTCP_AFB(15): 帶寬估計, type-206
- RTCP_RTP_FB_NACK_FMT(1): NACK重傳, type-205
圖5.1描述基本的RTCP格式。
5種格式都是4字節爲長度單位，組成部分如下:
- Version number(V). 當前版本爲2，也可以說沒有其他版本在用。
- Padding§. 這個標誌位表示是否補位。如果這個位置1，表示報文最後會有補齊。關於這個的使用注意事項，會在後面的章節詳細描述
- Item count(IC). 除了一些固定的報文信息，一些報文後面會有項目列表。IC就是表示項目列表的數量。
(這個字段對於不同的RTCP類型有不同的含義)。最大支持31個項，當然也受限於網絡單元。如果超過31項要發送，需要分解成多個RTCP來
發送。IC=0以爲項爲空(但是並不以爲報文爲空)。報文的一些類型IC做其他的用途。 - Packet type(PT). PT表示報文類型，5中標準的報文類型已經被定義，更多的報文類型會在未來被協議定義。
- Length. 這個字段表示報文頭後面內容的長度，單位是32bits，也就是4字節。所以如果你用字節來標識長度的話，可定會造成不連續
的問題。0也是合理的值，表示只有頭信息不符(這時頭中的IC字段也肯定是0)
在RTCP頭後面的就是RTCP數據(數據基於具體的RTCP類型)和可選的pad補充字段。多個RTCP頭和數據的合成在一起就是一個RTCP報文，當然只一個RTCP頭和數據也可以。5種標準報文在本章會介紹。RTCP報文很少單獨發送;相反RTCP是一起打包發送。每一個RTCP報文會被UDP/IP封裝發送。如果RTCP報文需要加密,那麼RTCP報文會有前綴。這個RTCP報文的結構會在圖5.2中顯示:
RTCP報文的組合打包發送，具體的組包方式會在本章的"Packing Issues"中描述。下面詳細介紹5中標準的RTCP報文。
5.4 RTCP RR: Receiver Reports
RTCP報文中重要的一項是接收者質量報告，它通過RR報文來完成，由數據接收方發送。
5.4.1 RTCP RR的格式
RR報文的RTCP類型是201，報文格式在圖5.3所示。接收者報文包含了rtp接收者的SSRC，後面跟着0個或多個報告數據，具體個數由RC字段定義
每個RR報文內容都描述了一個時間間隔接收RTP報文的質量情況。每個RR頭後面最大能攜帶31個RR報告塊。如果超過31個報告塊，就要劃分成多個RTCP報文發送。每個RR的報告數據庫有7個字段，共24個字節。(這裏說的RR數據塊是報告發送方SSRC字段後面的數據)
reportee SSRC定義的是接收RR報文方的SSRC。
cumulative number of packets lost(RTP報文丟失數)是24bit大小的整數，是期待接收到的RTP報文個數-實際收到報文個數。期待接收到報文的個數由：RTP中最新的sequence-第一個sequence。實際接收到的報文包括晚到，或重複到的，所以實際接收到的報文個數是有可能比大於期待的理論個數，這個字段有可能是負數。這個字段是基於整個RTP會話過程來計算的，而不是基於RTCP RR發送週期來計算的。這個字段最大的正數是0x7fffff。
loss fraction是在RR報告週期內，用丟失報文個數/期望收到報文個數。這個字段的表示方式是，丟失報文個數/期待報文個數x256。舉例，如果丟失率是1/4，那麼這個字段就是1/4x256=64。如果實際接收的個數大於期待接收的個數(因爲會有重複報文、晚到的報文)，那麼這個字段填寫0。
interarrival jitter是網絡傳輸時間估計值，表示rtp發送方報文發送的網絡時間。該字段用時間戳表示，所以它用32位bits無符號整型表示，同RTP時間戳。
爲了計算網絡傳輸時間的變化，必須測量網絡傳輸時間。因爲RTP發送者和接受者都沒有同步時鐘，所以也不大可能精確計算出絕對的報文發送時間。相反相對的報文發送時間就要通過RTP報文中的時間戳，與接收方本地時間戳來進行計算。計算需要rtp接受者爲每個源都維護一個時間，並且時間用與源都一致的時間頻率。因爲缺少rtp發送者和接受者的時間同步，相對的發送時間就會有未知的變數。但這不是問題，因爲我們就是對發送時間的變化感興趣: rtp接收方收到兩個報文的時間差，對rtp發送方發送兩個報文的時間差。接下來的算法，就是通過兩個未同步的時間進行相減。
如果Si是RTP報文內的時間戳，Ri是服務器接收到RTP報文的時間，那麼相對的傳輸時間就是(Ri-Si)。對於兩個連續的RTP報文i和j，差值就是應該如下表示: D(i,j) = (Rj-Sj) - (Ri-Si)
需要注意的是，Rx和Sx都是無符號32位整型，但是D(i,j)卻是有符號整型。
那麼到達間隔的jitter就是，每次報文到達，都用當前報文和上次到達報文計算出D(i,j)(這兩個報文不一定是sequence連續的)。Jitter就被維護成一個平均值，計算公式如下:
J(i) = J(i-1) + (|D(i-1, i)|-J(i-1))/16;
無論RR報文什麼時候生成，當前最新的J(i)就應該被放入interarrival jitter字段中。
LSR(Last sender report timestamp)，是最近收到發送方的RTCP SR報文中64位時間戳(NTP時間戳)中間的32位(有點變態，爲什麼是中間的32位)，如果沒有SR收到，該字段填寫0.
DLSR(delay since last sender report)，單位是1/65536秒，是接收到最新SR報文和當前發送RR報文的時間差。如果沒有收到SR報文，該字段爲0。
5.4.2 詳解一下RR數據
通過RR進行接收質量不僅對發送者有幫助，也對參與者和第三方管理有好處。通過RR的反饋，發送者可以調整發送速度。此外，其他的參與者能判斷出問題出在本地還是，其他人的質量也如此，並且網絡監控着可以通過RR的和其他RTCP報文得知網絡的狀況。
發送者能通過RR中的LSR和DLSR字段計算出RTT(round-trip time 發送者與接受者之間網絡來回耗時)。發送者接收到RR後，通過當前時間戳減去RR中的LSR字段，就得到發送SR和接收RR之間的時間差。然後，再減去RR中的DLSR，也就是去掉RR發送方內部接收RR和發送SR的時間差，這樣就得到了RTT.
RTT= RTP發送方本地時間 - RR中LSR - RR中DLSR
(注意，這裏的計算需要計算前統一一下時間單位)
具體如圖5.4所示:
注意RTT指的是網絡來回的耗時，不包括髮送、接收兩端的延時。舉例說明，如果接收方爲了播放防止抖動而緩存了數據(具體的緩存、播放等細節在第6章描述)
RTT非常的重要，因爲延時是交互最大的障礙。研究發現，如果總體上RTT大於300ms後會話就很難正常的完成了(當然，這個數字是估計值，也依賴聽衆和對音視頻的處理方法)。發送者可以用RTT去優化編碼–比如，當RTT比較大時，通過減少數據(應該是降低編碼質量)來減少打包延時–或者通過錯誤修復的代碼來完成(詳情見第9章, 糾錯)
丟包百分比能給接受者一個短期丟包率的信息。通過觀測報告數據的趨勢，發送者能判斷當前的丟包是暫時現象，還是長期現象。很多RR的數據字段都是累積值，也就是可以去平均總數據。通過兩個RR數據的不同點，能同時得到短期、長期的質量數據，讓報告數據更具有彈性。
比如說，從兩個間隔RR報文的累積統計字段(cumulative)就能得出報文丟失率，這是能直接得出的。兩個RR報文的累積字段(cumulative)的差值也就表示了間隔時間內的包丟包數，除以間隔時間內最新sequence差值(得到期望收到的包數)，這樣就能得到丟包率。這個算法的結果也等於RR報文中的Loss fraction字段，不過丟包率也只是估計的統計，因爲可能出現負數，原因是有可能出現重複發包。Loss fraction字段的好處是能從單一RR報文得到丟包信息，在大型會話中是非常有用的，因爲會話過程中，RR報文有可能出現丟失。
丟包率能是編碼格式和糾錯編碼方式選擇的基礎(糾錯，在第9章)。高丟包率就要選擇高丟包率的編碼方式，並且如果可能，比特率最好能降低(因爲丟包率都是網絡擁塞造成)
jitter字段也能用作檢測正在發送的擁塞: 一個突增的jitter將會預示着有丟包發生。這個主要依賴網絡拓撲，和流個數，流多路複用的程度，降低多路複用的程度就能減少jitter和將要發生擁塞的關聯性。
發送者應該意識到，jitter字段是通過報文中的時間戳來標識的。如果發送者延遲發送某些報文，那麼也會被記錄到jitter中。關於視頻報文，因爲視頻幀比較大，通常會被分成同一個時間戳的多包來發送，而不是單個打包一次發送。但這並不是個問題，因爲jitter的測量本來就是要告訴接收者應該加入多大的接收buffer(這個接收buffer需要能容忍jitter和包間延遲)
5.5 RTCP SR: Sender Reports
除了接收者報告外，RTCP協議也提供讓音視頻發送方傳輸發送者報告(SR)。SR提供發送音視頻媒體信息，主要爲了接收方能同步多個媒體流(比如說，音視頻同步)
5.5.1 SR格式
發送者報告的包類型是200，格式如圖5.5所示。除常規RTCP頭外，含24個字節，當然24字節後可以跟其他的RR報文，數量有RC字段設置，同RR報文類似。SR和RR一起發送僅僅當發送者同時也是接受者。
NTP時間戳是64位長度，表示SR的發送時刻。它是NTP時間戳格式，是從1900年1月1日到現在的秒數，高32位代表秒數，低32位表示秒的小數部分(這是64位的定點指，定點在32位上)。UNIX時間戳到NTP時間戳，需要加上2,208,988,800秒。
具體計算方式:
struct ntptime
{
unsigned int integer; //1900年以來的秒數
unsigned int fraction;//小數部份，單位是微秒數的4294.967296(=2^32/10^6)倍
};
#define JAN_1970 2208988800
timeval到ntp時間戳的轉換:
ntptime.integar=timeval.tv_sec+JAN_1970;
ntptime.fraction=timeva.tv_usec* 0x100000000/1000000;
RTP的時間戳字段記錄的時刻和NTP的時刻一致，但是單位是RTP報文時間戳單位。這個字段的值同RTP音視頻流中時間戳字段值不一定一樣，因爲RTCP與RTP發送的時間不一定一樣。見圖5.6，顯示SR報文時間戳的例子。SR報文有RTP時間戳，記錄的是SR報文發送的時刻，與發送的RTP報文時間戳是獨立的。
sender’s packet count是某個SSRC從會話開始發送報文的個數。
sender’s octet count是某個SSRC從會話開始發送報文的字節數(不包括RTP頭和pad)
#emsp;如果發送者改變SSRC，sender’s packet count和octet count會被清理(比如發生崩潰)。如果源持續發送很長時間，這兩個字段可能出現翻轉，但是這不是個問題。字段最新值減去上次的值，如果拿結果去模32，結果應該是一個2的32次方內的數字，即使翻轉了也在這個範圍內。這兩個字段能讓接收者計算出發送端的平均數據量。
5.5.1 SR具體含義
通過SR信息，接收方能在一個時間間隔計算出發送方的平均數據量和包量，即使沒有收到具體的數據。平均數據量除以包量，就得到平均包大小。如果嘉定丟包是獨立於包大小，用接收方實際收到的報文個數乘以平均包大小，就能得到平均的吞吐量。
時間戳信息，就拿來產生RTP時鐘與外部時鐘(NTP clock)的關聯。這對音視頻同步有幫助，具體見第7章。
5.6 RTCP SDES: Source Description
這章的知識，在實際中暫時沒有用到，先放一下。
5.7 RTCP BYE: Membership Control
RTCP通過RTCP BYE來提供比較鬆散的成員控制，BYE報文被用來表示成員離開會話。發送BYE報文，意味着有成員離開，或者成員SSRC改變–比如SSRC衝突，需要修改自己的SSRC來繼續通信。BYE報文也是可能在傳送中丟失，一些應用並不產生它；因此接受者必須提供超時機制，在一段時間後沒有收到數據就認爲會話結束，即使沒有收到BYE報文。
BYE的重要性對應用來說是種擴展。它直接表示成員離開RTP會話，但它也能對其他協議成員做關係參考。但是RTCP BYE不終結其他協議的會話。
BYE的報文類型是203，具體格式如圖5.10。RC字段表示有幾個SSRC要離開。RC字段爲0，有效但是沒什麼用。如果收到BYE報文，就知道BYE報文中的SSRC列表中的SSRC都離開會話，不在處理其對應的RTP/RTCP報文。當然，在收到BYE報文後繼續保留在線狀態一段時間，延遲對應數據的處理。
本章後面的成員數據庫會介紹狀態維護的華庭，這和超時機制和RTCP BYE報文有關。
BYT報文也包含了text可選字段，可用來表示離開會話原因描述，可以很方便的在用戶界面上顯示。text字段是可選的，但是程序肯定要接收它(及時不處理它)
5.8 RTCP APP: Application-Defined RTCP Packets
最後介紹的RTCP類型(APP)是可以應用自定義的擴展。報文類型是204，格式如圖5.11。APP報文中packet name是一個4字節的字符串，每個字符都是ASCII碼，區分大小寫。推薦packet name用於標識改應用類型，當然也可以用subtype字段來表示應用類型。報文最後部分是應用自定義。
APP報文用於非標準的RTCP擴展，用作新特性的擴展。目的還是，開發者可以把APP用來嘗試新的特性，並且如果某些新特性被廣泛使用後再註冊成新的報文類型。一些應用開發產生APP報文，程序應該丟棄不認識的APP報文