實(shí)時音視頻入門學(xué)習(xí):開源工程WebRTC的技術(shù)原理和使用淺析
Posted on 2022-01-10 16:19 Jack Jiang 閱讀(221) 評論(0) 編輯 收藏本文由ELab技術(shù)團(tuán)隊分享,原題“淺談WebRTC技術(shù)原理與應(yīng)用”,有修訂和改動。
1、基本介紹
WebRTC(全稱 Web Real-Time Communication),即網(wǎng)頁即時通信。 是一個支持網(wǎng)頁瀏覽器進(jìn)行實(shí)時語音對話或視頻對話的技術(shù)方案。從前端技術(shù)開發(fā)的視角來看,是一組可調(diào)用的API標(biāo)準(zhǔn)。

在WebRTC發(fā)布之前,開發(fā)實(shí)時音視頻交互應(yīng)用的成本是非常昂貴,需要考慮的技術(shù)問題很多,如音視頻的編解碼問題,數(shù)據(jù)傳輸問題,延時、丟包、抖動、回音的處理和消除等,如果要兼容瀏覽器端的實(shí)時音視頻通信,還需要額外安裝插件。
2010年5月:Google以6820萬美元收購VoIP軟件開發(fā)商Global IP Solutions的GIPS引擎,并改為名為“WebRTC”(見《了不起的WebRTC:生態(tài)日趨完善,或?qū)?shí)時音視頻技術(shù)白菜化》)。旨在建立一個互聯(lián)網(wǎng)瀏覽器間的實(shí)時通信的平臺,讓 WebRTC技術(shù)成為 H5標(biāo)準(zhǔn)之一。
2012年1月:谷歌已經(jīng)把這款軟件集成到Chrome瀏覽器中,Opera初步集成WebRTC。
2013年 6月:Mozilla Firefox[5]發(fā)布22.0版本正式集成及支持WebRTC。
2017年11月:W3C WebRTC 1.0 草案正式定稿。
2021年1月:WebRTC 被 W3C 和 IETF 發(fā)布為正式標(biāo)準(zhǔn)(見《WebRTC 1.0: Real-Time Communication Between Browsers》)。
(本文已同步發(fā)布于:http://www.52im.net/thread-3804-1-1.html)
2、重要意義
WebRTC的出現(xiàn)、發(fā)展和被業(yè)內(nèi)標(biāo)準(zhǔn)組織(如W3C)等普遍認(rèn)可,對于當(dāng)下和未來大前端技術(shù)發(fā)展具有重要的意義。
降低在web端的音視頻交互開發(fā)門檻:
- 1)以往的音視頻交互開發(fā)對于Web開發(fā)者而言具有一定技術(shù)門檻;
- 2)現(xiàn)在借助于WebRTC,Web開發(fā)者通過調(diào)用JS接口,可快速的實(shí)現(xiàn)音視頻交互應(yīng)用。
避免依賴、插件造成的次生問題:
- 1)以往的音視頻交互應(yīng)用構(gòu)建依賴于各種插件、軟件和服務(wù)器等;
- 2)現(xiàn)在借助于主流瀏覽器即可形成端到端的音視頻交互。
統(tǒng)一化和標(biāo)準(zhǔn)化對傳統(tǒng)音視頻交互環(huán)境差異性的規(guī)避:
- 1)以往音視頻交互需要面對不同的 NAT 、防火墻對媒體 P2P 的建立帶來了很大的挑戰(zhàn);
- 2)現(xiàn)在WebRTC 中有P2P 打洞的開源項(xiàng)目 libjingle ,支持 STUN,TURN 等協(xié)議。
更高效優(yōu)化的算法、技術(shù)對于音視頻交互性能的提升:
- 1)WebRTC 通過NACK、FEC技術(shù),避免了經(jīng)過服務(wù)端路由中轉(zhuǎn),減少了延遲和帶寬消耗;
- 2)還有 TCC + SVC + PACER + JitterBuffer 等技術(shù)對于音視頻流暢性進(jìn)行了優(yōu)化。
3、技術(shù)特征
WebRTC內(nèi)容豐富,主要的技術(shù)特征包含以下幾點(diǎn)。
1)實(shí)時通訊:
WebRTC是一項(xiàng)實(shí)時通訊技術(shù),允許網(wǎng)絡(luò)應(yīng)用或者站點(diǎn),在不借助中間媒介的情況下,建立瀏覽器之間點(diǎn)對點(diǎn)(Peer-to-Peer)的連接,實(shí)現(xiàn)視頻流和(或)音頻流或者其他任意數(shù)據(jù)的傳輸。
2)無依賴/插件:
WebRTC包含的這些標(biāo)準(zhǔn)使用戶在無需安裝任何插件或者第三方的軟件的情況下,創(chuàng)建點(diǎn)對點(diǎn)(Peer-to-Peer)的數(shù)據(jù)分享和電話會議成為可能。
3)協(xié)議棧 眾多:
WebRTC并不是單一的協(xié)議,包含了媒體、加密、傳輸層等在內(nèi)的多個協(xié)議標(biāo)準(zhǔn)以及一套基于 JavaScript的 API,它包括了音視頻的采集、編解碼、網(wǎng)絡(luò)傳輸、顯示等功能。通過簡單易用的 JavaScript API ,在不安裝任何插件的情況下,讓瀏覽器擁有了 P2P音視頻和數(shù)據(jù)分享的能力。
WebRTC依賴眾多協(xié)議棧圖:

