内网下chrome端webrtc协商失败
现象
我有一个webrtc服务器在局域网内,使用chrome浏览器访问时,发现webrtc在做媒体协商时失败。
具体表现是,在交换sdp后,ice的状态是oniceconnectionstatechange: failed
但是换成Firefox浏览器时,媒体沟通就成功了,语音可以正常发送。
分析
对比一下两者的sdp的区别
下面是Chrome 准备的candidate
{"candidate":"candidate:3173604209 1 udp 2113937151 e4a90cba-1bbb-4f52-a637-b19c53879494.local 53121 typ host generation 0 ufrag 8jU2 network-cost 999","sdpMid":"0","sdpMLineIndex":0,"usernameFragment":"8jU2"}
而Firefox 准备的candidate就多了
onIceCandidate:
{"candidate":"candidate:0 1 UDP 2122252543 192.168.56.1 53785 typ host","sdpMid":"0","sdpMLineIndex":0,"usernameFragment":"7565cd52"
}onIceCandidate:
{"candidate":"candidate:2 1 UDP 2122187007 192.168.35.14 53786 typ host","sdpMid":"0","sdpMLineIndex":0,"usernameFragment":"7565cd52"
}onIceCandidate:
{"candidate":"candidate:4 1 TCP 2105524479 192.168.56.1 9 typ host tcptype active","sdpMid":"0","sdpMLineIndex":0,"usernameFragment":"7565cd52"
} onIceCandidate:
{"candidate":"candidate:5 1 TCP 2105458943 192.168.35.14 9 typ host tcptype active","sdpMid":"0","sdpMLineIndex":0,"usernameFragment":"7565cd52"
}
这里主要区别是似乎Chrome准备的candidate没有任何内网ip信息!
Google了一下,原来是为了Google为了解决Webrtc leaks问题(主要是因为webrtc协商过程中携带了内网信息,可能会成为安全隐患)所以在chrome中默认隐藏了。
刚才我们在chrome的candidate中看到的 e4a90cba-1bbb-4f52-a637-b19c53879494.local,就是隐藏的内网信息。那么这个xxxx.local别人怎么识别呢? 这里要提一下mDNS了
什么是mDNS
mDNS(Multicast DNS,多播DNS)是一种基于DNS(域名系统)的协议,它允许局域网内的设备在没有传统DNS服务器的情况下相互发现和通信。mDNS使用组播技术,通过在局域网内发送广播消息来实现设备的发现和通信。它使用的默认端口是5353。
mDNS的工作原理是,当一个设备加入到局域网中,如果它开启了mDNS服务,就会向局域网内的所有设备发送组播消息,告知自己的存在以及IP地址等信息。其他开启mDNS服务的设备接收到这些消息后,就可以响应并提供自己的信息。这样,局域网内的设备就可以通过mDNS相互发现并知道彼此的IP地址,从而实现通信。
mDNS的限制
它的本意是在访问公网时,把内网信息隐藏。 但是如果是纯内网环境,这个功能就是多此一举了。 另外,如果要其他设备支持,也必须支持mDNS才可以。
所以回到我遇到的问题,之所以chrome不可以,就是因为它使用mDNS来隐藏了自己的内网信息。而局域网中的服务器不支持mDNS,所以无法获取到它的真实地址。
而Firefox可以,是因为Firefox没有采用这种方案。
解决方案
那么如何在chrome里正常使用呢?
在chrome中输入 chrome://flags/
然后找到Anonymize local IPs exposed by WebRTC
把它关掉,重启后就好了。
参考文档
https://bloggeek.me/psa-mdns-and-local-ice-candidates-are-coming/