Safari 11 ICE candidates don't work

[Andrew Parker]

Does anyone know exactly what behaviour is expected with Safari 11 and WebRTC ice candidates?

Try the following site https://browserleaks.com/webrtc.

• Browse to that site
  
• I see my public IP address 
  
• Grant audio/video permissions
  
• I see some local IPs and my IPv6 address 
  

This is slightly strange behaviour in itself. Why do I see my public IPv4 address without permissions?

Now if I check under Develop->WebRTC->Enable Legacy API I see this option is checked. Since Safari 11 claims to be WebRTC compliant and they also claim that API is deprecated then I tried disabling it. However, once disabled, if I refresh the page I see no IPs (permissions or not).

If I close the browser and reopen then Enable Legacy API has been set again! 

What on earth is going on? It's as if they're saying, actually we didn't finish support for this so we're going to leave the legacy APIs there for now as a stop gap. But this contradicts their release notes.

One other thing to note is that you can also set Develop->WebRTC->Disable ICE Candidate Restrictions. This seems to remove the need for permissions in order to get ice candidates. I guess that would make sense as a developer option. Wonder if there's any other reason that it's there.

Note that I intend to file a bug with Apple, but I was hoping there'd be some expertise here readily available. My experience with Apple bug reports is at best a long wait, at worst no reply at all.

[Nils Ohlmeier]

On Nov 15, 2017, at 09:50, Andrew Parker <andrew.j...@gmail.com> wrote:

Does anyone know exactly what behaviour is expected with Safari 11 and WebRTC ice candidates?

Try the following site https://browserleaks.com/webrtc.

• Browse to that site
  
• I see my public IP address 
  
• Grant audio/video permissions
  
• I see some local IPs and my IPv6 address 
  

This is slightly strange behaviour in itself. Why do I see my public IPv4 address without permissions?

Because the page opens a RTCPeerConnection with a data channel. And because you haven’t granted any camera permissions the address of your default route is handed out. But the same information can also be gathered from making a HTTP request from your browser to their web server. So no need to use WebRTC at all for that.

BTW all other browsers show the same behavior.

Now if I check under Develop->WebRTC->Enable Legacy API I see this option is checked. Since Safari 11 claims to be WebRTC compliant and they also claim that API is deprecated then I tried disabling it. However, once disabled, if I refresh the page I see no IPs (permissions or not).

If I close the browser and reopen then Enable Legacy API has been set again! 

What on earth is going on? It's as if they're saying, actually we didn't finish support for this so we're going to leave the legacy APIs there for now as a stop gap. But this contradicts their release notes.

Most likely the page you are using uses API calls which Apple considers Legacy. So if you turn that off the JS code on the page no longer works. That does not mean the WebRTC implementation in Safari is disabled at that point.

Best

  Nils Ohlmeier

[Andrew Parker]

Understood re the IPv4 address being available without WebRTC. Just felt a little inconsistent to me. BTW most other browsers actually show more IPs in this situation. There's definitely inconsistency here between what's visible depending on whether permissions have been granted.

Anyway, on the real problem. Yes, I was using a legacy API. I hadn't looked deep enough. The RTCPeerConnection class was not deprecated so I thought the code should still work. But the actual problem was when createOffer was called. My code (and BrowserLeaks etc) was using the old callback version of this function rather than the promise version. See here: https://developer.mozilla.org/en-US/docs/Web/API/RTCPeerConnection/createOffer

With that fix I now see Safari WebRTC working without the Legacy API. I presume they'll just disable that flag for the Legacy API eventually.

Thanks for the nudge in the right direction!