[Webkit-unassigned] [Bug 186302] iOS does not call onIceCandidate

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=186302

--- Comment #7 from philipp.kuederli at gmail.com ---
(In reply to youenn fablet from comment #6)

> (In reply to philipp.kuederli from comment #5)
> > It seems that without calling getUserMedia it is not possible to create a
> > data channel because of security reasons, is this correct? I actually dont
> > understand what the connection between video/audio and a data channel is
> > about security reasons. If a data channel could be insecure, why should a
> > user be aware of this just because of accepting a camera. The whole thing
> > makes WebRtc useless as data channel, which would be a pity :-(
> > 
> > So the question is: Do I have to try at all to make it working, or is WebRTC
> > on Safari useless for data channels and I can forget it?
> 
> I understand your frustration here.
> We are limiting private IP addresses for privacy reasons as this is used by
> many many web sites to track users.


Hello Youenn, 

sorry for my frustration, somtimes this happens when things dont want to work. I am actually very happy that iOS supports WebRTC :-)


> https://youennf.github.io/webrtc-tests/src/content/peerconnection/trickle-
> ice/ should work and provide srflx candidates.
> I do not know why Safari 11.1.1 is working for you but not iOS11.3.1 since
> they should have the same behavior.


I think they behave the same. It was a confusion by me. In Safari Web Developer I chose "Disable Local ICE Candidate Restrictions", but I did not realize that the change does only take effect when opening a new window (most likely I just refreshed). So when I deactivated it still worked and I did not realize that I am still running in this "special" mode.


> We are working to enable this kind of data-channel-only scenarios, using
> MDNS ICE candidates.
> This is covered in https://bugs.webkit.org/show_bug.cgi?id=174500 and is
> behind a runtime flag, off by default.
> 
> In Safari Tech Preview, go to "Develop -> Experimental Features ->
> ...MDNS...."
> The latest iOS 12 seed might have this switch as well in "Settings -> Safari
> -> Advanced -> Experimental Features -> ...MDNS..."

Yes at least in my case a better data channel support woud be great, so it would be nice if this will come.

For the moment I installed "coturn" on my server as a TURN server and it works quite good. I can make a data channel over this and it seems to be more efficient than using WebSockets. So this was a really positive experience without having to implement something additional, just by installing a server.

For completeness, I use the following configuration:

- For connection (my IP and passwords hidden):

    new RTCPeerConnection{
      "iceServers": [
        {
          urls: [
            "turn:xxx.xxx.xxx.xxx:3478"
          ],
          username: "myuser",
          credential: "mypassword"
        }
      ],
      "iceTransportPolicy": "all",
      "iceCandidatePoolSize": "0"
    };

- For Data Channel I did not configure something additional so far:

    connection.createDataChannel("sendDataChannel")

- For Offer i used the legacy option, just because of the examples (most likely it has no effect in my case):

    connection.createOffer({offerToReceiveAudio: 1}) 



With this configurationI get the following two candidates where I choose the "relay" candidate, for the srflx I did not get a data channel onopen event (my IP hidden again):

   candidate: "candidate:842163049 1 udp 1677729535 188.62.109.27 63248 typ srflx raddr 0.0.0.0 rport 0 generation 0 ufrag 6K3E network-cost 50"
   sdpMLineIndex: 0
   sdpMid: "data"

   candidate: "candidate:2468224366 1 udp 33562367 xxx.xxx.xxx.xxx 52606 typ relay raddr 0.0.0.0 rport 0 generation 0 ufrag 6K3E network-cost 50"
   sdpMLineIndex: 0
   sdpMid: "data"


So thank you so far for your great support, I think this ticket can be closed. The answer was most likely, that I had to call getUserMedia to get the candidates.

Philipp

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20180607/a9c11f7a/attachment.html>