Re: [rtcweb] WGLC for draft-ietf-rtcweb-ip-handling

[westhawk <[e-mail]>]

> On 15 Apr 2018, at 15:09, Justin Uberti <[e-mail]> wrote:
> 
> 
> 
> On Fri, Apr 13, 2018 at 8:36 AM Justin Uberti <[e-mail] <mailto:[e-mail]>> wrote:
> 
> 
> On Thu, Apr 12, 2018 at 11:59 PM westhawk <[e-mail] <mailto:[e-mail]>> wrote:
> 
> 
> > On 13 Apr 2018, at 02:22, Justin Uberti <juberti=[e-mail] <mailto:[e-mail]>> wrote:
> > 
> > Being non-interactive, it's not clear that those cases require Mode 1 though; they should work well even in Mode 2. I also don't think that suggesting "more appropriate means" is useful when we as a WG haven't been able to come up with any.
> 
> Whoa there! Non interactive, that’s a big step from non-conversational !
> So one current use-case is adjusting room lights over the data channel. You can literally see latency - an unnecessary cloud round-trip is entirely
> visible.
> 
> Another is driving a droid over the datachannel using it’s camera to feed live video to see where it is going 
> - again totally interactive, just not using local media at the user’s end (although we do use the 
> motion sensors to give a steering wheel feel) - latency here causes crashes!
> 
> A third one is baby cams, where again the video feed is one-way but you’d really like to keep the media on the home wifi
> if possible for cost (and privacy) reasons.
> 
> In all these I’ll have to introduce an otherwise needless GUM request to get the network behaviour I want. 
> 
> Perhaps I should present some of these non-call based usecases at a future F2F so that folks get a sense of the possibilities.
> 
> The original comment from Lorenzo that I was responding to specifically cited one-way media broadcasts. 
> 
> Regardless, I contend that those cases as well as your scenarios should all work as desired in Mode 2, which allows direct connections.
> 
> Now, one might reasonably ask: if this is the case, what's the benefit of Mode 1?
> 
> Simply stated, Mode 1 allows the client to pick whatever network interface works best, and this provides two key benefits:
> a) handoff or multipath between interfaces (e.g. wired/wifi or wifi/cell)
> b) use of non-VPN interfaces when a VPN exists
> 
> I imagine that a) is not unique to WebRTC, i.e., in-browser MPTCP or QUIC will already have to solve this, and it's also not clear that this situation actually presents an issue.

I’m not sure I agree - or disagree - yet.
Here are a couple of sources of my uncertainty:

SCTP has also has multipath/multihome capabilities which ICE is effectively obscuring in the current setup.
Given this is the 1.0 spec, we also have SRTP to worry about which isn’t capable of multipath (as far as I’m aware). 

An example of this may be an LTE phone that has a ‘data bearer channel’ and a ‘media bearer channel’ - the billing routability and QoS behaviour of these
two interfaces will be different. I could imagine that a carrier app might want to use the media bearer for a voice call. (Sorry for my 3GPP  semi-ignorance).

> 
> Therefore, the problem seems to reduce to b), and this may be a much more tractable situation. If a user is using a VPN to access a web application (i.e., the 'default' route that would be chosen by WebRTC is for a VPN adapter), one could imagine the browser asking permission to use non-VPN interfaces. 

Is it possible to tell if an interface is a VPN ? I’m not convinced I know how to reliably distinguish between a VPN and a multi-bearer LTE
config.

> 
> This could still be too complicated for typical users to understand (as I still don't know what the prompt text should say), but the key point here would be that only VPN users (who presumably are somewhat more savvy) would have to see this prompt.
> 
> Thoughts? If we like this formulation, we could redefine Mode 1 accordingly, and cite the mechanism above as a potential alternative to getUserMedia.
I like this in principle. But I also feel that the prompt would include the concept of revealing location/service provider.

Tim.