WebRTC browser peerconnection depends on who creates an offer - google-chrome

Question

Two Chrome browsers: Alice (A), Bob (B).
Different networks, so i'm using Coturn server (my own).
The problem is that when A creates an offer - everything is ok, ice connection state goes to "connected", everything works fine. But if B creates offer - every peer receives the same Ice candidates, but ice connection state after 10 sec "checking" goes to "disconnected". It depends on in what network is B. Only on some networks there is such problem.
Here are the details:
Not working case:
B creates an offer. His descriptor is:
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
Ice candidtates that receives B from A and adds to his peerconnection:
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
Ice candidates that receives A from B and adds to his peerconnection:
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
After that both peerconnections go to "checking" state (I mean ice connection state). After ~15 sec they go to "disconnected"
Working case:
Sometimes peers are connected even when B creates an offer, but quite rarely. So, here are 2 cases - when B creates an offer, and when A.
I will not paste SDP here, cause it is always the same (differs with a=setup:actpass|active).
B creates an offer (but now working!):
Ice candidtates that receives B from A and adds to his peerconnection:
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
Ice candidates that receives A from B and adds to his peerconnection:
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 creates an offer (works always):
Ice candidtates that receives B from A and adds to his peerconnection:
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
Ice candidtates that receives A from B and adds to his peerconnection:
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
So, the olny difference is with srflx port - maybe when it is below 10000, it blocks UDP packets? But what can we do with this - we do not control these ports, and the process of ICE discovery by Coturn.
The second - maybe some problems with async proccesses on client side (it is less lickely, but still) - but why only in some networks?

Answer 1

You are not getting any candidates with typ relay which means you are only using your TURN server as a STUN server. There are a couple of NATs where that can lead to a failure to establish the connection depending on who offers. There is an open bug in chrome's webrtc implementation for a couple of years now here
A working TURN server avoids the problem.