Cordova-plugin-iosrtc: iOS 13.3.1 iceConfig: Setting turn server causes 40s timeout

[derMani]

Hi,

we are experiencing a few issues with the ice server configuration since 6.0.x

Problem:

if we set the turn servers, we'll have to wait for a long timeout, until the

iceconnectionstatechange

event fires and the iceconnectionstate is set to completed.

If no turn servers are set, we can immediately get the possible candidates and we get a quick completed event.

If turn servers are set, we get the long timeout (only on iOS with this plugin).
With the same configuration, we'll get quick gathering results from Chrome, Firefox or Edge or even the android webview.

Expected behavior

Gathering of candidates is quick(er).

iceconnectionstatechange

will be set to completed after a short(er) period of time.

Observed behavior

It takes sometime 40s or more until

iceconnectionstatechange fires

and iceconnectionstate is set to completed.

Steps to reproduce the problem

We are using JSSIP 3.3.x

The Call of course can only be established after the gathering of ice candidates is completed.

We are using the following peerConnectionConfig

var peerConnectionConfig = {
    offerToReceiveVideo: true,
    offerToReceiveAudio: false,
    //iceTransportPolicy: 'relay',
   sdpSemantics: 'plan-b',
    bundlePolicy: 'max-compat',
    rtcpMuxPolicy: 'negotiate',
    iceServers: [
      {
        "url": "turn:global.turn.twilio.com:443?transport=tcp",
        "username": "myUser",
        "urls": "turn:global.turn.twilio.com:443?transport=tcp",
        "credential": "myCredential"
      }
    ]
};

Do you need turnserver credentials for testing? I don't want to drop the credentials here ;) but I could provide turnserver credentials if needed.

Is this a WebRTC bug or is this plugin behavior ?

Platform information

• Cordova version: 8.1.2
• Plugin version: Tested on 6.0.1 and 6.0.6
• iOS version: 13.3.1
• Xcode version: 11.2.1

[hthetiot]

Thank you @derMani for reporting your issue.

1. Can you tell me what type of turnserver you are using (Coturn, rfc-turnserver, third-party) ?
2. Did you test your TURN settings using Trickle ICE tools (including that it goes through TCP) ?https://webrtc.github.io/samples/src/content/peerconnection/trickle-ice/
3. I see that you are forcing TCP, It is not recommended, you may need to set iceTransportPolicy:"relay", to make it works (see below) or simply remove the transport parameter.

Source: https://stackoverflow.com/questions/44627013/webrtc-media-over-tcp/44707489#44707489

