?

去中心化的RTC網(wǎng)絡(luò)無(wú)需關(guān)心其它媒體服務(wù)狀態(tài)，可快速增加地域媒體服務(wù)節(jié)點(diǎn)部署，與信令服務(wù)無(wú)耦合。本文來(lái)自融云聯(lián)合創(chuàng)始人，CTO楊攀在LiveVideoStackCon 2019上海的演講內(nèi)容，由LiveVideoStack整理而成。在8月23-24日的LiveVideoStackCon2019北京大會(huì)上，楊攀還將分享《可擴(kuò)展的公有云媒體服務(wù)設(shè)計(jì)解析》。

文 / 楊攀

整理 / LiveVideoStack

大家好，我叫楊攀，從開始工作至今有17年了，一直在從事電信、通信、社交以及開放平臺(tái)領(lǐng)域相關(guān)的工作。大約在2004年左右，MSN剛開始進(jìn)入中國(guó)并落地，當(dāng)時(shí)我們的團(tuán)隊(duì)在上海將一些MSN的美國(guó)業(yè)務(wù)在本地做了電信運(yùn)營(yíng)商的落地。后續(xù)，我也參與到了整個(gè)飛信團(tuán)隊(duì)的建設(shè)之中，目前融云的研發(fā)團(tuán)隊(duì)就是之前中國(guó)移動(dòng)飛信的核心研發(fā)團(tuán)隊(duì)，整個(gè)團(tuán)隊(duì)從研發(fā)到產(chǎn)品再到運(yùn)營(yíng)在一起工作了大約12年之久。

一、背景介紹

?

融云做的是通信云服務(wù)，可以說(shuō)是基于IP的虛擬通信運(yùn)營(yíng)商，我們希望未來(lái)所有在Internet上的IP流量，包括消息、語(yǔ)音片段、視頻片段、紅包、表情、音頻通話和視頻通話等等，所有的這些通信都能承載在我們自己建設(shè)的全球通信網(wǎng)上，而這同樣也是我們的使命。因此，目前我們?cè)谌虼笠?guī)模地鋪設(shè)了自己的網(wǎng)絡(luò)，包括在北京、新加坡和北美建設(shè)的三個(gè)大數(shù)據(jù)中心，在全球有數(shù)百個(gè)接入節(jié)點(diǎn)和數(shù)千個(gè)加速節(jié)點(diǎn)。

本次要與大家分享的主要內(nèi)容就是在架構(gòu)尺度上的部分技術(shù)經(jīng)驗(yàn)與積累。

二、分布式無(wú)級(jí)聯(lián)的RTC架構(gòu)

?

首先，為大家介紹分布式無(wú)級(jí)聯(lián)的RTC架構(gòu)。對(duì)于RTC的架構(gòu)，在WebRTC中的定義是一個(gè)Peer到Peer的通信。其中并沒有直接給出一個(gè)明確的標(biāo)準(zhǔn)來(lái)告訴你如何去做信令服務(wù)、媒體服務(wù)等。那么，一個(gè)最簡(jiǎn)單的分布式媒體服務(wù)是什么樣的呢？

?

一般的基本模式是，A用戶和B用戶首先通過一個(gè)信令服務(wù)，信令服務(wù)為A和B分別分配媒體服務(wù)，然后幫助它們之間建立一個(gè)聯(lián)系。對(duì)于這種簡(jiǎn)單分布式但并不支持級(jí)聯(lián)的RTC架構(gòu)，它的優(yōu)點(diǎn)是每一個(gè)媒體服務(wù)本身都不需要和其它的媒體服務(wù)建立連接，并且不會(huì)進(jìn)行網(wǎng)絡(luò)優(yōu)化。但是，它最大的問題就是當(dāng)我們給A客戶端分配一個(gè)媒體服務(wù)后，B客戶端也是需要連接同一媒體服務(wù)的。假如我們先給A客戶端就近分配一個(gè)媒體服務(wù)，此時(shí)A客戶端和媒體服務(wù)之間連接的質(zhì)量是非常好的，但是如果A客戶端和B客戶端不在同一地區(qū)，B客戶端也許距離這個(gè)媒體服務(wù)非常遠(yuǎn)，中間的網(wǎng)絡(luò)就可能會(huì)非常不穩(wěn)定，此時(shí)A客戶端和B客戶端通過這個(gè)媒體服務(wù)建立的通信就是存在問題的。因此，這種模式只適用小規(guī)模范圍的通信，如城域或者是公司內(nèi)部的私網(wǎng)。

