19:49:49 <RRSAgent> RRSAgent has joined #webrtc
19:49:49 <RRSAgent> logging to http://www.w3.org/2016/06/28-webrtc-irc
19:50:30 <vivien> Meeting: WebRTC and Media Capture Virtual Interim
19:50:56 <vivien> Chair: Harald, Stefan, Erik
19:51:07 <vivien> Agenda: https://www.w3.org/2011/04/webrtc/wiki/June_28_2016
19:51:34 <vivien> RRSAgent, make logs public
19:52:39 <vivien> Slides: https://docs.google.com/presentation/d/155vFVUUX_wAPviEQ1RScTyoLwIf2Ot3UZG1jzpQP6ow
19:54:09 <vivien> -> https://mit.webex.com/mit/j.php?MTID=meb6000e92a438a4c9f3be1b1e6617049 WebEx link
19:54:17 <vivien> RRSAgent, draft minutes
19:54:17 <RRSAgent> I have made the request to generate http://www.w3.org/2016/06/28-webrtc-minutes.html vivien
19:57:26 <stefanh> stefanh has joined #webrtc
19:58:18 <vivien> Call is strating in 3 minutes you can join the WebEx session
19:58:34 <vivien> s/strating/starting/
19:58:46 <sherwinsim> sherwinsim has joined #webrtc
19:59:58 <dom> dom has joined #webrtc
20:00:42 <jib> jib has joined #webrtc
20:01:20 <vivien> present+ ccccccevieuivltdglgnfhgvinnhijcjhdlihjjrevbi
20:01:34 <dom> Present+ Dominique_Hazael-Massieux
20:01:40 <dom> RRSAgent, pointer?
20:01:40 <RRSAgent> See http://www.w3.org/2016/06/28-webrtc-irc#T20-01-40
20:01:47 <mt_____> present+ Martin_Thomson
20:02:54 <vivien> present+ Stefan, Harald, Bernard_Aboba, Dan_Burnett, Emil_Ivov, Sherwin_Sim, Shijun_Sun, Varun, Jan-Ivar
20:03:07 <vivien> present+ Vivien
20:03:56 <adambe> Is 643 771 091 the valid meeting #?
20:04:00 <vivien> present+ Andy_Hutton
20:04:13 <vivien> adambe, yes
20:05:33 <adambe> vivien: the WebEx-woman is complaining about it
20:06:24 <vivien> present+ Ekr
20:06:43 <stefanh> @mt +1 on that proposal
20:07:13 <mt_____> also, we use "browsing context" and "browsing session" seemingly interchangeably, are they the same thing?
20:08:38 <jib> mt: I thought browsing session = browsing context + current content, but don't quote me on it
20:08:59 <vivien> present+ AlexG
20:09:21 <jib> mt: https://www.google.com/search?q=browsing+context
20:09:35 <mt_____> jib: nothing is actually defined, so who knows; also, recall that browsing session had no definition when it was first inserted in the document
20:10:00 <hta1> hta1 has joined #webrtc
20:10:29 <vivien> FYI I started the Webex session recording
20:10:39 <varun> varun has joined #webrtc
20:11:07 <vivien> Scribe: stefanh
20:11:23 <vivien> Topic: Welcome
20:12:18 <stefanh> Stefan run through the initial slides...
20:12:36 <stefanh> bernard talks us through the slides
20:12:41 <vivien> Topic: Issue 350: New permission definitions are wrong (Harald)
20:12:58 <stefanh> First two mediacapture-main issues, #350 & #359
20:13:14 <stefanh> First out: Harald talking about #350
20:13:17 <vivien> -> https://github.com/w3c/mediacapture-main/issues/350 Issue 350
20:13:39 <stefanh> ...reason to reference Permission API spec - to do like everyone else
20:13:59 <stefanh> ...done fairly well, but not completely well
20:14:46 <stefanh> ...persistent vs. temporary permissions. Permission to use again or not was unclaer. Revocation was also unclear. Those two were or problems.
20:15:04 <stefanh> ...problem with Permission spec was that it is changing.
20:15:28 <stefanh> ...Will go through three issues in sequence, hoping to get agreement on them.
20:15:49 <stefanh> #1: what is temporary grant?
20:16:00 <dom> dom has joined #webrtc
20:16:03 <stefanh> ....e.g. use this camera once only
20:16:35 <stefanh> ...do getUserMedia again on the same device. Prompted or not?
20:17:24 <stefanh> ....I think the spec now says track B gets permission without prompt. Similar to clone track.
20:17:50 <stefanh> ...three options A, B, C - see slide.
20:18:00 <stefanh> Justin: how does others do?
20:18:16 <dom> s/does/do/
20:18:30 <stefanh> Harald: they do not have temporary permission, and use revocation instead to take away permission.
20:18:57 <stefanh> ...therefore I put temporary permission in our spec.
20:18:59 <vivien> present+ AdamB
20:19:18 <stefanh> Martin: geolocation implementations have temporary permission.
20:19:35 <stefanh> JiB: FF asks everytime, Safari different.
20:19:57 <stefanh> JiB: What interop problems are we solving by speccing this?
20:20:23 <stefanh> unknow said something I did not catch
20:20:28 <vivien> (slide 8)
20:20:42 <stefanh> Martin: tha tis what we got permission API for - the site can check
20:21:00 <stefanh> JiB: FF is updating permission UI
20:21:23 <stefanh> Harald: JiB you're proposing we do not to spec this out?
20:21:50 <vivien> ccccccevieuivrugkdfhdbrcblgickbujgrrdbctdgnc
20:21:55 <stefanh> JiB: this is an area where browsers add value
20:22:07 <stefanh> ...and differentiate
20:22:33 <stefanh> Ekr: I'm not follow, A and C seems to be the same.
20:22:49 <vivien> present+ Erik
20:23:06 <stefanh> ....big problem is prompting, the site need to know
20:23:40 <stefanh> Justin: needs to be clear if gUM on same device gives prompt.
20:23:55 <stefanh> ...we need to decide if we want A or C minimum
20:24:29 <stefanh> JiB: Permission API allows checking if a prompt will be shown or not
20:24:59 <stefanh> Justin: we could have different policies in different browsers asa long as we can check
20:25:42 <stefanh> Harald+Martin: we seem to agree on A
20:25:54 <stefanh> Justin: Chrome implements B
20:26:08 <stefanh> Martin: no, Chrome is fine with A
20:26:14 <Erik_L> Erik_L has joined #webrtc
20:27:10 <stefanh> Justin: I think we're good.
20:27:24 <stefanh> Conclusion: current spec OK!!
20:27:49 <stefanh> Harald: raise a nwe bug if you find it not determistic
20:27:56 <vivien> (slide 9)
20:28:02 <stefanh> Next slide
20:28:28 <stefanh> Harald: About registration so site would know if permission was revoked
20:28:37 <stefanh> ...we don't have text for that
20:28:48 <stefanh> ....two alternatives
20:29:00 <stefanh> ...A do nothing when revoked
20:29:19 <stefanh> ...B stop all track and fire "ended" event on the tracks
20:29:51 <stefanh> JiB: Sounds fine, but I'm confused about the Permission API - does it talk about the site or about the user?
20:30:50 <stefanh> Harald: seems to be two ways to reack revoked: site, UA can learn new info that leads it to revoking
20:31:20 <stefanh> Adambe: Comment to JiB: we've had stop() on track were a site can revoke its own permission
20:31:42 <stefanh> Ekr: ....missed...
20:32:07 <stefanh> JiB: revoking only deals with temprary permission, not persisted permission
20:32:14 <dom> [use case for permission revokation for getUserMedia from the site: the site wants to take a profile picture, but just once; ask for permission, gets the picture, then revoke it]
20:32:37 <mt_____> revoke() resets all access to that origin
20:32:37 <stefanh> s/revoking/stop()/
20:32:57 <mt_____> stop() just ends access to the track, if it's the last thing using that device, then the device can turn off
20:33:31 <stefanh> JiB: problem is that permission has a booleabn model, not none/temporary/persisted/
20:33:50 <stefanh> Harald: I think hearing that if permission is revoked tracks should stop.
20:34:05 <stefanh> Next slide: choosing from devices
20:34:54 <stefanh> ...prmission spec separated requesting permission and prompting user (to select right device)
20:35:47 <stefanh> ...I propose we change gUM to use the prompt the user algorithm from the permission spec (and drop the distance fitness stuff in gUM
20:36:15 <stefanh> JiB: is the intent to be neutral functionaluty wise?
20:36:19 <stefanh> harald: yes
20:36:45 <stefanh> JiB: not sure why we're creating a dependcy on a spec that is still alive
20:36:58 <stefanh> ...when in last call
20:37:29 <stefanh> Harlad: algorithm badly chosen word by me, its really an API
20:38:23 <stefanh> JiB: this does not anything like the request API
20:38:37 <vivien> (we are on slide 10)
20:39:01 <stefanh> ...we're going to ask for the resource, not fiddle with the settings. Makes sense?
20:39:11 <stefanh> Harald: yes, unfortunately
20:39:39 <stefanh> ...I'll file a new Issue, and we will return to this question.
20:40:16 <stefanh> JiB: OK with me. Question: what did we aim to solve with refering to Permission API?
20:40:35 <stefanh> Dom: one goal was to get revokation from the permission API
20:40:55 <mt_____> hta1: we can still use https://w3c.github.io/permissions/#prompt-the-user-to-choose; it doesn't imply a transition to "granted" in response to a positive result
20:41:17 <stefanh> ...still some open ends.
20:41:39 <stefanh> Martin: I think we can use the permission promtp the user algorithm
20:41:55 <stefanh> ...does not imply the permanent permission state would change
20:42:09 <Erik_L> @vivien I can take the slides now if that is desired
20:42:12 <stefanh> JiB: we can spec it in gum
20:42:23 <stefanh> Martin: editorial question.
20:42:50 <stefanh> Shijun: permission per device type, not per deviceId.
20:43:21 <stefanh> Martin: good qusetion. Permission spec vague on this point on purpose. Browsers differ.
20:43:42 <stefanh> ...all up to how the browser interprets the signals from the user.
20:44:34 <stefanh> Harald: when I patched the permission spec I included the deviceId. The idea was to allow using the permission API per device if the UA wants to.
20:44:42 <stefanh> ...up ro UA.
20:45:11 <stefanh> Shijun: So Chrome would allow any camera to be used if there is permission to use one camera.
20:45:23 <stefanh> Harald: other issues (slide 11)?
20:45:38 <dom> ScribeNick: dom
20:45:45 <dom> Topic: ISSUe 359
20:46:10 <dom> s/359/359 for Media Capture
20:46:17 <vivien> Erik_L, you are now presneter
20:46:24 <dom> -> https://github.com/w3c/mediacapture-main/issues/359 Media Capture Issue 359
20:46:42 <burn> shijun, there is some wording in the spec that the user needs to be made clear on whether the permission grant they give is per device or per device type, but the UA may choose either type as long as they are clear
20:46:44 <dom> Stefan: Browser is currently required to clear deviceId if permission was not granted and browsing session ended
20:46:59 <dom> ... this was added from the PING review to reduce the fingerprinting surface from device enumeration
20:47:26 <dom> ... issue 359 proposes to change this MUST to MAY
20:47:42 <dom> ... the argument being that this is similar to cookies and should be treated the same
20:47:59 <dom> ... from an architectural perspective, it adds complexity, and likewise for implementation
20:48:15 <dom> mt: when we added this from PING review, it was unclear what we meant by "browsing session"
20:48:48 <dom> ... since then, the definition seems to have converged towards something that makes this very complex to implement
20:48:55 <dom> ... and that complexity seems unnecessary
20:49:15 <dom> jib: I wrote the code martin referred to
20:49:40 <dom> ... I had to diverge from what the spec describes a little, tracking across tabs and windows for the given origin
20:50:02 <dom> ... so it's already more complex than "closing a tab" being the end of a browsing session
20:50:22 <dom> ... so if we keep the same as current, we would need to bring further clarity
20:50:31 <dom> ekr: what's the argument for keeping the current text?
20:50:40 <dom> stefan: it brings a fingerprint surface
20:50:43 <dom> ekr: just like cookies
20:50:54 <dom> stefan: but cookies aren't exposed the same way
20:51:03 <dom> ... we would have to add @@@ to make them the same
20:51:09 <dom> ekr: that sounds like a great solution
20:51:16 <dom> mt: we could then provide the right UX for this
20:51:36 <dom> jib: should we then link the MAY to having deviceIds exposed just like cookies
20:51:42 <dom> stefan: that would work for me
20:52:21 <dom> justin: so the proposal is "MUST" by default, and a MAY if the browser provides a cookies-like UX
20:52:46 <dom> mt: I think we're describing something a bit more engaged than this: e.g. if a site can't store cookies, deviceIds can't persist
20:53:08 <dom> ... if you clear your cookies, deviceIds get reset
20:53:31 <dom> ekr: the easiest way to implement this would be to create a pseudo-cookie for the device identifier
20:53:40 <dom> mt: I believe that's what some implementations do
20:53:52 <dom> ekr: although you wouldn't make it accessible through .cookies
20:54:17 <dom> stefan: I think we have 2 options: keep the MUST, or change to MAY and refer to cookie behavior
20:54:27 <dom> ekr: I think the 2nd is quite clearly superior
20:54:54 <dom> ... ie remove the MUST, and add text on cookie-behavior
20:55:10 <dom> ... the current is not a useful feature
20:55:28 <dom> jib: note that as soon as you use gUM, the deviceId becomes persistent, which is probably 99% of cases
20:55:46 <dom> ... but I would be happy with text making temp deviceId similar to cookies
20:55:52 <dom> justin: remind me whta's the privacy issue?
20:56:18 <dom> stefan: the drive-by Web not intending to use your camera but just doing device enumeration to act as a cookie
20:56:39 <dom> ... anyone willing to create a pull request to propose this change?
20:56:53 <dom> mt: I tried several times and got yelled at, so can't do it
20:57:01 <dom> jib: I can give it a shot
20:57:15 <dom> ... what behavior would we require for the MAY?
20:57:29 <dom> mt: my expectation is that during a browsing session, these identifiers MUST be stable
20:57:47 <dom> ... and the browser SHOULD persist them as long as cookies, and MUST NOT keep them longer than cookies
20:58:03 <dom> ... if a site is blocked from using cookies, I'm not sure what we should do
20:58:10 <dom> ... but we would need to say something about that
20:58:29 <dom> stefan: I think we need the same requirement that the deviceId can't be the same across browsing sessions
20:58:34 <dom> mt: or even across realms
20:58:40 <dom> ... there are multiple ways
20:59:03 <dom> jib: anything about making the deviceIds being as visible as cookies? currently they're not
20:59:23 <dom> justin: [missed]
20:59:37 <dom> mt: I don't think we should put UX requirements in
20:59:44 <dom> s/justin/shijun/
21:00:03 <dom> shijun: I think the current text has a good balance between privacy and the usage scenario
21:00:38 <dom> ... I don't think Chrome would satisfy the new requirements
21:00:55 <dom> ... and I don't they should need to since this is lower privacy level
21:01:07 <dom> mt: not sure what you're suggesting; maybe you could provide a pull request to clarify?
21:01:21 <dom> shijun: [misseð]
21:01:36 <burn> shijun is saying that he wants the current text.
21:01:45 <dom> mt: my position is that if someone wants to implement the current text, that's fine with me
21:01:48 <burn> (the MUST clear text)
21:01:55 <dom> ... so whatever text we produce should allow what the current spec mandates
21:02:23 <dom> jib: if we add the MAY, it would still allow the "hidden cookie" approach current browsers do
21:02:24 <vivien> s/[misseð]/I prefer to stay with the current text/
21:02:39 <dom> stefan: (in fact, in Chrome, clearing cookies doesn't clear deviceIds - you need to go through a different menu)
21:03:12 <dom> jib: selecting all "cookies" filtered for a given site won't clear deviceIds indeed, neither in FF nor in Chrome
21:03:22 <dom> ... but clearing cookies for a site should work
21:03:40 <dom> stefan: can we proceed with jib providing a pull request, and we check that it allows the current spec behavior?
21:03:51 <dom> jib: I'm not sure I know what the right language would be though
21:03:58 <dom> ... but I can give it a shot
21:04:21 <dom> Topic: Turn DTX on/off (WebRTC)
21:04:38 <vivien> Issue 644/PR 675: Attribute to turn on/off CN/DTX (Bernard Aboba)
21:04:47 <dom> Bernard: our goal is to allow to turn on/off DTX immediately on RtpSender
21:05:02 <dom> ... stefan noted that in some cases, DTX is always on
21:05:37 <dom> ... harald asked about DTX being activable only if CN has been negotiated
21:06:06 <dom> justin: I don't know how that would work
21:06:27 <dom> harald: the easy way out would be to define "no comfort noise" as "lower comfort noise level possible"
21:06:36 <dom> stefan: can I ask about use cases?
21:06:51 <dom> ekr: I thought this was about Opus where you can't actually have CN
21:07:00 <dom> ... where 911 require CN
21:07:16 <dom> aboba: one way to solve this is to @@@
21:07:31 <dom> ekr: I think cullen had a strong opinion on this
21:08:13 <Erik__L> Erik__L has joined #webrtc
21:08:18 <dom> aboba: the other question is whether anything is needed on receiver
21:08:28 <dom> ... or it should always decode
21:08:32 <dom> scribenick: stefanh
21:08:46 <stefanh> Just about the sender.
21:08:52 <stefanh> next slide
21:08:58 <stefanh> Current state of PR.
21:09:09 <stefanh> ...see slide.
21:09:29 <vivien> (slide 15)
21:09:37 <burn_> burn_ has joined #webrtc
21:10:01 <stefanh> ...question: what if getParam on a receiver, what will read out for DTX?
21:10:31 <stefanh> ...boolean on Enum?
21:10:50 <stefanh> Justin: we'll be sorry if we do boolean, let's use Enum
21:10:56 <stefanh> ...bike shed names
21:11:18 <stefanh> Bernard: nex tslide
21:11:31 <stefanh> RED/FEC/RTX
21:11:35 <vivien> (slide 16)
21:11:39 <stefanh> ...see slide
21:11:41 <vivien> Topic: Issue 548/PR 647/ RTX/RED/FEC Handling
21:11:52 <vivien> s/nex t/next /
21:12:56 <stefanh> ...use codec prefs to turn on/off FEC etc.
21:13:41 <stefanh> ...PR647 clarifies what is on slide 16, not changing anything.
21:13:45 <stefanh> ...comments?
21:14:04 <stefanh> ...Pr683 proposes changes
21:14:29 <stefanh> ...removes rtx from codecs[]
21:14:56 <stefanh> ...next slide
21:14:59 <vivien> (slide 18)
21:15:29 <stefanh> ...impact: creates problem, removes possiboility to take rtx in or out
21:16:09 <stefanh> ...rtx entry for each codec transmitted
21:16:54 <stefanh> Justin: if we hate how rtx works, why don't we change that instead of creating crazy apis? Use flex-rtx
21:17:14 <stefanh> Bernard: my rec is to not merge 683. OK?
21:17:25 <stefanh> Justin agrees
21:17:38 <stefanh> Bernard: next slide, issue 706 set direction
21:17:54 <vivien> Topic: Issue 706: How does setDirection interact with active/inactive sender/receivers?
21:18:06 <stefanh> ...JSEP 5.2.4 direction attributes in offer
21:18:23 <stefanh> ...what states are referred?
21:18:30 <stefanh> ...next slide
21:18:33 <vivien> s/slide 18/slide 17/
21:19:14 <stefanh> ...WebRTC 1.0 5.1: relation between setDirection and active/inactive senders/receivers
21:19:42 <stefanh> ...next slide: WebRTC 1.0 5.4
21:20:21 <stefanh> ...next slide: all the above creates confusion, Peter put up a proposal at github, see explanation i slide
21:21:35 <stefanh> ...Proposal: remove references to WebRTC 10 5.1 and update JSEP 5.2.4
21:21:43 <Erik__L> -40 mins remianing
21:21:59 <stefanh> Justin: this makes sense
21:22:25 <stefanh> Bernard: next slide proposes change to WebRTC 10 5.1.
21:22:35 <stefanh> ...see slide for details
21:23:06 <stefanh> ....makes sense?
21:23:14 <stefanh> XX: makes sense
21:23:35 <stefanh> Next slide, IdP. Martin to talk.
21:24:06 <vivien> Topic: Issue 555: Sort out requirements around IdpLoginError
21:24:37 <stefanh> Martin: Issue 555: IdP needs extra info from the user
21:25:01 <stefanh> ...current spec is bad: Throws, DOM exception
21:25:12 <stefanh> ...next slide has proposals
21:25:38 <stefanh> ...Option 1: overload return value - not great
21:25:56 <stefanh> ...Option 2 extra arguments to callback
21:26:45 <stefanh> ...I prefer Option 1. What do people think?
21:27:08 <stefanh> PR to be written by Martin for Option 1.
21:27:28 <vivien> Topic: Issue 678: Support Assertions that Identify the Recipient
21:27:31 <stefanh> ....Issue 678: identify the receiver
21:27:55 <stefanh> ...Cullen has been doing this in an inelegant way
21:28:22 <stefanh> ...proposal: extend setIdentityProvider
21:28:53 <stefanh> ...question: how to populate in certain situation (when it is unknown)?
21:29:18 <stefanh> Ekr: Martin's proposal seems OK
21:30:03 <stefanh> Martin: the IdP will know who you are talking to, not a big problem
21:30:21 <stefanh> Ekr: FB works like this, feature rather than a problem
21:30:35 <vivien> Topic: Issue 685: JSEP Reference for Receipt of Multiple RTP Encodings
21:30:37 <stefanh> Bernard: Issue 685
21:30:58 <stefanh> ...receive multiple RTP encodings (receive multicast)
21:31:27 <stefanh> ... a case talked about in JSEP, but not described
21:31:37 <stefanh> ... proposed to describe in JSEP
21:31:53 <stefanh> ... any opinion
21:32:29 <stefanh> Justin: we've talked about this, and we think we should have a section describing simulcast that can referred to
21:32:44 <stefanh> Bernard: next slide
21:32:49 <vivien> Topic: Issue 692: Meaning of “Liveness Checks” Have Failed
21:33:01 <stefanh> ...Issue 692 liveness checks
21:33:22 <stefanh> ....what is meant? How many must fail to go to disconnected
21:33:45 <stefanh> ...next slide.
21:34:10 <stefanh> Justin: I think liveness checks refers to rtp packets not coming in
21:34:24 <stefanh> XXX: can be different things
21:34:35 <stefanh> Bernard: wow more complex than I understood
21:35:20 <burn> burn has joined #webrtc
21:35:50 <vivien> present+ PeterT
21:35:54 <stefanh> Varun: I think applications are looking for detection speeds in the order of 100ms
21:36:10 <stefanh> Justin: more on the "some seconds" level
21:36:51 <stefanh> Justin: we should have two different things: transport OK, and packets being received. Different things.
21:37:15 <stefanh> Peter: we could reveal info on consent checks and last time a packet was received.
21:37:18 <vivien> s/XXX/Peter/
21:37:34 <stefanh> ...if we do that, what does disconnected mean? is it needed?
21:37:49 <stefanh> Bernard: [missed]
21:38:18 <stefanh> Varun: I think revealing the timestamp in stats is enough, we may not need disconnected
21:38:33 <stefanh> Bernard: in ortc it means consent check has failed.
21:39:01 <stefanh> Justin: disconnect related to consent checks.
21:39:25 <stefanh> Harald: relates to next issue - circuit breaker
21:40:07 <vivien> -> https://github.com/w3c/webrtc-pc/issues/700 webrtc-pc Issue 700
21:40:11 <stefanh> (different meanings of connection between circuit breaker and disconnected)
21:40:24 <stefanh> Bernard: anyone implementing circuit breakers?
21:40:36 <stefanh> Justin: we might consider to implement.
21:40:39 <Erik__L> yes my bad, 10 mins over
21:41:00 <stefanh> Liveness checks need more time, and we're out.
21:41:31 <vivien> [meeting adjourned]
21:42:14 <hta1> hm. can we make liveness checks an IETF topic and discuss it in Berlin?
21:46:15 <vivien> RRSAgent, draft minutes
21:46:15 <RRSAgent> I have made the request to generate http://www.w3.org/2016/06/28-webrtc-minutes.html vivien
21:46:44 <vivien> RRSAgent, bye
21:46:44 <RRSAgent> I see no action items