Also attaching Net-Internals file

Deleted: chrome-net-export-log.json 5.8 MB

chrome-net-export-log.json 5.8 MB View Download

We are able to connect WebRTC connection via proxy using TLS. But the problem now is, Chrome not trying to connect to PROXY server until TURN hostname is resolved, we have to add TURN IP entry in HOST file to make it work but that is not a feasible solution. This DNS lookup issue is only happening in case of TLS, in normal case Chrome is able to connect to PROXY server, but proxy is dropping the packets from TURN server.

Unable to triage this issue from TE-End, adding "TE-NeedsTriageFromMTV" label for further triage.

Any update on this?

Ping for triaging.

WebRTC ultimately should be using "GetBrowserContext()->GetResourceContext()->GetHostResolver()". Will this end up going through the HTTP proxy? What's the easiest way to test/verify this? CCing some people who may know.

Also, question for the reporter: when you say "the issue is only happening in case of TLS", do you mean a TLS connection to the TURN server, or to the HTTP proxy?

TLS connection to the TURN server using TURNS URLS

Thank you for providing more feedback. Adding requester "deadbeef@chromium.org" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

> WebRTC ultimately should be using "GetBrowserContext()->GetResourceContext()->GetHostResolver()".
> Will this end up going through the HTTP proxy? What's the easiest way to test/verify this? CCing some people who may know.

I don't believe the net::HostResolver will go through an HTTP proxy.  HTTP proxy resolution should be done prior to resolving host names.

I'm a bit confused now. If net::HostResolver doesn't go through an HTTP proxy, what host resolver does? And does webrtc need to do something to trigger HTTP proxy resolution? Does this normally happen automatically when we try to send packets?

> I'm a bit confused now. If net::HostResolver doesn't go through an HTTP proxy, 
> what host resolver does?

net::HostResolver resolves hosts.  For normal net::UrlRequests, if proxy resolution determines a proxy should be used, then the net::HostResolver will be used to resolve the host of the proxy (not of the intended destination), and the proxy will handle communication with the intended destination (including, if necessary, host resolution).

> And does webrtc need to do something to trigger HTTP proxy resolution?
> Does this normally happen automatically when we try to send packets?

WebRTC uses ProxyResolvingClientSocket to tunnel through proxies.

+asanka@ who fixed the case where the proxy needs auth in  Issue 439560  in January.

Ok, I now see that if the net::HostResolver fails, webrtc will fall back to creating a socket that connects via hostname, which is expected to do what you describe: https://cs.chromium.org/chromium/src/third_party/webrtc/p2p/base/turnport.cc?q=turnport.cc&dr&l=715

And it looks like ProxyResolvingClientSocket is used for TURN TLS sockets.

I tested this by hacking chromium/webrtc to always fail the initial address resolution, and only use TLS TURN servers, and it seems to be working with the link you provide (resolving the address through the proxy server). Is there any information I could be missing? Have you tried testing with a Canary build? Could be it an issue with the proxy server itself?

I believe this was due to a webrtc bug that was fixed. Especially given the fact that you said it only occurs for TURN over TLS, which is a property of the webrtc bug. See https://bugs.chromium.org/p/webrtc/issues/detail?id=8102