Support mode 4 in webRTCIPHandlingPolicy |
||||
Issue descriptionImplement mode 4 from https://tools.ietf.org/html/draft-ietf-rtcweb-ip-handling-09#section-5.2 via a new value in webRTCIPHandlingPolicy. This new value would be functionally equivalent to setting webRTCIPHandlingPolicy to "disable_non_proxied_udp" when a proxy is configured and setting "default_public_interface_only" when no proxy is configured. Extensions currently try to do this (see crbug.com/873987 ).
,
Aug 15
After more discussion in https://crbug.com/873987 , I think the existing options are sufficient. The underlying problem is that disable_non_proxied_udp disables all UDP - proxied UDP is not supported. Opening a new issue to track proxied udp support.
,
Aug 15
Support Proxied UDP Connections in WebRTC: http://crbug.com/874632
,
Aug 16
Flipping back to Available. The problem with disable-non-proxied-udp as an implementation of mode 4 is that it is inconsistent with the specification when a proxy is NOT present. The mode 4 description says that in this case it needs to fall back to mode 3. The implementation is that when there's no proxy present, no communication happens. We need a mode that works like that.
,
Aug 22
,
Oct 29
I did a little bit more research on this. The draft says: "when the application's HTTP traffic is sent through a proxy, WebRTC media traffic MUST also be proxied." I'm not sure how to interpret this when the application is a web browser because the browser might be proxying some, but not all of its HTTP traffic. The browser might also try to use a proxy, but fall back to using a direction connection if the proxy fails. Using the proxy behavior from however the javascript was delivered might be a good place to start. More notes here: https://docs.google.com/document/d/1JOWSlfNAdTGb6vXh8WVbF2ohGFxvl2dOLMsOvQtdYNU/edit?usp=sharing |
||||
►
Sign in to add a comment |
||||
Comment 1 by zstein@chromium.org
, Aug 14