W3C home > Mailing lists > Public > public-webrtc@w3.org > September 2012

[minutes] Sep 17 teleconf

From: Dominique Hazael-Massieux <dom@w3.org>
Date: Tue, 18 Sep 2012 15:16:55 +0200
Message-ID: <1347974215.15243.7.camel@cumulustier>
To: public-webrtc@w3.org

The draft minutes of our call yesterday are available at:
http://www.w3.org/2012/09/17-webrtc-minutes.html and copied as text

Please send proposed corrections to the list.


       Web Real-Time Communications Working Group Teleconference

17 Sep 2012



   See also: [3]IRC log

      [3] http://www.w3.org/2012/09/17-webrtc-irc


          fluffy, Harald_Alvestrand, Dan_Druta, juberti, jesup,
          Dom, Dan Romanascanu, Dan_Burnett, timpanton, gmandyam,
          adambe, stefanh, anant, tuexen, li, richard.ejzak,
          ganesh, +1.561.923.aamm, ekr, Andy, +1.831.426.aann,
          [IPcaller], +, +1.215.681.aapp, derf,

          hta, stefanh

          juberti, stefanh, hta


     * [4]Topics
         1. [5]Plan for moving forward
         2. [6]States in PeerConnection
         3. [7]Stats API
         4. [8]IdP
         5. [9]Round up
     * [10]Summary of Action Items

   <gmandyam> Giri Mandyam from Qualcomm Innovation Center (QuIC),
   calling in from (858) area code. I am joining the call as an

   <juberti> I can scribe for the non-IceState parts of the call

   <dom> ScribeNick: juberti

   stefanh: Propose to approve the minutes.

   <stefanh> Minutes Aug 28:


   hta: Any comments?

   hta: Hearing none, they are approved.

