Google chrome WebRTC connection chooses STUN instead of mDNS hostname

[eric littley]

I am testing an application that uses WebRTC to transmit video from a server to a client application running in Google Chrome ( 74.0.3729.157).  I am testing the Chrome flag Anonymize local IPs exposed by WebRTC  to make sure it works with our application.  Both the client and server are on the same LAN.  The application I am testing uses multiple WebRTC connections concurrently.  With the flag disabled everything works fine, the connection gets established using the LAN IP addresses.  When I enable the flag some of the client connections choose an mDNS hostname instead of a local IP address as expected.  However, some of the other connections try to use STUN to set up the connection to the server.  The STUN connection does not appear to be successful and for some reason, WebRTC does not fallback and try to use the mDNS hostname for the connection.  Why does chrome try to use STUN when the mDNS hostname would work? Also, why does WebRTC not switch over to mDNS when the STUN connection fails?  There may be some race condition because when I connect each session sequentially they always choose the mDNS hostname and never try to use STUN, its only when I try to make a bunch of concurrent connections that some choose to use STUN.

[Qingsi Wang]

One possibility I can think of is the loss of mDNS queries in this case, and the mDNS hostname is not resolved for some connections as a result. The underlying host candidate is not usable after the resolution failure, making the fallback impossible. Can you please file a Chromium bug for this and preferably attach a sample log for a problematic session? Thanks!

Qingsi

--

---
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/195fb441-bda1-4ec6-a22c-85b3ecccfe68%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Emad Omara]

+Jeroen de Borst +Qingsi Wang 

From: eric littley <eric.l...@ipconfigure.com>
Date: Thu, May 16, 2019 at 12:21 PM
To: discuss-webrtc

--

[eric littley]

Chromium bug: https://bugs.chromium.org/p/chromium/issues/detail?id=964951

On Thursday, May 16, 2019 at 5:20:55 PM UTC-4, Qingsi Wang wrote:

One possibility I can think of is the loss of mDNS queries in this case, and the mDNS hostname is not resolved for some connections as a result. The underlying host candidate is not usable after the resolution failure, making the fallback impossible. Can you please file a Chromium bug for this and preferably attach a sample log for a problematic session? Thanks!

Qingsi

From: eric littley <eric....@ipconfigure.com>
Date: Thu, May 16, 2019 at 12:21 PM
To: discuss-webrtc

I am testing an application that uses WebRTC to transmit video from a server to a client application running in Google Chrome ( 74.0.3729.157).  I am testing the Chrome flag Anonymize local IPs exposed by WebRTC  to make sure it works with our application.  Both the client and server are on the same LAN.  The application I am testing uses multiple WebRTC connections concurrently.  With the flag disabled everything works fine, the connection gets established using the LAN IP addresses.  When I enable the flag some of the client connections choose an mDNS hostname instead of a local IP address as expected.  However, some of the other connections try to use STUN to set up the connection to the server.  The STUN connection does not appear to be successful and for some reason, WebRTC does not fallback and try to use the mDNS hostname for the connection.  Why does chrome try to use STUN when the mDNS hostname would work? Also, why does WebRTC not switch over to mDNS when the STUN connection fails?  There may be some race condition because when I connect each session sequentially they always choose the mDNS hostname and never try to use STUN, its only when I try to make a bunch of concurrent connections that some choose to use STUN.

--

---
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...@googlegroups.com.