See also: IRC log
<stefanh> Proposed agenda: http://lists.w3.org/Archives/Public/public-webrtc/2014Apr/0040.html
<scribe> ScribeNick: dom
<scribe> scribe: dom
<stefanh> Minutes: 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]
<stefanh> http://lists.w3.org/Archives/Public/public-webrtc/2014Apr/att-0045/DC_f2f_planning_WebRTC.pdf
-> http://lists.w3.org/Archives/Public/public-webrtc/2014Apr/att-0045/DC_f2f_planning_WebRTC.pdf Proposed agenda for May F2F
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
<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
-> http://lists.w3.org/Archives/Public/public-webrtc/2014Apr/att-0048/ConstraintsPC-mt.pdf Martin's slides
<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
<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
[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