?

下面，將介紹有級(jí)聯(lián)的RTC架構(gòu)是如何實(shí)現(xiàn)的。

?

三、分布式有級(jí)聯(lián)的RTC架構(gòu)

?

有級(jí)聯(lián)的RTC架構(gòu)則要求A客戶端和B客戶端分別找到不同的媒體服務(wù)來(lái)進(jìn)行通信，媒體服務(wù)之間也要做級(jí)聯(lián)的通信，這樣就能解決上述無(wú)級(jí)聯(lián)RTC架構(gòu)存在的問題。如上圖所示，我們可以先為左邊的Client找到一個(gè)對(duì)它來(lái)講質(zhì)量最好的媒體服務(wù)，然后再為右邊的Client找到一個(gè)質(zhì)量最好的媒體服務(wù)，兩個(gè)媒體服務(wù)之間還要再通過一些網(wǎng)絡(luò)優(yōu)化的手段來(lái)保證它們的通信質(zhì)量。上圖系統(tǒng)中的藍(lán)色部分叫做Signal Server，Client可以通過Signal Server和Media Server進(jìn)行SDP交換。

分布式有級(jí)聯(lián)的RTC架構(gòu)可以實(shí)現(xiàn)鏈路的優(yōu)化，但同時(shí)我們也不難發(fā)現(xiàn)，Signal Server和Media Server之間存在的耦合問題。這是因?yàn)樗械腗edia Server都需要在Signal Server中進(jìn)行注冊(cè)登記以進(jìn)行管理，并且Signal Server還要和Media Server之間保持一個(gè)健康狀態(tài)的檢查，比如做一個(gè)TCP的長(zhǎng)連接、做一個(gè)心跳包。此外，Signal Server不僅需要知道Media Server里有哪些用戶正在使用流媒體通信，還需要知道它的用戶狀態(tài)。一方面，對(duì)于緊的耦合，當(dāng)部署一個(gè)新的媒體服務(wù)時(shí)，就會(huì)需要很復(fù)雜的工程實(shí)施，因?yàn)樵诤芏嗟胤骄猆pdate配置。另一方面，如果在通話過程中發(fā)現(xiàn)媒體服務(wù)或者信令服務(wù)之間存在一些異常狀態(tài)，則會(huì)導(dǎo)致整個(gè)通話斷掉，因?yàn)樗麄儍蓚€(gè)之間的耦合非常緊密。到目前為止，大家能夠在市面上看到的開源解決方案基本上都是按這個(gè)模式去設(shè)計(jì)的。在電信運(yùn)營(yíng)商領(lǐng)域，Signal Server最典型的就是用SIP協(xié)議來(lái)實(shí)現(xiàn)的，包括我們之前做飛信也是用的一個(gè)SIP的簡(jiǎn)化協(xié)議SIPC。還有一種方案就是，可以搭一個(gè)XMPP的服務(wù)器，用它來(lái)實(shí)現(xiàn)Presence管理，所謂的Presence管理與SIP一樣，就是用一條IM通道來(lái)做Signal Server。

?

在這一部分，我們分析了分布式有級(jí)聯(lián)RTC架構(gòu)的優(yōu)點(diǎn)和缺點(diǎn)。接下來(lái)，我們一起來(lái)看看融云對(duì)分布式RTC網(wǎng)絡(luò)的思考。

?

四、融云對(duì)分布式RTC網(wǎng)絡(luò)的思考

?

如上所述，由于信令服務(wù)器和媒體服務(wù)是有耦合的，我們上線或下線任何一個(gè)媒體服務(wù)器均要在Signal Server里Update相關(guān)狀態(tài)和配置。因此，我們的第一個(gè)訴求就是要設(shè)計(jì)一種將信令服務(wù)和媒體服務(wù)解耦開來(lái)的架構(gòu)；第二個(gè)訴求就是要使得我們的信令服務(wù)和媒體服務(wù)之間能不管對(duì)方的狀態(tài)如何，讓它們不需要狀態(tài)同步；第三個(gè)訴求就是讓每一個(gè)媒體中心都是獨(dú)立的；第四個(gè)訴求就是要降低新建與維護(hù)媒體中心的成本，因?yàn)橥ㄐ旁品?wù)有數(shù)以千計(jì)或萬(wàn)計(jì)的機(jī)器和節(jié)點(diǎn)要管理；最后一個(gè)訴求就是要全面復(fù)用融云即時(shí)通訊通道。

