- From: Dominique Hazael-Massieux <dom@w3.org>
- Date: Tue, 29 Apr 2014 16:59:54 +0200
- To: public-webrtc <public-webrtc@w3.org>
Hi,
The minutes of our teleconference yesterday (April 28) are available at:
http://www.w3.org/2014/04/28-webrtc-minutes.html and copied as text
below. Please send corrections to the list.
The accompanying audio record is available at:
http://media.w3.org/2014/04/28-webrtc.ogg or
http://media.w3.org/2014/04/28-webrtc.mp3
Dom
Web Real-Time Communications Working Group Teleconference
28 Apr 2014
[2]Agenda
[2]
http://lists.w3.org/Archives/Public/public-webrtc/2014Apr/0040.html
See also: [3]IRC log
[3] http://www.w3.org/2014/04/28-webrtc-irc
Attendees
Present
ekr, mt, +1.403.244.aaaa, [Microsoft], fluffy, stefanh,
Jim_Barnett, gmandyam, +aacc, +91.22.39.14.aadd, hta,
Milan_Patel, dom, Dan_Druta, +46.1.07.14.aaee,
Stephane_Cazeaux, [IPcaller], adambe?, adam, jesup,
+1.408.902.aaff, milan_patel?, +1.214.414.aagg,
+1.267.934.aahh, +1.425.610.aaii, jib, +1.703.628.aajj,
+1.604.210.aakk, +1.613.435.aall
Regrets
Chair
stefanh, hta
Scribe
dom
Contents
* [4]Topics
1. [5]Admin
2. [6]May F2F agenda
3. [7]Schedule and scoping
4. [8]Use of "constraint compromise" in WebRTC
5. [9]Privacy & Security
6. [10]AOB
* [11]Summary of Action Items
__________________________________________________________
<stefanh> Proposed agenda:
[12]http://lists.w3.org/Archives/Public/public-webrtc/2014Apr/0
040.html
[12]
http://lists.w3.org/Archives/Public/public-webrtc/2014Apr/0040.html
<scribe> ScribeNick: dom
<scribe> scribe: dom
Admin
<stefanh> Minutes:
[13]http://lists.w3.org/Archives/Public/public-webrtc/2013Dec/0
081.html
[13]
http://lists.w3.org/Archives/Public/public-webrtc/2013Dec/0081.html
StefanH: approving minutes from our scoping meeting discussions
on Dec 19?
RESOLUTION: Dec 19 minutes approved
Stefanh: [reviewing proposed agenda]
May F2F agenda
<stefanh>
[14]http://lists.w3.org/Archives/Public/public-webrtc/2014Apr/a
tt-0045/DC_f2f_planning_WebRTC.pdf
[14]
http://lists.w3.org/Archives/Public/public-webrtc/2014Apr/att-0045/DC_f2f_planning_WebRTC.pdf
->
[15]http://lists.w3.org/Archives/Public/public-webrtc/2014Apr/a
tt-0045/DC_f2f_planning_WebRTC.pdf Proposed agenda for May F2F
[15]
http://lists.w3.org/Archives/Public/public-webrtc/2014Apr/att-0045/DC_f2f_planning_WebRTC.pdf
stefanh: slide 2 describes the overall schedule of the 3 days
meeting
... mornings will be used by the IETF RTCWeb WG
... we have the afternoons; the first one will be used by the
Media Capture TF
... Tuesday and Wednesday will be for the WebRTC WG, for which
the chairs are proposing the agenda described on slide 3
... Justin sent out an updated proposal for the "doohickey"
... [reviewing detailed agenda described on slide 3]
... This is a strawman proposal on which we're seeking feedback
... incl on what we're missing
cullen: I assume the doohickey will take more time than
allotted
... it would be good to come out of the meeting with a complete
proposal
ekr: I agree; we should steal time from admin and stats to add
to doohickey
... (e.g. leave only 15 min for admin and 15 min for stats)
cullen: we have a spare hour on Tuesday, we may not need to
steal any time
hta: on stats: the API seems to be well agreed upon
... but the actual stats have not been reviewed in details
... before the meeting, I'll make a proposal, incl. possibly
moving them to a separate document
... but the group needs to look through the stats
ekr: I would suggest we do that by email, and only discuss
controversial ones at the F2F
hta: OK, makes sense to me
juberti: +1, but I want to make sure we review them
... overall, the agenda seems to match the topics we need to
discuss
... on error handling, I have a proposal on TURN server errors
... not sure about what other things would need to be reviewed
... Another item is review of scope
... when can we declare victory?
stefanh: to me, that's part of the schedule discussion
juberti: but waiting till Wed. for that seems to be a recipe
failure
<ekr> I am indifferent to when we discuss it
juberti: we should discuss it early one since that affects the
rest of what we discuss
hta: the meeting should be about decisions, after having made
progress on the list
... until we make progress on the list, I'm not sure how to
progress here
stefanh: we'll look more into when to schedule scoping based on
that feedback
... if the group agrees on the topics, we'll reach out to
individuals to prepare each of them
... for instance, the doohickey proposal will need to be hashed
out on email
hta: ideally, people charged with proposals would get the
discussions started on the list well before the meeting
... so that we can record our agreements at the meeting
juberti: let's assign owners now
stefanh: doohickey should be for justin, ok?
juberti: will do
stefanh: for error handling, we would like to constitute a
small team
... around ekr
... the idea would be to go through the spec and state where we
are wrt error handling
... hopefully most of it should be ok, but there should be
proposals where we're not
ekr: happy to do that
stefanh: stats for hta?
hta: yup
stefanh: for identity, martin or ekr?
ekr: I volunteer martin
mt: works for me
stefanh: for interop issues, we're suggesting Alexandre
Gouaillard to drive this
... alex has been very active in discussion groups on WebRTC
implementation and has lots of experience there
Alexandre: would be happy to prepare something for the meeting
cullen: alex, could you describe some of the things you're
thinking of for interop issues?
alexandre: e.g. the data channels
... interop issues between FF and Chrome
... a few more items that makes it hard
<ekr> +1
cullen: let's focus on where the spec leads to defects, rather
than implementation bugs
ekr: +1
... 3 categories: really unclear spec, ambiguous spec,
implementation bugs
... only the first 2 are useful
... the 2nd case is when reasonable people can interpret the
spec differently
Alexandre: agree we shouldn't discuss implementation bugs
stefanh: for the schedule/scoping, this would be down to hta
and me
hta: it would perhaps be logical to move scoping to end of
Tuesday
... this topic can be very time consuming, so I want a
timeboxed slot
... end of Tuesday would probably work well, allowing also
people to sleep over the discussions
cullen: will there be a proposal ahead of time?
hta: there will, otherwise we will cancel that agenda item
Schedule and scoping
<scribe> scribenick: stefanh
Dom: Last time we talked about scoping was on an earlier telco
... Last week I proposed a new way to scope: freeze what we
have in the spec now, and move that to LC
... additional stuff should be in separate documents.
... We need to agree on that we need a scope, and secondly what
is in and out of that scope.
<ekr> could you please restate the proposal?
Ekr: sound like we're having the DC discussion now
Dom: no, trying to prepare us for DC
... first part of my proposal is to agree that we need to agree
on that there is a set of features in v1 and features that are
out
... we need to agree that we need to freeze
Ekr: Agree, but the spec is a subset of what we need before
freezing, e.g. doohickeys
Hta: anything more than doohickeys
ekr: I can produce a list
cullen: the w3c process means freezing
... the question is if we're close to the point when we can
freeze
... the other question is what we need to add
Dom: We should done sooner rather than later, and that input
was given by app developers.
... at the meeting in May we need a list of items in v1.0, and
I think it should not be much more than what is in the doc now.
Cullen: do you think we have consensus to add doohickeys?
Dom: have nothing against adding, but we should not add a dozen
of more features.
... can we agree that we can develop a list of features before
the May?
... what additional features are needed?
Justin: I think we need doohickeys, stats, and turn error
handling
Dom: can we give out an action to start building a list?
Justin: the data is out there, just look in mailboxes
... we need to have the discussion, but I will dig out the data
we already have.
Harald: I will produce a proposal, but will take input from
people having input to give.
<dom> scribenick: dom
<stefanh> End of schedule discussion.
<stefanh> Next: Constraints in WebRTC
Use of "constraint compromise" in WebRTC
->
[16]http://lists.w3.org/Archives/Public/public-webrtc/2014Apr/a
tt-0048/ConstraintsPC-mt.pdf Martin's slides
[16]
http://lists.w3.org/Archives/Public/public-webrtc/2014Apr/att-0048/ConstraintsPC-mt.pdf
<stefanh> Martin: motivated by Suhas sending a proposal on
doohickeys
Martin: this was triggered by the discussion of what doohickeys
might look like
... I think it has some important points
... not sure I agree with everything it it yet :)
... [slide 3]
... this is what we have to control the peer connection at this
time
... the RTCPeerConnection constructor, updateIce
... the arguments for createOffer
... you also get control surface via SDP modifications
... still aspirational
<ekr> mt, send a pull request for JSEP
Martin: addStream arguments
... slide 4 describes the additional control surface provided
by doohickeys
... with track-specific control
... e.g. distinguishing on-hold vs receive-only
... it opens up a lot of other possibilities; could be used as
a bus for more stuff, e.g. stats, state
... [slide 5]
... the existing control surface doesn't let you provide what's
possible
... nor what is currently being done
... the control surface is "do X", but doesn't tell you whether
X is occurring
... these features are probably needed in a number of cases
... we need to identify these
cullen: doohickeys is bound to a given peer connection,
independently on how many pc a track was added to
martin: indeed
cullen: in terms of capabilities discovery, we need to be
careful that this is a negotiation between the local and remote
ends
martin: clearly
... that's worth keeping in mind while we look to drawbacks of
constraints where the constraints ability to negotiate among
actors is not needed (as I claim)
... which one was one of the origins of constraints for the
camera API
... (in addition to giving latitude to browsers in picking some
values, which is also useful e.g. for bandwidth)
... another drawback of constraints is that feature detection
is not really possible
... and there is less certainty about what browsers do
... slide 7 shows how constraints would be used to detect
capabilities (although the example is probably contrived here)
... then apply, and check state
... slide 8 shows the same without constraints
... slide 9 looks at values where giving leeway to browsers
would be useful
... "advanced" type of settings allow for codependent settings
cullen: this makes sense to me
... mute/unmute is something on which there is direct control
... but resolution switching is more complex and would more
likely benefit from a range of possible values
... as allowed by constraints
... I think it's probably the same set of things as in gUM
martin: I'm starting to get that same conclusion myself,
despite my initial violent reaction to that idea
... constraints make more sense to me know
cullen: if we talk about maxBandwith instead of bandwidth, it
becomes clearer this is more something like mute
martin: @@@missed
<ekr> I note that VideoEngine has minBandwidth
<mt> it was the point that we continually get requests for
minimum bandwidth
hta: the only sensible semantic of min bandwidth is "if
congestion control tells me that I'm below that bandwidth,
throw an error and stop sending"
timpanton: when we first discussed constraints a very long time
ago, we wanted to express them as aspirations
... letting developers express what they want to achieve rather
than direct the browser directly
... if they want to emphasize e.g the speed of movement,
developers should be able to express it
... we've failed to develop a list that would match these
aspirations
... but it might be easier to look at this from a more abstract
approach rather than looking at the bandwidth level
martin: there is definitely situations where you want to cap
bandwidth
... but in general, you're right; I think the other constraints
match what you describe
jib: I agree with martin's list of constraints drawbacks; it
misses one:
... constraints were designed in a space where you need to do
as much as possible in a single call (before of the permission
prompts)
... given that we don't have this here, it seems to me we
should limit ourselves to a more traditional approach where you
make a call, get an error and then make another updated call
... I think we should start simpler, e.g. with just settings
... if it fails, then we move to the more complex solution
juberti: agree with jib
... we've backed away on many fronts on constraints because of
the complexity it brings to implementations
... the fact that we don't have the one-shot limitation here
means we likely don't need constraints
... I'm strongly on the opinion we should have direct API
enveloppe, and not use constraints unless we absolute need it
ekr: independent settings design works for me, as long as we
make sure that things that are not in fact independent are
treated as such
... e.g. framerate and bandwidth consumption
juberti: if you set things in an inconsistent state, you would
get an error
<mt> x.maxBandwidth = 100; x.minBandwidth = 10000; // second
fails
ekr: in hardware codec, frame size, bandwidth and framesize are
not independent properties
... constraints leave more room to browsers for picking the
right properties
... I'll go back and see if this is really an issue
jesup: I share some of ekr's concerns about this
... esp. how would I deal with an error when I set these things
independently
... let's see what ekr comes up with
<ekr> I'm not trying to obstructionist here.
<ekr> If I can't come up with a number of good examples, I'll
STFU
<JimBarnett> we can add an applyConstraint call to
Constrainable that sets/modifies a single property and leaves
other constraints in place.
jesup: when there is not enough bandwidth, apps may adapt
differently (e.g. drop some streams)
<JimBarnett> If it's just a question of API simplicity (for the
app developer - not the UA)
jesup: one of the downside is distinguishing bandwidth vs
quality, which is hard
hta: I'm getting a déjà -vu from 2 years ago
... we had the same discussion; the big argument was that, when
you want to change the state of something, you have to change
everything at once
... because of changing one thing at a time may lead you to
inconsistent states
... the argument was to set all these things at once
... if we expose a 100 knobs with a "apply" step with ad-hoc
rules on inconsistent state sounds scary
... constraints seems like a reasonable approach to describe
what you want and let the browsers deal with the complexity
... the main motivation for constraints was to avoid these
meaningless microstates or these ad-hoc processes
cullen: the resolution + aspect ratio + framerate is a good
example
... I agree we don't want a more complicated mechanism that we
need
... I disagree with the no-prompt claim
... what you request through the doohickey may trigger a
permission prompt to the other end, with a possible human
intervention
... if you think we don't need constraints here, I don't
understand why we would need them in gUM
... we're talking about reserving resources which are not
completely independent
<Suhas> ack
<ekr> So I assume that the way this behaves is that if you do
something that would require extra offers
<ekr> that you can do:
<ekr> frob, frob, frob, frob: createOffer()
martin: jib pointed out that gum has a commitment due to user
prompt
... I think you get the same kind of commitment with the SDP
blob that gets sent over
... that's what tipped me over to constraints
... it sucks, but the bar has been set pretty low
... we don't want to use constraints for everything (e.g.
send/no send)
<stefanh> ekr, each "frob" would generate a "negotiatinneeded"
event
<ekr> stefanh: agreed
martin: but for things that need to be negotiated and where
browsers could use leeway, constraints are teh best things we
have for the moment
<ekr> but I hope you could ignore them
<fluffy> So to summrize Martin, for things wehre constraints
make snese becuase we negotaiton or changes by browser at run
time, constraints make sense. For things like sending /
notSending, they do not.
<fluffy> And I am +1 on what Martin
jib: constraints don't have the monopoly of settings multiple
things at once
... you get that from simple dictionaries
... I think constraints may mean different things to different
people
<stefanh> ekr, yes you can ... I was thinking about a badly
designed app that would just listen to all of them and do
createOffer setLocal.......
jib: cullen, is the person on the other side a separate actor?
are we sure we need e.g. overconstrained events?
<ekr> stefanh: that would be a sad app
cullen: I'm sure we do
jib: let's try it both ways as an experiment
<stefanh> yes, but we will see those too
jib: given the complexity of constraints, I think we need to
look into alternatives
<stefanh> ekr: but I may be wrong - thinking out loud
jib: I don't think we need a full and/or set of settings for
dealing with these codependencies
cullen: send something away, and I'll explain where I think it
doesn't work
jib: I suggest we look at the two approaches and compare
juberti: I don't think we need the entire constraints syntax to
deal with the dependency between framerate/resolution
... the other things we've talked about (send/no-send, bitrate,
...) don't seem to need constraint
... I would rather find ourselves try the simple way, fail and
move to constraints, rather than start form the assumption we
definitely need it
ekr: I think we have the two proposals matching jib's
... suhas and justin
cullen: suhas covers more stuff than would need to be covered
by constraints
ekr: cullen has a use case where he claims you need constraints
... if you can disprove that, do it
jib: I think we should start from scratch, and see if we end up
identifying needs that constraints fulfill
cullen: how do you deal with constraints set on one side and
not the other?
... I think you're pushing for removing constraints from gum
jib: I don't see it that way; we're reusing constraints because
we have it, not because we need it
cullen: the resolution/bandwidth use case exists, you can't
simply wish it away
jib: I'm not wishing it away
<juberti> I think this use case can be handled, without
constraints.
ekr: two possible position: we don't need a bulk-setting
mechanism (constraints being one of various options); we need a
resolution-conflict mechanism, but constraints aren't it
... justin's point is the former, that seems possible
... 2nd one seems crazy to me
... does the browser need to resolve conflicts?
hta: let's move this to the list, consensus is not emerging on
this
Privacy & Security
<stefanh> I've had a look
hta: I sent a proposal for a privacy & security section in
WebRTC
... has anyone looked at this?
[several]: glanced at it briefly only
hta: is it good enough to put it in a draft?
... please take a look and send comments to the list
AOB
[crickets]
stefanh: actions I noted
... harald will propose a scope list with input from others
... ekr will lead error handling for F2F
... hta stats
... martin identity
... alex interop
... justin doohickey
hta: some people have promised to do stuff around constraints
... cullen promised to show one use case that can be satisfied
with only settings (I think?)
cullen: don't remember having said that, but OK
juberti: should we focus on the core doohickey stuff in place
and see the settings/constraints stuff later?
... or are they too intertwined?
hta: I suggest doing the non-intertwined core first sounds
reasonable
cullen: I think the resolution/bandwidth needs to be part of
what doohickeys solve
... independently of how
<Erik> thanks dom
Summary of Action Items
[End of minutes]
__________________________________________________________
Received on Tuesday, 29 April 2014 15:00:19 UTC