1. 简介:
本文通过web和janus进行实时音视频通信的Demo,结合rfc-5245来学习ice交换的过程。
2. 测试模型
本文测试模型为一个NAT内的web的客户端,向一个NAT内的janus服务器发起请求。
3. rfc 5245
本文只捡基础的一个流程进行分析,5245协议本身囊括的内容较多。(这里主要围绕2, 2.1, 2.2三段)。
ICE的过程主要分为三个过程:
1) 各个peer首先向各自的stun server请求,获取各自的对外IP。(非必须)
2) 各个peer收集自己的ice candidate,这里包括了本机的local地址,及打洞后获取的对外IP,双方交换ice candidate。
3) 各个peer收到对应的ice candidate后,排序后向各个candidate发起stun请求,用stun协议进行连通性测试,通过后择优。
4. 过程分析
本次例子客户端发往打洞服务器被墙……,从抓包上来看,客户端打洞请求发出,但是没有收到对端服务器的响应,而服务端响应正常。
下图为客户端打洞请求,但是并没有从相应的服务器得到相应的回复。
下图为服务端的打洞请求,服务端收到了打洞服务器的响应,并得到了自己的对外IP和端口。
接着我们继续查看客户端发给服务端的请求,这里还是查找POST请求,我们会发现,这里发送给服务端的ice candidate中都是NAT内部的IP。
服务端日志上正是收到如上部分的candidate。
[5261413890922073] Trickle candidate (sdparta_0): candidate:0 1 UDP 2122252543 192.168.0.102 55349 typ host
[5261413890922073] Trickle candidate (sdparta_0): candidate:0 2 UDP 2122252542 192.168.0.102 59517 typ host
[5261413890922073] Trickle candidate (sdparta_1): candidate:0 2 UDP 2122252542 192.168.0.102 50268 typ host
[5261413890922073] Trickle candidate (sdparta_1): candidate:0 1 UDP 2122252543 192.168.0.102 50842 typ host
[5261413890922073] Trickle candidate (sdparta_2): candidate:0