- From: Dominique Hazael-Massieux <dom@w3.org>
- Date: Tue, 18 Sep 2012 15:16:55 +0200
- To: public-webrtc@w3.org
Hi,
The draft minutes of our call yesterday are available at:
http://www.w3.org/2012/09/17-webrtc-minutes.html and copied as text
below.
Please send proposed corrections to the list.
Dom
Web Real-Time Communications Working Group Teleconference
17 Sep 2012
[2]Agenda
[2]
http://lists.w3.org/Archives/Public/public-webrtc/2012Sep/0141.html
See also: [3]IRC log
[3] http://www.w3.org/2012/09/17-webrtc-irc
Attendees
Present
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], +91.80.33.41.aaoo, +1.215.681.aapp, derf,
+1.215.681.aaqq
Regrets
Chair
hta, stefanh
Scribe
juberti, stefanh, hta
Contents
* [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
observer.
<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:
[11]http://lists.w3.org/Archives/Public/public-webrtc/2012Aug/0
238.html
[11]
http://lists.w3.org/Archives/Public/public-webrtc/2012Aug/0238.html
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
[12]
http://lists.w3.org/Archives/Public/public-webrtc/2012Sep/0142.html
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
surface.
fluffy: Well, W3C and IETF have agreed to work together on this
work.
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
Matthew/Martin.
<stefanh> items in categories:
[14]http://lists.w3.org/Archives/Public/public-webrtc/2012Sep/0
142.html
[14]
http://lists.w3.org/Archives/Public/public-webrtc/2012Sep/0142.html
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:
[15]http://lists.w3.org/Archives/Public/public-webrtc/2012Sep/0
146.html
[15]
http://lists.w3.org/Archives/Public/public-webrtc/2012Sep/0146.html
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
API
hta: We still need to figure out the details here.
stefanh: Pausing amd muting of streams - there is ongoing work
here.
... 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
call.
... 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
WG.
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
interaction,.
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
mid-session.
... 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
good.]
<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
[16]
http://lists.w3.org/Archives/Public/public-webrtc/2012Sep/att-0097/WebRTCstatesandcallbacks.pdf
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,
connectied
<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
state
... 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
machine
Matthew: why is all this necessary?
Justin: use case where the app needs to know
Matthew: you could just expose primitives....no diagrams
needed.
... message I sent on Aug 27
Justin: this assumes we do ICE machine in browser.
<dom> [17]Matthew suggesting not having an ICE machine
[17]
http://lists.w3.org/Archives/Public/public-webrtc/2012Aug/0193.html
(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
end-points?
Ekr: don't understand Matthew? What we do will interop with
ICE.
... I'm happy to listen to Matthew or talk (talk)
...question: state for each component, and a global state,
right?
... 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
in-between
... 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
agenda.
... 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
overall.
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
consensus
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
changes.
<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
out?
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
callbacks
Adam: a terminology question.
<ekr> what is the difference between event handler and a
callback?
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
callbacks
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
[19]
http://lists.w3.org/Archives/Public/public-webrtc/2012Sep/0025.html
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
go?
Justin: could be a list of transports just as we have a list of
MediaStream.
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
[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
anyway
... 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
missed)
<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.
IdP
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
[21]http://www.w3.org/2012/09/17-webrtc-minutes.html#action01]
<trackbot> Created ACTION-51 - Change States proposal in
accordance with discussion. [on Justin Uberti - due
2012-09-24].
<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
[22]http://www.w3.org/2012/09/17-webrtc-minutes.html#action01]
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