?

上圖是融云的分布式RTC網(wǎng)絡(luò)架構(gòu)，我們將Signal Server換成了融云的IM基礎(chǔ)設(shè)施。簡(jiǎn)單來(lái)說(shuō)，IM是用來(lái)發(fā)消息的，它實(shí)際上就是把一段數(shù)據(jù)通過一個(gè)長(zhǎng)連接的、永遠(yuǎn)在線的通道從一端推送到另外一端，而且該服務(wù)要保證這條通道永遠(yuǎn)是可用的，同時(shí)發(fā)的每一個(gè)信令、指令都不能丟失，并且要以最快的速度到達(dá)。總的來(lái)說(shuō)，這就是Signal Server的使命。

接下來(lái)，我將為大家詳細(xì)講解融云的RTC建連過程。

?

如上圖所示包含有五個(gè)角色，分別是Client A、Client A對(duì)應(yīng)的Media Server、IM Server、Client B對(duì)應(yīng)的Media Server、Client B。Client A是通信的發(fā)起方，IM Server就是我們的Signal Server。在這個(gè)架構(gòu)里面，我們引入Pub/Sub模型來(lái)實(shí)現(xiàn)解耦，下面將分兩部分講解。

?

Pub過程：Client A會(huì)利用Smart DNS直接找到自己對(duì)應(yīng)的Media Server，然后調(diào)用該Media Server上開放的一個(gè)HTTP接口，調(diào)用該接口是為了傳遞傳Token、Room ID/Channel ID，以及交換SDP，這個(gè)在后面會(huì)詳細(xì)解釋。調(diào)用完之后，Media Server會(huì)返回該Media Server的IP地址和Client A在Media Server上注冊(cè)后所分配的Resource ID，Resource ID是Client A在Media Server上唯一的身份標(biāo)識(shí)。Client A接收到Media Server返回的信息后就可以直接與Media Server建立RTC連接，接著就可以開始利用信令通道了。之后IM Server要將Client A呼叫Client B的指令Push給Client B，并且會(huì)將Media Server返回給Client A的信息直接Send給Client B。此時(shí)，Pub過程就完成了。

?

Sub過程：與前面相同，Client B也要通過Smart DNS找到一個(gè)相對(duì)來(lái)說(shuō)質(zhì)量最好的Media Server，然后調(diào)用其另外一個(gè)接口將剛才傳過來(lái)的信息告訴這個(gè)Media Server。當(dāng)Client B對(duì)應(yīng)的Media Server拿到了Client A對(duì)應(yīng)的Media Server的信息后，由Resource ID就可以知道要將Client A和Client B之間建立連接，在內(nèi)部建立關(guān)聯(lián)后返回一個(gè)ACK，說(shuō)明已經(jīng)調(diào)用成功。一旦Client A和Client B建立RTC連接成功后，Client A對(duì)應(yīng)的Media Server和Client B對(duì)應(yīng)的Media Server就建立起了級(jí)聯(lián)。

?

當(dāng)RTC的通道連接建立成功后，去中心化完成，此時(shí)我們就完成了Media Server和Signal Server之間的解耦。

?

總結(jié)一下，融云的RTC建連過程采用了極簡(jiǎn)的接口設(shè)計(jì)。如上述的時(shí)序圖，有幾次HTTP調(diào)用實(shí)際上全都是通過一個(gè)HTTP接口來(lái)實(shí)現(xiàn)的，而這一個(gè)HTTP接口通過傳遞不同的參數(shù)就非常簡(jiǎn)單的實(shí)現(xiàn)了發(fā)布/取消發(fā)布流，SFU和MCU的訂閱/取消訂閱。

下面將詳細(xì)講解一下在前面提到的Media Server。

?

