要實現基于WebRTC的實時音視頻通信功能，應至少首先弄清以下以個相關概念，各關鍵字可以通過RFC相關介紹進一步詳細了解，在此僅以最簡單的描術方式讓您弄清他們大概是什么：

• 候選地址（Candidates）:?
  一個候選地址可理解為一組IP+端口號+優先級+網絡類型組成的字符串。每個終端因網絡環境不同可能有多個候選地址，比如我們的手機同時具有4G網絡地址和wifi給分配的局域網地址。

• NAT:?
  可理解為一個防火墻或一個網關或路由器。比如我們的手機在使用wifi的情況下，我們的IP地址一般是192.168.0.1這種局域網地址，這時我們可以說我們在手機端在NAT后面，不是直接擁有公網地址。

• STUN服務器：?
  一個位于公網的具有公網IP的服務器，我們位于NAT后面（局域網內）的終端可通過訪問STUN服務器來獲取我們所有的候選地址。其實就是我在局域網內，我不知道自己的IP地址，不知道自己的公網IP地址也不知道自己的網絡類型，這時我可以問STUN服務器，當我向其發消息時，身處公網的STUN服務器會將其收集到的我的網絡信息發送給我。STUN服務器可以在github上找到并在某個公網機器上搭建一個，也可以使用已知的公用的一些STUN服務器，網上可以搜到很多。

• TURN服務器：?
  這個目前可以先忽略，主要是用來應急用的。當兩個想建立連接進行音視頻通信的網絡環境都很復雜，都處于NAT后面且雙方始終無法建立連接時，可通過連接到TURN服務器的方式，用其幫忙轉發音視頻流。因TURN服務器身處公網，所以大家都可以連接上它。

• SDP：?
  是一個媒體信息描述文件，用于描述自身的能力，比如我的瀏覽器想做為一個終端與另一端進行音視頻通信，我應該告訴對方我是否支持音頻或視頻通信，以及我所支持的編解碼格式，我是否支持丟包重傳，FEC校驗等等。?
  另外，也可以把candidates（候選地址）添加到SDP中，一并告訴對方可以連接到我的地址是哪幾個。

• OFFER：?
  由通話發起端發出的SDP叫做OFFER

• ANSWER：?
  由通話接受端發出的對應對方OFFER的應答SDP文件叫做ANSWER。是SDP文件在通話發起方和接受方的不同名稱。

• 信令服務器（SIP）：?
  是實現WEBRTC通信很重要的一個部件，主要負責交換2個終端的候選地址（Candidates）和媒體信息描述文件（SDP）。?
  當2個終端都在NAT后面時，雙方都不知道對方的地址也無法連接到對方，而且雙方也不知道對方所支持的媒體類型以及是否支持某些特定的網絡協議。因為需要一個身處公網的服務器（信令服務器）來為雙方交換這些信息。?
  信令服務器也可以起到房間管理的作用。可以在整個通信過程中與雙方客戶端始終保持長連接來通知雙方房間狀態，比如有人離開，會議結束等等。?
  信令服務器僅用于發送一些命令及轉發一些連接用的信息和媒體信息，不能用作TURN服務器，TURN服務器是用于在雙方無法建立連接的時候代為轉發音視頻流數據包的。不是必需的，而信令服務器是必需的。

• JitterBuffer:?
  是webrtc源碼中用于緩存接收到的視頻流數據包的一個動態BUFFER，因為網絡狀態是不穩定的，而且音視頻數據包是以UDP的方式發送的，在網絡中傳輸時，無法保證按順序到達。而為了保證視頻流輸出流暢，需要在播放端對視頻流數據包進行重排序，只要對包進行重排序就需要進行緩存，而緩存長度過大會導致遲延增大，過小會導致丟幀。JitterBuffer是一個可依網絡動態變化而變化的BUFFER，會自動伸縮長度。對于視頻質量的提高有很大作用。但應注意webrtc中的jitterBuffer吐出的數據是以幀為單位的，目前主要用于接收端。?
  另外，對于H264編碼減少B幀的使用對于提高實時性也有一定幫助，因為B幀是中間過度幀，其需要參考前后2個幀才能計算出自身幀數據。因此會等待后面的幀，可能會造成一定延遲。

• NetEQ:?
  類似于JitterBuffer的功能，是作用于音頻的在播放端的一個動態buffer,對于提高音頻通話質量，減少延遲具有很大作用。但需注意它吐出的數據是以10ms固定間隔的。此外NetEq還具有其他一些功能比如加減速丟包隱藏等，來彌補網絡差時的情況。

• 發送者報告（SenderReport）:?
  一般稱為SR消息，在任何一端作為數據發送端時，都應該實時以固定間隔（如200ms）發送SR消息給數據接收端。用于報告自己已經發送了多少數據包等信息。

• 接收者報告（ReveriverReport）:?
  也叫RR消息，在任何一端作為接收端時，當接收數據流的同時應該以固定時間間隔，如500ms發送一個描述自己接收情況的信息給對方，主要包含接收了多少數據包，在接收過程中丟失了多少數據包，上一次接收到的SR消息是誰（可以通過某規則為接收到的每一個SR消息進行標識，雙方需要一致）等等。

• 發送者和接收者報告消息非常重要，很多網絡信息需要通過他們獲得或根據他們的到達時間來計算出來。這些信息會用于JitterBuffer,NACK，帶寬估計等模塊。

• NACK（丟包重傳）：?
  在TCP連接中，我們是通過發送一個包，接收到對方的ACK（確認消息）消息來確認對方正確收到了我們發出的包，繼而發送下一個數據包的。但在UDP連接中，我們是不會等待對方反饋的。但對方可以在確定某包丟失未收到的情況下，向發送端發送一個NACK消息來告知發送端某個包或某幾個包未收到。希望對方重傳。

• SSRC （源標識符）?
  比如一個音頻流或一個視頻流我們可以稱為一個發送源，每個源都有一個唯一的標識，叫SSRC，比如一個客戶端可以同時接收多路視頻流，則也就有了多個SSRC，在一個鏈路通道中，我們是使用SSRC來區分每一個數據包是屬于哪個視頻源的。進而將此數據包解碼后渲染在正確的窗口。

• PacedSender (步長發送器)?
  因為視頻是按幀采集的，一幀視頻數據量在比較大的時候需要拆分成多個RTP包進行發送，如I幀，如此便 會造成各RTP包的發送間隔不規律，屬于一幀的各RTP包可能在很短暫的時間間隔內發送出去了，如1ms內，然后等待了幾十ms之后才開始發送第二幀的第一個RTP包，這樣各RTP的發送間隔不規律會造成瞬間的發送碼率過大，可能會因此丟包等。加入一個PacedSender可盡量平均各RTP包（幀內或幀間）的發送間隔時間。?
  —-未完待續

超強干貨來襲 云風專訪：近40年碼齡，通宵達旦的技術人生

總結

以上是生活随笔為你收集整理的WebRtc音视频实时通信--基本术语的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。