W3C

Web Real-Time Communications Working Group Teleconference

10 Jan 2013

Agenda

See also: IRC log

Attendees

Present
+1.908.578.aabb, Dan_Burnett, hta, stefanh, +972.9.957.aaee, Milan_Patel, dom, +91.22.39.14.aagg, derf, Dan_Druta, +1.630.423.aajj, dan_romascanu?, adambe, jesup, fluffy, +91.22.39.14.aall, juberti, +1.831.440.aaoo, JeromeMarcon, nstratford, +91.22.39.14.aapp, +44.190.881.aaqq, adam
Regrets
Chair
stefanh, hta
Scribe
adambe, fluffy

Contents


<trackbot> Date: 10 January 2013

<stefanh> Agenda, and some stuff: http://www.w3.org/2011/04/webrtc/wiki/Teleconferences#Thu.2C_Jan_10_2013

<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> http://www.w3.org/2011/04/webrtc/wiki/Teleconferences#Thu.2C_Jan_10_2013

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: http://lists.w3.org/Archives/Public/public-webrtc/2012Dec/0048.html

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> Stats API proposal

hta: the most important part is that we've changed the returned report
... 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> +33.6.85.56.aamm = 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

<adam> http://www.w3.org/2011/04/webrtc/wiki/File:20130110error_handling.pdf

<dom> 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 https://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#error-names-0, the name should be INVALID_STATE_ERR rather than INVALID_STATE]

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

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 time

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

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 people

<dom> " So decided that invalid_state will be a callback no exception" 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 http://www.w3.org/2013/01/10-webrtc-minutes.html#action01]

<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 http://dev.w3.org/2011/webrtc/editor/webrtc.html#widl-RTCPeerConnection-updateIce-void-RTCConfiguration-configuration-MediaConstraints-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." http://dev.w3.org/2011/webrtc/editor/webrtc.html#widl-RTCPeerConnection-getIdentityAssertion-void

fluffy: ask ekr to clarify if getIdentityAssertion() need callbacks

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 completeness

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

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 http://www.w3.org/2013/01/10-webrtc-minutes.html#action02]

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

<dom> ACTION: jesup to review needs for callback and errors callbacks in webrtc (with hta) [recorded in http://www.w3.org/2013/01/10-webrtc-minutes.html#action03]

<trackbot> Error finding 'jesup'. You can review and register nicknames at <http://www.w3.org/2011/04/webrtc/track/users>.

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 http://www.w3.org/2013/01/10-webrtc-minutes.html#action04]

<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> A proposal on minute-takers for the WEBRTC WG meetings

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

schedule

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 http://www.w3.org/2013/01/10-webrtc-minutes.html#action05]

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

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

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 http://www.w3.org/2013/01/10-webrtc-minutes.html#action04]
[NEW] ACTION: jesup to review needs for callback and errors callbacks in webrtc (with hta) [recorded in http://www.w3.org/2013/01/10-webrtc-minutes.html#action03]
[NEW] ACTION: juberti to review needs for callback and errors callbacks in webrtc (with hta) [recorded in http://www.w3.org/2013/01/10-webrtc-minutes.html#action02]
[NEW] ACTION: justin to draft guideline text [recorded in http://www.w3.org/2013/01/10-webrtc-minutes.html#action01]
[NEW] ACTION: stefanh to develop more granular estimate for schedule of WebRTC with hta [recorded in http://www.w3.org/2013/01/10-webrtc-minutes.html#action05]
 
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.137 (CVS log)
$Date: 2013/01/10 17:33:06 $