- From: Dominique Hazael-Massieux <dom@w3.org>
- Date: Wed, 14 Mar 2012 09:19:09 +0100
- To: public-webrtc@w3.org
Hi,
The minutes of our call yesterday are available at:
http://www.w3.org/2012/03/13-webrtc-minutes.html
and copied as text below.
Dom
Web Real-Time Communications Working Group Teleconference
13 Mar 2012
[2]Agenda
[2]
http://lists.w3.org/Archives/Public/public-webrtc/2012Mar/0044.html
See also: [3]IRC log
[3] http://www.w3.org/2012/03/13-webrtc-irc
Attendees
Present
Christophe_Eyrignoux, Cullen_Jennings, Dan_Burnett,
Dan_Druta, Dom, Harald_Alvestrand, Randell_Jesup,
Rich_Tibbett, TimPanton, [Mozilla], adambe, ceyrigno,
juberti, li, nstratford, richt, stefanh
Regrets
Chair
Stefan_Hakansson, Harald_Alvestrand
Scribe
adambe, juberti, fluffy
Contents
* [4]Topics
1. [5]Action Items review
2. [6]Data API
3. [7]JSEP support
4. [8]Constraints and hints
* [9]Summary of Action Items
__________________________________________________________
<stefanh> agenda proposal:
[10]http://lists.w3.org/Archives/Public/public-webrtc/2012Mar/0
044.html
[10]
http://lists.w3.org/Archives/Public/public-webrtc/2012Mar/0044.html
<dom> ScribeNick: adambe
hta: there's one more agenda item
... we should officially aprove the minutes from the last
meeting
... no objections
Action Items review
<stefanh>
[11]http://www.w3.org/2011/04/webrtc/track/actions/open
[11] http://www.w3.org/2011/04/webrtc/track/actions/open
stefanh: first three open ones 11, 12 and 13
<dom> ACTION-11?
<trackbot> ACTION-11 -- Daniel Burnett to add Hints API to API
spec -- due 2012-01-12 -- OPEN
<trackbot>
[12]http://www.w3.org/2011/04/webrtc/track/actions/11
[12] http://www.w3.org/2011/04/webrtc/track/actions/11
<dom> ACTION-12?
<trackbot> ACTION-12 -- Daniel Burnett to add Stats API to API
spec -- due 2012-01-20 -- OPEN
<trackbot>
[13]http://www.w3.org/2011/04/webrtc/track/actions/12
[13] http://www.w3.org/2011/04/webrtc/track/actions/12
<dom> ACTION-13?
<trackbot> ACTION-13 -- Daniel Burnett to add Capabilities API
to API spec -- due 2011-12-12 -- OPEN
<trackbot>
[14]http://www.w3.org/2011/04/webrtc/track/actions/13
[14] http://www.w3.org/2011/04/webrtc/track/actions/13
stefanh: the three APs are on Dan
... We have discussed the capabilities/contraints proposal in
the media capture TF
... next task is on Dan Druta
<dom> close ACTION-15
<trackbot> ACTION-15 Look into mechanisms to handle incoming
notifications, and report to WG closed
DanD: stefanh initiated a mail thread on webapps saying that
the webrtc group is interested in push notifications and the
work shold be done in webapps
<dom> [15]Regarding app notification and wake up thread on
public-webapps
[15]
http://lists.w3.org/Archives/Public/public-webapps/2012JanMar/1077.html
<dom> ACTION-15: see public-webapps thread
[16]http://lists.w3.org/Archives/Public/public-webapps/2012JanM
ar/1077.html
[16]
http://lists.w3.org/Archives/Public/public-webapps/2012JanMar/1077.html
<trackbot> ACTION-15 Look into mechanisms to handle incoming
notifications, and report to WG notes added
stefanh: next item is on ekr
... it has been discussed in the IETF group
<hta> Rescorla's draft:
[17]draft-rescorla-rtcweb-generic-idp-01
[17]
http://www.ietf.org/mail-archive/web/i-d-announce/current/msg43401.html
hta: ekr's draft just came out in a new version
stefanh: I think we sholud close this action
<fluffy> just got discconned - will dial back in
stefanh: and open a new one if we need to do further work
hta: yes, close it
stefanh: next action 18, is on me
<hta> Randell, you're already identified.
stefanh: It's about contacting the Web & TV interest group
... It's not done yet
... next one is on me (21)
<dom> ACTION-21?
<trackbot> ACTION-21 -- Stefan Håkansson to ensure that Randell
get the echo cancellation into the spec -- due 2011-12-22 --
OPEN
<trackbot>
[18]http://www.w3.org/2011/04/webrtc/track/actions/21
[18] http://www.w3.org/2011/04/webrtc/track/actions/21
stefanh: ensure that Randall gets echo cancellation into the
spec
<jesup> me
<dom> [19]Echo cancellation API bug in Bugzilla
[19] https://www.w3.org/Bugs/Public/show_bug.cgi?id=15747
jesup: I've created an issue in the bug tracker
stefanh: should we give fluffy the responsibility for the task
previously assigned to jesup
... next task is on hta
<dom> ACTION: fluffy to incorporate echo cancellation API based
on [20]https://www.w3.org/Bugs/Public/show_bug.cgi?id=15747
[recorded in
[21]http://www.w3.org/2012/03/13-webrtc-minutes.html#action01]
[20] https://www.w3.org/Bugs/Public/show_bug.cgi?id=15747
<trackbot> Sorry, couldn't find user - fluffy
<dom> ACTION: cullen to incorporate echo cancellation API based
on [22]https://www.w3.org/Bugs/Public/show_bug.cgi?id=15747
[recorded in
[23]http://www.w3.org/2012/03/13-webrtc-minutes.html#action02]
[22] https://www.w3.org/Bugs/Public/show_bug.cgi?id=15747
<trackbot> Created ACTION-34 - Incorporate echo cancellation
API based on
[24]https://www.w3.org/Bugs/Public/show_bug.cgi?id=15747 on
Cullen Jennings - due 2012-03-20].
[24] https://www.w3.org/Bugs/Public/show_bug.cgi?id=15747
<dom> close ACTION-21
<trackbot> ACTION-21 Ensure that Randell get the echo
cancellation into the spec closed
stefanh: Task to change numeric constants to strings is on burn
<dom> ACTION-21: see follow-up in ACTION-34
<trackbot> ACTION-21 Ensure that Randell get the echo
cancellation into the spec notes added
stefanh: we skip actions 30 and 31 (jsep and Data API)
... action 32 is a followup on DanD's task
<dom> close ACTION-32
<trackbot> ACTION-32 Contact webapps regarding push and
notifications, saying it is important for webrtc and ask for
webapps' plans closed
stefanh: it was on me and it's done, I propose we close it
<dom> ACTION-32: see
[25]http://lists.w3.org/Archives/Public/public-webapps/2012JanM
ar/1077.html
[25]
http://lists.w3.org/Archives/Public/public-webapps/2012JanMar/1077.html
<trackbot> ACTION-32 Contact webapps regarding push and
notifications, saying it is important for webrtc and ask for
webapps' plans notes added
stefanh: ok, I guess we're done with the action
actions
fluffy: can we talk about the echo cancelation
... this is being incoperated in burn's contraints work
<jesup> Ok, good, thanks
stefanh: I'll add a note about it into the bug
fluffy: ok
... I'll help dan with it
burn: I will discuss it with fluffy
stefanh: next item is the API document
... I'll leave the floor to the editors
... we need a new scribe
(silence)
<hta> harald offers to scribe.
Data API
<dom> scribenick: juberti
<jesup> Thanks
he is
cullen: New changes to spec - Data API and JSEP
... data API is the main set of changes, going public this week
... JSEP changes not going into main document, going into
separate document
someone: Data API, is it what was discussed on list, i.e.
alignment with WebSockets?
adambe: Does it work exactly as WebSockets, with bufferedAmount
<hta> draft-jesup-rtcweb-data-protocol-00.txt
randell: New channels don't need to be negotiated in SDP
<dom> [26]WebRTC Data Channel Protocol
[26] http://tools.ietf.org/html/draft-jesup-rtcweb-data-protocol-00
thanks stefan
randell: no signaling is needed for data channel opens, but
signaling needed to indicate the existence of the overall data
channel
hta: Michael Tuexen has a draft for SDP desriptions of data
channels
randell: Salvatore Loreto has a draft for SCTP over DTLS
<dom> so the data channel API will be incorporated in the main
spec? or as a separate one?
hta: there are enough drafts for the data part of the channel,
and Adam has proposed a viable API for the data channel
... is that a proper summary?
group: yes
<stefanh> in the main draft Dom
adambe: once we get data channel to certain level of maturity,
can we use the bug tracker to advance the work?
<jesup>
[27]http://www.ietf.org/internet-drafts/draft-ietf-rtcweb-data-
channel-00.txt
[27]
http://www.ietf.org/internet-drafts/draft-ietf-rtcweb-data-channel-00.txt
cullen: can't log into bug tracker, we need to fix that first
<jesup> cullen++
cullen: we need to have a discussion about what tools we are
going to use and discuss on the list, pick one way of how we
are going to do things
dom: How will the data channel API be integrated into the
WebRTC spec?
... planning to go to last call by end of 2Q 2012
... what is timeline for moving forward with all of these
documents?
... Is the data API part of the main spec, or a separate doc?
someone: part of main spec
dom: will this inhibit our ability to move forward with the
main spec?
hta: It's part of our regular work.
... Whether we're ready for last call, is another topic.
dom: If we can do modular specs, we can have less dependencies
cullen: There's not even an IETF WG document for how the
signaling for data works
... It's a long way from done.
randell: We have reasonable consensus on what should be done,
but there's still a bunch of work to do.
hta: Next topic
adambe: We mentioned JSEP briefly (JSEP was 3.2, data was 3.3)
... We're not going on to 4 yet.
hta: Dan Burnett isn't here
dan: I am here.
JSEP support
dan: I'm about to send a draft to the list for caps/hints
cullen: Taking current IETF JSEP draft and mapping it as
closely as possible into a new WebRTC API document
... I've branched the existing doc for the spec
... Haven't gotten it done yet, but will be out by the end of
the weekend
... This will be a proposal that we can compare against the
current draft and we can see if we think this is acceptable
... if so, we can move it into the main doc, which should be
simple since it's a standard branch
... nothing surprising in this doc, since it's mainly the same
thing as the IETF doc
... there is a second branch that adam has created; adam,
please describe
<dom> [28]jspep_easy1 (adambe's) branch on webrtc editors draft
[28] https://github.com/fluffy/webrtc-w3c/tree/jsep_easy1
adambe: I thought that the new API (JSEP) made things harder.
So I took some of the things from the old API, and tried to use
JSEP from this API
... It hasn't been communicated that we are working on 2
different branches
... I think this is a problem, at some point we need to figure
this out
... There are specific operations you need to do in a specific
order, and we could combine those into building blocks
cullen: We need to get these drafts done and out to the lists
... Then we can compare and figure out what we want the editor
draft to look like
... That's the next major set of work that we need to get done
adambe: We should have entier API IDLs and have examples in
place
cullen: We need the baselines so that we can compare and the WG
can provide feedback
hta: that was a long 2 minutes
... Does anyone else have comments on what was discussed?
stefanh: I would like a time estimate
cullen: by end of weekend
... by Sunday
adambe: I can publish something tomorrow (Wednesday)
... Fewer changes than Cullen's
... Do you see a problem if I present that one first?
... We can't compare until Cullen's work is done
cullen: THe sooner the better
hta: Send it out
... There is some skepticism, so let's see it as soon as
possible
[silence]
hta: any more comments on JSEP?
... hearing done, Dan, are you ready?
<scribe> done=none
Constraints and hints
<dom> [29]Constraints and Capabilities API for getUserMedia:
more detailed proposal
[29]
http://lists.w3.org/Archives/Public/public-media-capture/2012Mar/0033.html
<dom>
<dom> [30]New draft-burnett-rtcweb-constraints-registry-00
[30]
http://lists.w3.org/Archives/Public/public-media-capture/2012Mar/0000.html
<dom> [31]IANA Registry for RTCWeb Media Constraints
[31]
https://datatracker.ietf.org/doc/draft-burnett-rtcweb-constraints-registry/
dan: Registry is a very basic drat
... used by GetUserMedia and WebRTC
... constraints are for audio and video
... page 4, media types are audio and video
<dom> [32]RTCWeb Media Constraints
[32]
http://tools.ietf.org/html/draft-burnett-rtcweb-constraints-registry-00#section-3
dan: currently the only constraint types are min, max, and enum
... contraints need to begin with an alpha character
... the only requirements that IANA needs to follow is a name
and a reference or lst of refs
... Need for expert review, instructions for designated expert
... Names must be < 80 chars long
... Names should be human readable
... requirement that if you have a tpe of audio, must be
relevant for audio streams, same for video
... 2 pieces for constraints - how they can be used when
requesting a stream, and how they can be used as capabilites
informations
[dan] min constraint type indicates the min value an author is
willing to accept
dan: could be width, height, bandwidth
... just because you have a minwidth and a minheight, doesn't
mean you can get both of those together
... max is similar to min
... enum example - audio is either 'voice' or 'generic'
... not defining this now, but this is an example
... some other words in here - that the constraint is
understandable
... everything we've come up with so far has fallen into the 3
categories (min/max/enum)
cullen: Combining height/width and aspect ratio allowed us to
solve all the use cases that have been brought up
dan: are there any questions about the registry?
dom: will we seed the registry with pre-existing constraints?
dan: these documents will register constraints
dom: aspect ratio is a constraint - is that an enum?
dan: I sent a link with an example to the list
<fluffy> example at
[33]http://lists.w3.org/Archives/Public/public-media-capture/20
12Mar/0033.html
[33]
http://lists.w3.org/Archives/Public/public-media-capture/2012Mar/0033.html
dan: we can look at that example now
... aspect is a flaoting-point min/max
... 4:3 can be represented (imperfectly) as floating point
... any other questions?
... dom, did that answer your question?
dom: will using an approximation cause problems down the line?
dan: I don't think it will be a problem for most apps
... The approximation is close enough
cullen: You need to specify enough digits so that multiplying
aspect times height gives you the right width.
dan: work will be in precisely definining this
juberti: need to find a new room
<dom> scribenick: fluffy
<dom> [34]Constraints and Capabilities API for getUserMedia:
more detailed proposal
[34]
http://lists.w3.org/Archives/Public/public-media-capture/2012Mar/0033.html
dan: Moving off the registry topic and on to the topic of email
at
[35]http://lists.w3.org/Archives/Public/public-media-capture/20
12Mar/0033.html
[35]
http://lists.w3.org/Archives/Public/public-media-capture/2012Mar/0033.html
richt: Looking at proposal and use cases. Would be nice to have
use cases for local capture and local media.
<juberti> back
hta: There are some uses cases. HTA will try and post link.
<hta>
[36]https://dvcs.w3.org/hg/dap/raw-file/tip/media-stream-captur
e/scenarios.html#find-the-ball-assignment--video-effects-and-up
load-requirements
[36]
https://dvcs.w3.org/hg/dap/raw-file/tip/media-stream-capture/scenarios.html#find-the-ball-assignment--video-effects-and-upload-requirements
<hta> the specific requirement is "Set the webcam into a
low-resolution (320x200 or as supported by the hardware)
capture mode"
<dom> ACTION-25?
<trackbot> ACTION-25 -- Harald Alvestrand to action Travis to
Draft a setup of initial requirements based on the WebRTC and
the Scenarios document -- due 2012-03-06 -- OPEN
<trackbot>
[37]http://www.w3.org/2011/04/webrtc/track/actions/25
[37] http://www.w3.org/2011/04/webrtc/track/actions/25
stefanh: Requirements are not spelled out in use case document
- Travis is going to start requirements document that derives
the requirements from the scenario documents.
richt: Was looking at IETF requirements document but want to
see how it maps to the local use cases.
dan: will look at requirements document and make sure it aligns
with this proposal
... not sure of status of current link or connection but will
investigate
... Constraint replaces old hint
... Constraint has an mandatory list and an optional list
... Constraint is a key value pair
<dom> Example from Dan's message:
<dom> Example:
<dom> navigator.getUserMedia(
<dom> {mandatory:[video-min-height:600,
video-max-bandwidth:500],
<dom> optional:[
<dom> video-max-aspectratio:1.333333333333,
dan: May want to come up with more restrictions on things like
lengths of values
<dom> video-min-timebetweenrefframes:20,
<dom> video-min-framerate:30,
<dom> video-autowhitebalance:on]},
<dom> gotStream, didntGetStream);
dan: There was a questions for algorithm to process these
constraints. This time there is a write up of the algorithm.
... look at the example, after the algorithm, this shows what
it might look like
<dom> how would you specify whether you want audio (or not) at
all? is "audio" a constraint itself?
dan: two lists, and the lists are ordered
<dom> (I'm not sure I understand how I would do echo
cancellation with that approach)
dan: In this case, the intent is they get a video stream with a
min hight of 600 pixels, and max bandwidth of 500 (whatever the
units are) . These are absolute and if they don't get this they
want an error if both of these are not satisfied. Additional,
they have some optional things they hope can satisfied in
priority order. They would like aspect ration of 4/3.
... video-autowhitebalance:on should be
video-enum-autowhitebalance:on
... If browser can do video-min-timebetweenrefframes:20, and
als could do video-min-framerate:30, but not both, then the
browser should do the video-min-timebetweenrefframes:20,
... When talking about mandatory constraints, order does not
matter. For optional, needed to sperate audio and video
... Basis is a set and algorithm is removing some streams from
it
... want to make sure never remove all audio or all video
stream
... could end up with all stream remvoed
<juberti> Dropping off
dan: In the cases of optional for two different type of media
constraint, does optional mean eliminate all of one type, is
that OK, or is there implicit assumption they want at lease one
video and one audio. As an app developer, I would want one of
both
... Moving to Capabilities
... having challenges with webild
... In the trusted cases, for each device, we get the
constraints with values.
<dom> I think that rather than {camera001:...,camera002:...} it
would be more logical to have {cameras:[{...}, {...}]}
dan: So when we get video-max-width: 1024, this means there is
no video stream this camera can provide with a width greater
than 1023
... did not deal with ENUM values yet - not sure that this is
information we need. Will add if this is needed
<dom> I think enums would be logically mapped to array of
values?
hta: Can imagine a case where one is using values and would
want to know all values. For example camera supports b/w ,
color, and infrared
dan: LIke some uses cases where need to return more than one
value. In this case will need to discuss the syntax
... Most of work is in defining the constraints
hta: Should make sure the first constraints we do are mapped
back to requirements and use cases
stefanh: this is what was proposed in TF and got a lot of
support
hta: Thank you very much, continue discussion on list
stefanh: Most important action are for Cullen and Adam to get
the JSEP like API proposal out
<Tim> Is there likely to be JSEP supporting implemenation in
the near future ?
dan: Plan for next Telco ?
hta: Some time after IETF
<hta> action stefanh create doodle for next meeting
<trackbot> Sorry, couldn't find user - stefanh
stefanh: Stephan has action to set up next telco
<jesup> ta!
hta: End of meeting - Bye
<dom> ACTION: stefan create doodle for next meeting [recorded
in
[38]http://www.w3.org/2012/03/13-webrtc-minutes.html#action03]
<trackbot> Created ACTION-35 - Create doodle for next meeting
[on Stefan Håkansson - due 2012-03-20].
<Josh_Soref> trackbot, end meeting
Summary of Action Items
[NEW] ACTION: cullen to incorporate echo cancellation API based
on https://www.w3.org/Bugs/Public/show_bug.cgi?id=15747
[recorded in
[39]http://www.w3.org/2012/03/13-webrtc-minutes.html#action02]
[NEW] ACTION: fluffy to incorporate echo cancellation API based
on https://www.w3.org/Bugs/Public/show_bug.cgi?id=15747
[recorded in
[40]http://www.w3.org/2012/03/13-webrtc-minutes.html#action01]
[NEW] ACTION: stefan create doodle for next meeting [recorded
in
[41]http://www.w3.org/2012/03/13-webrtc-minutes.html#action03]
[End of minutes]
Received on Wednesday, 14 March 2012 08:19:36 UTC