對(duì)于Media Server，我們可以將其理解為在一臺(tái)物理硬件的服務(wù)器上面部署了一套服務(wù)。但事實(shí)上，對(duì)于大規(guī)模的云廠商來(lái)講，一般是在某一個(gè)地方建立一個(gè)數(shù)據(jù)中心，在里面會(huì)投入很多的機(jī)器來(lái)運(yùn)轉(zhuǎn)。一個(gè)媒體服務(wù)中心的架構(gòu)設(shè)計(jì)往往非常簡(jiǎn)單，對(duì)于左邊的HTTP請(qǐng)求要做Load Balance，然后把它分布在其他各種平臺(tái)的Media Server上，并且在中間還加了一個(gè)反向代理。在數(shù)據(jù)中心里雖然有很多的媒體服務(wù)，但如果我們不做任何策略的話，就可能會(huì)出現(xiàn)以下情況：當(dāng)三個(gè)人在一個(gè)房間聊天時(shí)，可能會(huì)被分配到了兩臺(tái)Media Server上，即在數(shù)據(jù)中心內(nèi)還需要Media Server之間的通信，這樣是十分影響性能和質(zhì)量的。那么，我們?cè)撊绾谓鉀Q這個(gè)問題呢？如前所述，調(diào)用接口時(shí)要傳Token、Room ID/Channel ID、SDP。因此，我們可以通過算法將Room ID相同的用戶歸并到同一臺(tái)Media Server上，只要這個(gè)房間內(nèi)的訂閱人數(shù)沒有超過該Media Server的物理上限，則可以保證該房間里用戶全在一個(gè)Media Server上進(jìn)行通信，此時(shí)的性能是非常好的。除了上述情況外，還有另外一個(gè)問題，例如當(dāng)前進(jìn)行會(huì)議的房間的人數(shù)特別多，而且用戶數(shù)超過了Media Server所能承載的業(yè)務(wù)量。對(duì)于這種情況，我們就需要進(jìn)行打散，也就是將用戶分散在不同的Media Server上。

?

接下來(lái)，總結(jié)一下我們?cè)诿襟w服務(wù)方面除了上述內(nèi)容之外還做了哪些事情。在進(jìn)行HTTP接口調(diào)用時(shí)，HTTP接口支持QUIC，可減少交互握手的次數(shù)來(lái)優(yōu)化性能。另外，我們還做了媒體服務(wù)的端口收斂以及盡可能的去實(shí)現(xiàn)單中心間媒體服務(wù)的0調(diào)用。

?

接下來(lái)，針對(duì)前面提出的問題來(lái)總結(jié)一下結(jié)果：1）我們按照新設(shè)計(jì)的架構(gòu)模型實(shí)現(xiàn)了信令服務(wù)和媒體服務(wù)的解耦，當(dāng)上線一個(gè)新的媒體服務(wù)時(shí)，無(wú)需在信令服務(wù)里添加任何注冊(cè)配置，唯一要做的就是在Smart DNS里為這個(gè)媒體服務(wù)增加一條記錄；2）信令和媒體服務(wù)之間不存在任何調(diào)用關(guān)系，所以也就不存在任何數(shù)據(jù)和狀態(tài)的同步；3）媒體中心間也不需要狀態(tài)同步；4）我門已經(jīng)把媒體服務(wù)管理和添加的成本降到非常低的水平；5）直接復(fù)用融云的通訊通道，在融云RTC的SDK里面已經(jīng)內(nèi)涵了一個(gè)精簡(jiǎn)版的IM協(xié)議棧。

下面將介紹一下融云的RTC全球網(wǎng)絡(luò)。

?

五、融云RTC全球網(wǎng)絡(luò)

?

融云是一家覆蓋全球的云通信服務(wù)商，目前已經(jīng)建立了全球的通信網(wǎng)絡(luò)，遍布中國(guó)、東南亞、中東等地。只要客戶需要，我們的工程團(tuán)隊(duì)就可以去當(dāng)?shù)亟ㄔO(shè)數(shù)據(jù)中心，將整個(gè)的通信網(wǎng)絡(luò)基礎(chǔ)設(shè)施鋪到那里。目前，我們已經(jīng)將全新建設(shè)一個(gè)Media Server的成本降到非常低的程度，以至于只僅添加一條DNS記錄就可以搞定，這也是我們整個(gè)后端的研發(fā)團(tuán)隊(duì)引以自豪的地方。

?

那么，我們?cè)谌蚓W(wǎng)絡(luò)上做了哪些工作呢？首先，我們引入了一個(gè)新的概念HTTPDNS，融云每天有幾千萬(wàn)的活躍用戶，因此連接訪問的次數(shù)可能會(huì)是特別大數(shù)量級(jí)的。根據(jù)我們手里掌握數(shù)據(jù)的分析結(jié)果來(lái)看，DNS是影響連通率指標(biāo)的罪魁禍?zhǔn)?#xff0c;尤其在國(guó)內(nèi)復(fù)雜的網(wǎng)絡(luò)環(huán)境下。因此，需要引入HTTPDNS來(lái)進(jìn)一步提高通信質(zhì)量。其次，媒體中心間的物理鏈路優(yōu)化。級(jí)聯(lián)的一種簡(jiǎn)單方式就是物理連接，現(xiàn)在幾乎所有的廠商都會(huì)花錢進(jìn)行物理鏈路的優(yōu)化。此外，對(duì)于跨廠商或者在網(wǎng)絡(luò)比較復(fù)雜地區(qū)可能要建設(shè)一些物理服務(wù)器，那我們就要解決邏輯鏈路的優(yōu)化，在這里面通常是采用一些轉(zhuǎn)發(fā)的策略，其中的基礎(chǔ)邏輯就是收集數(shù)據(jù)、實(shí)時(shí)分析數(shù)據(jù)然后做出決策去實(shí)現(xiàn)調(diào)度。