I have tested 6.0.x with CoTurn (https://github.com/coturn/coturn) using UDP on AWS with NAT gateway without any issues and JSSIP 3.1.2 with Freeswitch allowing the IP of the TURN server on the SIP server.

You can send me your TURN credentials by email at hthetiot-at-sylaps.com if you want me to test your TURN server on my side. But I recommend to first test it localy using that page and confirm it goes TCP https://webrtc.github.io/samples/src/content/peerconnection/trickle-ice/

[derMani]

Hi, thanks for the quick answer.

Looks like the turn server we are using is on:

COTURN 4.5.0.7

I have removed the?transport=tcp parameter, but I am still getting the timeout.
I've also tested this with "relay only" which did unfortunately not help.

We did also a test with twilio and their turn servers, but again - still getting the timeout.

So I can currently reproduce this with two different turn server configurations in different locations

Steps to reproduce:

• I have created a new cordova project (ios 5.1.1, iosrtc 6.0.6).
• I have also downloaded the trickle ice code from the github repo
• You only have to add the cordova.plugins.iosrtc.registerGlobals() command in the start() method of trickle-ice (main.js).

If you like, I can provide the project to test this as well.

You should have received a mail with test credentials for our turn servers.

PS: This does not happen in the mobile safari or desktop chrome/edge/ff. We are experiencing the timeout only with the plugin.

[hthetiot]

Thank you @derMani I will investigate and comeback to you.

I wonder if it's related to isNegotiating workaround (see comment in the code).

• https://github.com/cordova-rtc/cordova-plugin-iosrtc/blob/master/src/PluginRTCPeerConnection.swift#L620

[hthetiot]

Hello @derMani, I do not reproduce this candicate timeout issue.

I have tested the sample Trickle Ice Cordova application you sent me using the Turn Server credentials you provided by email on my side on iOS 12.4.5 on iPhone 6 with Wifi and it does works, see capture below.

{"urls":["turn:turn.bitnamic.net:443?transport=tcp"], "username": "*", "credential": "*"}

I have implemented RTCIceCandidate foundation, component, priority, type, address, ip, protocol, port, relatedAddress and relatedPort properties for iOSRTC RTCIceCandidate via #468 but that only fix the display of information but does not changes that it does works for me using following setup.

The only explanation for me is that the Network of your device (Wifi or GSM) is not allowing Relay to connect due Firewall Restriction.

[derMani]

I have tested the sample Trickle Ice Cordova application you sent me using the Turn Server credentials you provided by email on my side on iOS 12.4.5 on iPhone 6 with Wifi and it does works, see capture below.

I tested this on multiple networks, even LTE only.

I am on iOS 13.3 with an iphone xs.
Is this iOS 13 related ?

[hthetiot]

We made a debug session with @derMani and we confirmed that it does Ice gathering timeout on iOS 13.3.1 using TURN.

If any other user can confirm that when using a TURN server they do experience issue with iOS 13.1.1 that would help.

On my side I only have an iPhone 6 and iPad Mini 3 that cannot be upgraded to iOS 13, therefor I cannot test iOS 13 on device.

I will try borrow an iOS 13 device in the comming days to try to confirm and debug the issue.

[hthetiot]

Clould be related: https://github.com/coturn/coturn/issues/249

[hthetiot]

Cloud be related:

• https://bugs.chromium.org/p/chromium/issues/detail?id=984553&q=component%3ABlink%3EWebRTC%3ENetwork&can=2
• https://bugs.chromium.org/p/chromium/issues/detail?id=966798&q=iOS%20client%20ice%20candidate&can=2
• https://bugs.chromium.org/p/chromium/issues/detail?id=878465&q=iOS%20client%20ice%20candidate&can=2

[hthetiot]

This comment is interesting:

What the spec recommends is actually pretty easy and wouldn't require large changes (such as changing offerer/answerer role)
If you previously did something along the lines of
  pc.oniceconnectionstatechange = () => {
    if (initialOffer && pc.iceConnectionState === 'failed') {
      doAnIceRestart()
    }    
  }
then what the spec says can be as simple as this:
  pc.oniceconnectionstatechange = () => {
    if (initialOffer && pc.iceConnectionState === 'disconnected') {
      setTimeout(() => {
        if (pc.iceConnectionState === 'disconnected') doAnIceRestart()
      }, 2000)
    }    
i.e. just waiting two seconds and if the connection hasn't recovered do the ice restart.

Alternatively you can get the old behaviour back by setting {sdpSemantics: 'plan-b'} in the peerconnection constructor :-)

Source: https://bugs.chromium.org/p/chromium/issues/detail?id=982793#c16

Note: Launching Sylaps iOS (https://apps.apple.com/us/app/sylaps/id954016392) that use iosrtc 8.0.7 using following URL https://sylaps.com/app/room/iosrtc?relay=relay in safari to open the application to force relay type relay does work and Sylaps do perform an IceRestart that may be why Sylaps did work on iOS 13.3.1 test session with @derMani

[akilude]

We use both STUN and TURN on ios 13.2 , haven't faced this issue.

Using plugin version 6.0.7, built with xcode 10.2

[hthetiot]

Thank you @akilude, @derMani and I think it's a iOS 13.3.1 related issue.
I asked @derMani to test m75 by email to see if that solve the issue.

• https://github.com/cordova-rtc/cordova-plugin-iosrtc/issues/469

[hthetiot]

I have a device on 13.3, I will test now, then upgrade to 13.3.1 to see if that related to the iOS update.

[hthetiot]

Unfortunately @derMani I do not reproduce the issue on iOS 13.3.0 and 13.3.1 using iPhone 11 Pro using 6.0.8.

I did test 13.3.0 then upgraded to 13.3.1 did not change anything both worked.

Here is 13.3.1 Capture:

May be one thing that can be tested is Reset your Network Settings. “Tap Settings > General > Reset > Reset Network Settings.”

[hthetiot]

Closed due inactivity of reporter.
Will reply if reporter manifest himself.

[abardik]

Risking to be banned by @hthetiot for commenting on closed issue, but it's relevant.

I had exactly the same issue on iosRTC 6.0.x (5.0.x works fine). The issue exists on devices running iOS 13.* using JsSIP 3.4.4, as well as a plain webrtc API. In my case, the call is established as usual when iOS device is on LTE, but it is never established while on Wi-Fi (with JsSIP it's established after ~40 seconds, as reporter mentioned above).

I don't know the nature of this bug, but I solved it by leaving just one stun/turn server in pcConfig.iceServers (default google stun OR my corporate turn, but not both at the same time).