Sometimes connect time is very slow (up to 40 seconds)

[Adam Ben-Ayoun]

Hi guys,

We have a test application on Android (native), on normal operation it works perfectly. However, there's one scenario in which the connect time is very long. This happens when WiFi is off and cellular data is on, we take WiFi on, and immediately trying to connect, it seems like at this point, the cellular interface on the device is shutting down (because it's going to disappear in a few seconds, so the device will maintain a single interface), but maybe WebRTC picks it up in that window and it takes it ~30 seconds to timeout. Another evident to this is that if we actually wait for about 30 seconds, it doesn't happen. One strange thing is that it only happens when we use STUN/TURN. Not 100% sure it's related, but I do see these in the logs (10.148.132.32 is the cellular interface IP):

05-07 21:10:53.864  12396-12414/XXX.app E/libjingle﹕ Error(stunport.cc:90): Binding request timed out from 10.148.132.32:44668 (rmnet_usb0)

05-07 21:10:53.864  12396-12414/XXX.app E/libjingle﹕ Error(stunport.cc:90): Binding request timed out from 10.148.132.32:46535 (rmnet_usb0)

05-07 21:11:03.434  12396-12414/XXX.app E/libjingle﹕ Error(stunport.cc:90): Binding request timed out from 10.148.132.32:44668 (rmnet_usb0)

05-07 21:11:03.444  12396-12414/XXX.app E/libjingle﹕ Error(stunport.cc:90): Binding request timed out from 10.148.132.32:46535 (rmnet_usb0)

05-07 21:11:13.004  12396-12414/XXX.app E/libjingle﹕ Error(stunport.cc:90): Binding request timed out from 10.148.132.32:44668 (rmnet_usb0)

05-07 21:11:13.004  12396-12414/XXX.app E/libjingle﹕ Error(stunport.cc:90): Binding request timed out from 10.148.132.32:46535 (rmnet_usb0)

05-07 21:11:14.606  12396-12414/XXX.app E/libjingle﹕ Error(stunport.cc:446): sendto : [0x00000016] Invalid argument

05-07 21:11:14.656  12396-12414/XXX.app E/libjingle﹕ Error(stunport.cc:263): Jingle:Port[audio:1:0::Net[rmnet_usb0:10.148.132.32/30:Unknown]]: UDP send of 116 bytes failed with error 22

05-07 21:11:15.237  12396-12414/XXX.app E/libjingle﹕ Error(stunport.cc:263): Jingle:Port[audio:1:0::Net[rmnet_usb0:10.148.132.32/30:Unknown]]: UDP send of 112 bytes failed with error 22

05-07 21:11:16.198  12396-12414/XXX.app E/libjingle﹕ Error(stunport.cc:263): Jingle:Port[audio:1:0::Net[rmnet_usb0:10.148.132.32/30:Unknown]]: UDP send of 112 bytes failed with error 22

05-07 21:11:16.208  12396-12414/XXX.app E/libjingle﹕ Error(stunport.cc:446): sendto : [0x00000016] Invalid argument

05-07 21:11:17.159  12396-12414/XXX.app E/libjingle﹕ Error(stunport.cc:263): Jingle:Port[audio:1:0::Net[rmnet_usb0:10.148.132.32/30:Unknown]]: UDP send of 112 bytes failed with error 22

Any idea?

Thanks,

Adam

[Jeremy Noring]

Yes; how are you sending candidates?  Trickling them, or full OFFER/ANSWER exchange? 

[Adam Ben-Ayoun]

We are using SIP, hence, we wait for gathering to COMPLETE and then send an offer. It works fine usually, but not in this case.

[Adam Ben-Ayoun]

Another finding is that all final candidates are received on onIceCandidate callback, but it takes additional 10 seconds for gathering state to become COMPLETE (this is where we send the sdp to the server).

[Jeremy Noring]

On Friday, May 8, 2015 at 6:04:04 AM UTC-6, Adam Ben-Ayoun wrote:

Another finding is that all final candidates are received on onIceCandidate callback, but it takes additional 10 seconds for gathering state to become COMPLETE (this is where we send the sdp to the server).

I'm thinking the problem is candidate gathering is taking a long time to complete, and you're sending full OFFER/ANSWER.  To work around that, you want to change to using trickle-ICE.  To do that, basically you ship over your initial offer (sans candidates), and then send candidates to the remote client as they appear in onIceCandidate.  This way you don't have to wait for the gathering state to complete.  

There are other scenarios where it'll take your clients a long time to connect, particularly on corporate/enterprise networks.  I'd definitely swap to trickle.