Web Real-Time Communications Working Group Teleconference

<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: 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> 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> WebRTC Poll Result Analysis and Next Steps, Stefan H

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