同時WebRTC 并不是一個孤立的協(xié)議,它擁有靈活的信令,可以便捷的對接現(xiàn)有的SIP 和電話網(wǎng)絡(luò)的系統(tǒng)。
4、兼容覆蓋
目前大部分主流瀏覽器都正常兼容WebRTC:

▲ 上圖引用自《WebRTC實(shí)時音視頻技術(shù)的整體架構(gòu)介紹》
更詳細(xì)的瀏覽器及版本兼容情況,可以看看下圖:
主流瀏覽器都支持 WebRTC 標(biāo)準(zhǔn) API ,因此也讓瀏覽器之間無插件化的音視頻互通成為可能, 大大降低了音視頻開發(fā)的門檻,開發(fā)者只需要調(diào)用 WebRTC API 即可快速構(gòu)建出音視頻應(yīng)用。
5、技術(shù)框架
如下圖所示:的技術(shù)框架描述了WebRTC的核心內(nèi)容和面向不同開發(fā)者的API設(shè)計。
WebRTC技術(shù)框架圖:
從圖中可看到,WebRTC主要面向三類開發(fā)者的API設(shè)計:
- 1)對于Web開發(fā)者的API:框架包含了基于JavaScript 、 經(jīng)過W3C認(rèn)證了的一套API標(biāo)準(zhǔn),使得web開發(fā)者可以基于這套API開發(fā)基于WebRTC的即時通訊應(yīng)用;
- 2)對于瀏覽器廠商的API:框架同樣包含了基于C++的底層WebRTC接口,對于瀏覽器廠商底層的接入十分友好;
- 3)瀏覽器廠商可自定義的部分:框架中還包含瀏覽器廠商可自定義的音視頻截取等擴(kuò)展部分。
6、技術(shù)核心
從上節(jié)框架中可以看到,WebRTC主要有音頻、視頻引擎和傳輸三部分組成,其中又包含眾多的協(xié)議和方法等。
1)Voice Engine(音頻引擎):
- a、Voice Engine包含iSAC/iLBC Codec(音頻編解碼器,前者是針對寬帶和超寬帶,后者是針對窄帶);
- b、NetEQ for voice(處理網(wǎng)絡(luò)抖動和語音包丟失);
- c、Echo Canceler(回聲消除器)/ Noise Reduction(噪聲抑制)。
2)Video Engine(視頻引擎):
- a、VP8 Codec(視頻圖像編解碼器);
- b、Video jitter buffer(視頻抖動緩沖器,處理視頻抖動和視頻信息包丟失);
- c、Image enhancements(圖像質(zhì)量增強(qiáng))。
3)Transport。
7、技術(shù)原理
7.1 基本情況
WebRTC主要的技術(shù)特征:
- 1)SRTP:安全的實(shí)時傳輸協(xié)議,用于音視頻流傳輸;
- 2)Multiplexing:多路復(fù)用;
- 3)P2P:STUN+TURN+ICE,用于NAT網(wǎng)絡(luò)和防火墻穿越;
- 4)DTLS:安全傳輸可能還會用到DTLS(數(shù)據(jù)報安全傳輸),用于加密傳輸和密鑰協(xié)商;
- 5)UDP:整個WebRTC通信是基于UDP的。
限于篇幅,本文以下章節(jié)將不細(xì)致介紹音視頻采集、編碼和處理等內(nèi)容,僅介紹實(shí)時通訊的建立過程原理的核心內(nèi)容。
7.2 公網(wǎng)IP映射:明確網(wǎng)絡(luò)定位信息
WebRTC是基于瀏覽器端到端的連接(P2P)實(shí)現(xiàn)的.
由于不需要服務(wù)器中轉(zhuǎn),所以獲取連接對象的網(wǎng)絡(luò)地址的方式,是借助于ICE、STUN、TURN等輔助內(nèi)網(wǎng)穿透技術(shù)(NAT)得到對應(yīng)主機(jī)的公網(wǎng)網(wǎng)絡(luò)地址和端口等網(wǎng)絡(luò)定位信息。
明確網(wǎng)絡(luò)定位是建立端與端直接通訊的基礎(chǔ)。
NAT穿透原理圖:

