WebRTC 浏览器对等连接取决于谁创建了报价答案

【问题标题】：WebRTC browser peerconnection depends on who creates an offerWebRTC 浏览器对等连接取决于谁创建了报价
【发布时间】：2021-02-11 22:35:06
【问题描述】：

两个 Chrome 浏览器：Alice (A)、Bob (B)。不同的网络，所以我使用的是 Coturn 服务器（我自己的）。

问题在于，当 A 创建报价时 - 一切正常，ice 连接状态变为“已连接”，一切正常。但是如果 B 创建提议 - 每个对等点都收到相同的 Ice 候选者，但 10 秒后的 ice 连接状态“检查”变为“断开连接”。这取决于B在哪个网络中。只有在某些网络上才会出现这样的问题。

详情如下：

不工作的情况：

B 创建报价。他的描述符是：

v=0  
o=- 8029235411980231901 2 IN IP4 127.0.0.1  
s=-  
t=0 0  
a=group:BUNDLE 0 1  
a=msid-semantic: WMS ZX5bxsJkF64NCyKHSLQyIbHoU0nLjkjehVPE  
m=audio 9 UDP\/TLS\/RTP\/SAVPF 111 103 104 9 0 8 106 105 13 110 112 113 126  
c=IN IP4 0.0.0.0  
a=rtcp:9 IN IP4 0.0.0.0  
a=ice-ufrag:L8TQ  
a=ice-pwd:sQx1uSKfnmvUAsXBrzRlLJzw  
a=ice-options:trickle  
a=fingerprint:sha-256 25:12:9F:F2:50:A7:68:F0:73:C9:E7:87:C5:44:CD:CE:7E:14:12:3D:BF:E0:52:2F:3B:5C:7E:1B:29:35:DF:77  
a=setup:actpass  
a=mid:0  
a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level  
a=extmap:2 http:\/\/www.webrtc.org\/experiments\/rtp-hdrext\/abs-send-time  
a=extmap:3 http:\/\/www.ietf.org\/id\/draft-holmer-rmcat-transport-wide-cc-extensions-01  
a=extmap:4 urn:ietf:params:rtp-hdrext:sdes:mid  
a=extmap:5 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id  
a=extmap:6 urn:ietf:params:rtp-hdrext:sdes:repaired-rtp-stream-id  
a=sendrecv  
a=msid:ZX5bxsJkF64NCyKHSLQyIbHoU0nLjkjehVPE 4f8d8244-9ed8-4128-b4bd-3cdaaeb31ef3  
a=rtcp-mux  
a=rtpmap:111 opus\/48000\/2  
a=rtcp-fb:111 transport-cc  
a=fmtp:111 minptime=10;useinbandfec=1  
a=rtpmap:103 ISAC\/16000  
a=rtpmap:104 ISAC\/32000  
a=rtpmap:9 G722\/8000  
a=rtpmap:0 PCMU\/8000  
a=rtpmap:8 PCMA\/8000  
a=rtpmap:106 CN\/32000  
a=rtpmap:105 CN\/16000  
a=rtpmap:13 CN\/8000  
a=rtpmap:110 telephone-event\/48000  
a=rtpmap:112 telephone-event\/32000  
a=rtpmap:113 telephone-event\/16000  
a=rtpmap:126 telephone-event\/8000  
a=ssrc:2775790640 cname:yRYToPhoe5nm5Lkn  
a=ssrc:2775790640 msid:ZX5bxsJkF64NCyKHSLQyIbHoU0nLjkjehVPE 4f8d8244-9ed8-4128-b4bd-3cdaaeb31ef3  
a=ssrc:2775790640 mslabel:ZX5bxsJkF64NCyKHSLQyIbHoU0nLjkjehVPE  
a=ssrc:2775790640 label:4f8d8244-9ed8-4128-b4bd-3cdaaeb31ef3  
m=video 9 UDP\/TLS\/RTP\/SAVPF 96 97 98 99 100 101 102 121 127 120 125 107 108 109 124 119 123
c=IN IP4 0.0.0.0  
a=rtcp:9 IN IP4 0.0.0.0  
a=ice-ufrag:L8TQ  
a=ice-pwd:sQx1uSKfnmvUAsXBrzRlLJzw  
a=ice-options:trickle  
a=fingerprint:sha-256 25:12:9F:F2:50:A7:68:F0:73:C9:E7:87:C5:44:CD:CE:7E:14:12:3D:BF:E0:52:2F:3B:5C:7E:1B:29:35:DF:77  
c  
a=mid:1  
a=extmap:14 urn:ietf:params:rtp-hdrext:toffset  
a=extmap:2 http:\/\/www.webrtc.org\/experiments\/rtp-hdrext\/abs-send-time  
a=extmap:13 urn:3gpp:video-orientation  
a=extmap:3 http:\/\/www.ietf.org\/id\/draft-holmer-rmcat-transport-wide-cc-extensions-01  
a=extmap:12 http:\/\/www.webrtc.org\/experiments\/rtp-hdrext\/playout-delay  
a=extmap:11 http:\/\/www.webrtc.org\/experiments\/rtp-hdrext\/video-content-type  
a=extmap:7 http:\/\/www.webrtc.org\/experiments\/rtp-hdrext\/video-timing  
a=extmap:8 http:\/\/www.webrtc.org\/experiments\/rtp-hdrext\/color-space  
a=extmap:4 urn:ietf:params:rtp-hdrext:sdes:mid  
a=extmap:5 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id  
a=extmap:6 urn:ietf:params:rtp-hdrext:sdes:repaired-rtp-stream-id  
a=sendrecv  
a=msid:ZX5bxsJkF64NCyKHSLQyIbHoU0nLjkjehVPE 65e0c0d9-234e-41ec-ba90-0bde346b97f7  
a=rtcp-mux  
a=rtcp-rsize  
a=rtpmap:96 VP8\/90000  
a=rtcp-fb:96 goog-remb  
a=rtcp-fb:96 transport-cc  
a=rtcp-fb:96 ccm fir  
a=rtcp-fb:96 nack  
a=rtcp-fb:96 nack pli  
a=rtpmap:97 rtx\/90000  
a=fmtp:97 apt=96  
a=rtpmap:98 VP9\/90000  
a=rtcp-fb:98 goog-remb  
a=rtcp-fb:98 transport-cc  
a=rtcp-fb:98 ccm fir  
a=rtcp-fb:98 nack  
a=rtcp-fb:98 nack pli  
a=fmtp:98 profile-id=0  
a=rtpmap:99 rtx\/90000  
a=fmtp:99 apt=98  
a=rtpmap:100 VP9\/90000  
a=rtcp-fb:100 goog-remb  
a=rtcp-fb:100 transport-cc  
a=rtcp-fb:100 ccm fir  
a=rtcp-fb:100 nack  
a=rtcp-fb:100 nack pli  
a=fmtp:100 profile-id=2  
a=rtpmap:101 rtx\/90000  
a=fmtp:101 apt=100  
a=rtpmap:102 H264\/90000  
a=rtcp-fb:102 goog-remb  
a=rtcp-fb:102 transport-cc  
a=rtcp-fb:102 ccm fir  
a=rtcp-fb:102 nack  
a=rtcp-fb:102 nack pli  
a=fmtp:102 level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=42001f  
a=rtpmap:121 rtx\/90000  
a=fmtp:121 apt=102  
a=rtpmap:127 H264\/90000  
a=rtcp-fb:127 goog-remb  
a=rtcp-fb:127 transport-cc  
a=rtcp-fb:127 ccm fir  
a=rtcp-fb:127 nack  
a=rtcp-fb:127 nack pli  
a=fmtp:127 level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=42e01f  
a=rtpmap:120 rtx\/90000  
a=fmtp:120 apt=127  
a=rtpmap:125 H264\/90000  
a=rtcp-fb:125 goog-remb  
a=rtcp-fb:125 transport-cc  
a=rtcp-fb:125 ccm fir  
a=rtcp-fb:125 nack  
a=rtcp-fb:125 nack pli  
a=fmtp:125 level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=4d001f  
a=rtpmap:107 rtx\/90000  
a=fmtp:107 apt=125  
a=rtpmap:108 H264\/90000  
a=rtcp-fb:108 goog-remb  
a=rtcp-fb:108 transport-cc  
a=rtcp-fb:108 ccm fir  
a=rtcp-fb:108 nack  
a=rtcp-fb:108 nack pli  
a=fmtp:108 level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=64001f  
a=rtpmap:109 rtx\/90000  
a=fmtp:109 apt=108  
a=rtpmap:124 red\/90000  
a=rtpmap:119 rtx\/90000  
a=fmtp:119 apt=124  
a=rtpmap:123 ulpfec\/90000  
a=ssrc-group:FID 2392484040 323248106  
a=ssrc:2392484040 cname:yRYToPhoe5nm5Lkn  
a=ssrc:2392484040 msid:ZX5bxsJkF64NCyKHSLQyIbHoU0nLjkjehVPE 65e0c0d9-234e-41ec-ba90-0bde346b97f7  
a=ssrc:2392484040 mslabel:ZX5bxsJkF64NCyKHSLQyIbHoU0nLjkjehVPE  
a=ssrc:2392484040 label:65e0c0d9-234e-41ec-ba90-0bde346b97f7  
a=ssrc:323248106 cname:yRYToPhoe5nm5Lkn  
a=ssrc:323248106 msid:ZX5bxsJkF64NCyKHSLQyIbHoU0nLjkjehVPE 65e0c0d9-234e-41ec-ba90-0bde346b97f7  
a=ssrc:323248106 mslabel:ZX5bxsJkF64NCyKHSLQyIbHoU0nLjkjehVPE  
a=ssrc:323248106 label:65e0c0d9-234e-41ec-ba90-0bde346b97f7

