W3C home > Mailing lists > Public > public-webrtc@w3.org > July 2016

Summary of decisions made at the joint media capture and webrtc virtual interim meeting of June 28 2016

From: Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com>
Date: Tue, 12 Jul 2016 15:53:48 +0000
To: "public-media-capture@w3.org" <public-media-capture@w3.org>, "public-webrtc@w3.org" <public-webrtc@w3.org>
Message-ID: <1447FA0C20ED5147A1AA0EF02890A64B46B51A84@ESESSMB208.ericsson.se>
Below is a summary of decisions made at the joint media capture and 
webrtc virtual interim meeting of June 28 2016. The slides referred to 
are at [1].

We send this out to get feedback if others agree to the decisions we 
recorded, but also to enable those who were not able attend to provide 
input if they think any of the decisions are wrong.

Note that other things were also discussed at the call (see [2] for 
minutes and [3] for recording), below is just a summary of what was decided.

Sorry for cross posting, but the meeting dealt with both 
mediacapture-main and webrtc-pc.

Stefan for the chairs

[2] https://www.w3.org/2016/06/28-webrtc-minutes
[3] https://www.w3.org/2011/04/webrtc/wiki/June_28_2016#Minutes
[4] https://github.com/w3c/mediacapture-main/pull/373


Related to Issue #350:
- Temporary vs. persistent permission (to use camera/microphone): 
Current spec is right (i.e. option A in slide 8)
- What happens at revocation: all tracks sourced by the device to which 
right to use was revoked are stopped (i.e. option B in slide 9)

Issue #359 (slide 12): The spec currently says that the UA must clear 
all deviceIds at the end of the current browsing session (given that the 
origin has never been given the right to use any camera or microphone) 
to avoid a big fingerprint. However, there were some at the meeting 
pushing for that the UA should have the alternative to treat deviceIds 
like cookies. The outcome was that Jan-Ivar is going to draft a proposal 
(in the form of a PR) that introduces this alternative, and if the group 
accepts it it will be added to the spec. Note, this PR is already out 
for review [4]

Issue 644/PR 675: The proposal in slide 15 was liked and will be 
adopted. getParameters().encodings[].dtx will read out an enum (not a 
boolean) - name of it will be bikeshedded.

PR 683 will not be merged (slide 17)

Issue 706: Bernards proposal of updating JSEP and WebRTC 1.0 was liked; 
for WebRTC 1.0 section 5.1 will be updated as outlined in slide 23.

Issue 555 (slides 26 - 28): option 1 (slide 27) was preferred, Martin 
will draft a PR

Issue 678 (slide 30): we will support Id’ing the intended receiver (in 
addition to the sender) as Martin proposes

Issue 685: A section describing multicast SDPs will be added to JSEP.
Received on Tuesday, 12 July 2016 15:54:50 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:48 UTC