如何解决WebRTC 浏览器对等连接取决于创建报价的人
两个 Chrome 浏览器：Alice (A)、Bob (B)。 不同的网络，所以我使用 Coturn 服务器（我自己的）。
问题是，当 A 创建报价时 - 一切正常，冰连接状态变为“已连接”，一切正常。但是，如果 B 创建报价 - 每个对等方都会收到相同的 Ice 候选者，但 10 秒“检查”后的冰连接状态变为“断开连接”。这取决于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 并添加到他的对等连接的 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 并添加到他的对等连接的 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 并添加到他的对等连接的 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 并添加到他的对等连接的 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 并添加到他的对等连接的 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 并添加到他的对等连接的 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 的过程。 第二个 - 也许客户端的异步过程有一些问题（它不太好，但仍然如此） - 但为什么只在某些网络中？
解决方法
您没有获得任何带有 typ relay 的候选人，这意味着您仅将 TURN 服务器用作 STUN 服务器。有几个 NAT 可能会导致无法建立连接，具体取决于提供者。几年来，chrome 的 webrtc 实现中存在一个未解决的错误 here
一个正常工作的 TURN 服务器避免了这个问题。
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 dio@foxmail.com 举报，一经查实，本站将立刻删除。
