WebRTC connection establishment takes about 5s

[Peter Schraffl]

Hi,

we are using the WebRTC library on a server (based on M103) to establish a WebRTC connection between browser and server. We now have the issue at a customer that connection establishment takes about 5s - which is too slow.

The server is behind a NAT (three STUN servers are in use on the server side). The server has two network interfaces. One of those is just used for internal purposes; it is not possible to reach the client nor the STUN servers via that interface.

It seems that this second interface is somehow causing the issue because it was faster when we told the peer connection to ignore that interface (at least when "connecting" using a browser outside the customers network; from an "internal" browser it still took some seconds).
During a nightly debugging session we did this in a hacky way through the "ignore VPN adapters" functionality, like so

   webrtc::PeerConnectionInterface::RTCConfiguration config;
   rtc::IPAddress ip;
   RTC_CHECK(IPFromString("10.75.163.153", &ip));
   config.vpn_list = { rtc::NetworkMask(ip, 32) };
   config.vpn_preference = webrtc::VpnPreference::kNeverUseVpn;

and also told the peer connection factory to ignore VPN adapters

  webrtc::PeerConnectionFactoryInterface::Options opt;
  opt.network_ignore_mask = rtc::ADAPTER_TYPE_VPN | rtc::ADAPTER_TYPE_LOOPBACK;
  pcFactory->SetOptions(opt);

That seems to do the trick for the mentioned "connect from external" scenario, but we are just wondering whether there is a clean way to ignore specific network interfaces (not by faking VPN adapters) and track down what is really causing the slow down as establishment is still slow when using a browser on a "network internal" computer of the customer (which also has multiple network interfaces/adapters).

Any feedback would be appreciated.

[Peter Schraffl]

Just wanted to add an observation me made today: We did some more testing and noticed, that the call to getUserMedia() in the browser seems to take up to 16 seconds (according to some tracing and webrtc-internal), which is of course way too long. Does anybody know what is going on behind the scenes of this call? It is currently the only customer having this trouble. Might there e.g. be some certificate checking involved? The issue is also present when using the app via a public available URL, not only from the company internal network? It somehow seems that the "location" of the browser does influence the issue (the above mentioned 16s were seen when accessing the web app from our company network but when using a home PC there was almost no delay...)

[Philipp Hancke]

15 seconds is the usual timeout for a stun binding request from an interface that is not routable.

This is one of the reasons why ICE candidate trickling was "invented", it avoids such problems by not insisting on waiting for all theoretically possible 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-webrt...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/94434312-20d9-4c04-8cc5-bdc780d5f724n%40googlegroups.com.

[Sots Ts]

Is anyone seeing inordinately long calls / page component loads since this new Chrome release ?

…with getUserMedia() or elsewhere ?

 
We are.

[Nils Ohlmeier]

Are observing these delays for getUserMedia() by any chance on the latest macOS 13?

It appears that the new macOS feature for using your iphone as a camera for your laptop adds significant delay to gUM().

Best regards
  Nils Ohlmeier

[Peter Schraffl]

Hello,

 

I just wanted to give you a quick update: After doing further testing and analysis it turned out that some higher “background” JS load (and/or localstorage usage) while setting up the WebRTC connection was slowing down the browser and thus also affecting the getUserMedia() performance (or better the completion of the promise). The duration for getUserMedia() shown in the WebRTC internals (and in some of our own console logs) was then leading us into the wrong direction.

Another reason influencing our analysis was one of our test PCs which had a general issue slowing down sometimes and in this way creating some false positives.
Anyways – first tests with a changed version are looking good so far and we are awaiting feedback from our customer. So it seems to be no browser internal issue. Sorry for bothering you.

 

Regards Peter

--

---
You received this message because you are subscribed to a topic in the Google Groups "discuss-webrtc" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/discuss-webrtc/YbzIpFWya-4/unsubscribe.
To unsubscribe from this group and all its topics, send an email to discuss-webrt...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/17d61535-9431-40a5-9432-7ce068ac3fa2n%40googlegroups.com.