详解融云的RTC建连过程

如上图所示包含有五个角色，分别是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的订阅/取消订阅。