ICE candidates are gathering long time(40-60 sec) on iOS implementation.

[Hasan Van Dingham]

The whole pack of ice candidates gather approximately 0.5 sec, but after last detected ice candidate webRTC wait about 40-60 sec to change iceGatheringState in Complete long time.

Has anyone experienced the same issue? I'm using WebRTC.framework from 16 Aug 2017 version.

Initing peerConnection:

- (void)peerConnection {

    RTCConfiguration* configuration = [RTCConfiguration new];

    configuration.bundlePolicy = RTCBundlePolicyMaxCompat;

    configuration.iceTransportPolicy = RTCIceTransportPolicyRelay;

    configuration.iceServers = self.iceServers;

    

    self.peerConnection =

        [self.peerCF peerConnectionWithConfiguration:configuration

                                         constraints:sdpConstraints

                                            delegate:self];

    [self initLocalMediaStream];

}

OfferToReceiveVideo = false

OfferToReceiveAudio = true

DtlsSrtpKeyAgreement = true

[Antonis Tsakiridis]

I had a similar issue on iOS and it was the iceServers urls that were wrong. I would suggest that you test each of the STUN/TURN urls and make sure that they work properly. You should be able to use this demo to do that.

If that is not it maybe check if you have any weird network interfaces like VPNs enabled, and that causes PeerConnection to try get candidates from them too and having issues?

Hope that helps

Best regards,

Antonis Tsakiridis

[Alin Radut]

We've been experiencing long wait times for ICE candidates as well on iOS.

Our fix was to set the CONNECTION_WRITE_TIMEOUT to 2 seconds in port.h, because if we can't connect and write to another server in 2 seconds we don't care about using it as a TURN server anyway as the latency would be too great.

On Monday, August 21, 2017 at 12:57:22 PM UTC+3, Hasan Van Dingham wrote:

[Taylor Brandstetter]

See this bug (closed as "expected behavior"): https://bugs.chromium.org/p/webrtc/issues/detail?id=7844

This is a topic that comes up relatively often. In short: we don't go to the "completed" state until everything that's being attempted times out, and our timeouts are pretty generous. So, although the "completed" states may be useful for logging/statistics/etc., I wouldn't recommend triggering any application-level logic off of them. If you use trickle ICE, there should be no reason to wait for the completed state. If you don't use trickle ICE, you should define your own criteria (or timeout) for deciding when to send the offer+candidates.

--

---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrtc+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/2df24b0b-1c59-4d09-9f6a-ed7e7dcec8ea%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Chintan Parikh]

Found the issue that causes 40 Seconds for ICE Gathering to be completed.

When the iPhone is connected to MAC, there seems to be a special interface between 2 like WLAN or Something similar.

I get candidates with IP like "169.254.50.174".

When I unplug the iPhone from MAC everything works fine.

Hope this helps and hope its fixed too.

To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrt...@googlegroups.com.

[Taylor Brandstetter]

As mentioned above, this is expected behavior. It's infeasible to predict every situation where a network interface is unusable, and sometimes the prediction may be wrong (maybe someone wants to use WebRTC between their iPhone and Mac over USB, who knows). So, there are always going to be cases where ICE gathering finishes as a result of STUN timeouts. You just shouldn't be using the "completed" state for anything in the critical path of your application.

To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrtc+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/4b3c8bcd-ee81-49e3-8d66-76903c31d980%40googlegroups.com.