要實(shí)現(xiàn)基于WebRTC的實(shí)時(shí)音視頻通信功能，應(yīng)至少首先弄清以下以個(gè)相關(guān)概念，各關(guān)鍵字可以通過(guò)RFC相關(guān)介紹進(jìn)一步詳細(xì)了解，在此僅以最簡(jiǎn)單的描術(shù)方式讓您弄清他們大概是什么：

• 候選地址（Candidates）:?
  一個(gè)候選地址可理解為一組IP+端口號(hào)+優(yōu)先級(jí)+網(wǎng)絡(luò)類型組成的字符串。每個(gè)終端因網(wǎng)絡(luò)環(huán)境不同可能有多個(gè)候選地址，比如我們的手機(jī)同時(shí)具有4G網(wǎng)絡(luò)地址和wifi給分配的局域網(wǎng)地址。

• NAT:?
  可理解為一個(gè)防火墻或一個(gè)網(wǎng)關(guān)或路由器。比如我們的手機(jī)在使用wifi的情況下，我們的IP地址一般是192.168.0.1這種局域網(wǎng)地址，這時(shí)我們可以說(shuō)我們?cè)谑謾C(jī)端在NAT后面，不是直接擁有公網(wǎng)地址。

• STUN服務(wù)器：?
  一個(gè)位于公網(wǎng)的具有公網(wǎng)IP的服務(wù)器，我們位于NAT后面（局域網(wǎng)內(nèi)）的終端可通過(guò)訪問(wèn)STUN服務(wù)器來(lái)獲取我們所有的候選地址。其實(shí)就是我在局域網(wǎng)內(nèi)，我不知道自己的IP地址，不知道自己的公網(wǎng)IP地址也不知道自己的網(wǎng)絡(luò)類型，這時(shí)我可以問(wèn)STUN服務(wù)器，當(dāng)我向其發(fā)消息時(shí)，身處公網(wǎng)的STUN服務(wù)器會(huì)將其收集到的我的網(wǎng)絡(luò)信息發(fā)送給我。STUN服務(wù)器可以在github上找到并在某個(gè)公網(wǎng)機(jī)器上搭建一個(gè)，也可以使用已知的公用的一些STUN服務(wù)器，網(wǎng)上可以搜到很多。

• TURN服務(wù)器：?
  這個(gè)目前可以先忽略，主要是用來(lái)應(yīng)急用的。當(dāng)兩個(gè)想建立連接進(jìn)行音視頻通信的網(wǎng)絡(luò)環(huán)境都很復(fù)雜，都處于NAT后面且雙方始終無(wú)法建立連接時(shí)，可通過(guò)連接到TURN服務(wù)器的方式，用其幫忙轉(zhuǎn)發(fā)音視頻流。因TURN服務(wù)器身處公網(wǎng)，所以大家都可以連接上它。

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

• OFFER：?
  由通話發(fā)起端發(fā)出的SDP叫做OFFER

• ANSWER：?
  由通話接受端發(fā)出的對(duì)應(yīng)對(duì)方OFFER的應(yīng)答SDP文件叫做ANSWER。是SDP文件在通話發(fā)起方和接受方的不同名稱。

• 信令服務(wù)器（SIP）：?
  是實(shí)現(xiàn)WEBRTC通信很重要的一個(gè)部件，主要負(fù)責(zé)交換2個(gè)終端的候選地址（Candidates）和媒體信息描述文件（SDP）。?
  當(dāng)2個(gè)終端都在NAT后面時(shí)，雙方都不知道對(duì)方的地址也無(wú)法連接到對(duì)方，而且雙方也不知道對(duì)方所支持的媒體類型以及是否支持某些特定的網(wǎng)絡(luò)協(xié)議。因?yàn)樾枰粋€(gè)身處公網(wǎng)的服務(wù)器（信令服務(wù)器）來(lái)為雙方交換這些信息。?
  信令服務(wù)器也可以起到房間管理的作用?？梢栽谡麄€(gè)通信過(guò)程中與雙方客戶端始終保持長(zhǎng)連接來(lái)通知雙方房間狀態(tài)，比如有人離開(kāi)，會(huì)議結(jié)束等等。?
  信令服務(wù)器僅用于發(fā)送一些命令及轉(zhuǎn)發(fā)一些連接用的信息和媒體信息，不能用作TURN服務(wù)器，TURN服務(wù)器是用于在雙方無(wú)法建立連接的時(shí)候代為轉(zhuǎn)發(fā)音視頻流數(shù)據(jù)包的。不是必需的，而信令服務(wù)器是必需的。

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