STUN服務(wù)器用于輔助內(nèi)網(wǎng)穿透得到對應(yīng)主機(jī)的公網(wǎng)網(wǎng)絡(luò)地址和端口信息圖:

▲ 上圖引用自《WebRTC實(shí)時音視頻技術(shù)的整體架構(gòu)介紹》
7.3 信令服務(wù)器:網(wǎng)絡(luò)協(xié)商與信息交換
信令服務(wù)器的作用是基于雙工通信來中轉(zhuǎn)信息。
中轉(zhuǎn)信息包括公網(wǎng)IP映射后的網(wǎng)絡(luò)定位信息,比如:公網(wǎng)IP、端口和媒體數(shù)據(jù)流等。
概念圖:

信令服務(wù)器信息交互過程圖:

7.4 會話描述協(xié)議SDP:統(tǒng)一的媒體協(xié)商方式
SDP的作用:
- 1)不同端/瀏覽器對于媒體流數(shù)據(jù)的編碼格式各異,如VP8、VP9等,參與會話的各個成員的能力不對等、用戶環(huán)境與配置不一致等;
- 2)WebRTC通訊還需要確定和交換本地和遠(yuǎn)程音頻和視頻媒體信息,例如分辨率和編解碼器功能。交換媒體配置信息的信令通過使用會話描述協(xié)議 (SDP) 交換Offer和Anwser來進(jìn)行;
- 3)SDP的交換一定是先于音視頻流交換的。其內(nèi)容包括會話基本信息、媒體信息描述等。
//SDP的結(jié)構(gòu)體
Session description(會話級別描述)
v= (protocol version)
o= (originator and session identifier)
s= (session name)
c=* (connection information -- not required ifincluded inall media)
One or moreTime descriptions ("t="and "r="lines; see below)
a=* (zero or moresession attribute lines)
Zero or moreMedia descriptions
Time description
t= (timethe session is active)
Media description(媒體級別描述), ifpresent
m= (media name and transport address)
c=* (connection information -- optional ifincluded at session level)
a=* (zero or moremedia attribute lines)
一個SDP例子如下:
v=0 //代表版本,目前一般是`v=0`.
o=- 3883943731 1 IN IP4 127.0.0.1
s=
t=0 0 //會話處于活動狀態(tài)的時間
a=group:BUNDLE audio video //:描述服務(wù)質(zhì)量,傳輸層復(fù)用相關(guān)信息
m=audio 1 RTP/SAVPF103 104 0 8 106 105 13 126 //...
a=ssrc:2223794119 label:H4fjnMzxy3dPIgQ7HxuCTLb4wLLLeRHnFxh81
7.5 一對一連接建立過程
以建立一對一的Web RTC連接過程為例來簡要講解。
一對一過程圖:

