根據項目需求及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的搭建測試過程，再然後介紹實際開發過程。
