W3C home > Mailing lists > Public > public-webrtc@w3.org > April 2014

[minutes] April 28 teleconf

From: Dominique Hazael-Massieux <dom@w3.org>
Date: Tue, 29 Apr 2014 16:59:54 +0200
Message-ID: <1398783594.4336.57.camel@cumulustier>
To: public-webrtc <public-webrtc@w3.org>

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


       Web Real-Time Communications Working Group Teleconference

28 Apr 2014



   See also: [3]IRC log

      [3] http://www.w3.org/2014/04/28-webrtc-irc


          ekr, mt, +1.403.244.aaaa, [Microsoft], fluffy, stefanh,
          Jim_Barnett, gmandyam, +aacc, +, hta,
          Milan_Patel, dom, Dan_Druta, +,
          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


          stefanh, hta



     * [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:


   <scribe> ScribeNick: dom

   <scribe> scribe: dom


   <stefanh> Minutes:


   StefanH: approving minutes from our scoping meeting discussions
   on Dec 19?

   RESOLUTION: Dec 19 minutes approved

   Stefanh: [reviewing proposed agenda]

May F2F agenda



   tt-0045/DC_f2f_planning_WebRTC.pdf Proposed agenda for May F2F


   stefanh: slide 2 describes the overall schedule of the 3 days
   ... 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
   ... it would be good to come out of the meeting with a complete

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

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

   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

   tt-0048/ConstraintsPC-mt.pdf Martin's slides


   <stefanh> Martin: motivated by Suhas sending a proposal on

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

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

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

   <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
   ... I agree we don't want a more complicated mechanism that we
   ... 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
   ... 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
   ... 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"

   <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

   <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

   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

Privacy & Security

   <stefanh> I've had a look

   hta: I sent a proposal for a privacy & security section in
   ... 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



   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

   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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:17:55 UTC