从 A 接收 B 并添加到他的 peerconnection 的 Ice 候选人：

candidate:3596738868 1 udp 2122260223 192.168.1.16 60011 typ host generation 0 ufrag UxdQ network-id 1  
candidate:544315616 1 udp 1686052607 {A ip here} 60011 typ srflx raddr 192.168.1.16 rport 60011 generation 0 ufrag UxdQ network-id 1  
candidate:2564955588 1 tcp 1518280447 192.168.1.16 9 typ host tcptype active generation 0 ufrag UxdQ network-id 1

从 B 接收 A 并添加到他的 peerconnection 的 Ice 候选者：

candidate:211156821 1 udp 2122260223 192.168.1.5 57710 typ host generation 0 ufrag L8TQ network-id 1 network-cost 10  
candidate:211156821 1 udp 2122260223 192.168.1.5 57711 typ host generation 0 ufrag L8TQ network-id 1 network-cost 10  
candidate:2781507712 1 udp 1686052607 {B ip here} 8101 typ srflx raddr 192.168.1.5 rport 57710 generation 0 ufrag L8TQ network-id 1 network-cost 10  
candidate:2781507712 1 udp 1686052607 {B ip here} 8102 typ srflx raddr 192.168.1.5 rport 57711 generation 0 ufrag L8TQ network-id 1 network-cost 10  
candidate:1108738981 1 tcp 1518280447 192.168.1.5 9 typ host tcptype active generation 0 ufrag L8TQ network-id 1 network-cost 10  
candidate:1108738981 1 tcp 1518280447 192.168.1.5 9 typ host tcptype active generation 0 ufrag L8TQ network-id 1 network-cost 10

