[minutes] March 13 Teleconf


The minutes of our call yesterday are available at:

and copied as text below.


       Web Real-Time Communications Working Group Teleconference

13 Mar 2012



   See also: [3]IRC log

      [3] http://www.w3.org/2012/03/13-webrtc-irc


          Christophe_Eyrignoux, Cullen_Jennings, Dan_Burnett,
          Dan_Druta, Dom, Harald_Alvestrand, Randell_Jesup,
          Rich_Tibbett, TimPanton, [Mozilla], adambe, ceyrigno,
          juberti, li, nstratford, richt, stefanh

          Stefan_Hakansson, Harald_Alvestrand

          adambe, juberti, fluffy


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


   <dom> ScribeNick: adambe

   hta: there's one more agenda item
   ... we should officially aprove the minutes from the last
   ... no objections

Action Items review


     [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


     [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


     [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


     [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


   <dom> ACTION-15: see public-webapps thread


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


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


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

   stefanh: ensure that Randall gets echo cancellation into the

   <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

     [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

     [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


   <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


   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


   <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

   hta: Michael Tuexen has a draft for SDP desriptions of data

   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?



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

   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


   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



   <dom> [30]New draft-burnett-rtcweb-constraints-registry-00


   <dom> [31]IANA Registry for RTCWeb Media Constraints


   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


   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

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


   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


   dan: Moving off the registry topic and on to the topic of email


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


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

   <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
   ... 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
   ... want to make sure never remove all audio or all video
   ... 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
   ... 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

   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

   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

   <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
   [NEW] ACTION: fluffy to incorporate echo cancellation API based
   on https://www.w3.org/Bugs/Public/show_bug.cgi?id=15747
   [recorded in
   [NEW] ACTION: stefan create doodle for next meeting [recorded

   [End of minutes]

Received on Wednesday, 14 March 2012 08:19:36 UTC