Bug 189503 – RTCDataChannel seems broken on iOS 11/12

• Component: WebRTC
• Status: NEW

[Chad Phillips]

None of the 'RTCDataChannel' examples at https://github.com/webrtc/samples work in Safari on iOS 11/12. These include: 

 - https://webrtc.github.io/samples/src/content/datachannel/basic/
 - https://webrtc.github.io/samples/src/content/datachannel/filetransfer/
 - https://webrtc.github.io/samples/src/content/datachannel/datatransfer/
 - https://webrtc.github.io/samples/src/content/datachannel/messaging/

All of those examples work on Safari on MacOS (as well as other browsers), and they are the gold standard for spec compliance, so I suspect something is broken for datachannels on iOS.

[youenn fablet]

Hi Chad,

These examples require host candidates which are not disclosed to JS except if using getUserMedia at the moment or MDNS ICE candidates.
Can you confirm that if you call getUserMedia from the web inspector, the data channel examples will work.

[Chad Phillips]

I can confirm that the following examples work after issuing a getUserMedia() request:

 - https://webrtc.github.io/samples/src/content/datachannel/basic/
 - https://webrtc.github.io/samples/src/content/datachannel/filetransfer/
 - https://webrtc.github.io/samples/src/content/datachannel/datatransfer/

The https://webrtc.github.io/samples/src/content/datachannel/messaging/ example doesn't work, throwing the following error:

[Error] Unhandled Promise Rejection: Error: render() not implemented
	update (lit-element.js:18)
	_validate (updating-element.js:362)
	(anonymous function) (updating-element.js:344)
	asyncFunctionResume
	(anonymous function)
	promiseReactionJob

Just so others are clear, the process to get code that uses local ICE candidates working on iOS is:

1. Set up the iOS device to connect to the Safari web inspector on an OS X machine: https://developer.apple.com/library/archive/documentation/AppleApplications/Conceptual/Safari_Developer_Guide/GettingStarted/GettingStarted.html
2. Open the example in Safari on iOS, but don't execute it yet
3. Open the web inspector for that page in the web inspector on the OS X device.
4. Go to the 'Console' tab
5. At the very bottom of the console there is a place to enter commands, fire off a getUserMedia() request from here: navigator.mediaDevices.getUserMedia({audio: true, video: true});
6. Accept the media device permissions request on the iOS Safari page.
7. Run the example code, and it should now have access to the local ICE candidates.

@youenn, thanks for pointing this out. It would be nice if this was a bit easier, or at least some intelligible error was thrown to inform the user about the issue and a possible workaround.

First of all, huge thanks for making WebRTC data channels available in Safari!

Is there any plan to change this behavior of not disclosing host candidates without granting access to mic and camera? Maybe it would be possible to introduce a separate native dialog or a browser setting that users could toggle to enable it?

Long time ago I developed a file sharing app that doesn't use mic or camera at all. It's going to be rather hard to explain to users that on iOS they need to grant my app access to their mic and camera, just to be able to send a file. In this particular case it actually makes it less secure.

[youenn fablet]

(In reply to szimek from comment #3)
> First of all, huge thanks for making WebRTC data channels available in
> Safari!
> 
> Is there any plan to change this behavior of not disclosing host candidates
> without granting access to mic and camera? Maybe it would be possible to
> introduce a separate native dialog or a browser setting that users could
> toggle to enable it?

For the reference, this is a topic under discussion.
See https://github.com/w3c/webrtc-pc/issues/2012 for more information.

> 
> Long time ago I developed a file sharing app that doesn't use mic or camera
> at all. It's going to be rather hard to explain to users that on iOS they
> need to grant my app access to their mic and camera, just to be able to send
> a file. In this particular case it actually makes it less secure.

We recently enabled MDNS ICE candidates by default in WebKit ToT.
This should enable Safari <-> Safari connections in networks supporting MDNS.
@szimek, would that help?

WebKit <-> Chrome or WebKit <-> Native app should work in most cases as Chrome/native apps provide host ICE candidates.