WebRTC and Media Capture Virtual Interim

28 Jun 2016



See also: IRC log


Dominique_Hazael-Massieux, Martin_Thomson, Stefan, Harald, Bernard_Aboba, Dan_Burnett, Emil_Ivov, Sherwin_Sim, Shijun_Sun, Varun, Jan-Ivar, Vivien, Andy_Hutton, Ekr, AlexG, AdamB, Erik, PeterT
Harald, Stefan, Erik
Stefan, Dom



Stefan run through the initial slides...

bernard talks us through the slides

Stefan: First two mediacapture-main issues, #350 & #359

Stefan: First out: Harald talking about #350

Issue 350: New permission definitions are wrong (Harald)

Issue 350

Harald: reason to reference Permission API spec - to do like everyone else
...done fairly well, but not completely well

Harald: persistent vs. temporary permissions. Permission to use again or not was unclaer. Revocation was also unclear. Those two were or problems.
... problem with Permission spec was that it is changing.
... Will go through three issues in sequence, hoping to get agreement on them.

Harald:#1: what is temporary grant?
... e.g. use this camera once only
... do getUserMedia again on the same device. Prompted or not?
... I think the spec now says track B gets permission without prompt. Similar to clone track.
... three options A, B, C - see slide.

Justin: how do others do?

Harald: they do not have temporary permission, and use revocation instead to take away permission.
... therefore I put temporary permission in our spec.

Martin: geolocation implementations have temporary permission.

JiB: FF asks everytime, Safari different.
... What interop problems are we solving by speccing this?

(unknow said something I did not catch)

<vivien> (slide 8)

Martin: tha tis what we got permission API for - the site can check

JiB: FF is updating permission UI

Harald: JiB you're proposing we do not to spec this out?

JiB: this is an area where browsers add value
... and differentiate

Ekr: I'm not follow, A and C seems to be the same.
... big problem is prompting, the site need to know

Justin: needs to be clear if gUM on same device gives prompt.
... we need to decide if we want A or C minimum

JiB: Permission API allows checking if a prompt will be shown or not

Justin: we could have different policies in different browsers asa long as we can check

Harald+Martin: we seem to agree on A

Justin: Chrome implements B

Martin: no, Chrome is fine with A

Justin: I think we're good.

Conclusion: current spec OK!!

Harald: raise a nwe bug if you find it not determistic

Next slide

<vivien> (slide 9)

Harald: About registration so site would know if permission was revoked
... we don't have text for that
... two alternatives
... A do nothing when revoked
... B stop all track and fire "ended" event on the tracks

JiB: Sounds fine, but I'm confused about the Permission API - does it talk about the site or about the user?

Harald: seems to be two ways to reack revoked: site, UA can learn new info that leads it to revoking

Adambe: Comment to JiB: we've had stop() on track were a site can revoke its own permission

Ekr: ....missed...

JiB: stop() only deals with temprary permission, not persisted permission

<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]

<mt_____> revoke() resets all access to that origin

<mt_____> stop() just ends access to the track, if it's the last thing using that device, then the device can turn off

JiB: problem is that permission has a booleabn model, not none/temporary/persisted/

Harald: I think hearing that if permission is revoked tracks should stop.

Next slide: choosing from devices

