（2）Kurento之KMS通信架构

根据项目需求及Kurento协议，设计如下架构：

这个看起来貌似很复杂，但其实只是WebRTC的拓展而已，即中间加入第三方进行通信，所以任意一端和KMS实际上组成了原始的WebRTC架构。你可以只看左边或者右边的通信架构，即发现其实本质上一样的。在Kurento通信架构中，KMS和每个客户端（图中的Android和PC-Browser）组成了一个“通信对端”，视频数据首先经过KMS，然后在转发对端。注意：

1、只有相同颜色的箭头可以通信。
2、通信顺序依然为1、2、3。编号为1.的理解为同时进行，故2.、3.*的也是不分先后。
3、特别注意，如果KMS服务器部署在公网上（不处在NAT之后），则无需向stun/turn发出候选地址获取请求。这里使用了ICE的拓展协议：Trickle ICE。也叫异步ICE。即可以一边获取一边交换，同时如果本身网卡的IP地址就是公网地址，则本地IP可以直接通信，所以就不需要获取候选地址了。

关于是否处在NAT后，只需要查看自己网卡的IP地址（Linux下：ifconfig；Windows下：ipconfig）是否是公网地址就行了。而stun/turn服务是否有效，则在实际使用的机器上访问这个网页即可测试：

https://webrtc.github.io/samples/src/content/peerconnection/trickle-ice/

接下来将介绍每个服务器、DEMO的搭建测试过程，再然后介绍实际开发过程。