W3C home > Mailing lists > Public > public-webrtc@w3.org > January 2013

[minutes] Jan 10 teleconf

From: Dominique Hazael-Massieux <dom@w3.org>
Date: Thu, 10 Jan 2013 18:35:01 +0100
Message-ID: <1357839301.1510.22.camel@cumulustier>
To: public-webrtc <public-webrtc@w3.org>

The minutes of our call today are available at:

and copied as text below.


       Web Real-Time Communications Working Group Teleconference

10 Jan 2013



   See also: [3]IRC log

      [3] http://www.w3.org/2013/01/10-webrtc-irc


          +1.908.578.aabb, Dan_Burnett, hta, stefanh,
          +972.9.957.aaee, Milan_Patel, dom, +,
          derf, Dan_Druta, +1.630.423.aajj, dan_romascanu?,
          adambe, jesup, fluffy, +, juberti,
          +1.831.440.aaoo, JeromeMarcon, nstratford,
          +, +44.190.881.aaqq, adam

          stefanh, hta

          adambe, fluffy


     * [4]Topics
         1. [5]Minutes approval
         2. [6]Statistics API
         3. [7]Error handling
         4. [8]Scribing procedures
         5. [9]schedule
         6. [10]face to face meeting
     * [11]Summary of Action Items

   <trackbot> Date: 10 January 2013

   <stefanh> Agenda, and some stuff:


   <dan_romascanu> aaff may be me

   <adambe> Zakim: aaii is me

   <fluffy> Zkaim, aaaa is fluffy

   <fluffy> thanks dom

   <dom> ScribeNick: adambe

   stefanh: let's get started



   stefanh: I've pasted the link to the agenda
   ... any comments/objections to the agenda

Minutes approval

   stefanh: we need to aprove the minutes
   ... any objections?

   <stefanh> minutes:


   stefanh: I consider the minutes approved
   ... we're ending the technical session at the hour

Statistics API

   stefanh: and discuss how we use the f2f time in February

   hta: I'm assuming that everyone has read the proposal

   <dom> [15]Stats API proposal


   hta: the most important part is that we've changed the returned
   ... away from the local - report format
   ... into a rtc stats object
   ... with operators
   ... the second part is documentation format
   ... we use WebIDL dictionaries to describe what the data
   objects are
   ... the third part is a few suggestions for stat objects
   ... that would be part of an actual implementation
   ... I hope for this meeting that we can get agreement that the
   approach is right enough
   ... and that we can get it into the spec

   <JeromeMarcon> + = Jerome Marcon

   hta: we can work out the the details as we move on
   ... that was the intro.. questions?

   jesup: in general I don't have a problem with the design
   ... how much data could be associated with these objects?
   ... there might be cases where you want hight detail.. it could
   be a lot of data
   ... we need to make sure people understand that stats could
   generate a lot of data

   hta: we will end up with quite a few objects
   ... defaul will be grab em all
   ... probably in the 10s of kb range

   jesup: we have the space issue.. may not be that big

   <adam> ?

   jesup: grabing a lot of data that you don't need can hurt you

   hta: yes
   ... I'm been thinking of this in 10s of seconds basis
   ... if ppl want to do this 100 times a second we're in trouble

   jesup: I'm worried about the size of deep copy operatios

   fluffy: I think this is an issue in selecting stats
   ... I have a nit with the timestamp
   ... otherwise, I like it

   juberti: I like this too

   <jesup> cullen++

   juberti: the question is how we select stats
   ... We could have an option to say "just give me ICE stats"
   ... transport info
   ... maybe we need a more general way to express what we want to
   collect stats about

   hta: the selector object started of as an any type
   ... to make it flexible

   juberti: I don't know how the syntax would look

   hta: I'd like to look at the use cases

   stefanh: any more comments questions?
   ... ppl seem to be pretty happy with this

   <dom> [the WebIDL has syntax errors, but I assume the editors
   will take care of it]

   stefanh: does anyone have anything against integrating the API
   into the spec

   fluffy: I can do that

   stefanh: I conclude that we should start integrating the new
   stats API into the spec

   <fluffy> I think the action is roughly me to move the API part
   of RTCWEBStatsv2.pdf proposal into spec

   stefanh: nex topic is error handling

