課程地址：零聲學院 WebRTC入門與提高 https://ke.qq.com/course/435382?tuin=137bb271

技術支持QQ群：782508536

webrtc時序圖.png

支持原創，轉載必須注明出處，歡迎關注我的微信公眾號blacker（微信ID：blackerteam 或 webrtcorgcn）。

一 前言

RTP/RTCP協議是流媒體通信的基石。RTP協議定義流媒體數據在互聯網上傳輸的數據包格式，而RTCP協議則負責可靠傳輸、流量控制和擁塞控制等服務質量保證。在WebRTC項目中，RTP/RTCP模塊作為傳輸模塊的一部分，負責對發送端采集到的媒體數據進行進行封包，然后交給上層網絡模塊發送；在接收端RTP/RTCP模塊收到上層模塊的數據包后，進行解包操作，最后把負載發送到解碼模塊。因此，RTP/RTCP 模塊在WebRTC通信中發揮非常重要的作用。

本文在深入研究WebRTC源代碼的基礎上，以Video數據的發送和接收為例，力求用簡潔語言描述RTP/RTCP模塊的實現細節，為進一步深入掌握WebRTC打下良好基礎。

二 RTP/RTCP協議概述

RTP協議是Internet上針對流媒體傳輸的基礎協議，該協議詳細說明在互聯網上傳輸音視頻的標準數據包格式。RTP協議本身只保證實時數據的傳輸，RTCP協議則負責流媒體的傳輸質量保證，提供流量控制和擁塞控制等服務。在RTP會話期間，各參與者周期性彼此發送RTCP報文。報文中包含各參與者數據發送和接收等統計信息，參與者可以據此動態控制流媒體傳輸質量。

RFC3550 [1]定義RTP/RTCP協議的基本內容，包括報文格式、傳輸規則等。除此之外，IETF還定義一系列擴展協議，包括RTP協議基于檔次的擴展，和RTCP協議基于報文類型的擴展，等等。詳細內容可參考文獻[2]。

三 WebRTC線程關系和數據流

WebRTC對外提供兩個線程：Signal和Worker，前者負責信令數據的處理和傳輸，后者負責媒體數據的處理和傳輸。在WebRTC內部，有一系列線程各司其職，相互協作完成數據流管線。下面以Video數據的處理流程為例，說明WebRTC內部的線程合作關系。

image

如圖1所示，Capture線程從攝像頭采集原始數據，得到VideoFrame；Capture線程是系統相關的，在Linux系統上可能是調用V4L2接口的線程，而在Mac系統上可能是調用AVFoundation框架的接口。接下來原始數據VideoFrame從Capture線程到達Worker線程，Worker線程起搬運工的作用，沒有對數據做特別處理，而是轉發到Encoder線程。Encoder線程調用具體的編碼器(如VP8, H264)對原始數據VideoFrame進行編碼，編碼后的輸出進一步進行RTP封包形成RTP數據包。然后RTP數據包發送到Pacer線程進行平滑發送，Pacer線程會把RTP數據包推送到Network線程。最終Network線程調用傳輸層系統函數把數據發送到網絡。

在接收端，Network線程從網絡接收字節流，接著Worker線程反序列化為RTP數據包，并在VCM模塊進行組幀操作。Decoder線程對組幀完成的數據幀進行解碼操作，解碼后的原始數據VideoFrame會推送到IncomingVideoStream線程，該線程把VideoStream投放到render進行渲染顯示。至此，一幀視頻數據完成從采集到顯示的完整過程。

在上述過程中，RTP數據包產生在發送端編碼完成后，其編碼輸出被封裝為RTP報文，然后經序列化發送到網絡。在接收端由網絡線程收到網絡數據包后，經過反序列化還原成RTP報文，然后經過解包得到媒體數據負載，供解碼器進行解碼。RTP報文在發送和接收過程中，會執行一系列統計操作，統計結果作為數據源供構造RTCP報文之用。RTP報文構造、發送/接收統計和RTCP報文構造、解析反饋，是接下來分析的重點。

四 RTP報文發送和接收

RTP報文的構造和發送發生在編碼器編碼之后、網絡層發送數據包之前，而接收和解包發生在網絡層接收數據之后、解碼器編碼之前。本節詳細分析這兩部分的內容。

