I'm not sure if it's use of an old API or misconfiguration on my side, but STUN and TURN don't seem to work with the current Safari Technology Preview. I used two tests. The first one - our own - can be found at https://web.threema.ch/troubleshoot/ (click the "click to test" button on the bottom part of the page to start). The source code can be found here: https://web.threema.ch/troubleshoot/troubleshoot.js The page also uses adapter.js. The test first creates a new RTCPeerConnection with three server entries (TCP, UDP and TLS). It then creates a new datachannel (to trigger the negotiation needed flag) and an offer. The offer should trigger collection of ICE candidates in the browser. This does not seem to happen. The second test is the WebRTC Trickle Ice Demo found at https://webrtc.github.io/samples/src/content/peerconnection/trickle-ice/ in default configuration. No candidates are gathered. I'm aware that Safari does candidate filtering (see Bug 173052). But checking "Disable ICE candidate filtering" does not change the behavior (and it wouldn't make sense either since relay candidates do not leak local IP addresses). Both tests work fine in Firefox and Chromium. (PS: You should probably add a WebRTC component to your Bugzilla.)
Both instances here are due to the fact that we filter private IPs out in DataChannel-only situations. *** This bug has been marked as a duplicate of bug 173052 ***
The trickle ice test is not working as it uses offerToReceiveAudio option that we do not support. If you create a data channel instead, the test works. As of your webpage, can you describe how you are testing stun/turn? Do you receive a callback with no candidates, meaning that ice gathering was done?
> Both instances here are due to the fact that we filter private IPs out in DataChannel-only situations. But we're talking about TURN here. Relay candidates are *not* private IPs. > As of your webpage, can you describe how you are testing stun/turn? The test first creates a new RTCPeerConnection with three server entries (TCP, UDP and TLS). It then creates a new datachannel (to trigger the negotiation needed flag) and an offer. The offer should trigger collection of ICE candidates in the browser. I log every candidate found to the debug console. When disabling ICE candidate filtering in the media flags, I get two local candidates (IPv4 and IPv6), but srflx or relay candidates never show up. > Do you receive a callback with no candidates, meaning that ice gathering was done? Yes, after some time I receive a callback (pc.onicecandidate) with a null candidate. But no other candidates are gathered. For reference, the code can be found here: https://web.threema.ch/troubleshoot/troubleshoot.js I do not think that this is a duplicate of bug 173052.
Reopening for further study
> I log every candidate found to the debug console. When disabling ICE > candidate filtering in the media flags, I get two local candidates (IPv4 and > IPv6), but srflx or relay candidates never show up. We had an issue in the past with TLS using SNI that was blocking candidate gathering (see https://bugs.webkit.org/show_bug.cgi?id=171747). Maybe we have another issue there. Looking at your JS, you have 3 possible STUN/TURN servers. Can you try gathering candidates with each one of them and see whether you get some results?
Yes, there are 3 servers, but they all point to the same instance (just with different configuration). I tried it again with just "turn:turn.threema.ch:443" as the only ICE server, which didn't help either. Ports other than the default port (443 in this case) should be supported, right? I'm not sure whether SNI is involved, there is no proxy in front of the coturn server.
I tried https://youennf.github.io/webrtc-tests/src/content/peerconnection/trickle-ice/ which is a modified version of webrtc.github.io trickle test with data channel. turn:turn.threema.ch:443?transport=udp and turn:turn.threema.ch:443?transport=tcp seems to work like in Chrome. turns:turn.threema.ch:443 seems to be the cause of the issue.
(In reply to youenn fablet from comment #7) > I tried > https://youennf.github.io/webrtc-tests/src/content/peerconnection/trickle- > ice/ > which is a modified version of webrtc.github.io trickle test with data > channel. > > turn:turn.threema.ch:443?transport=udp and > turn:turn.threema.ch:443?transport=tcp seems to work like in Chrome. That did not work for me. I simply don't get any candidates (with or without credentials), after 40 seconds it shows a "Not reachable?" message. If I disable host candidate filtering, I get the two host candidates (IPv4 / IPv6) but nothing else. Chrome on the same machine with the same configuration gathers 12 host candidates, 3 srflx candidates and 6 relay candidates. > turns:turn.threema.ch:443 seems to be the cause of the issue. Even if TURNS would not be supported, that should not affect whether TURN or STUN work.
<rdar://problem/34134293>
I don't think that this is a duplicate of 34134293. That other issue seems to deal with sending large chunks through a data channel, while this issue is about some ICE candidates not being gathered.
Oh, sorry for the comment, I thought that the bug importer comment had something to do with the marking as duplicated, but it seems unrelated.
Danilo, I tried again with your TURN server and did not find any issue. I guess there has been a change of configuration that fixed the issue. Can you confirm this? I'll close the bug but please reopen it if needed and let me know if you did any fix on your side.
youenn, I tested again, with your trickle ice example: https://youennf.github.io/webrtc-tests/src/content/peerconnection/trickle-ice/ When using "stun:turn.threema.ch", gathering srflx candidates seems to work indeed. Same counts for "turn:turn.threema.ch" with correct credentials (this also includes relay candidates). We did indeed change something about the configuration: The DNS server for turn.threema.ch used to return both A records (IPv4) and AAAA records (IPv6). Now it only returns A records (see "dig +short AAAA turn.threema.ch"). We created another hostname for dual-stack access: ds-turn.threema.ch with both A and AAAA records (see "dig +short AAAA ds-turn.threema.ch"). Both DNS names return the same three server IPs running Coturn. While gathering srflx candidates in Safari 11 works with stun:turn.threema.ch, it does not return any results for stun:ds-turn.threema.ch. It does work in Chrome however. So maybe this could be an issue with IPv6? Danilo
As a sidenote, when using "turn:turn.threema.ch" without credentials in your trickle ice test page, the tab in Safari 11 crashes immediately and reproducibly (tested on 2 different computers).
(In reply to Danilo from comment #14) > As a sidenote, when using "turn:turn.threema.ch" without credentials in your > trickle ice test page, the tab in Safari 11 crashes immediately and > reproducibly (tested on 2 different computers). Thanks for the additional information. Can you send me the crash logs? Have you tried on STP52?
Created attachment 337485 [details] Safari crash log
Segfault does not seem to happen on STP53 though (released April 4th).