Error handling

   burn: I sent some slides to the list



   <dom> [17]Error Handling slides


   burn: before december there hadn't been so much discussion
   about error handling
   ... the behaviour wasn't consistent between our documents

   <jesup> Agreed justin's suggestion is an option and solves the
   size issue. If you need links to other parts, you could tell it
   to include the other part. Downside is complexity. Perhaps use
   selection only for adding non-baseline items (packet-level
   stats, histogram data, etc)

   burn: I'll cover the main topics

   <jesup> that was on the stats issue

   burn: anant had proposed.. exceptions and callbacks
   ... detectable within < 50 ms should be an exception

   fluffy: we talked about that and discarded it

   burn: we throw an exception on a bad argument
   ... and at illegal state
   ... otherwise we use the error callback
   ... I want to make sure we agree on this

   hta: two comments

   <dom> [based on
   rror-names-0, the name should be INVALID_STATE_ERR rather than


   <dom> [TypeMismatch is enforced by WebIDL in any case]

   hta: there might be other cases than bad arguments and state

   burn: browsers could do better but our guidelines says don't do

   fluffy: last time we came to the conclusion time wasn't
   relevant here

   <jesup> cullen++

   fluffy: it's more about on which thread something is executed

   <dom> +1 to juberti

   juberti: I agree with fluffy that it shouldn't be based on a

   <jesup> juberti++

   juberti: exceptions are programming errors and exceptions are
   runtime errors

   second exceptions should be error callbacks

   burn: we should change the quidelines to say that exceptions
   are thrown on programming errors

   <dom> PROPOSED RESOLUTION: exceptions are thrown upon
   programming errors (for example invalid argument types or call
   in an invalid state); other errors are pushed as error

   fluffy: I find this very abstract

   burn: we need guidelines to avoid this discussion again

   dom: I don't think we're changing the guidelines.. perhaps
   reformulating them

   fluffy: I think we're missing too much people in this call
   ... to change what we decided in a meeting with a lot more

   <dom> " So decided that invalid_state will be a callback no

     [19] http://www.w3.org/2012/10/29-webrtc-minutes.html#item04

   stefanh: could someone propose a change based on what we've
   talked about in this meeting

   fluffy: I don't think we've agreed to anything here

   stefanh: I think we need specific text in the form of an email

   <hta> ACTION: justin to draft guideline text [recorded in

   <trackbot> Created ACTION-79 - Draft guideline text [on Justin
   Uberti - due 2013-01-17].

   burn: I went through the document that doesn't have callbacks
   ... the resulting list is on slide 7
   ... I've underlined 4 of them
   ... but I don't remember fully what that meant

   <dom> [updateIce makes reference to a "failure callback", but
   it's not clear which callback, since updateIce itself doesn't
   take a callback param
   aConstraints-constraints ]


   <juberti> +juberti

   burn: question: do updateIce and addIceCandidate need callbacks

   juberti: I don't think addIceCandidate needs callbacks

   fluffy: thread boundaries might need to be crossed to find out
   if a candidate have a bad line number

   <dom> (could also be an oniceerror event)

   juberti: an exception wouldn't be appropriate in that case

   dom: we colud have an ice error event

   <adam> juberti: +1

   juberti: we should report errors consistently between
   addIceCandidate() and, e.g., setLocalDesc

   burn: I agree with juberti

   juberti: events happen asyc that may not be a result of a
   function call

   fluffy: I think we're fairly consistent on this

   jesup: I think this sounds resonable

   <jesup> justin++

   <hta> justin said it

   <fluffy> +1

   juberti: we need the success callback to know when we can stop
   waiting for the error callback

   <jesup> one function call -> leads to one callback (either
   error or success)

   dom: the success callback might not give much.. we could go
   with one callback for both cases

   burn: we've talked about this before
   ... the first thing would always be to check for an error

   dom: I remember that conclusion
   ... but that might have been under other circumstanses
   ... in geolocation you get the position in the success callback

   <dom> [hixie recently highlighted the pain of having a useless
   parameter in pushState]

   <juberti> same for createOffer and createAnswer

   adambe: do we need to listen to the success cb and not continue
   before we get it or is it OK to ignore it

   dom: I'm not aware of any other web api that does this, but
   this may not be the best time to bring up this discussion again

   Zakim: ack me

   <dom> "getIdentityAssertion Initiates the process of obtaining
   an identity assertion."


   fluffy: ask ekr to clarify if getIdentityAssertion() need

   burn: that operation is optional

   <dom> [I think burn should send his analysis by email to
   kickstart the discussions :) ]

   burn: I would encourage other ppl to look at this as well
   ... anything that updates sdp needs to be queued
   ... if something needs to queue, it can't return right away

   juberti: anything that mutaates sdp would fall into that bucket

   stefanh: but not until createOffer is issued right?

   juberti: I agree that addIceCandidate might need a callback for

   <dom> [the constructor should also have a callback then,
   shouldn't it?]

   juberti: udateIce takes the same arguments as the
   PeerConnection constructor
   ... and it doesn't have a error callback
   ... we might want to change addIceCandidate

   <juberti> be right back

   <dom> re updateIce, the spec says "an RTCError object of type
   INCOMPATIBLE_CONSTRAINTS is provided to the failure callback if
   the constraints could not be successfully applied."

   fluffy: if you give a bad password to the turn server
   ... we need an error for that case

   <jesup> createDataChannel is supposed to be synchronous; it
   (for consistency with WebSockets) it fires an onopen when the
   channel opens and the object can't be used to transfer until

   burn: there are other proposals for error handling
   ... ppl should review them

   hta: juberti and I can look at it with our chrome eyes
   ... I wolud like to hear an opinion from Mozilla

   burn: anyone from Mozilla on the call?

   <dom> ACTION: juberti to review needs for callback and errors
   callbacks in webrtc (with hta) [recorded in

   <trackbot> Created ACTION-80 - Review needs for callback and
   errors callbacks in webrtc (with hta) [on Justin Uberti - due

   <dom> ACTION: jesup to review needs for callback and errors
   callbacks in webrtc (with hta) [recorded in

   <trackbot> Error finding 'jesup'. You can review and register
   nicknames at

     [25] http://www.w3.org/2011/04/webrtc/track/users%3E.

   jesup: we will look at it as a team (at Mozilla)

   <dom> ACTION: derf to review needs for callback and errors
   callbacks in webrtc (with hta) [recorded in

   <trackbot> Created ACTION-81 - Review needs for callback and
   errors callbacks in webrtc (with hta) [on Timothy Terriberry -
   due 2013-01-17].

   fluffy: we need to go through all calls and sort out what needs
   to produce errors

   burn: we want this to be consistent between the specs
   ... that's all about error handling for today

   <matthew> (was on call, but have conflict now)

   stefanh: we're moving on to the organizational section

   <dom> ScribeNick: fluffy

Scribing procedures

   Discussion around scribing procedures

   <dom> [27]A proposal on minute-takers for the WEBRTC WG


   see HTA proposal to list

   We are not getting volunteers,, so we make a random list and
   work down it

   Dan: when someone scribes, their names goes to bottom of the
   list. If someone is not there or presenting, they stay at top
   of the list

   charis: plan to use that proposal


   chairs wondering about WG LC in Q3 this year

   hta: this depends on output of GUM

   … can not sent GUM to LC until after face

   stefanh: have dependencies on IETF specs

   hta: some of it can be done without IETF being done, some of it
   we can not

   dom: Our charter says we would be done by now and we need to
   update and review by AC

   … A lot of people with expectation need fought estimates of
   when this will be done

   … If we have reasonable objectives, it will easier to focus on
   getting things done

   fluffy: suggest we write down a schedule to try and estimate
   when we would be done

   <dom> ACTION: stefanh to develop more granular estimate for
   schedule of WebRTC with hta [recorded in

   <trackbot> Created ACTION-82 - Develop more granular estimate
   for schedule of WebRTC with hta [on Stefan Håkansson - due

   hta: It's not the work that is creating long time line , it is
   the periods of waiting. Possible to get done faster, if people,
   especially editors rapid turn around cycle and people,
   especially chairs, keep the formal things that need to be done
   lined up and moving. We need to work on that, as always

face to face meeting

   <dom> [29]Proposed Interim Agenda from EKR


   stefanh: EKR proposed to use more time on media capture on
   email to list. What do people think of that?

   crikets: <silence>

   juberti: makes sense to finish that

   <dan_romascanu> still here

   hta: The more we can get things like error handling sketch out,
   the better

   stefanh: on the webrtc part of EKR's proposal

   … chairs will use this as starting point for more detailed

   Fluffy asked about good standing process. Dom and other
   explained a bit. Chairs hope to never need to use it.

Summary of Action Items

   [NEW] ACTION: derf to review needs for callback and errors
   callbacks in webrtc (with hta) [recorded in
   [NEW] ACTION: jesup to review needs for callback and errors
   callbacks in webrtc (with hta) [recorded in
   [NEW] ACTION: juberti to review needs for callback and errors
   callbacks in webrtc (with hta) [recorded in
   [NEW] ACTION: justin to draft guideline text [recorded in
   [NEW] ACTION: stefanh to develop more granular estimate for
   schedule of WebRTC with hta [recorded in
Received on Thursday, 10 January 2013 17:35:15 UTC

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