• NetEQ:?
  類似于JitterBuffer的功能，是作用于音頻的在播放端的一個(gè)動(dòng)態(tài)buffer,對(duì)于提高音頻通話質(zhì)量，減少延遲具有很大作用。但需注意它吐出的數(shù)據(jù)是以10ms固定間隔的。此外NetEq還具有其他一些功能比如加減速丟包隱藏等，來(lái)彌補(bǔ)網(wǎng)絡(luò)差時(shí)的情況。

• 發(fā)送者報(bào)告（SenderReport）:?
  一般稱為SR消息，在任何一端作為數(shù)據(jù)發(fā)送端時(shí)，都應(yīng)該實(shí)時(shí)以固定間隔（如200ms）發(fā)送SR消息給數(shù)據(jù)接收端。用于報(bào)告自己已經(jīng)發(fā)送了多少數(shù)據(jù)包等信息。

• 接收者報(bào)告（ReveriverReport）:?
  也叫RR消息，在任何一端作為接收端時(shí)，當(dāng)接收數(shù)據(jù)流的同時(shí)應(yīng)該以固定時(shí)間間隔，如500ms發(fā)送一個(gè)描述自己接收情況的信息給對(duì)方，主要包含接收了多少數(shù)據(jù)包，在接收過(guò)程中丟失了多少數(shù)據(jù)包，上一次接收到的SR消息是誰(shuí)（可以通過(guò)某規(guī)則為接收到的每一個(gè)SR消息進(jìn)行標(biāo)識(shí)，雙方需要一致）等等。

• 發(fā)送者和接收者報(bào)告消息非常重要，很多網(wǎng)絡(luò)信息需要通過(guò)他們獲得或根據(jù)他們的到達(dá)時(shí)間來(lái)計(jì)算出來(lái)。這些信息會(huì)用于JitterBuffer,NACK，帶寬估計(jì)等模塊。

• NACK（丟包重傳）：?
  在TCP連接中，我們是通過(guò)發(fā)送一個(gè)包，接收到對(duì)方的ACK（確認(rèn)消息）消息來(lái)確認(rèn)對(duì)方正確收到了我們發(fā)出的包，繼而發(fā)送下一個(gè)數(shù)據(jù)包的。但在UDP連接中，我們是不會(huì)等待對(duì)方反饋的。但對(duì)方可以在確定某包丟失未收到的情況下，向發(fā)送端發(fā)送一個(gè)NACK消息來(lái)告知發(fā)送端某個(gè)包或某幾個(gè)包未收到。希望對(duì)方重傳。

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

• PacedSender (步長(zhǎng)發(fā)送器)?
  因?yàn)橐曨l是按幀采集的，一幀視頻數(shù)據(jù)量在比較大的時(shí)候需要拆分成多個(gè)RTP包進(jìn)行發(fā)送，如I幀，如此便 會(huì)造成各RTP包的發(fā)送間隔不規(guī)律，屬于一幀的各RTP包可能在很短暫的時(shí)間間隔內(nèi)發(fā)送出去了，如1ms內(nèi)，然后等待了幾十ms之后才開(kāi)始發(fā)送第二幀的第一個(gè)RTP包，這樣各RTP的發(fā)送間隔不規(guī)律會(huì)造成瞬間的發(fā)送碼率過(guò)大，可能會(huì)因此丟包等。加入一個(gè)PacedSender可盡量平均各RTP包（幀內(nèi)或幀間）的發(fā)送間隔時(shí)間。?
  —-未完待續(xù)

超強(qiáng)干貨來(lái)襲 云風(fēng)專訪：近40年碼齡，通宵達(dá)旦的技術(shù)人生

總結(jié)

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

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。