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

[Justin Uberti <[e-mail]>]

Here's a specific and minimal proposal, which is a slight modification
of Sean's
proposal in https://github.com/juberti/draughts/pull/98/files:

*The details of this consent are left to the implementation; one potential
mechanism is to tie this consent to getUserMedia consent. Alternatively
implementations can provide a specific mechanism to obtain user consent
where needed, e.g., when a VPN is in use.*

Are folks in favor of:
a) the text above
b) Sean's proposal (without the boldface)
c) something else

On Sun, Apr 15, 2018 at 8:51 AM Justin Uberti <[e-mail]> wrote:

>
>
> On Sun, Apr 15, 2018 at 8:34 AM westhawk <[e-mail]> wrote:
>
>>
>>
>> On 15 Apr 2018, at 17:12, Justin Uberti <[e-mail]> wrote:
>>
>>
>>> 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).
>>>
>>
>> I don't think this is relevant to this discussion; since this isn't
>> surfaced upwards as different interfaces to the OS, any behavior here is
>> the same as you would get in Mode 2 when using the cellular interface.
>>
>>
>> That’s not the impression I got from this CCC talk
>> https://events.ccc.de/congress/2015/Fahrplan/system/event_attachments/attachments/000/002/829/original/2015.12.28_CCC_Dissecting_VoLTE.pdf
>>
>> One of the slides explicitly shows 2 interfaces surfaced to the ifconfig
>> in linux busybox.
>> I realise that these slides are a couple of years old, but I doubt VoLTE
>> has changed much in that time. (I’m still semi-ignorant on 3gpp )
>>
>
> Yes, I see what you mean. It seems like the bearer is intended to be
> locked down to VoLTE traffic - but this may not always be happening yet in
> practice (although this issue was reported to Google and may have been
> fixed in a recent version of Android). Regardless, I would still contend
> that selecting a specific bearer for WebRTC traffic is outside of our
> current remit.
>