Bug 186302 – iOS does not call onIceCandidate

• Status: RESOLVED
• Resolution: DUPLICATE
• Component: WebRTC

I can create a data channels for the following:
- MacOS Safari 11.1.1 (on older it did not work)
- Chrome (always worked)
- Android (always worked)

However onIceCandidate is never called on iOS. 

The latest try was with iOS 11.3.1. 

The following offer was created without candidates: 

v=0
o=- 1552489341325168126 2 IN IP4 127.0.0.1
s=-
t=0 0
a=group:BUNDLE data
a=msid-semantic: WMS
m=application 9 DTLS/SCTP 5000
c=IN IP4 0.0.0.0
a=ice-ufrag:QqDF
a=ice-pwd:X9yzupGuGY8xQ6NbGWMHZtVD
a=ice-options:trickle
a=fingerprint:sha-256 0A:DE:0F:E5:C4:3B:BC:34:93:CF:91:CE:12:9A:D1:B7:39:79:3B:B7:F5:CD:BE:F0:A4:2D:D5:49:D8:82:29:9F
a=setup:actpass
a=mid:data
a=sctpmap:5000 webrtc-datachannel 1024

[youenn fablet]

Can you provide a test case?
https://youennf.github.io/webrtc-tests/src/content/peerconnection/trickle-ice/ is doing just that and is supposed to be working on iOS.

Your link neither worked on iOS Safari. I reduced the whole example to the simple gathering. The project example file is here: 
https://github.com/kudi82/webrtc-ios/blob/master/static/webrtc.js

The code should actually be the same as in your link, but also does not work (no candidates):

##################################################################

var config = {
  'iceServers': [
    {
      urls: [
        'stun:stun.l.google.com:19302'
      ]
    }
  ],
  'iceTransportPolicy': 'all',
  'rtcpMuxPolicy': 'negotiate'
};

var constraints = {
  optional: [
    { 'RtpDataChannels': false }
  ]
}

var constraints = {
  optional: [
    { 'googIPv6': true }
  ]
}

var offerOptions = {
  offerToReceiveAudio: 1
}


var connection = new RTCPeerConnection(config, constraints);

connection.createDataChannel('channel');

connection.onicecandidate = function(event) {
  appendCandidate(event.candidate)
};

connection.createOffer(offerOptions)
.then(function(offer) {
  return connection.setLocalDescription(offer);
})
.then(function() {
  appendOffer(connection.localDescription)
  appendOfferDetail(connection.localDescription)
})
.catch(function(error) {
  appendError(error)
})

##################################################################

In the meantime I tried to simplify more on master, so the code from above is here:

https://github.com/kudi82/webrtc-ios/blob/4ddaaae6fca17898efad4ecb02c4834a5f22c158/static/webrtc.js

Still not working. On Android I get a list of audio, video and data candidates. On iOS nothing but null after about a minute.

I have now read so many stuff about WebRtc on iOS that I have no idea anymore what should work and what not and in which version. So to clarify what I try to do: 

I have a car game running in the Mac OS Safari where you can steer the cars with your iPhone in the iOS Safari. I need just a data channel, no video no sound to send the commands directly to the game. The game sends also data to the phone (which however is a bit less important). Of course I dont want the user to accept the camera just for data.

So what I need is a direct connection between the phone and the browser on the Mac. I read that depending on the location (I am in Europe) the gathering of the candidates could fail. However I cannot imagine why this should be the case, so I guess rather not.

I found the workaround which Adapter uses (not yet tried out), however I dont know if this is needed for data channel, so I have not yet tried out:
https://github.com/webrtc/adapter/commit/ee197f1b07ae502f48026d832dd0cd952846a78b

I have read this, however this did not help so far:
https://webkit.org/blog/7763/a-closer-look-into-webrtc/

Some say the example you posted is already outdated:
https://youennf.github.io/webrtc-tests/src/content/peerconnection/trickle-ice/

I am quite lost so far, should it work at all to make a data channel on iOS? I spend so much time with testing and trying out.

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?

[youenn fablet]

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

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.

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

(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

[youenn fablet]

Thanks for reporting back all this information, that might be useful to somebody else.

*** This bug has been marked as a duplicate of bug 174500 ***