[minutes] April 10 teleconf


The minutes of our teleconf yesterday are available at:
linked from http://www.w3.org/2011/04/webrtc/#meeting

There are a couple of points that I missed when I scribed noted as
"@@@", from Adam and Justin; let me know if you remember what was said

Text version of the minutes below.


       Web Real-Time Communications Working Group Teleconference

10 Apr 2012



   See also: [3]IRC log

      [3] http://www.w3.org/2012/04/10-webrtc-irc


          +1.403.244.aaaa, Dan_Burnett, Cullen_Jennings,
          Jim_Barnett, +1.415.800.aabb, dom, +,
          stefanh, +, adambe, +1.908.541.aaee,
          +1.650.961.aaff, +1.415.800.aagg, anant, derf,
          Dan_Druta, +1.610.889.aahh, +, jesup,
          +47.41.44.aajj, hta, nstratford, +1.617.575.aakk,
          juberti, +1.408.902.aall, +1.650.678.aamm, Narm_Gadiraju

          Stefan_Hakansson, Harald_Alvestrand

          juberti, dom


     * [4]Topics
         1. [5]Minutes approval
         2. [6]Action items
         3. [7]F2F meetings
         4. [8]Media Capture
         5. [9]Audio WG feedback request
         6. [10]Spec status
         7. [11]JSEP API
     * [12]Summary of Action Items

   <fluffy> I joined the call but unfortunately I am in another
   meeting for the first part of this.

   <anant> I will have to take my leave at 9am, unfortunately

   <dom> scribenick: juberti

   stefan: agenda review
   ... audio WG request for review
   ... status of the spec
   ... any other business

   <jesup> Does someone have a URL for the audio WG request for

Minutes approval

   <dom> [13]March 13 minutes

     [13] http://www.w3.org/2012/03/13-webrtc-minutes.html

   stefan: first action - approve minutes from last meeting

   hta: if no objections, they are approved

   <dom> jesup,


   <dom> [15]Open Action items

     [15] http://www.w3.org/2011/04/webrtc/track/actions/open

Action items

   stefan: review open actions

   <dom> ACTION-11?

   <trackbot> ACTION-11 -- Daniel Burnett to add Hints API to API
   spec -- due 2012-01-12 -- OPEN


     [16] http://www.w3.org/2011/04/webrtc/track/actions/11

   hta: Constraints API status

   dan: proposal, hasn't been added to spec, not sure if we have

   hta: want to send note to Media Capture task force saying we
   have sufficient consensus

   <dom> ACTION-11:
   12Mar/0033.html Constraints and Capabilities API for


   <trackbot> ACTION-11 Add Constraints API to API spec notes

   <dom> ACTION-13:
   12Mar/0033.html Constraints and Capabilities API for


   <trackbot> ACTION-13 Add Capabilities API to API spec notes

   <dom> ACTION-12?

   <trackbot> ACTION-12 -- Daniel Burnett to add Stats API to API
   spec -- due 2012-01-20 -- OPEN


     [19] http://www.w3.org/2011/04/webrtc/track/actions/12

   dan: no progress on stats API

   <dom> ACTION-18?

   <trackbot> ACTION-18 -- Stefan Håkansson to contact Web and
   TV/Media TF to understand if their reqs and views of
   MediaStreams and Tracks is similar -- due 2011-11-16 -- OPEN


     [20] http://www.w3.org/2011/04/webrtc/track/actions/18

   <dom> [21]Any overlap with webrtc WG?, Stefan Hakansson LK on
   March 20


   stefan: don't think there are they many similarities, Stefan
   will follow up and see if there is any overlap

   <dom> ACTION-18: see


   <trackbot> ACTION-18 Contact Web and TV/Media TF to understand
   if their reqs and views of MediaStreams and Tracks is similar
   notes added

   hta: changing numeric constants to be strings

   dan: remind me what this is?

   <dom> ACTION-29?

   <trackbot> ACTION-29 -- Daniel Burnett to change all numeric
   constants to be enumerated strings -- due 2012-04-01 -- OPEN


     [23] http://www.w3.org/2011/04/webrtc/track/actions/29

   hta: stop using numeric enums, switch to using strings

   dan: don't remember the specifics of this

   hta: cullen did this in his draft JSEP proposal
   ... dan, will follow up with you on this one
   ... echo cancellation API - is cullen here?
   ... proposed moving mediastream API from PeerConnection to
   ... recent discussion on getting adam/cullen/justin together to
   discuss JSEP API
   ... end of action list

