New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 612806 link

Starred by 3 users

Issue metadata

Status: Duplicate
Merged: issue 342476
Owner:
Last visit > 30 days ago
Closed: Jun 2016
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 2
Type: Feature



Sign in to add a comment

webRTC and proxy/relay

Reported by kenneth....@gmail.com, May 18 2016

Issue description

UserAgent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/50.0.2661.102 Safari/537.36

Steps to reproduce the problem:
To be able to use WebRTC at its current design in enterprise environment it needs to be able to connect through a http proxy or some kind of relay-sever so the clients talk via specific ports and destinations to other clients.  This is because allowing UDP or TCP traffic from a client to any other client (P2P) both inside and outside our network would make any application able to talk to other clients without network restrictions(which is not wished for in an enterprise environment)

What is the expected behavior?
Being able to control the communications stream through disignatet ports

What went wrong?
"Random high ports" UDP is internet<->any is not allowed for many(or all?) enterprise organisations

Did this work before? No 

Chrome version: 50.0.2661.102  Channel: stable
OS Version: 6.1 (Windows 7, Windows Server 2008 R2)
Flash Version: Shockwave Flash 21.0 r0

The above is the observation on how webRTC behaves. There may be other views on how the socket works. The bottom line however is that it is challenging to implement webRTC with its current design(and the browsers design)
 
Components: Blink>WebRTC>Network
Cc: jansson@chromium.org
Labels: -OS-Windows -Type-Bug OS-All Type-Feature
Owner: pthatcher@chromium.org
Status: Assigned (was: Unconfirmed)
If you want to force WebRTC traffic, then you can use Chrome's configuration to do so.  For example, this extension:

https://chrome.google.com/webstore/detail/webrtc-network-limiter/npeicpdbkakmehahjeeohfdhnlpdklia?hl=en

Allows you to set the configuration to force traffic through HTTP proxies (if present).

Thank you for the quick response! 

In our case the webRTC limiter gives us the functionality of not disclosing the internal IP adress(which is good). 

The extensions does however not handle the UDP trafic as far as I understand. And we will not be able to allow UDP trafic to and from the internet.

Or have we missed something with the extension that will allow us to work with webRTC through our webproxy?

Comment 5 by tommi@chromium.org, May 26 2016

Cc: hta@chromium.org tommi@chromium.org
The extension has various settings.  One of them forces traffic through proxies, and currently only TCP proxies are supported by Chrome.  So there's no way to force traffic through proxies and use UDP at the same time because there are no UDP proxies at the moment.  RETURN is a spec which may allow for UDP proxies, but it's not implemented in Chrome yet.  If you want UDP, then you can allow traffic to go outside the proxy, of course.

By the way, all the extension does is set some configuration settings in Chrome.  Those same settings should be settable by corp policies.  The settings are:

chrome.privacy.network.webRTCNonProxiedUdpEnabled 
chrome.privacy.network.webRTCIPHandlingPolicy

And you can see how the extension works by looking at its source code:

https://github.com/webrtc/samples/tree/gh-pages/src/content/extensions/multipleroutes/src
 
Mergedinto: 342476
Status: Duplicate (was: Assigned)

Sign in to add a comment