簡要過程圖:

如上圖所示,解釋一下:
- 1)交換SDP,獲取各自媒體配置信息;
- 2)STUN服務(wù)器交換網(wǎng)絡(luò)地址和端口等網(wǎng)絡(luò)信息;
- 3)Turn中轉(zhuǎn)音視頻媒體流數(shù)據(jù)。
工作流程圖:

如上圖所示,解釋一下:
- 1)A和B雙方先調(diào)用 getUserMedia 打開本地攝像頭,作為本地待輸出媒體流;
- 2)向信令服務(wù)器發(fā)送加入房間請求;
- 3)Peer B 接收到 Peer A 發(fā)送的 offer SDP 對象,并通過PeerConnection的SetLocalDescription方法保存 Answer SDP 對象并將它通過信令服務(wù)器發(fā)送給 Peer A;
- 4)在 SDP 信息的 offer/answer 流程中,Peer A 和 Peer B 已經(jīng)根據(jù) SDP 信息創(chuàng)建好相應(yīng)的音頻 Channel 和視頻 Channel,并開啟Candidate 數(shù)據(jù)的收集,Candidate數(shù)據(jù)(本地IP地址、公網(wǎng)IP地址、Relay服務(wù)端分配的地址);
- 5)當(dāng) Peer A 收集到 Candidate 信息后通過信令服務(wù)器發(fā)送給 Peer B。同樣的過程 Peer B 對 Peer A 也會再發(fā)送一次。
7.6 多對多的建立
多對多建立點(diǎn)到點(diǎn)連接概念圖,以三個用戶點(diǎn)對點(diǎn)的連接為例:

7.7 WebRTC的主要JavaScrip接口
getUserMedia():訪問數(shù)據(jù)流,例如來自用戶的相機(jī)和麥克風(fēng)
//請求媒體類型
const constraints = {
video: true
audio:true
};
const video = document.querySelector('video');
//掛載流到相應(yīng)dom展示本地媒體流
function handleSuccess(stream) {
video.srcObject = stream;
}
function handleError(error) {
console.error('getUserMedia error: ', error);
}
//利用攝像頭捕獲多媒體流
navigator.mediaDevices.getUserMedia(constraints).
then(handleSuccess).catch(handleError);
RTCPeerConnection:通過加密和帶寬管理工具啟用音頻或視頻通話
// 允許 RTC 服務(wù)器配置。
const server = {
"iceServers":
[{ "urls": "stun:stun.stunprotocol.org"}]
};
// 創(chuàng)建本地連接
const localPeerConnection = newRTCPeerConnection(servers);
// 收集Candidate 數(shù)據(jù)
localPeerConnection.onicecandidate=function(event){
...
}
// 監(jiān)聽到媒體流接入時的操作
localPeerConnection.ontack=function(event){
...
}
RTCDataChannel:支持通用數(shù)據(jù)的點(diǎn)對點(diǎn)通信,常用于數(shù)據(jù)點(diǎn)到點(diǎn)的傳輸
const pc = newRTCPeerConnection();
const dc = pc.createDataChannel("my channel");
//接受數(shù)據(jù)
dc.onmessage = function(event) {
console.log("received: "+ event.data);
};
//打開傳輸
dc.onopen = function() {
console.log("datachannel open");
};
//關(guān)閉傳輸
dc.onclose = function() {
console.log("datachannel close");
};
8、應(yīng)用案例
這里以WebRTC的多人視頻案例為實(shí)踐來大致演示一下。
8.1 設(shè)計框架
多人視頻基本框架圖:

8.2 關(guān)鍵代碼
8.2.1)媒體捕獲:
獲取瀏覽器視頻權(quán)限,捕獲本地視頻媒體流,在Video元素中附加媒體流,顯示本地視頻結(jié)果。代碼如下。
//攝像頭兼容性處理
navigator.getUserMedia = ( navigator.getUserMedia ||
navigator.webkitGetUserMedia ||
navigator.mozGetUserMedia ||
navigator.msGetUserMedia);
// 獲取本地音頻和視頻流
navigator.mediaDevices.getUserMedia({
"audio": false,
"video": true
}).then( (stream)=> {
//顯示自己的輸出流,掛到頁面Video元素上
document.getElementById("myVido").srcObject=stream
})
捕獲本地視頻媒體流的顯示結(jié)果截圖:

為每個新的客戶端連接創(chuàng)建RTCPeerConnection對象:
// stun和turn服務(wù)器 const iceServer = {
"iceServers": [{
urls:"stun:stun.l.google.com:19302"
}]
};
//為點(diǎn)到點(diǎn)的連接創(chuàng)建RTCPeerConnection
const peerRTCConn=newRTCPeerConnection(iceServer);
8.2.2)網(wǎng)絡(luò)協(xié)商:
主要任務(wù)就是:創(chuàng)建對等連接,收集ICE候選,等待媒體流接入時掛載到dom。
交互式連通性建立(Interactive Connectivity Establishment — ICE)是一個允許實(shí)時對等端發(fā)現(xiàn)對方并且彼此連接的框架。此技術(shù)允許對等方發(fā)現(xiàn)有關(guān)彼此拓?fù)涞淖銐蛐畔ⅲ瑥亩锌赡茉诒舜酥g找到一條或多條通信路徑。ICE 代理負(fù)責(zé):收集本地IP,端口元組候選、在同級之間執(zhí)行連接檢查和發(fā)送連接保持活動。(關(guān)于ICE的介紹,見《P2P技術(shù)之STUN、TURN、ICE詳解》)
// 發(fā)送ICE候選到其他客戶端 peerRTCConn.onicecandidate = function(event){
if(event.candidate) {
//向信令服務(wù)器轉(zhuǎn)發(fā)收集到的ICE候選 socket.send(JSON.stringify({
"event": "relayICECandidate",
"data": {
'iceCandidate': {
'sdpMLineIndex': event.candidate.sdpMLineIndex,
'candidate': event.candidate.candidate
}
},
"fromID":signalMsg['data']['peerId']
}));
}
}
//有媒體流介入就掛載dom peerRTCConn.ontrack=function(event){
let v=document.createElement("video")
v.autoplay=true
v.style="width:200px"
document.getElementById("peer").appendChild(v)
v.srcObject=event.streams[0]
}
8.1.3)媒體協(xié)商:
發(fā)起時創(chuàng)建Offer。peer利用setLocalDescription方法將會話信息加到RTCPeerConnection(),并由信令服務(wù)器中轉(zhuǎn)。其他Peer會返回相應(yīng)的Answer。SDP過程:
//新加入節(jié)點(diǎn)發(fā)起offer if(canOffer){
peerRTCConn.createOffer(
function(localDescription) {
peerRTCConn.setLocalDescription(localDescription,
function() {
//發(fā)送描述信息給信令服務(wù)器 socket.send(JSON.stringify({
"event":"relaySessionDescription",
"data":localDescription,
"fromID":peerId
}))
},
function() { alert("offer failed"); }
);
},
function(error) {
console.log("error sending offer: ", error);
}
)
}
響應(yīng)時創(chuàng)建Answer。會話描述包括音視頻信息等內(nèi)容,當(dāng)發(fā)起者向響應(yīng)者發(fā)出offer類型的描述后,響應(yīng)者會返回answer類型的描述:
//創(chuàng)建Answer會話
peer.createAnswer(
function(_remoteDescription) {
peer.setLocalDescription(_remoteDescription,
function() {
//發(fā)送描述信息給信令服務(wù)器 socket.send(JSON.stringify({
"event":"relaySessionDescription",
"data":_remoteDescription,
"callerID":signalMsg['fromId'],
"fromID":signalMsg['fromId']
})) },
function() { alert("answer failed"); }
);
},
function(error) {
console.log("error creating answer: ", error);
});
當(dāng)收到ICE候選共享后,會把ICE候選添加到遠(yuǎn)程對等點(diǎn)描述中:
//對應(yīng)的RTCPeerConnection
const peer = peers[signalMsg["fromID"]];
//ICE候選添加到遠(yuǎn)程對等點(diǎn)描述
peer.addIceCandidate(newRTCIceCandidate(signalMsg["data"].iceCandidate));
多人視頻結(jié)果截圖<本地模擬效果>:

8.2.4)信令中轉(zhuǎn):
信令服務(wù)部分關(guān)鍵代碼:
wss.on('connection', function(ws) {
ws.on('message', function(message) {
let meeageObj=JSON.parse(message)
//交換ICE候選 if (meeageObj['event'] =='relayICECandidate') { wss.clients.forEach(function (client) {
console.log("send iceCandidate")
client.send(JSON.stringify({
"event": "iceCandidate",
"data": meeageObj['data'],
"fromID": meeageObj['fromID']
}));
});
}
//交換SDP
if (meeageObj['event'] =='relaySessionDescription') {
console.log(meeageObj["fromID"],meeageObj["data"].type)
wss.clients.forEach(function(client) {
if(client!=ws) {
client.send(JSON.stringify({
"event": "sessionDescription",
"fromId":meeageObj["fromID"],
"data": meeageObj["data"],
}));
}
});
}
})
})
9、小結(jié)一下
WebRTC的優(yōu)點(diǎn)主要是:
1)方便:對于用戶來說,在WebRTC出現(xiàn)之前想要進(jìn)行實(shí)時通信就需要安裝插件和客戶端,但是對于很多用戶來說,插件的下載、軟件的安裝和更新這些操作是復(fù)雜而且容易出現(xiàn)問題的,現(xiàn)在WebRTC技術(shù)內(nèi)置于瀏覽器中,用戶不需要使用任何插件或者軟件就能通過瀏覽器來實(shí)現(xiàn)實(shí)時通信。對于開發(fā)者來說,在Google將WebRTC開源之前,瀏覽器之間實(shí)現(xiàn)通信的技術(shù)是掌握在大企業(yè)手中,這項(xiàng)技術(shù)的開發(fā)是一個很困難的任務(wù),現(xiàn)在開發(fā)者使用簡單的HTML標(biāo)簽和JavaScript API就能夠?qū)崿F(xiàn)Web音/視頻通信的功能。
2)免費(fèi):雖然WebRTC技術(shù)已經(jīng)較為成熟,其集成了最佳的音/視頻引擎,十分先進(jìn)的codec,但是Google對于這些技術(shù)不收取任何費(fèi)用。
3)強(qiáng)大的打洞能力:WebRTC技術(shù)包含了使用STUN、ICE、TURN、RTP-over-TCP的關(guān)鍵NAT和防火墻穿透技術(shù),并支持代理。
WebRTC的缺點(diǎn)主要是:
1)缺乏服務(wù)器方案的設(shè)計和部署。
2)傳輸質(zhì)量難以保證。WebRTC的傳輸設(shè)計基于P2P,難以保障傳輸質(zhì)量,優(yōu)化手段也有限,只能做一些端到端的優(yōu)化,難以應(yīng)對復(fù)雜的互聯(lián)網(wǎng)環(huán)境。比如對跨地區(qū)、跨運(yùn)營商、低帶寬、高丟包等場景下的傳輸質(zhì)量基本是靠天吃飯,而這恰恰是國內(nèi)互聯(lián)網(wǎng)應(yīng)用的典型場景。
3)WebRTC比較適合一對一的單聊,雖然功能上可以擴(kuò)展實(shí)現(xiàn)群聊,但是沒有針對群聊,特別是超大群聊進(jìn)行任何優(yōu)化。
4)設(shè)備端適配,如回聲、錄音失敗等問題層出不窮。這一點(diǎn)在安卓設(shè)備上尤為突出。由于安卓設(shè)備廠商眾多,每個廠商都會在標(biāo)準(zhǔn)的安卓框架上進(jìn)行定制化,導(dǎo)致很多可用性問題(訪問麥克風(fēng)失敗)和質(zhì)量問題(如回聲、嘯叫)。
5)對Native開發(fā)支持不夠。WebRTC顧名思義,主要面向Web應(yīng)用,雖然也可以用于Native開發(fā),但是由于涉及到的領(lǐng)域知識(音視頻采集、處理、編解碼、實(shí)時傳輸?shù)龋┹^多,整個框架設(shè)計比較復(fù)雜,API粒度也比較細(xì),導(dǎo)致連工程項(xiàng)目的編譯都不是一件容易的事。
10、參考資料
[1] 開源實(shí)時音視頻技術(shù)WebRTC的現(xiàn)狀
[2] 簡述開源實(shí)時音視頻技術(shù)WebRTC的優(yōu)缺點(diǎn)
[3] 訪談WebRTC標(biāo)準(zhǔn)之父:WebRTC的過去、現(xiàn)在和未來
[4] 良心分享:WebRTC 零基礎(chǔ)開發(fā)者教程(中文)[附件下載]
[5] WebRTC實(shí)時音視頻技術(shù)的整體架構(gòu)介紹
[6] 新手入門:到底什么是WebRTC服務(wù)器,以及它是如何聯(lián)接通話的?
[7] WebRTC實(shí)時音視頻技術(shù)基礎(chǔ):基本架構(gòu)和協(xié)議棧
[8] 淺談開發(fā)實(shí)時視頻直播平臺的技術(shù)要點(diǎn)
[9] 基于開源WebRTC開發(fā)實(shí)時音視頻靠譜嗎?第3方SDK有哪些?
[10] 開源實(shí)時音視頻技術(shù)WebRTC在Windows下的簡明編譯教程
[11] 網(wǎng)頁端實(shí)時音視頻技術(shù)WebRTC:看起來很美,但離生產(chǎn)應(yīng)用還有多少坑要填?
[12] 了不起的WebRTC:生態(tài)日趨完善,或?qū)?shí)時音視頻技術(shù)白菜化
[13] 零基礎(chǔ)入門:基于開源WebRTC,從0到1實(shí)現(xiàn)實(shí)時音視頻聊天功能
[14] P2P技術(shù)詳解(一):NAT詳解——詳細(xì)原理、P2P簡介
[15] P2P技術(shù)詳解(二):P2P中的NAT穿越(打洞)方案詳解(基本原理篇)
(本文已同步發(fā)布于:http://www.52im.net/thread-3804-1-1.html)
作者:Jack Jiang (點(diǎn)擊作者姓名進(jìn)入Github)
出處:http://www.52im.net/space-uid-1.html
交流:歡迎加入即時通訊開發(fā)交流群 215891622
討論:http://www.52im.net/
Jack Jiang同時是【原創(chuàng)Java
Swing外觀工程BeautyEye】和【輕量級移動端即時通訊框架MobileIMSDK】的作者,可前往下載交流。
本博文
歡迎轉(zhuǎn)載,轉(zhuǎn)載請注明出處(也可前往 我的52im.net 找到我)。