Plan for moving forward

   stefanh: Candidate plan sent out in email.
   ... Continuing use of SDP and PeerConnection.

   stefanh: Enumerating the open items that have been raised, but
   not necessarily in the first version. (ex: congestion control)
   ... Aim to provide all tools needed for implementation.

   <dom> [12]Sorting possible technical issues into categories,
   Stefan H


   stefanh: List of desired items has been made
   ... Once PeerConnection work is done, we can revisit the idea
   of a lower-level interface.
   ... Those are the main points of this plan.

   <dom> [13]WebRTC Poll Result Analysis and Next Steps, Stefan H

     [13] http://lists.w3.org/Archives/Public/public-webrtc/2012Sep/

   fluffy: Some of these proposals, e.g. coming up with a
   replacement for SDP, would be out of scope for W3C.
   ... We would need to work closely with the IETF for something
   like that.

   matthew: Really not in IETF's purview if it's just an API

   fluffy: Well, W3C and IETF have agreed to work together on this

   Matthew: I think maybe we agree to disagree.

   fluffy: The W3C can make the choices it wants. (Matthew agrees)

   matthew: The SDP being used by W3C in its API only somewhat
   resembles SDP as understood by IETF

   timpanton: It will be much clearer what the scope of the W3C
   API needs to be once implementations stabilize.
   ... Perhaps we should revisit in December once Firefox exists
   as a second implementation.

   martin: I disagree with the term "low-level".

   stefanh: any more comments?
   ... Discussing the various categories of requests from

   <stefanh> items in categories:


   hta: Yes, we should review this and find someone who can work
   on each item.

   martin: I responded to this email with descriptions of the
   particular items that were unclear.

   stefanh: I haven't had a chance to read that mail yet.

   <martin> Clarifications for the "underspecified" items:


   stefanh: We didn't address removing SDP since the poll result
   to support SDP was clear.
   ... Certain items that were deemed to be IETF items were also
   not included (e.g. H.264-SVC, ICE interop)
   ... Items that we think _are_ being addressed now.
   ... ICE candidates.
   ... This would be part of stats.

   <martin> sorry, missed the window - once these are resolved in
   the IETF, there may be some API consequences, but I agree that
   until they are resolved, we can't know if they will affect the

   hta: We still need to figure out the details here.

   stefanh: Pausing amd muting of streams - there is ongoing work
   ... Expose add'l ICE state, changes to offer-answer,
   description of state machines - there are ongoing discussions
   on all of these items.
   ... I hope we will discuss some of these items later in this
   ... Are MediaStreams mutable objects? No, not according to
   latest version of specs.
   ... Category of "needs to be addressed"
   ... Rollback of offers - mentioned but not discussed
   ... BWE feedback - discussed but have not come around
   ... Needs more discussion - DTMF onTone callback
   ... SDES setting API - we are waiting for that discussion in
   the IETF to stabilize
   ... Learning of network change events - need to figure out role
   of app versus role of user agent
   ... Priority allocation...

   fluffy: Network change events is being handled by another W3C

   martin: The network information API.

   hta: Need to figure out what the effect of network change
   should be on our systems, and whether it requires app

   stefanh: API for discovering capabilities.

   <martin> As Harald observes, we would need to examine the
   consequences on our API.

   stefanh: Capabilities could be used for fingerprinting.

   ekr: I'd like the chairs to schedule time to discuss
   fingerprinting. We're running into it everywhere.

   martin: +1 to that

   <fluffy> +1

   <matthew> also +1

   +1 from juberti

   <martin> +1 to EKR doing an intro to inform the discussion

   <dom> [we discussed it somewhat back in Mountain view IIRC]

   stefanh: Those are the items for discussions

   <matthew> i think there are use cases that a strong
   anti-fingerprinting stance would make impossible, so if we end
   up there we will also need to edit use cases

   stefanh: Martin, perhaps you could provide additional insight
   on these.

   <dom> [we could also arrange a meeting with people from the
   Privacy Interest Group if that's useful]

   martin: I think we already addressed duped tracks.
   ... Rather lengthy discussion of cert-based stuff. We might
   want an app to be able to reject a connection or session based
   on presented credentials.
   ... Splitting SDP between PC and MS.

   ekr: I think the cert stuff sounds reasonable

   martin: Splitting streams from transport, we still want to deal
   with that
   ... programmatic description of streams before they are created
   (i.e. introspect SDP)

   hta: What is the problem you are trying to solve?

   martin: Want to make sure I don't lose capabilities in
   ... Want to let user know, prior to acting on anything, that
   the remote side has multiple video streams

   stefanh: Thank you for the input.

   hta: Anything to add?>
   ... Nothing more to add.

States in PeerConnection

   stefanh: Next topic, states.

   <martin> [re: fingerprinting, I know that it's been discussed
   at length, but I don't recall there being a specific discussion
   on direction. Involving privacy groups as necessary would be

   <dom> ScribeNick: stefanh

   (Justin looking for document)

   <ekr> re: fingerprinting, the high order bit seems to be
   whether it's already a lost cause

   <dom> [16]ICE States


   Justin: doc contains Peer states and ICE states

   <ekr> derf, anant, I think that's a fair characterization. I
   would like to see if there are any security people who think
   this can be rolled back

   total state an aggregation of those two

   scribe: compared to previous desc: actual state for candidates
   orthogonal to peer state

   scribe: can be in gathering state while starting, connecting,

   <ekr> I take it bz would like the internet to stop working for
   firefox user?

   scribe: typical progressing starting, getting candidates,
   checking, valid pairs, connected,

   Ekr: valid pair for every stream?

   Justing: talking for a specific component

   <matthew> what a strange user interface. ok.

   Justing: should anything go wrong -> failed state, restart can
   be triggered by app

   <matthew> if only there were some sort of technology that
   allowed for user interfaces to be exposed to generic "browsers"

   Justing: same if in connected, getting time out, ->disconnected
   ... finally closed state.
   ... then aggregation part
   ...checking: any component being checked
   ...connected: all components working
   ... some more which scribe missed.
   ... callbacks indicating changes
   ... discussed in phone call last week: per stream ice state

   Matthew: why is all this necessary?

   Justin: use case where the app needs to know

   Matthew: you could just expose primitives....no diagrams
   ... message I sent on Aug 27

   Justin: this assumes we do ICE machine in browser.

   <dom> [17]Matthew suggesting not having an ICE machine


   (scribe missed a part of what Matthew said)

   Matthew: this is going to fall back to the IETF side
   ... interoperability, cycle around, change API

   Justin: on the other hand we can have this API in the browser
   quite soon

   Matthew: the question is if we're going to design a flexible
   API or a solid one
   ... for the interop cases

   Justin: are there use cases that need interop with non-ICE

   Ekr: don't understand Matthew? What we do will interop with
   ... I'm happy to listen to Matthew or talk (talk)
   ...question: state for each component, and a global state,
   ... how do I find the state for each comp?

   Justin: you dont, only global state

   Martin: why not only expose success and fail?

   Justin: some things you can do with more info (info to user and
   so on).

   Martin: why not go the whole way: broken, working, or
   ... not-working, working, in-progress

   Justin: there are differences between disconnected and failed'
   ... low cost having more states

   Martin: can't send an offer unless completed?

   Justin: you can always send a new offer.

   Martin: unnecessarly restrictive, we should discuss more
   ... what uses are seen for the in-between states. Not clear
   what use-cases that drive them.

   Justin: let's discuss more.

   Fluffy: q for chairs: ICE in browser or not is not on the
   ... for Justin: I think this looks great. Our impl. say we need
   to know when the gathering is finalized. Want to check that
   (not an event).
   ... in the same way as gathering is separable, checking is also
   separatble, collapse into the same state.

   Justin: May be collapsed, need to think a bit more.

   Fluffy: the only that moves you into checking is setRemote.

   hta: two points: one important difference is that you can
   ignore all states if you want a simple app
   ... second point: many people on the call, give room to others.

   Ekr: Not sure I understand Fluffys points.

   Fluffy: I think the enum thing - we could only event, but would
   like to be able to check state

   <martin> +1 to having state exposed via an enumeration

   Ekr: would like a consistent model. enums or callbacks.

   <martin> as long as both are the same

   Ekr: merging starting and checking: I don't like that
   ... would not like to merge them.
   ... having to remember seems not like the right thing.

   Justin: agree on the gathering part.

   <martin> for later consideration, how does this interact with
   something like the ice mobility stuff?

   Justin: don't have much more right now.
   ... how to expose per component state can be discussed next.

   hta: seems to me that we have two separate comments. One: this
   is the wrong approach, the other: this seems reasonable.
   ... seems reasonable to accept this as first draft, and that we
   ask editors to start editing it into the spec.

   Fluffy: we have time, can resolve some tweaks now. But agree

   Ekr: agree to Fluffy.
   ... some making a list?

   <martin> merging states that are driven by application actions
   (Starting > Checking)

   <martin> adding status for gathering

   Fluffy: enums vs callbacks

   <martin> +1 to ekr as a general design

   Ekr: enums that reflct state, events that reflects changes
   ... is what we should go with.

   Fluffy: agree, and is what develpers are used to

   <jesup> +1 to ekr

   Justin: we may end up with some extra gathering info state

   Fluffy: agree with enums + events for changes; seems like

   Martin: on-icechange does not seem approp.
   ... sorry made a mistake

   Justin clarified

   <martin> good

   <fluffy> So will add an enum that indicates the state of
   gathering. Will have some callback that indicates when this

   <martin> You should use the new WebIDL stuff for callbacks.
   "Function?" is very old-fashioned.

   hta: Justin: do you haveinfo enough to change the prop and send

   Justin: yes (some details missed)

   <hta> Martin, send text - the conventions of WebIDL are obscure
   enough (and change often enough) that I have a hard time
   keeping track.

   <martin> +1 to Adam, these aren't callbacks, you have event
   handlers (that take Event arguments)

   Adam: for the record: event+event-listeners - not callbacks

   <dom> +1 to adambe

   <martin> hta, you mean
   [18]http://html5labs.com/cu-rtc-web/cu-rtc-web.htm ?

     [18] http://html5labs.com/cu-rtc-web/cu-rtc-web.htm

   Justin: following up on that: all callbacks are defined as

   Adam: a terminology question.

   <ekr> what is the difference between event handler and a

   Adam: the IDLs are correct

   <martin> callbacks are passed to functions, event handlers are
   the "on*" attributes

   Adam: just a clarification

   <hta> martin, I mean "you need to describe an event handler
   like XXX and a callback as YYYY, and this is written in WebIDL
   draft ZZZ"

   <ekr> OK. I'm one of those cavemen who thinks they are both

   Adam: we should be consistent with the wording.

   Ekr: should we have independent access to each component?
   ... the answer is yes.
   ... but which API should be used?

   <martin> ekr, events have a particular structure that
   distinguishes them from callbacks. each event has a target
   (EventTarget) and the callback receives a single Event
   argument, etc...

   Ekr: I think the stats API

   Timpanton: seems like a slight mis-use of a stats API. SHould
   not be used for controlling behaviour.

   <fluffy> +1 to EKR on detailed per component access to ICE
   state should b via stats api

   Ekr: would you be happier if we changed the name?

   Timpanton: does it allow setting?

   hta: no

   Justin: we may want to mutate, need a new surface for this

   Ekr: I'n not sure I want to allow the app to be able to
   interfer with ICE

   adambe: I heard a lot of time that we look for an API surface,
   I posted a proposal for that last week

   <dom> [19]PeerConnection representation of MediaStreams that
   are sent/received, Adam B


   adambe: a MediaStream surface on PeerConn, could solve a lot of
   the cases we discuss

   <ekr> I had missed this. I will try to read it

   <jesup> It's on my list

   Matthew: I don't see how this is going to work. If extra info
   exposed via stats, then it is not mutable. Need to modify SDP
   and push down into the browser. We will need an API
   ... that asks the ICE amchine to stop checking. Where does that

   Justin: could be a list of transports just as we have a list of

   Matthew: SDP is not the right API for this, and stats is not.
   need something else
   ... need we need to figure out the API for this

   Fluffy: We do need to get some info from JS down to hte
   browser: reveal local IP or not.
   ... we had used hints for this. Can be used for more.

   Fluffy: we can use hints to change, use stats to check

   <martin> I discovered a problem with our IP hiding solution.

     [20] http://tools.ietf.org/html/rfc5245#appendix-B.2

   Ekr: Vague on use-cases that need deep control ICE. Plus one on
   using hints.
   ... if someone have a public IP address checks will be seen
   ... difficult to affect ICE without breaking things.

   Timpanton: I'm good with hints for some uses, but struggle with
   somethign that is symmetrical (read - change)
   ... if we come across we're in trouble.

   <fluffy> I assure you I am focused on the web to legacy case

   Matthew: I second Ekr: much more you'll read out than control.
   Affect ICE machine: I think focus on web-to-web is a mistake.
   ... misses interop cases.

   hta: looking forward to a write down on the use cases.
   ... Justin: can you make new version?

   Justin: absolutely. (detailed question that can be deferred

   <hta> question was whether we want to retain the onopen
   callback now that we have anohter calllback that fires at the
   same time.

   Ekr: we have 9 minutes left.
   ... I suggest we pull stats and IdP into the doc now

Stats API

   <fluffy> I think it is a good idea

   hta: anyone objecting pulling stats into the doc?
   ... no-one objected.


   Ekr: does anyone object putting IdP in?

   <fluffy> put it in

   Justin: what about hierarciacal stats? Open issue?

   Fluffy: we put a note in the doc.

   <martin> +1 ekr

Round up

   <hta> scribenick: hta

   Actions: Rephrase the bullet mentioning "low level API" in the
   plan moving ahead.

   <fluffy> 1) should change "low level" in chair writeup

   <fluffy> 2) just change api propsoal

   <fluffy> 3) editor will take etas api and put in to draft

   <fluffy> 4) editors will take IdP and put in editor draft

   <martin> Justin also agreed to describe possible application
   actions for each of the ice states

   <scribe> ACTION: Justin to change States proposal in accordance
   with discussion. [recorded in

   <trackbot> Created ACTION-51 - Change States proposal in
   accordance with discussion. [on Justin Uberti - due

   <martin> it could just be part of the second one here

   <juberti> I will also discuss the fate of onopen() on the list.

   <fluffy> on 2 "just" should be justin

Summary of Action Items

   [NEW] ACTION: Justin to change States proposal in accordance
   with discussion. [recorded in

   action: Stefan to change phrasing in the "plan for moving
   ahead, remove 'low-level'"

   action: one of the editors to add stats API to draft

   action: one of the editors to add IdP API to draft
Received on Tuesday, 18 September 2012 13:17:56 UTC

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