See also: IRC log
<dom> ScribeNick: stefanh
Harald: checking who's on line
<tpanton> tpanton = tim panton @ voxeo
<CE> ce = christophe eyrignoux
<juberti> juberti = justin @ google
Markus Isomäki on call (not in IRC)
harald: agenda OK?
harald: agenda OK...
Next topic: API document status
adambe giving update on the API documet
adambe: what is new in the editor's draft of Dec 12
moved access to mic cam to separate document (but still in the webrtc document - will be removed)
scribe: a lot of editorial
... separating tracks into separate audio and video track lists
....motivation: align with media element (which now has separate track lists for audio and video)
... examples updated to be aligned with specificaion
... a lot of editorial: broken links, clean up, removing stuff that did not render.
hta: in next sections we will
talk about planned changes.
... planned changes:
remove getUserMedia, track list
adambe: move state handling from stream to track before adding "addTrack/removeTrack" funtions
will come in next version
hta: let's talk about
... make track lists of MediaStream's mutable (to allow add and remove of tracks) is coming
will be introduced very soon
scribe: what I have been working
on for some time is when "addstream" is fired. before this was
tied to data in
... at least one of the tracks,
... but now decided to fire when the signaling carried out
... tracks will then be in muted state, and become live as data starts arriving.
... the simple app will not have to be changes, but gives more control to the advanced app.
... Moving state handling to track level also makes things more consistent at "error" cases (like camer unplugged but mic still present)
... Quite a big change, but seems to make a lot of sense.
hta: not in the released spec
yet, but in the github version.
... more changes will be discussed when going through actions.
... do the editors have open items that they want feedback on from the group?
dom: couple of questions
... 1. Echo cancellation. How much control in the API? Needs to be watched.
... 2. Updating the WD according to W3C rules. A new dated WD needed every 3rd month.
... so we should plan for a release at least before the f2f
hta: EC (Echo Cancellation) need to know the relation of what streams out of the device and what is played
<jesup> Agree - see derf's comment tonight on the list
hta: not so simple as saying it's a PeerConnection detail. Need to wait for a proposal on the list.
justing: Randell has a proposal on the list.
Randell: yes, I proposed a simple
... a comment made to make a media options API to prepare for extensions
justing: that could be a starting point for a proposal.
hta: randell, could you take an action?
<hta> ACTION: randell to get the echo cancellation into the spec [recorded in http://www.w3.org/2011/12/15-webrtc-minutes.html#action01]
<trackbot> Sorry, couldn't find user - randell
<scribe> ACTION: propose EC API on jesup [recorded in http://www.w3.org/2011/12/15-webrtc-minutes.html#action02]
<trackbot> Sorry, couldn't find user - propose
adambe: should be simple to use
randell: yes of course
hta: next question: should we use bugzilla?
adambe: talked about that earlier, makes sense to introduce now,
justing: agree, to be used when wee start iterating on a solution.
burn: agrees to this. Use list to start discussions, but when getting into details bugzilla to be used
adambe: will be some more work (mark duplicates, policing,...), sometimes move stuff back to list
<dom> (we could also use W3C's tracker, in which case we can track issues by mentioning their nickname (e.g. ISSUE-2))
burn: yes, html wg has clear rules for when to move things back, closing items, ...
<dom> ("mentioning" in emails sent to the list)
justin: nice to have bugzilla to
discuss details of something agreed to do
... should adopt bugzilla.
hta: if we use bugzilla: should things proposed to bugzilla also go to the list
<soohyunc> justin seems to introduce a bit of.echo while talking to the zakim system
adambe: you can't just comment in a bug and expect that all have read it.
dom: one way to make bugzilla part of the discussion is to post bugzilla discussions on the mailing list
justin: makes sense to do that.
hta: we have support for using bugzilla, set up in a way that all changes are sent to the mail list. OK?
<dom> ACTION: Dom to configure bugzilla ofr Web RTC with activity sent to public mailing list [recorded in http://www.w3.org/2011/12/15-webrtc-minutes.html#action03]
<trackbot> Created ACTION-20 - Configure bugzilla ofr Web RTC with activity sent to public mailing list [on Dominique Hazaël-Massieux - due 2011-12-22].
hta: finished API document
... media capture TF
<dom> ACTION: Stefan to ensure that Randell get the echo cancellation into the spec [recorded in http://www.w3.org/2011/12/15-webrtc-minutes.html#action04]
<trackbot> Created ACTION-21 - Ensure that Randell get the echo cancellation into the spec [on Stefan Håkansson - due 2011-12-22].
hta: set up to take care of
things common between webrtc and DAP in terms of media
... having an active discussion
... much on the media stream track interface, some wanting stream and track to be defined by TF
... but chairs hesitant as there is a tight connection between streams, tracks and peerconnection
... but open for more input
dom: I tend to agree that part of
media stream api will have to be integrated in
... not clear how we can split things out cleanly
... not so simple, need a specific proposal at some stage.
hta: changes to mediastream can always be proposed to WebRTC
dom: not only about documents, but also about getting apis that can be implemented and tested as standalone components
hta: yes, and there is a strong
link between the things
... the TF is working on a req and scenarion document
... not yet finished.
hta: any other comments on the
media cap TF?
... move to report of status of actions
... first on richt to bring new use cases. overtaken by TF?
stefanh: I think the action was
to bring some AR use cases
... should be brought to the TF anyway
<dom> ACTION-9: needs to be sent to the Media Capture Task Force
<trackbot> ACTION-9 Send new use cases on getUserMedia to webRTC mailing-list notes added
hta: we leave it open as the TF doesn't have a tracker
<trackbot> ACTION-13 -- Daniel Burnett to add Capabilities API to ROAP and API spec -- due 2011-12-31 -- OPEN
hta: add hints and stats API. burn, any comment?
burn: not much to report, not much done yet
<trackbot> ACTION-14 -- Harald Alvestrand to revise Data API proposal and mail to list -- due 2011-11-16 -- OPEN
hta: revise data API
justing: published a new version
on the list, addresses some comments on the list
... looking into the Stream API proposal to see if that is applicable
... want's to see a unified way to handle media and data streams
... more discussion on the list.
hta: to be incorporated in spec
... appropriate time to put into draft
... would like to incorporate in spec by an editor.
burn: only two of the editors on call.
<hta> ACTION: hta to Incorporate data api into spec (find editor volunteer) [recorded in http://www.w3.org/2011/12/15-webrtc-minutes.html#action05]
<trackbot> Created ACTION-22 - Incorporate data api into spec (find editor volunteer) [on Harald Alvestrand - due 2011-12-22].
<dom> (I guess we can close ACTION-14 then?)
<dom> ACTION-22: follow up to ACTION-14
<trackbot> ACTION-22 Incorporate data api into spec (find editor volunteer) notes added
<dom> close ACTION-14
<trackbot> ACTION-14 Revise Data API proposal and mail to list closed
<dom> ACTION-14: follow up in ACTION-22
<trackbot> ACTION-14 Revise Data API proposal and mail to list notes added
hta: look into incoming
notification. Dan not on call, no update
... next one: identity framework connections proposal
... not ready yet
... no update
... next DTMF: done more or less
justing: trying to summrize the discussions into a single api
hta: how to know if a tracks supports dtmf or not?
<dom> can we add a pointer to the latest proposal for DMTF? I'm not sure which mail it is
adambe: a track can have support
for dtmf or not
... can it really change during run time?
... exceptions can be used
stefanh: really a property of the other end, can it receive dtmf or not
hta: stattus of discussion with web and tv on tracks?
stefanh: waiting for this webrtc wg to be be more ready with this part before approaching web and tv IG
hta: next one (add/remove tracks)
... next thing: next meeting. we have a f2f Feb 1st (from noon)
... do we need any meeting before then? I would say not.
dom: only reason to approve a new WD
burn: we can do that on mail
hta: AoB. What about JSEP?
justin: working on a draft, not
ready for this call though
... working with mathew kaufman
... moving control to JS
... ready by end of week
... in draft version.
adambe: has there any conclusions on the data api? a long time since we talked about it
hta: recently updated proposal
hta: to be discussed in bugzilla
<juberti> Please feel free to leave comments in the DTMF or DataStream docs.
hta: thanks all for coming and see you Feb 1st