如上圖所示包含有五個角色，分別是Client A、Client A對應的Media Server、IM Server、Client B對應的Media Server、Client B。Client A是通信的發起方，IM Server就是我們的Signal Server。在這個架構里面，我們引入Pub/Sub模型來實現解耦，下面將分兩部分講解。

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

Sub過程：與前面相同，Client B也要通過Smart DNS找到一個相對來說質量最好的Media Server，然后調用其另外一個接口將剛才傳過來的信息告訴這個Media Server。當Client B對應的Media Server拿到了Client A對應的Media Server的信息后，由Resource ID就可以知道要將Client A和Client B之間建立連接，在內部建立關聯后返回一個ACK，說明已經調用成功。一旦Client A和Client B建立RTC連接成功后，Client A對應的Media Server和Client B對應的Media Server就建立起了級聯。

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

總結一下，融云的RTC建連過程采用了極簡的接口設計。如上述的時序圖，有幾次HTTP調用實際上全都是通過一個HTTP接口來實現的，而這一個HTTP接口通過傳遞不同的參數就非常簡單的實現了發布/取消發布流，SFU和MCU的訂閱/取消訂閱。