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."
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.
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.
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?
(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.