接下來(lái)，再補(bǔ)充介紹一些其它的技術(shù)點(diǎn)。

1）RTC鑒權(quán)

?

在最初的實(shí)時(shí)通信模型架構(gòu)中，根據(jù)Room ID/Channel ID直接加入即可訂閱它的流，并且可以看到它里面的內(nèi)容，這就導(dǎo)致了存在安全的隱患。那么如何解決這個(gè)問題呢？解決方法就是在前面所講到的模型中調(diào)HTTP接口時(shí)要傳一個(gè)Token。具體來(lái)講，當(dāng)兩個(gè)客戶端建立連接時(shí)，在同步調(diào)用Signal Server的過程中會(huì)傳一個(gè)Token回來(lái)，Token是信令服務(wù)調(diào)用后臺(tái)的密鑰服務(wù)所分發(fā)的一個(gè)令牌。當(dāng)拿著這個(gè)令牌去連Client對(duì)應(yīng)的Media Server時(shí)，Media Server會(huì)Check令牌隱含的信息是否與要建立連接Client的Room ID/Channel ID相匹配。如果不匹配，則沒有權(quán)限查看里面的內(nèi)容。驗(yàn)證是否匹配的基本邏輯是上圖中的Key Server和Media Server共享一套密鑰算法和密鑰，它們都是部署在數(shù)據(jù)中心里的，里面的協(xié)議也都是我們內(nèi)部來(lái)實(shí)現(xiàn)的。此外，在這里還有一個(gè)算法來(lái)驗(yàn)證Token是否有二次的I/O請(qǐng)求和調(diào)用，這是一個(gè)常見的大規(guī)模高并發(fā)系統(tǒng)架構(gòu)設(shè)計(jì)的基礎(chǔ)原理，即盡量在某些場(chǎng)合巧妙的通過一些算法和驗(yàn)證減少I/O的請(qǐng)求和調(diào)用。

2）融云IM加速網(wǎng)絡(luò)

?

接下來(lái)，為大家介紹一下融云IM的加速網(wǎng)絡(luò)。從上圖中可以看出，我們的加速網(wǎng)絡(luò)模型是一個(gè)混合云，包含國(guó)內(nèi)私有部署、國(guó)外私有部署，目前已經(jīng)實(shí)現(xiàn)了國(guó)內(nèi)外的互通。需要跟大家介紹的是，國(guó)內(nèi)和國(guó)外的網(wǎng)絡(luò)之間訪問的質(zhì)量是受到影響的，因此對(duì)于國(guó)內(nèi)外的互通還需要進(jìn)行一些專門的優(yōu)化。這些優(yōu)化說(shuō)白了就是砸錢來(lái)解決問題，因此我們?cè)趪?guó)內(nèi)有自己的加速節(jié)點(diǎn)，在國(guó)外也有自己的加速節(jié)點(diǎn)，并且還可以在國(guó)內(nèi)外實(shí)現(xiàn)私有部署，包括把信令服務(wù)私有部署在用戶那里。舉例說(shuō)明，目前我們有一個(gè)客戶是一家國(guó)內(nèi)頂尖的IT企業(yè)，它的員工大概有十幾萬(wàn)人，遍布在全球的各個(gè)城市和大區(qū)，他們希望通過我們幫助建立企業(yè)內(nèi)部十幾萬(wàn)人之間的IM與RTC溝通。由于全球各個(gè)地區(qū)網(wǎng)絡(luò)情況復(fù)雜，他們自己的團(tuán)隊(duì)無(wú)法保證網(wǎng)絡(luò)質(zhì)量的問題，對(duì)于鏈路情況復(fù)雜和距離較遠(yuǎn)的情況也無(wú)法解決。最終，他們采用的是融云的解決方案，通過在北京的數(shù)據(jù)中心私有部署了一套IM的基礎(chǔ)設(shè)施服務(wù)，然后租用了融云的全球加速網(wǎng)絡(luò)，采用的就是經(jīng)典的混合云模式。

