【webrtc】Chrome和Firefox在SDP协商过程中，针对localhost的不同处理

本文主要是介绍【webrtc】Chrome和Firefox在SDP协商过程中，针对localhost的不同处理，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

内网下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地址，从而实现通信。