Harald: permission spec separated requesting permission and prompting user (to select right device)
... I propose we change gUM to use the prompt the user algorithm from the permission spec (and drop the distance fitness stuff in gUM

JiB: is the intent to be neutral functionaluty wise?

harald: yes

JiB: not sure why we're creating a dependcy on a spec that is still alive
... when in last call

Harlad: algorithm badly chosen word by me, its really an API

JiB: this does not anything like the request API

<vivien> (we are on slide 10)

JiB: we're going to ask for the resource, not fiddle with the settings. Makes sense?

Harald: yes, unfortunately
... I'll file a new Issue, and we will return to this question.

JiB: OK with me. Question: what did we aim to solve with refering to Permission API?

Dom: one goal was to get revokation from the permission API

<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

Dom: still some open ends.

Martin: I think we can use the permission promtp the user algorithm
... does not imply the permanent permission state would change

<Erik_L> @vivien I can take the slides now if that is desired

JiB: we can spec it in gum

Martin: editorial question.

Shijun: permission per device type, not per deviceId.

Martin: good qusetion. Permission spec vague on this point on purpose. Browsers differ.
... all up to how the browser interprets the signals from the user.

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.
... up ro UA.

Shijun: So Chrome would allow any camera to be used if there is permission to use one camera.

Harald: other issues (slide 11)?

Issue 359: MUST clear requirement for deviceId

Issue 359

<dom> ScribeNick: dom

<vivien> Erik_L, you are now presenter

<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

Stefan: Browser is currently required to clear deviceId if permission was not granted and browsing session ended
... this was added from the PING review to reduce the fingerprinting surface from device enumeration
... issue 359 proposes to change this MUST to MAY
... the argument being that this is similar to cookies and should be treated the same
... from an architectural perspective, it adds complexity, and likewise for implementation

mt: when we added this from PING review, it was unclear what we meant by "browsing session"
... since then, the definition seems to have converged towards something that makes this very complex to implement
... and that complexity seems unnecessary

jib: I wrote the code martin referred to
... I had to diverge from what the spec describes a little, tracking across tabs and windows for the given origin
... so it's already more complex than "closing a tab" being the end of a browsing session
... so if we keep the same as current, we would need to bring further clarity

ekr: what's the argument for keeping the current text?

stefan: it brings a fingerprint surface

ekr: just like cookies

stefan: but cookies aren't exposed the same way
...we would have to add text saying persisted deviceIds must be shown when the user inspects cookies for a site, that they must be cleared when cookies are cleared, and that if the user does not allow cookies for a site then persisting deviceIds is not allowed for the site to make them the same

ekr: that sounds like a great solution

mt: we could then provide the right UX for this

jib: should we then link the MAY to having deviceIds exposed just like cookies

stefan: that would work for me

justin: so the proposal is "MUST" by default, and a MAY if the browser provides a cookies-like UX

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
... if you clear your cookies, deviceIds get reset

ekr: the easiest way to implement this would be to create a pseudo-cookie for the device identifier

mt: I believe that's what some implementations do

ekr: although you wouldn't make it accessible through .cookies

stefan: I think we have 2 options: keep the MUST, or change to MAY and refer to cookie behavior

ekr: I think the 2nd is quite clearly superior
... ie remove the MUST, and add text on cookie-behavior
... the current is not a useful feature

jib: note that as soon as you use gUM, the deviceId becomes persistent, which is probably 99% of cases
... but I would be happy with text making temp deviceId similar to cookies

justin: remind me whta's the privacy issue?

stefan: the drive-by Web not intending to use your camera but just doing device enumeration to act as a cookie
... anyone willing to create a pull request to propose this change?

mt: I tried several times and got yelled at, so can't do it

jib: I can give it a shot
... what behavior would we require for the MAY?

mt: my expectation is that during a browsing session, these identifiers MUST be stable
... and the browser SHOULD persist them as long as cookies, and MUST NOT keep them longer than cookies
... if a site is blocked from using cookies, I'm not sure what we should do
... but we would need to say something about that

stefan: I think we need the same requirement that the deviceId can't be the same across browsing sessions

mt: or even across realms
... there are multiple ways

jib: anything about making the deviceIds being as visible as cookies? currently they're not

shijun: [missed]

mt: I don't think we should put UX requirements in

shijun: I think the current text has a good balance between privacy and the usage scenario
... I don't think Chrome would satisfy the new requirements
... and I don't they should need to since this is lower privacy level

mt: not sure what you're suggesting; maybe you could provide a pull request to clarify?

shijun: I prefer to stay with the current text

<burn> shijun is saying that he wants the current text.

mt: my position is that if someone wants to implement the current text, that's fine with me

<burn> (the MUST clear text)

mt: so whatever text we produce should allow what the current spec mandates

jib: if we add the MAY, it would still allow the "hidden cookie" approach current browsers do

stefan: (in fact, in Chrome, clearing cookies doesn't clear deviceIds - you need to go through a different menu)

jib: selecting all "cookies" filtered for a given site won't clear deviceIds indeed, neither in FF nor in Chrome
... but clearing cookies for a site should work

stefan: can we proceed with jib providing a pull request, and we check that it allows the current spec behavior?

jib: I'm not sure I know what the right language would be though
... but I can give it a shot

Issue 644/PR 675: Turn DTX on/off

Issue 644 & PR 675

<vivien> Issue 644/PR 675: Attribute to turn on/off CN/DTX (Bernard Aboba)

Bernard: our goal is to allow to turn on/off DTX immediately on RtpSender
... stefan noted that in some cases, DTX is always on
... harald asked about DTX being activable only if CN has been negotiated

justin: I don't know how that would work

harald: the easy way out would be to define "no comfort noise" as "lower comfort noise level possible"

stefan: can I ask about use cases?

ekr: I thought this was about Opus where you can't actually have CN
... where 911 require CN

Bernard: one way to solve this is to @@@

ekr: I think cullen had a strong opinion on this

Bernard: the other question is whether anything is needed on receiver
... or it should always decode

<scribe> scribenick: stefanh

Just about the sender.

next slide

Current state of PR.

<vivien> (slide 15)

Bernard: see slide.
...question: what if getParam on a receiver, what will read out for DTX?
... boolean on Enum?

Justin: we'll be sorry if we do boolean, let's use Enum
... bike shed names

Bernard: next slide

Issue 548/PR 647: RTX/RED/FEC Handling

Issue 548 & PR 647

<vivien> (slide 16)

Bernard: see slide

Bernard: use codec prefs to turn on/off FEC etc.
... PR647 clarifies what is on slide 16, not changing anything.
... comments?
... Pr683 proposes changes
... removes rtx from codecs[]
... next slide

<vivien> (slide 17)

Bernard: impact: creates problem, removes possiboility to take rtx in or out
... rtx entry for each codec transmitted

Justin: if we hate how rtx works, why don't we change that instead of creating crazy apis? Use flex-rtx

Bernard: my rec is to not merge 683. OK?

Justin agrees

Issue 706: How does setDirection interact with active/inactive sender/receivers?

Issue 706

Bernard: next slide, issue 706 set direction

Bernard: JSEP 5.2.4 direction attributes in offer
... what states are referred?
... next slide
... WebRTC 1.0 5.1: relation between setDirection and active/inactive senders/receivers
... next slide: WebRTC 1.0 5.4
... next slide: all the above creates confusion, Peter put up a proposal at github, see explanation i slide
...Proposal: remove references to WebRTC 10 5.1 and update JSEP 5.2.4

<Erik__L> -40 mins remaining

Justin: this makes sense

Bernard: next slide proposes change to WebRTC 10 5.1.
... see slide for details
... makes sense?

XX: makes sense

Next slide, IdP. Martin to talk.

Issue 555: Sort out requirements around IdpLoginError

Issue 555

Martin: Issue 555: IdP needs extra info from the user
... current spec is bad: Throws, DOM exception
... next slide has proposals
... Option 1: overload return value - not great
... Option 2 extra arguments to callback
... I prefer Option 1. What do people think?

PR to be written by Martin for Option 1.

Issue 678: Support Assertions that Identify the Recipient

Issue 678

Martin: Issue 678: identify the receiver
... Cullen has been doing this in an inelegant way
...proposal: extend setIdentityProvider
...question: how to populate in certain situation (when it is unknown)?

Ekr: Martin's proposal seems OK

Martin: the IdP will know who you are talking to, not a big problem

Ekr: FB works like this, feature rather than a problem

Issue 685: JSEP Reference for Receipt of Multiple RTP Encodings

Issue 685

Bernard: Issue 685
... receive multiple RTP encodings (receive multicast)
... a case talked about in JSEP, but not described
... proposed to describe in JSEP
... any opinion

Justin: we've talked about this, and we think we should have a section describing simulcast that can referred to

Bernard: next slide

Issue 692: Meaning of “Liveness Checks” Have Failed

Issue 692

Bernard: Issue 692 liveness checks
... what is meant? How many must fail to go to disconnected
... next slide.

Justin: I think liveness checks refers to rtp packets not coming in

Peter: can be different things

Bernard: wow more complex than I understood

Varun: I think applications are looking for detection speeds in the order of 100ms

Justin: more on the "some seconds" level
... we should have two different things: transport OK, and packets being received. Different things.

Peter: we could reveal info on consent checks and last time a packet was received.
... if we do that, what does disconnected mean? is it needed?

Bernard: [missed]

Varun: I think revealing the timestamp in stats is enough, we may not need disconnected

Bernard: in ortc it means consent check has failed.

Justin: disconnect related to consent checks.

Harald: relates to next issue - circuit breaker

<vivien> webrtc-pc Issue 700

(different meanings of connection between circuit breaker and disconnected)

Bernard: anyone implementing circuit breakers?

Justin: we might consider to implement.

Liveness checks need more time, and we're out.

<Erik__L> yes my bad, 10 mins over

<vivien> [meeting adjourned]

<hta1> hm. can we make liveness checks an IETF topic and discuss it in Berlin?

Summary of Action Items

Summary of Resolutions

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.144 (CVS log)
$Date: 2016/07/04 07:17:45 $