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

WebRTC browser peerconnection depends on who creates an offer

两个 Chrome 浏览器:爱丽丝 (A)、鲍勃 (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 并添加到他的对等连接的 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 并添加到他的 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 

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

您没有得到任何具有 typ relay 的候选人,这意味着您仅将 TURN 服务器用作 STUN 服务器。有几个 NAT 可能会导致无法建立连接,具体取决于提供者。 chrome 的 webrtc 实现中有一个开放的错误已经有几年了 here

工作的 TURN 服务器避免了这个问题。