之后，两个对等连接都进入“检查”状态（我的意思是冰连接状态）。大约 15 秒后，他们会“断开连接”

工作案例：
有时，即使 B 创建了报价，对等点也会连接，但很少见。因此，这里有 2 种情况 - B 创建报价时，以及 A 时。
我不会在此处粘贴 SDP，因为它始终相同（与 a=setup:actpass|active 不同）。

B 创建报价（但现在有效！）：

从 A 接收 B 并添加到他的 peerconnection 的 Ice 候选人：

candidate:3596738868 1 udp 2122260223 192.168.1.16 58234 typ host generation 0 ufrag kplj network-id 1  
candidate:544315616 1 udp 1686052607 {A ip here} 58234 typ srflx raddr 192.168.1.16 rport 58234 generation 0 ufrag kplj network-id 1  
candidate:2564955588 1 tcp 1518280447 192.168.1.16 9 typ host tcptype active generation 0 ufrag kplj network-id 1

从 B 接收 A 并添加到他的 peerconnection 的 Ice 候选者：

candidate:211156821 1 udp 2122260223 192.168.1.5 55597 typ host generation 0 ufrag THyF network-id 1 network-cost 10  
candidate:211156821 1 udp 2122260223 192.168.1.5 55598 typ host generation 0 ufrag THyF network-id 1 network-cost 10  
candidate:2781507712 1 udp 1686052607 {B ip here} 10637 typ srflx raddr 192.168.1.5 rport 55597 generation 0 ufrag THyF network-id 1 network-cost 10  
candidate:2781507712 1 udp 1686052607 {B ip here} 10646 typ srflx raddr 192.168.1.5 rport 55598 generation 0 ufrag THyF network-id 1 network-cost 10  
candidate:1108738981 1 tcp 1518280447 192.168.1.5 9 typ host tcptype active generation 0 ufrag THyF network-id 1 network-cost 10  
candidate:1108738981 1 tcp 1518280447 192.168.1.5 9 typ host tcptype active generation 0 ufrag THyF network-id 1 network-cost 10