3）融云RTC SDK

?

融云RTC SDK就是我們將所有東西解耦之后所得到的另一個(gè)副產(chǎn)品。實(shí)際上，音視頻通信云服務(wù)領(lǐng)域已經(jīng)發(fā)展多年，在這個(gè)領(lǐng)域有一個(gè)很有意思的現(xiàn)象就是很多廠商把能力和功能耦合在一起。這就會(huì)導(dǎo)致如果我想做一個(gè)場(chǎng)景，那么就需要添加大量新的接口，而在大量新加的代碼里隱含著一個(gè)業(yè)務(wù)的場(chǎng)景和邏輯。前面講過，我們將RTC建連過程轉(zhuǎn)變成了Pub/Sub模型，使得系統(tǒng)變得極其簡(jiǎn)單，如同幾塊樂高積木一樣。因此，無(wú)論我們想要引入何種邏輯，比如兩人通話、多人會(huì)議、千人的會(huì)議、小班課、直播連麥等等。這些場(chǎng)景都可以通過簡(jiǎn)單的幾個(gè)模塊直接搭建出來(lái)，而我們要做的就是在上層將這一段業(yè)務(wù)場(chǎng)景或邏輯封裝成一個(gè)SDK，目前已有的SDK包括Call Kit、Call Lib等等，其中Kit指的就是UI Competent。舉例說(shuō)明，微信音視頻電話的場(chǎng)景，我們的SDK包含了這個(gè)場(chǎng)景的UI組件和通信組件，用戶想要實(shí)現(xiàn)這個(gè)場(chǎng)景直接引用SDK即可，不用再做任何二次開發(fā)的工作。類似地，會(huì)議會(huì)控、直播的UI組件和通信組件等等都會(huì)封裝成SDK。并且，我們會(huì)隨著用戶的需求通過這些積木實(shí)現(xiàn)不同的業(yè)務(wù)場(chǎng)景。?

?

接下來(lái)總結(jié)一下融云RTC SDK的特點(diǎn)：1）我們真正做到了SDK組件自底向上地單向依賴，并且SDK組件沒有任何交叉調(diào)用；2）架構(gòu)中間的可替換的信令層Signal Server與Media Server沒有任何關(guān)系，這意味著用戶可以使用我們的Media Server，使用自己的Signal Server，這個(gè)架構(gòu)完全實(shí)現(xiàn)了解耦；3）所有場(chǎng)景都全部實(shí)現(xiàn)組件化，因?yàn)樗鼈兊牡讓泳褪怯梅e木搭建出來(lái)。

?

六、未來(lái)計(jì)劃

?

最后，我們的架構(gòu)設(shè)計(jì)未來(lái)計(jì)劃是可以將Media Server做成Dockerfile，放到網(wǎng)站上供大家下載。我們還可以支持混合云模式，實(shí)現(xiàn)RTC Media Server的眾包。眾包指的就是用戶可以找尋合適的網(wǎng)絡(luò)，通過自己的硬件部署一個(gè)Dockerfile、架設(shè)一個(gè)自己寫的Media Server，還可以成為融云全球加速通信網(wǎng)的節(jié)點(diǎn)中的一員。第二種模式就是用戶租用融云的全球通信網(wǎng)，但可以實(shí)現(xiàn)私有的信令部署。再有一種模式就是用戶可以按照模型自建媒體服務(wù)，然后自建私有的信令部署。

?

LiveVideoStack? 招募

LiveVideoStack正在招募編輯/記者/運(yùn)營(yíng)，與全球頂尖多媒體技術(shù)專家和LiveVideoStack年輕的伙伴一起，推動(dòng)多媒體技術(shù)生態(tài)發(fā)展。同時(shí)，也歡迎你利用業(yè)余時(shí)間、遠(yuǎn)程參與內(nèi)容生產(chǎn)。了解崗位信息請(qǐng)?jiān)贐OSS直聘上搜索“LiveVideoStack”，或通過微信“Tony_Bao_”與主編包研交流。

LiveVideoStackCon 2019北京 音視頻技術(shù)大會(huì) 初版日程現(xiàn)已上線，掃描圖中二維碼或點(diǎn)擊【閱讀原文】了解大會(huì)最新日程。

總結(jié)

以上是生活随笔為你收集整理的去中心化的 RTC 通信平台架构设计的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

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