WebRTC Ice gathering never completes

• Component: WebRTC
• Status: RESOLVED FIXED

[Clement Wehrung]

Steps to reproduce: 
- In Chrome, the following test succeeds and returns results: https://webrtc.github.io/samples/src/content/peerconnection/trickle-ice/
- In Safari, it never completes (no error, no success) 

The following article specifically mentions this: https://webrtchacks.com/safari-webrtc/
"The ICE implementation appears to work the same as Chrome with Trickle. TURN/TLS seems unsupported. In addition the candidate gathering demo does not work as createOffer({offerToReceiveAudio})  has a bug and creates and offer without any m-lines."

[youenn fablet]

This test page is using a legacy option (offerToReceiveAudio: 1) that is not supported by Safari.
As you saw, the SDP is almost empty and no ICE candidate gathering will start.

The test would succeed gathering candidates if using:
- pc.addTransceiver('video');
- or pc.createDataChannel('test');

In both cases, you would expect to only see STUN/TURN candidates, not host ones.

[Clement Wehrung]

Thank you for your quick reply. It's good to know that this should not ever be expected to work in Safari. Would you believe it should be shimmed by webrtc-adapter? I feel like many apps will break with this currently.

[youenn fablet]

A shim in adapter.js for both offerToReceiveAudio and offerToReceiveVideo is a great idea!

I hope current WebRTC WebKit support would be sufficient for that but I haven't made the exercise.
Working on this shim would be very valuable.

@youenn fablet 

Why would I expect to only see STUN/TURN candidates?
Is it possible to also get the Host candidates?

[youenn fablet]

(In reply to sebastian.schenk from comment #4)
> @youenn fablet 
> 
> Why would I expect to only see STUN/TURN candidates?


Currently, WebKit only exposes Host addresses if camera and/or microphone access has been granted.
This prevents a privacy issue (IP address gathering).

> Is it possible to also get the Host candidates?

You can call getUserMedia.
In Safari, there is also a way in the developer/WebRTC menu to disable candidate filtering.

If you have a particular use case where host candidates are important and you do not want to request camera/microphone access, please describe it in bug 174500.