F2F meetings

   stefan: next task is to discuss upcoming f2f meetings
   ... proposal is to do back-to-back with upcoming IETF interim

   adambe: where will this meeting be located?

   <jesup> SFO, NYC, BOS, London, STockholm

   <anant> burn, just for reference, ACTION-29 refers to changing
   all the 'const' as listed in
   tion to strings


   <dom> [25]Doodle for picking dates for next RTCWeb meeting

     [25] http://doodle.com/nm3pp69znr3286cy

   hta: not sure yet - SFO, NYC, BOS, STO

   anant: how will the venue be chosen?

   hta: no specific procedure

   anant: can't really fill out the doodle poll until we know what
   venue will be chosen

   hta: doodle poll closes this friday

   stefan: next f2f is TPAC in October

   hta: interacting with DAP WG and Media Task Force

   <dom> (for the May/June F2F, have we decided for how long? how
   it would relate to the IETF meeting?)

   stefan: so we should aim to have our meetings on the same days

   dom: would we have 1 day for the W3C f2f?

   stefan: I think the IETF f2f would be 2 days, so the W3C would
   be just before or after

   hta: I think 0.5 days was too short the last time, this time
   we'll do a whole day
   ... any comments?

   stefan: next thing on the agenda

Media Capture

   stefan: chairs to report on Media Capture Task Force
   ... anant has made many proposals for changes and updates
   ... not much feedback to date. Would like to see more feedback
   from this community.
   ... hta, anything from your side?

   anant: proposed changes to getUserMedia spec, but only 2-3
   people responding

   stefan: should we move the definition of MediaStream into the
   getUserMedia specification?

   anant: you could still have a MediaStream even outside of
   ... OTOH, PeerConnections have specific mappings to RTP streams

   <dom> +1 on moving MediaStream to getUserMedia

   anant: so need to figure out where this should go
   ... I lean towards putting it in getUserMedia
   ... define the base MediaStream stuff in getUserMedia doc,
   extensions for realtime usage can go into PeerConnection doc

   dom: I think we'll see getUserMedia show up in browsers sooner
   than PeerConnection, so I think MediaStream should go in that

   juberti: How would we do this split?

   anant: An example could be attributes on the MediaStream for
   packet loss
   ... which is only relevant to PeerConnection

   <jesup> Seems reasonable to move it to me.

   suhas: Can we make a standalone for for MediaStream?

   anant: we could, but there is overhead - I don't see a case
   where getUserMedia has stuff that isn't needed in the general

   hta: no real dissent voiced

   <jesup> Robert O'Callahan's MediaStream Processing spec also
   extends MediaStreams slightly - adds currentTime,
   createProcessor(), createWorkerProcessor()

   juberti: I agree that getUserMedia will ship sooner and also be
   unlikely to have things that aren't generally useful

   stefan: I agree with this direction

   someone: could we get dropped frames info from the MediaStream?

   jesup: what about stats tied to data in the stream

   hta: decision to move the spec as described

   <hta> ACTION: anant to move MediaStream spec to getUserMedia
   [recorded in

   <trackbot> Created ACTION-38 - Move MediaStream spec to
   getUserMedia [on Anant Narayanan - due 2012-04-17].

   <jesup> We can extend MediaStream in WebRTC (as we already do
   for localMediaStreams)

Audio WG feedback request

   stefan: audio WG sent request for review of their spec to the
   WebRTC list

   <dom> [27]Audio WG request for feedback


   stefan: not sure if we should accumulate group feedback versus
   individual feedback. what do people think?

   jesup: there are some competing proposals
   ... proposal from Mozilla ties audio processing/video
   processing more closely with MediaStreams

   hta: one piece of feedback is that we would like to only have
   to evaluate one proposal

   derf: haven't seen satisfactory answers to the concerns that
   have been raised for real-time usage

   jesup: would be nice to process audio streams and video streams
   in the same framework
   ... but it doesn't do this right now

   derf: proposal doesn't handle synchronization

   stefan: suggestion is to do individual feedback

   <jesup> Synchronization is critical to WebRTC

   <dom> scribenick: dom

Spec status

   hta: JSEP aligned API - status?

   stefanh: should we wait for cullen to join the call?
   ... he said he would be late

   hta: let's wait and see
   ... let's move to Data API

   dom: regarding constraints, I was suggesting this should be
   done separately from getUserMedia
   ... due again to the difference in release schedule for that
   ... getUserMedia will be shipped without constraints at first
   ... so contraints should be spec-d separately
   ... with the proper hook

   Dan: I definitely see the need to be able to say "I want a
   video stream" independently of constraint
   ... but I'm a bit nervous about saying we'll deal with
   constraints later
   ... constraints are also useful for local user media
   ... e.g. screen resolutions
   ... there may be a need to actually specific some constraints
   that are camera-related

   <jesup> Agreed on screen resolutions, frame rate, etc

   Dan: some people have a notion of a logical media stream
   ... the encoding e.g. depends on the resolution
   ... so that dependency makes me nervous

   hta: a logical way forward is to have a place where to list
   constraints, without specifying constraints

   dan: I would prefer that
   ... as a group, we'll need to define what set of constraints we
   want to proceed with
   ... this may be an empty set
   ... e.g. no constraints may be necessary for the local case

   Randell: this seems reasonable to me
   ... this also exposes the fact that we haven't talked about how
   to modify the parameters of a source after having obtained it
   from getUserMEdia
   ... e.G. changing resolution of framerate from an existing
   ... at this time, the only way to do that is to get a different
   getUserMedia stream
   ... I would think you would want to be able to modify the
   stream you're getting

   dan: so you're thinking we could still use constraints but it
   would be a new set of constraints that would replace the
   existing ones on an existing stream
   ... I don't know if that cover all cases, but it covers some of
   them for sure
   ... that means you don't have to drop your stream to get a new
   ... you want to make sure you don't tear down a number of
   states that would have to be rebuilt
   ... some constraints would not require a new permission check;
   some might
   ... but that doesn't mean we wouldn't want to make that kind of

   dom: no question about the need for constraints, but clearly
   this adds complexity, possible another API for modifying
   ... all of which is unlikely to be shipped as early as
   ... so we should focus on getUserMedia first, constraints later

   dan: Adam's proposal might be acceptable with me; but if we do
   start adding hints as others have suggested, then I want to
   have constraints added in the first phase
   ... since hints are exactly what constraints are supposed to
   ... rich has been suggesting having hints

   randell: e.g. a way to express preference of resolution vs

   justin: we have specific use cases of what we want to do
   ... if we don't think that hints solve our use cases, then that
   doesn't seem like a worthy proposal

   stefanh: hints seems to be equivalent to optional constraints

   randell: I haven't thought enough about this; I don't have an
   opinion on the matter at this point

   hta: I haven't see any evidence that hints would differ from
   optional constraints

   dan: so it sounds like there is agreement for the people on
   this call that any request for hints can most likely be
   satisfied with a constraints structure
   ... not working on constraints might work if we don't get hints
   back in
   ... how would this work in practice?
   ... Adam's proposal wasn't to do away with constraints

   Adam: my proposal was to add the constraints object as a third
   property of the first param in getUserMedia
   ... to break the dependency between getUserMedia and
   constraints definitions

   <anant> I apologize, I have to leave for another meeting that
   starts in 5 minutes, I will review minutes later to see what I

   <fluffy> I have joined the call again

   dom: my idea was not to stop work on constraints, but move it
   to a parallel work item with less attention from the group
   ... we probably need to look a concrete integration proposals
   ... but the idea was that constraints would be a third property
   in the mediastreamoptions object
   ... that browsers should block on if they can't interpret it

   dan: that sounds like fine if we agree on the dictionary
   ... the "fail on unknown" constraint sounds like approach to

   cullen: given that audio and video are completely trivial to
   specify, shouldn't we just do that?

   dom: it's a bit hard to follow these suggestions without
   concrete proposals

   justin: shipping getUserMEdia with just VGA resolution would be
   very useful

   Adam: @@@

   Dan: I don't think the group will agree that VGA only is the
   right way to start

   Adam: if the options is getting VGA in two months or wait
   another year for other options, people will want VGA first

   Justin: I'm not sure that getting resolutions right is that
   trivial, so it would probably take a while

   Cullen: my only proposal that selecting audio and video streams
   would themselves be designed as constraints

   Randell: I'm concerned that we spend a lot of time about
   designing an API for setting static parameters
   ... sounds like we're missing a big aspect of this
   ... The solution might not be to design a overall constraints
   API right now
   ... but rather to define a way to have a way to change the
   parameters of an existing media stream
   ... then we don't have to solve the issue at the

   Dan: I see the two as the same problem
   ... the constraints approach has two usefulness: don't do
   anything if I don't get this; how strongly the dev cares about
   a particular setting

   Randell: yes, but it's not obvious that this needs to be hard
   set in the algorithm in the spec
   ... rather than by code in the Web app itself

   Cullen: this is not a constraint language by any definition

   <adambe> yes

   EKR: what are you allowed to say in this language? I've only
   skimmed it some time ago

   dan: it allows you to set min/max values for a number of
   properties (e.g. aspect ratio, framerate, ...)

   EKR: will this metastasized?
   ... how can someone express something that hasn't been defined?

   Randell: let's take a video source that has an embedded encoder
   in it
   ... that means you would have to specify constraint for that
   encoder as well

   dan: as an app dev, you only have to specify what you care
   ... The browser will have to work out how to satisfy your

   Randell: you're defining a constraints language for this, and
   say that the app developer only has to deal with this if he
   cares about it
   ... but what if he cares? how does he deal with that case?

   dan: I don't know that we can avoid the lower level code in
   that case
   ... constraints allow for a high level approach for most
   developers needs

   Randell: I don't have a problem with defining a constraint
   language if we want one
   ... if it convers everything we need
   ... but I don't want it to forbid getting access to important
   things that applications will want to access, e.g. setting
   ... we can get by without it, but the pressure to get it will
   be high

   justin: not sure why VGA won't be sufficient for v1?

   Cullen: mobile won't do it

   justin: this could be the highest thing to ask for

   hta: this is a more detailed discussion than we have had on the
   ... With 15 minutes left, we need to return to JSEP

   justin: it seems reasonable to have an initial constraint, plus
   an API to change constraints

   dan: the proposal was never to suggest we shouldn't let change
   ... the proposal only gives examples of constraints; we would
   need to define the first set of constraints
   ... All of these are great discussions points: what constraints
   in the first version? how can we change streams along the way?
   can it be done using the same API?
   ... i.e. using the same data structure

   dom: how do we move forward with this?

   hta: any action items?
   ... earlier in the call there was an action item about
   incorporating capabilities in the editors draft of getUserMedia

   dan: there are some modifications that I need to bring to my
   proposal based on what Adam proposed; or maybe based on
   Cullen's proposal
   ... I'm happy to do that and send an updated proposal
   ... please read it then :)

   hta: so Adam and Cullen, will you suggest modifications to
   Dan's proposal?

   dan: Adam already did
   ... although you referenced the registry rather than my

   <scribe> ACTION: Dan to send an updated Capabilities proposal
   to Media Capture Task Force [recorded in

   <trackbot> Sorry, amibiguous username (more than one match) -

   <trackbot> Try using a different identifier, such as family
   name or username (eg. ddruta, dburnett, dromasca)

   <scribe> ACTION: burnett to send an updated Capabilities
   proposal to Media Capture Task Force [recorded in

   <trackbot> Created ACTION-39 - Send an updated Capabilities
   proposal to Media Capture Task Force [on Daniel Burnett - due


   stefanh: we've only had limited feedback on which of the
   proposals for moving forward with JSEP

   cullen: current status is that we're trying to find a time with
   Justin, Adam and me to discuss our proposals in more details
   ... I've always characterized the two proposals by the number
   of function calls
   ... but this was a flawed understanding apparently
   ... we haven't looked at the different important
   ... nothing has moved during IETF
   ... but we're getting back on track now

   dom: getting this list of differences would also help the rest
   of us know which proposal we are likely to prefer :)
   ... unless it is sufficient to make you guys decide to merge
   into one proposal

   justin: @@@
   ... the other change relates to what happens when you call
   ... does the local description change right away? or do you
   have install it with setLocalDescription?
   ... implicit update seemed like an easy win
   ... but I need to look at what happens if the state machine is
   not in the right state when receiving an offer
   ... Once we resolve this, we could have a draft of a merged

   Cullen: my proposal lets you change the SDP when you add a
   ... e.G. to remove a codec
   ... this seems an important feature that people wants

   Justin: you could always replace the SDP and
   setLocalDescription with an updated SDP

   hta: there is also a difference in terms of initiative
   ... in Adam's proposal, the application just reacts to what the
   browser does
   ... in the other proposal, you're on your own to manage the
   whole ice state machine

   Adam: the browser doesn't really do anything if the developer
   doesn't do anything

   hta: in the JSEP API, if the application developer decides that
   he has created a PeerConnection and connected two media streams
   to it, and want to wait for a while until a specific event
   ... in the JSEP proposal, you can just not call createOffer()
   ... in the other proposal, there will be an onsignaling
   callback — what should you do about it?

   stefanh: the application could still wait to call the addStream

   adam: addStream is still in the control of the JavaScript

   hta: the difference in philosophy is that in one case you get
   callbacks and you respond to that, in the other you have to
   manage this on your own

   justin: there were comments that getting callbacks at random
   times create weird bugs

   stefanh: I want to ensure that cullen, adam and justin have
   this meeting next Monday
   ... that meeting should either produce a list of differences,
   or a merged proposal in a reasonable amount of time

   justin: I think we've enumarated the main differences of the
   two APIs

   adam: in the browser, everything is asynchronous

   cullen: so our meeting will help the discussions; but I suspect
   we'll still be back to multiple orthogonal decisions
   ... I wouldn't be surprised that we will need another phone
   call to go through this

   stefanh: yes; that would be a better informed phone call though

   adam: clearly the first step is for the 3 of us to better
   understand the two proposals

   Randell: I'll bring the Data API on the list

   stefanh: and implementation feedback would be very welcome as

Summary of Action Items

   [NEW] ACTION: anant to move MediaStream spec to getUserMedia
   [recorded in
   [NEW] ACTION: burnett to send an updated Capabilities proposal
   to Media Capture Task Force [recorded in
   [NEW] ACTION: Dan to send an updated Capabilities proposal to
   Media Capture Task Force [recorded in

   [End of minutes]

Received on Wednesday, 11 April 2012 07:01:45 UTC