10+ second call startup delay when STUN unavailable

[David Elliston]

Hi.

I'm experiencing a 10+ second delay in media path setup when I make calls between two endpoints (chome v60) using a cloud service that provides STUN and TURN resources. 

The cloud service provides STUN and TURN UDP/TCP/TLS urls. The caller endpoint is on public IP and can access all these urls. The called endpoint is on a corporate network and can only access the TURN TLS/433 url.

When called, the corporate endpoint takes 10 seconds before giving up on the host candidates and obtaining a TURN candidate that will work. I have attached the webrtc-internals log showing the main events.

Having searched for answers I'm aware that 10 seconds is the standard STUN timeout. Also this posted issue seems to be very similar: https://bugs.chromium.org/p/webrtc/issues/detail?id=4699

Is there a way to influence chrome to reduce this timeout? Alternatively is there a way to push the relay candidate up in priority so that is tried earlier the the ICE negotiation?

I have tried setting iceTransportPolicy=relay - this seems to remove all the initial host/reflexive candidates but still incurrs the 10 sec delay before obtaining the relay candidate.

Failing this I guess we will have no option but to provide a different access point for corporate use that provides only the TURN TLS url but this is something we've wanted to avoid.

Thanks
David.

[Taylor Brandstetter]

I don't know what would cause a 10 second delay, actually. The linked bug is about taking 10 seconds for gathering to time out and give you the "gathering complete" signal, not 10 seconds to get a TURN candidate. There's no logic I'm aware of that does anything like "only gather TURN candidates if host candidates fail"; they all should be gathered as soon as possible. Can you collect a native webrtc log?

--

---
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/ee528b70-942a-4171-bfa3-36698b4855c9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Philipp Hancke]

what is the priority of the relay candidate? Wondering if it is a TURN/TCP or TURN/TLS candidate

--

[Warren McDonald]

It could be related to this bug - https://bugs.chromium.org/p/chromium/issues/detail?id=741224. 

I found that this behaviour has become worse with 59 and 60. Essentially it's the presence of a second (or third) network interface, that can't reach any STUN/TURN protocol/port combination, that causes the delay. You can test this fairly easily by installing the WebRTC Network Limiter Chrome Extension, and selecting "Use only my public IP". With this set the delay should not be present.

This situation seems to be complicated by the presence of an IPv6 address, which is effectively treated as a second network interface. It can't reach the STUN/TURN server and so waits the 10 seconds. I have started looking at the combination of network which makes this worse. It could be that the IPv6 has a 6to4 translator and so thinks it should be able to connect, but this is not implemented properly, so fails. It could be Teredo tunnelled IPv6. I will try to look further this week.

The other culprits are virtual interfaces for VMWare or VirtualBox, commonly use by developers. Or VPN clients that create an interface even when not connected.  

All in all, it was a joy to debug on my machine, which has all of the above :( 

[Iñaki Baz Castillo]

Definitely waiting for ICE gathering completion is not a good idea. Can't you do Trickle ICE? 

--

---
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/c5cb1474-848d-44be-aee5-186fecfab419%40googlegroups.com.

[Taylor Brandstetter]

It could be related to this bug - https://bugs.chromium.org/p/chromium/issues/detail?id=741224. 

That's still not the same as the bug that started this thread, though. Taking a long time for ICE to time out is different than taking a long time to gather a TURN candidate.

To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/CALiegfm60%2BLvyPpoB20sz-OPpGRDSr%3Drpq%3DDE-CH%3Dm3j%3DZnfeQ%40mail.gmail.com.