WebRTC over HTTP Proxy

[Shmuel]

Hi,

I have a configuration of WebRTC client (Chrome browser) that connects through HTTP Proxy to a streaming server in order to receive a video stream from the server.

The HTTP Proxy is configured in the web client operating system (Windows) and used by the chrome browser.

The server sends 2 ICE candidates: UDP host, and TCP host.

In general, I would like to have the following behavior:

• Web Socket opens through the HTTP Proxy (client <--> proxy <--> server).
• Video stream is sent directly from the server to the client (server --> client), and not through the HTTP Proxy, in order to avoid overloading of the HTTP Proxy.

I test this with 3 different scenarios of firewall configurations. In all the scenarios, the WebSocket opens through the HTTP Proxy, as expected, but the behavior of the media data (the video stream) is different:

1. Firewall blocks outbound UDP and TCP (except for the Proxy port) --> Media data is sent through the Proxy using the TCP ice candidate.
2. Firewall is disabled --> Media data is sent directly server to client using the UDP ice candidate, not through the proxy.
   
3. Firewall blocks outbound UDP only --> Media data is sent through the Proxy using the TCP ice candidate.
   

My questions:

• For scenario #3, why does the media go through the proxy instead of directly on the TCP ice candidate, as it does in scenario #2 when using UDP? I would expect to have the same behavior in both cases: either go through Proxy in both cases or go directly in both cases.
• Can the Peer Connection be configured to define whether to send media through the Proxy or directly?
  

Attached webrtc internals dumps for all the scenarios.

Thanks,

Shmuel

[Justin Uberti]

For TCP connections, WebRTC defers to the browser's networking stack, which uses a proxy if one is configured (as with WebSockets).

[Roman Shpount]

Hi Justin,

Was TCP connections always established through the HTTP proxy or did it change over the past few years?

Does this affect only ice-tcp candidates or TURN TCP/TLS as well?

Thank You,

[Warren McDonald]

In our experience, the behaviour has been static for some years now and is a little counter intuitive.

TURN connections (Port and Protocol combinations) are all tried but given preference in the order they are defined in ICE config array.

For TCP, if there is a route or NAT path to the TURN server, it will try that before falling back to use a web proxy defined in the browser. 

A browser defined proxy does not force the connection via the proxy, so if you need to test a proxy tunnel, block the network egress to the TURN server from the browser in a firewall (on host will do).  

The web proxy will only work if:

  a) the destination port is defined as allowed to CONNECT in the proxy. This is normally allowed for all TLS ports, so 443 would work, but non common web ports like 3478 may not.

  b) the browser has ability to authenticate to the web proxy (if required)

TLS connections use the same logic.

If you must use port 443, consider specifying TLS ( TURNS: protocol) in your ICE config, as some more advanced networks will drop non TLS traffic to common TLS ports.

Cheers,

Warren   

[Roman Shpount]

Thank you Warren!

I guess what bugs me here is that, according to your description, for TURN servers direct TCP connection is attempted first, before connecting through the HTTP proxy. On the other hand, according to the initial email in this chain, for ICE-TCP candidates, connection is always established through HTTP proxy even if direct TCP connection is possible. If this is the case, one of those scenarios is doing something wrong.

Roman,

[Warren McDonald]

In terms of spec and implementation design, I would defer to Justin, but this is what we see day to day.

[Shmuel Lange]

Hi,

Thank you all for your replies.

As I wrote in the initial of this chain, according to my tests TCP is used via the Proxy, and that fits Justin's explanation above.

Now, I made an additional test, similar to scenario #3 in my previous mail (Firewall blocks outbound UDP, TCP is enabled) but this time I configured the Proxy using chrome API  (chrome.proxy.settings.set).

I configured it with bypass list so that the Proxy will not be used for the specific TCP port which in the ice candidates from the media streaming server (in the following example port 1937).

This is the configuration:

var config = {

        mode: "fixed_servers",

        rules: {

            singleProxy: {

            scheme: "http",

            host: "myProxyServer.com",

            port: 3128

           },

          bypassList: [".myMediaServer:1937"]

        }

    };

chrome.proxy.settings.set(

      {value: config, scope: 'regular'},

      function() {});

But still, I see the media goes through the Proxy, following client HTTP CONNECT request to the proxy, with TCP port 1937 according to the ice candidate of the media streaming server.

I expected the client not to use the Proxy, as this port is included in the bypass list, but still the Proxy is used.

BTW - just to verify that the bypass configuration is correct I tried the same for the web management port of this server (adding it to bypass list) it worked as expected and bypassed the proxy. So the configuration itself works.

According to this, it seems that the WebRTC implementation doesn't refer to the bypass list.

Can anyone explain it? Why doesn't the Peer connection refer to bypass configuration?

Thanks,

Shmuel

On Fri, Oct 11, 2019 at 1:36 PM Warren McDonald <warren....@gmail.com> wrote:

In terms of spec and implementation design, I would defer to Justin, but this is what we see day to day.

--

---
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/1cc6445b-5a27-4ad4-ba02-959210062f10%40googlegroups.com.

[Justin Uberti]

@Warren McDonald - the behavior should be the same for ICE-TCP or TURN/TCP. Can you confirm that TURN/TCP connections do not go through the proxy?

@Shmuel Lange - it's possible that there's some problem where the origin matching for the bypass list doesn't work for WebRTC connections. Suggest filing a crbug on this.

To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/CAGwDCJc_wFNF7he6Qm-WNhTY83N63%3DfTSsHxPEzJJwqkRoOZJg%40mail.gmail.com.

[Shmuel Lange]

@Justin Uberti - I fixed the bypass configuration in my previous mail. I should have used the server's IP as it appears in the ICE candidate, instead of using the server DNS name.

Now it works for me as expected. Media goes directly from the TCP ICE candidate (not through the Proxy).

Here is the fixed configuration:

ar config = {

        mode: "fixed_servers",

        rules: {

            singleProxy: {

            scheme: "http",

            host: "myProxyServer.com",

            port: 3128

           },

          bypassList: ["a.b.c.d:1937"]

        }

    };

chrome.proxy.settings.set(

      {value: config, scope: 'regular'},

      function() {});

Thanks,

Shmuel

To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/CAOJ7v-0Bv-GDjiehJ3dymiRZudNGs-p%2BJ41K5iRNA-%2BZ3G9MvQ%40mail.gmail.com.

[Justin Uberti]

Thanks for the followup, that makes sense - ICE connections are always made to an IP, but TURN connections (which you aren't using) can be made to a hostname.

To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/CAGwDCJew2dxr5kGd59K05kju7k2oRrcBnGmBwHJmd%3D0yytZteg%40mail.gmail.com.

[Yifei Cheng]

Hi! Stumbled upon this post as it's revelant to some of my struggles. I don't get how media can be forwarded via the HTTP proxy, isn't media raw TCP packets and not HTTP? So you would need a SOCKS5 proxy instead?

[Warren McDonald]

Hi,

A TURN Server is a relay device, which uses the STUN protocol for forwarding packets to a WebRTC endpoint. There is a lot to this, which I won't go into in this response, but to cut a long story very short, a TURN server can listen on several ports and protocols, including HTTP and HTTPS. HTTP/S is used for network egress where the native STUN ports (3478 etc) are blocked. It is effectively a TCP tunnel for the media between the TURN Client and TURN server, which is commonly forwarded to a UDP port on the target WebRTC endpoint.

If you search for my historical posts/replies in this group and the TURN Server (https://groups.google.com/g/turn-server-project-rfc5766-turn-server) group you will see some explanations of the flow. 

Warren