(2)Kurento之KMS通信架构

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

(2)Kurento之KMS通信架构_第1张图片

这个看起来貌似很复杂,但其实只是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的搭建测试过程,再然后介绍实际开发过程。

你可能感兴趣的:(WebRTC/Kurento,Kurento项目开发教程)