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

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

About this issue

  • Original URL
  • State: closed
  • Created 4 years ago
  • Comments: 15 (12 by maintainers)

Most upvoted comments

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