A 创建报价（始终有效）：

从 A 接收 B 并添加到他的 peerconnection 的 Ice 候选人：

candidate:3596738868 1 udp 2122260223 192.168.1.16 60034 typ host generation 0 ufrag WGEW network-id 1  
candidate:3596738868 1 udp 2122260223 192.168.1.16 60035 typ host generation 0 ufrag WGEW network-id 1  
candidate:544315616 1 udp 1686052607 {A ip here} 60034 typ srflx raddr 192.168.1.16 rport 60034 generation 0 ufrag WGEW network-id 1  
candidate:544315616 1 udp 1686052607 {A ip here} 60035 typ srflx raddr 192.168.1.16 rport 60035 generation 0 ufrag WGEW network-id 1  
candidate:2564955588 1 tcp 1518280447 192.168.1.16 9 typ host tcptype active generation 0 ufrag WGEW network-id 1  
candidate:2564955588 1 tcp 1518280447 192.168.1.16 9 typ host tcptype active generation 0 ufrag WGEW network-id 1

从 B 接收 A 并添加到他的 peerconnection 的 Ice 候选人：

candidate:211156821 1 udp 2122260223 192.168.1.5 49288 typ host generation 0 ufrag QIgM network-id 1 network-cost 10  
candidate:2781507712 1 udp 1686052607 {B ip here} 13932 typ srflx raddr 192.168.1.5 rport 49288 generation 0 ufrag QIgM network-id 1 network-cost 10  
candidate:1108738981 1 tcp 1518280447 192.168.1.5 9 typ host tcptype active generation 0 ufrag QIgM network-id 1 network-cost 10

所以，唯一的区别在于 srflx 端口 - 也许当它低于 10000 时，它会阻止 UDP 数据包？但是我们能用这个做什么 - 我们不控制这些端口，以及 Coturn 发现 ICE 的过程。第二个 - 可能是客户端异步进程的一些问题（它不太可能，但仍然存在） - 但为什么只在某些网络中？

【问题讨论】：

标签： google-chrome webrtc stun turn

【解决方案1】：

你没有得到任何typ relay 的候选人，这意味着你只是将你的 TURN 服务器用作 STUN 服务器。有几个 NAT 可能会导致无法建立连接，具体取决于谁提供。几年来，chrome 的 webrtc 实现中存在一个未解决的错误here

一个正常工作的 TURN 服务器可以避免这个问题。

【讨论】：

谢谢！你是对的，问题出在 Coturn 配置错误（TURN 无法正常工作）。尽管您可能会对对等连接（非对称呼叫/被呼叫者）的奇怪行为感到困惑，但问题在于 TURN，在面对某种类型的 NAT 时您需要它。此外，如果有人有类似的问题：您可以通过在客户端的 peerconnection 配置中传递 iceTransportPolicy:relay 来测试您的 TURN 服务器 - 这样您的客户端将只接收和使用“中继”类型的冰候选