4.1 RTP報文構造和發送

圖2描述發送端編碼之后RTP報文的構造和發送過程，涉及三個線程：Encoder、Pacer和Network，分別負責編碼和構造RTP報文，平滑發送和傳輸層發送。下面詳細描述這三個線程的協同工作過程。

image

圖2 RTP報文構造和發送

Encode線程調用編碼器(比如VP8)對采集到的Raw VideoFrame進行編碼，編碼完成以后，其輸出EncodedImage通過回調到達VideoSendStream::Encoded()函數，進而通過PayloadRouter路由到ModuleRtpRtcpImpl::SendOutgoingData()。接下來，該函數向下調用RtpSender::SendOutgoingData()，進而調用RtpSenderVideo::SendVideo()。該函數對EncodedImage進行打包，然后填充RTP頭部構造RTP報文；如果配置了FEC，則進一步封裝為FEC報文。最后返回RtpSender::SendToNetwork()進行下一步發送。

RtpSender::SendToNetwork()函數把報文存儲到RTPPacketHistory結構中進行緩存。接下來如果開啟PacedSending，則構造Packe發送到PacedSender進行排隊，否則直接發送到網絡層。

Pacer線程周期性從隊列中獲取Packet，然后調用PacedSender::SendPacket()進行發送，接下來經過ModuleRtpRtcpImpl到達RtpSender::TimeToSendPacket()。該函數首先從RtpPacketHistory緩存中拿到Packet的負載，然后調用PrepareAndSendPacket()函數：更新RtpHeader的相關域，統計延遲和數據包，調用SendPacketToNetwork()把報文發送到傳輸模塊。

Network線程則調用傳輸層套接字執行數據發送操作。至此，發送端的RTP構造和發送流程完成。需要注意的是，在RtpSender中進行Rtp發送后，會統計RTP報文相關信息。這些信息作為RTCP構造SR/RR報文的數據來源，因此非常重要。

4.2 RTP報文接收和解析

在接收端，RTP報文的接收和解包操作主要在Worker線程中執行，RTP報文從Network線程拿到后，進入Worker線程，經過解包操作，進入VCM模塊，由Decode線程進行解碼，最終由Render線程進行渲染。下圖3描述RTP報文在Worker線程中的處理流程。

image

圖3 RTP報文接收和解析

RTP數據包經網絡層到達Call對象，根據其SSRC找到對應的VideoReceiveStream，通過調用其DeliverRtp()函數到RtpStreamReceiver::DeliverRtp()。該函數首先解析數據包得到RTP頭部信息，接下來執行三個操作：1.碼率估計；2.繼續發送數據包；3.接收統計。碼率估計模塊使用GCC算法估計碼率，構造REMB報文，交給RtpRtcp模塊發送回發送端。而接收統計則統計RTP接收信息，這些信息作為RTCP RR報文的數據來源。下面重點分析接下來的數據包發送流程。

RtpStreamReceiver::ReceivePacket()首先判斷數據包是否是FEC報文，如果是則調用FecReceiver進行解包，否則直接調用RtpReceiver::IncomingRtpPacket()。該函數分析RTP報文得到通用的RTP頭部描述結構，然后調用RtpReceiverVideo::ParseRtpPacket()進一步得到Video相關信息和負載，接著經過回調返回RtpStreamReceiver對象。該對象把Rtp描述信息和負載發送到VCM模塊，繼續接下來的JitterBuffer緩存和解碼渲染操作。

RTP報文解包過程是封包的逆過程，重要的輸出信息是RTP頭部描述和媒體負載，這些信息是下一步JitterBuffer緩存和解碼的基礎。另外對RTP報文進行統計得到的信息則是RTCP RR報文的數據來源。

五 RTCP報文發送和接收

RTCP協議是RTP協議的控制下可以，負責流媒體的服務質量保證。比較常用的RTCP報文由發送端報告SR和接收端報告RR，分別包含數據發送統計信息和數據接收信息。這些信息對于流媒體質量保證非常重要，比如碼率控制、負載反饋，等等。其他RTCP報文還有諸如SDES、BYE、SDES等，RFC3550對此有詳細定義。

本節重點分析WebRTC內部RTCP報文的構造、發送、接收、解析、反饋等流程。需要再次強調的是，RTCP報文的數據源來自RTP報文發送和接收時的統計信息。在WebRTC內部，RTCP報文的發送采取周期性發送和及時發送相結合的策略：ModuleProcess線程周期性發送RTCP報文；而RtpSender則在每次發送RTP報文之前都判斷是否需要發送RTCP報文；另外在接收端碼率估計模塊構造出REMB報文后，通過設置超時讓ModuleProcess模塊立即發送RTCP報文。

5.1 RTCP報文構造和發送

在發送端，RTCP以周期性發送為基準，輔以RTP報文發送時的及時發送和REMB報文的立即發送。發送過程主要包括Feedback信息獲取、RTCP報文構造、序列化和發送。圖4描述了RTCP報文的構造和發送過程。

image

圖4 RTCP報文構造和發送

ModuleProcess線程周期性調用ModuleRtpRtcpImpl::Process()函數，該函數通過RTCPSender::TimeToSendRtcpReport()函數確定當前是否需要立即發送RTCP報文。若是，則首先從RTPSender::GetDataCounters()獲取RTP發送統計信息，然后調用RTCPSender::SendRTCP()，接著是SendCompoundRTCP()發送RTCP組合報文。關于RTCP組合報文的定義，請參考文獻[1]。

在SendCompoundRTCP()函數中，首先通過PrepareReport()確定將要發送何種類型的RTCP報文。然后針對每一種報文，調用其構造函數(如構造SR報文為BuildSR()函數)，構造好的報文存儲在PacketContainer容器中。最后調用SendPackets()進行發送。

接下來每種RTCP報文都會調用各自的序列化函數，把報文序列化為網絡字節流。最后通過回調到達PacketContainer::OnPacketReady()，最終把字節流發送到傳輸層模塊：即通過TransportAdapter到達BaseChannel，Network線程調用傳輸層套接字API發送數據到網絡。

RTCP報文的構造和發送過程總體不是很復雜，最核心的操作就是獲取數據源、構造報文、序列化和發送。相對來說構造報文和序列化比較繁瑣，基于RFC定義的細節進行。

5.2 RTCP報文接收和解析

接收端的RTCP報文接收和解析過程如圖5所示。

image

圖5 RTCP報文接收和解析

在接收端，RTCP報文的接收流程和RTP一樣，經過網絡接收之后到達Call對象，進而通過SSRC找到VideoReceiveStream，繼而到達RtpStreamReceiver。接下來RTCP報文的解析和反饋操作都在ModuleRtpRtcpImpl::IncomingRtcpPacket()函數中完成。該函數首先調用RTCPReceiver::IncomingRtcpPacket()解析RTCP報文，得到RTCPPacketInformation對象，然后調用 TriggerCallbacksFromRTCPPacket()，觸發注冊在此處的各路觀察者執行回調操作。

RTCPReceiver::IncomingRtcpPacket()使用RTCPParser解析組合報文，針對每一種報文類型，調用對應的處理函數(如處理SDES的HandleSDES函數)，反序列化后拿到報文的描述結構。最后所有報文綜合在一起形成RTCPPacketInformation對象。該對象接下來作為參數調用TriggerCallbacksFromRTCPPacket()函數觸發回調操作，如處理NACK的回調，處理SLI的回調，處理REMB的回調，等等。這些回調在各自模塊控制流媒體數據的編碼、發送、碼率等服務質量保證，這也是RTCP報文最終起作用的地方。

至此，我們分析了RTCP報文發送和接收的整個流程。

六 總結

本文在深入分析WebRTC源代碼的基礎上，結合流程圖描述出RTP/RTCP模塊的實現流程，在關鍵問題上(如RTCP報文的數據來源)進行深入細致的研究。為進一步深入掌握WebRTC的實現原理和細節打下良好基礎。

參考文獻

[1] RFC3550 - RTP: A Transport Protocol for Real-Time Applications
https://www.ietf.org/rfc/rfc3550.txt

[2] 超越RFC3550 － RTP/RTCP協議族分析 : http://www.lxweimin.com/p/e5e21aeb219f