IRC log of webrtc on 2012-09-17

Timestamps are in UTC.

19:46:09 [RRSAgent]
RRSAgent has joined #webrtc
19:46:09 [RRSAgent]
logging to http://www.w3.org/2012/09/17-webrtc-irc
19:46:11 [trackbot]
RRSAgent, make logs world
19:46:11 [Zakim]
Zakim has joined #webrtc
19:46:13 [trackbot]
Zakim, this will be RTC
19:46:13 [Zakim]
ok, trackbot; I see UW_Web RTC()4:00PM scheduled to start in 14 minutes
19:46:14 [trackbot]
Meeting: Web Real-Time Communications Working Group Teleconference
19:46:14 [trackbot]
Date: 17 September 2012
19:52:04 [Zakim]
UW_Web RTC()4:00PM has now started
19:52:11 [Zakim]
+ +1.403.244.aaaa
19:52:45 [hta1]
hta1 has joined #webrtc
19:53:00 [fluffy]
fluffy has joined #webrtc
19:53:23 [Zakim]
+[Google]
19:53:37 [hta1]
zakim, [google] is me
19:53:37 [Zakim]
+hta1; got it
19:53:59 [hta]
zakim, who is on?
19:53:59 [Zakim]
I don't understand your question, hta.
19:54:10 [hta]
zakim, help
19:54:10 [Zakim]
Please refer to http://www.w3.org/2001/12/zakim-irc-bot for more detailed help.
19:54:13 [Zakim]
Some of the commands I know are:
19:54:13 [Zakim]
xxx is yyy - establish yyy as the name of unknown party xxx
19:54:13 [Zakim]
if yyy is 'me' or 'I', your nick is substituted
19:54:13 [Zakim]
xxx may be yyy - establish yyy as possibly the name of unknown party xxx
19:54:13 [Zakim]
I am xxx - establish your nick as the name of unknown party xxx
19:54:13 [Zakim]
xxx holds yyy [, zzz ...] - establish xxx as a group name and yyy, etc. as participants within that group
19:54:16 [Zakim]
xxx also holds yyy - add yyy to the list of participants in group xxx
19:54:17 [Zakim]
who's here? - lists the participants on the phone
19:54:20 [Zakim]
who's muted? - lists the participants who are muted
19:54:21 [Zakim]
mute xxx - mutes party xxx (like pressing 61#)
19:54:23 [Zakim]
unmute xxx - reverses the effect of "mute" and of 61#
19:54:26 [Zakim]
is xxx here? - reports whether a party named like xxx is present
19:54:27 [Zakim]
list conferences - reports the active conferences
19:54:28 [hta]
zakim, who's here?
19:54:29 [fluffy]
zakim, who is here?
19:54:29 [Zakim]
this is xxx - associates this channel with conference xxx
19:54:31 [Zakim]
excuse us - disconnects from the irc channel
19:54:33 [Zakim]
I last learned something new on $Date: 2012/02/01 21:15:02 $
19:54:35 [Zakim]
On the phone I see +1.403.244.aaaa, hta1
19:54:42 [Zakim]
On the phone I see +1.403.244.aaaa, hta1
19:54:42 [stefanh]
stefanh has joined #webrtc
19:54:49 [DanD]
DanD has joined #webrtc
19:54:50 [fluffy]
zakim, aaa is me
19:54:52 [Zakim]
sorry, fluffy, I do not recognize a party named 'aaa'
19:54:56 [dom]
Zakim, aaaa is fluffy
19:54:56 [Zakim]
+fluffy; got it
19:54:58 [fluffy]
zakim, aaaa is me
19:54:58 [Zakim]
sorry, fluffy, I do not recognize a party named 'aaaa'
19:55:08 [timpanton]
timpanton has joined #webrtc
19:55:14 [Zakim]
+ +1.215.681.aabb
19:55:17 [hta]
zakim, hta1 is Harald_Alvestrand
19:55:17 [Zakim]
+Harald_Alvestrand; got it
19:55:33 [Zakim]
+Dan_Druta
19:55:38 [jesup]
jesup has joined #webrtc
19:56:17 [Zakim]
+ +1.610.889.aacc
19:56:18 [Zakim]
+[GVoice]
19:56:25 [juberti]
juberti has joined #webrtc
19:56:30 [juberti]
Zakim, who's here
19:56:30 [Zakim]
juberti, you need to end that query with '?'
19:56:33 [juberti]
Zakim, who's here?
19:56:33 [Zakim]
On the phone I see fluffy, Harald_Alvestrand, +1.215.681.aabb, Dan_Druta, +1.610.889.aacc, [GVoice]
19:56:44 [jesup]
zackim: aacc is me
19:56:49 [juberti]
Zakim, [GVoice] is juberti
19:56:49 [Zakim]
+juberti; got it
19:57:00 [Zakim]
+??P21
19:57:01 [jesup]
zackim, aacc is me
19:57:11 [hta]
zakim, who is talking?
19:57:21 [timpanton]
zakim +??P21 is me
19:57:24 [Zakim]
hta, listening for 12 seconds I could not identify any sounds
19:57:33 [dan_romascanu]
dan_romascanu has joined #webrtc
19:57:38 [jesup]
zackim, +1.610.889.aacc is me
19:57:47 [timpanton]
zakim ??P21 is me
19:57:49 [jesup]
zackim: aacc is jesup
19:57:50 [Zakim]
+ +1.858.651.aadd
19:57:57 [juberti]
Zakim, aacc is jesup
19:57:57 [Zakim]
+jesup; got it
19:58:01 [jesup]
finally
19:58:06 [burn]
burn has joined #webrtc
19:58:12 [jesup]
Need better AI
19:58:15 [gmandyam]
gmandyam has joined #webrtc
19:58:23 [dom]
Zakim, call dom-mobile
19:58:23 [Zakim]
ok, dom; the call is being made
19:58:24 [Zakim]
+Dom
19:58:24 [timpanton]
Zakim, who's here ?
19:58:24 [Zakim]
On the phone I see fluffy, Harald_Alvestrand, +1.215.681.aabb, Dan_Druta, jesup, juberti, ??P21, +1.858.651.aadd, Dom (muted)
19:58:37 [dom]
Zakim, mute me
19:58:37 [Zakim]
Dom should now be muted
19:58:42 [Zakim]
+ +46.1.07.14.aaee
19:58:42 [Zakim]
+ +46.1.07.14.aaff
19:58:44 [timpanton]
Zakim ??P21 is me
19:58:50 [Zakim]
+ +972.9.957.aagg
19:58:50 [Zakim]
+Dan_Burnett
19:58:52 [gmandyam]
Giri Mandyam from Qualcomm Innovation Center (QuIC), calling in from (858) area code. I am joining the call as an observer.
19:58:52 [dom]
Zakim, ??P21 is timpanton
19:58:52 [Zakim]
+timpanton; got it
19:58:55 [Zakim]
+??P33
19:58:57 [adambe]
adambe has joined #webrtc
19:59:02 [dom]
Zakim, aadd is gmandyam
19:59:02 [Zakim]
+gmandyam; got it
19:59:09 [timpanton]
Dom, thanks.
19:59:32 [dan_romascanu]
+972.9.957.aagg must be me
19:59:33 [Zakim]
+ +1.503.264.aahh
19:59:35 [dom]
Zakim, aaee is probably adam
19:59:35 [Zakim]
+adam?; got it
19:59:42 [dom]
Zakim, aaff is probably stefan
19:59:43 [Zakim]
+stefan?; got it
19:59:50 [dom]
Zakim, mute stefan
19:59:50 [Zakim]
stefan? should now be muted
19:59:53 [Zakim]
+ +1.630.423.aaii
19:59:54 [dom]
Zakim, unmute stefan
19:59:54 [Zakim]
stefan? should no longer be muted
20:00:00 [martin]
martin has joined #webrtc
20:00:02 [dom]
Zakim, stefan is really adambe
20:00:02 [Zakim]
+adambe; got it
20:00:10 [dom]
Zakim, adam is really stefanh
20:00:10 [Zakim]
+stefanh; got it
20:00:15 [anant]
anant has joined #webrtc
20:00:43 [Zakim]
+[Mozilla]
20:00:43 [Li]
Li has joined #webrtc
20:00:49 [Richard]
Richard has joined #webrtc
20:00:53 [anant]
Zakim: Mozilla is anant
20:01:02 [Zakim]
+ +44.190.881.aajj
20:01:13 [anant]
Zakim, Mozilla is anant
20:01:13 [Zakim]
+anant; got it
20:01:24 [Zakim]
+ +49.441.6.aakk
20:01:29 [juberti]
I can scribe for the non-IceState parts of the call
20:01:50 [Zakim]
+ +1.908.541.aall
20:02:02 [dom]
Zakim, who's on the call?
20:02:02 [Zakim]
On the phone I see fluffy, Harald_Alvestrand, +1.215.681.aabb, Dan_Druta, jesup, juberti, timpanton, gmandyam, Dom (muted), adambe, stefanh, +972.9.957.aagg, Dan_Burnett, ??P33,
20:02:04 [dom]
ScribeNick: juberti
20:02:05 [Zakim]
... +1.503.264.aahh, +1.630.423.aaii, anant, +44.190.881.aajj, +49.441.6.aakk, +1.908.541.aall
20:02:15 [Zakim]
-anant
20:02:27 [roger]
roger has joined #webrtc
20:02:28 [dom]
Zakim, unmute me
20:02:28 [Zakim]
Dom should no longer be muted
20:02:40 [Li]
zakim, aall is li
20:02:40 [Zakim]
+li; got it
20:02:49 [dom]
Zakim, mute me
20:02:49 [Zakim]
Dom should now be muted
20:03:00 [Jerome]
Jerome has joined #webrtc
20:03:19 [Zakim]
+[Mozilla]
20:03:22 [anant]
Zakim, Mozilla is anant
20:03:22 [Zakim]
+anant; got it
20:03:27 [dom]
Zakim, aaii is richard.ejzak
20:03:27 [Zakim]
+richard.ejzak; got it
20:03:36 [martin]
I am a +1 something, so I'm probably the +1.503 number
20:03:43 [martin]
OK, that's not me
20:03:50 [dom]
Zakim, aahh is ganesh
20:03:50 [Zakim]
+ganesh; got it
20:03:54 [mreavy]
mreavy has joined #webrtc
20:04:02 [Zakim]
+ +1.561.923.aamm
20:04:04 [Zakim]
+ekr
20:04:23 [martin]
andy will be 44
20:04:25 [ekr]
ekr has joined #webrtc
20:04:34 [ekr]
zakim, who is here?
20:04:34 [Zakim]
On the phone I see fluffy, Harald_Alvestrand, +1.215.681.aabb, Dan_Druta, jesup, juberti, timpanton, gmandyam, Dom (muted), adambe, stefanh, +972.9.957.aagg, Dan_Burnett, ??P33,
20:04:37 [Zakim]
... ganesh, richard.ejzak, +44.190.881.aajj, +49.441.6.aakk, li, anant, +1.561.923.aamm, ekr
20:04:39 [dom]
Zakim, aajj is Andy
20:04:39 [Zakim]
+Andy; got it
20:04:52 [juberti]
stefanh: Propose to approve the minutes.
20:04:58 [stefanh]
Minutes Aug 28: http://lists.w3.org/Archives/Public/public-webrtc/2012Aug/0238.html
20:04:58 [martin]
Zajim, aabb is martin
20:04:59 [juberti]
hta: Any comments?
20:05:03 [Zakim]
+ +1.831.426.aann
20:05:11 [tuexen]
+49 ist tuexen
20:05:14 [Zakim]
+[IPcaller]
20:05:15 [juberti]
hta: Hearing none, they are approved.
20:05:40 [juberti]
stefanh: Candidate plan sent out in email.
20:05:52 [juberti]
stefanh: Continuing use of SDP and PeerConnection.
20:05:55 [Zakim]
+ +91.80.33.41.aaoo
20:05:57 [dom]
Topic: Plan for moving forward
20:06:03 [dom]
Agenda: http://lists.w3.org/Archives/Public/public-webrtc/2012Sep/0141.html
20:06:15 [juberti]
stefanh: Enumerating the open items that have been raised, but not necessarily in the first version. (ex: congestion control)
20:06:28 [AndyH]
AndyH has joined #webrtc
20:06:34 [matthew]
matthew has joined #webrtc
20:06:35 [juberti]
stefanh: Aim to provide all tools needed for implementation.
20:06:45 [dom]
-> http://lists.w3.org/Archives/Public/public-webrtc/2012Sep/0142.html Sorting possible technical issues into categories, Stefan H
20:06:55 [juberti]
stefanh: List of desired items has been made
20:07:11 [juberti]
stefanh: Once PeerConnection work is done, we can revisit the idea of a lower-level interface.
20:07:22 [juberti]
stefanh: Those are the main points of this plan.
20:07:25 [fluffy]
q+
20:07:29 [dom]
-> http://lists.w3.org/Archives/Public/public-webrtc/2012Sep/ WebRTC Poll Result Analysis and Next Steps, Stefan H
20:08:15 [matthew]
q+
20:08:19 [juberti]
fluffy: Some of these proposals, e.g. coming up with a replacement for SDP, would be out of scope for W3C.
20:08:21 [timpanton]
q+
20:08:25 [martin]
q+
20:08:38 [juberti]
fluffy: We would need to work closely with the IETF for something like that.
20:08:55 [juberti]
matthew: Really not in IETF's purview if it's just an API surface.
20:09:49 [juberti]
fluffy: Well, W3C and IETF have agreed to work together on this work.
20:10:06 [juberti]
Matthew: I think maybe we agree to disagree.
20:10:37 [juberti]
fluffy: The W3C can make the choices it wants. (Matthew agrees)
20:10:48 [dom]
q?
20:10:53 [dom]
ack fluffy
20:11:25 [dom]
ack matthew
20:11:27 [dom]
ack timpanton
20:11:28 [juberti]
matthew: The SDP being used by W3C in its API only somewhat resembles SDP as understood by IETF
20:11:54 [juberti]
timpanton: It will be much clearer what the scope of the W3C API needs to be once implementations stabilize.
20:11:57 [Zakim]
- +1.215.681.aabb
20:12:11 [juberti]
timpanton: Perhaps we should revisit in December once Firefox exists as a second implementation.
20:12:37 [Zakim]
+ +1.215.681.aapp
20:12:55 [juberti]
martin: I disagree with the term "low-level".
20:12:58 [Ganesh_Venkatesan]
Ganesh_Venkatesan has joined #webrtc
20:13:13 [martin]
q-
20:13:55 [juberti]
stefanh: any more comments?
20:14:04 [Zakim]
+[Mozilla]
20:14:35 [juberti]
stefanh: Discussing the various categories of requests from Matthew/Martin.
20:14:48 [stefanh]
items in categories: http://lists.w3.org/Archives/Public/public-webrtc/2012Sep/0142.html
20:14:49 [juberti]
hta: Yes, we should review this and find someone who can work on each item.
20:14:56 [martin]
q+
20:15:33 [juberti]
martin: I responded to this email with descriptions of the particular items that were unclear.
20:15:36 [derf]
Zakim, [Mozilla] contains me
20:15:36 [Zakim]
+derf; got it
20:15:46 [juberti]
stefanh: I haven't had a chance to read that mail yet.
20:15:53 [fluffy]
q?
20:16:07 [martin]
q-
20:16:24 [martin]
Clarifications for the "underspecified" items: http://lists.w3.org/Archives/Public/public-webrtc/2012Sep/0146.html
20:16:25 [juberti]
stefanh: We didn't address removing SDP since the poll result to support SDP was clear.
20:16:59 [juberti]
stefanh: Certain items that were deemed to be IETF items were also not included (e.g. H.264-SVC, ICE interop)
20:17:09 [juberti]
stefanh: Items that we think _are_ being addressed now.
20:17:28 [juberti]
stefanh: ICE candidates.
20:17:36 [juberti]
stefanh: This would be part of stats.
20:17:37 [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
20:17:50 [juberti]
hta: We still need to figure out the details here.
20:18:01 [juberti]
stefanh: Pausing amd muting of streams - there is ongoing work here.
20:18:20 [Zakim]
+Andy.a
20:18:30 [juberti]
stefanh: Expose add'l ICE state, changes to offer-answer, description of state machines - there are ongoing discussions on all of these items.
20:18:40 [Zakim]
-Andy
20:18:40 [juberti]
stefanh: I hope we will discuss some of these items later in this call.
20:19:11 [juberti]
stefanh: Are MediaStreams mutable objects? No, not according to latest version of specs.
20:19:23 [juberti]
stefanh: Category of "needs to be addressed"
20:19:30 [dom]
Zakim, who's noisy?
20:19:33 [juberti]
stefanh: Rollback of offers - mentioned but not discussed
20:19:42 [Zakim]
dom, listening for 10 seconds I heard sound from the following: stefanh (28%), +49.441.6.aakk (39%)
20:19:47 [dom]
Zakim, mute aakk
20:19:47 [Zakim]
+49.441.6.aakk should now be muted
20:19:58 [juberti]
stefanh: BWE feedback - discussed but have not come around
20:20:06 [juberti]
stefanh: Needs more discussion - DTMF onTone callback
20:20:28 [juberti]
stefanh: SDES setting API - we are waiting for that discussion in the IETF to stabilize
20:20:44 [juberti]
stefanh: Learning of network change events - need to figure out role of app versus role of user agent
20:20:50 [juberti]
stefanh: Priority allocation...
20:21:05 [juberti]
fluffy: Network change events is being handled by another W3C WG.
20:21:12 [juberti]
martin: The network information API.
20:21:48 [juberti]
hta: Need to figure out what the effect of network change should be on our systems, and whether it requires app interaction,.
20:21:57 [juberti]
stefanh: API for discovering capabilities.
20:21:57 [martin]
As Harald observes, we would need to examine the consequences on our API.
20:22:14 [juberti]
stefanh: Capabilities could be used for fingerprinting.
20:22:38 [juberti]
ekr: I'd like the chairs to schedule time to discuss fingerprinting. We're running into it everywhere.
20:22:42 [juberti]
martin: +1 to that
20:22:44 [fluffy]
+1
20:22:48 [matthew]
also +1
20:23:05 [juberti]
+1 from juberti
20:23:07 [martin]
+1 to EKR doing an intro to inform the discussion
20:23:17 [dom]
[we discussed it somewhat back in Mountain view IIRC]
20:23:18 [juberti]
stefanh: Those are the items for discussions
20:23:20 [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
20:23:46 [juberti]
stefanh: Martin, perhaps you could provide additional insight on these.
20:23:50 [dom]
[we could also arrange a meeting with people from the Privacy Interest Group if that's useful]
20:23:57 [juberti]
martin: I think we already addressed duped tracks.
20:24:21 [juberti]
martin: 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.
20:24:45 [juberti]
martin: Splitting SDP between PC and MS.
20:24:58 [juberti]
ekr: I think the cert stuff sounds reasonable
20:25:13 [juberti]
martin: Splitting streams from transport, we still want to deal with that
20:25:37 [juberti]
martin: programmatic description of streams before they are created (i.e. introspect SDP)
20:25:47 [juberti]
hta: What is the problem you are trying to solve?
20:26:04 [juberti]
martin: Want to make sure I don't lose capabilities in mid-session.
20:26:41 [juberti]
martin: Want to let user know, prior to acting on anything, that the remote side has multiple video streams
20:26:48 [juberti]
stefanh: Thank you for the input.
20:26:52 [juberti]
hta: Anything to add?>
20:27:03 [juberti]
hta: Nothing more to add.
20:27:12 [dom]
Topic: States in PeerConnection
20:27:12 [juberti]
stefanh: Next topic, states.
20:27:41 [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.]
20:28:22 [matthew]
just screenshare into IRC
20:28:39 [stefanh]
scribe stefanh
20:28:47 [dom]
ScribeNick: stefanh
20:29:11 [stefanh]
(Justin looking for document)
20:29:22 [ekr]
re: fingerprinting, the high order bit seems to be whether it's already a lost cause
20:29:55 [Zakim]
- +1.215.681.aapp
20:30:06 [juberti]
https://docs.google.com/document/d/1iTpbMCD9QI7gCLlnhXq7T8P-zT-r982JLZcRyyvo55w/edit
20:30:16 [Zakim]
+ +1.215.681.aaqq
20:30:47 [jesup]
blank here
20:31:14 [dom]
-> http://lists.w3.org/Archives/Public/public-webrtc/2012Sep/att-0097/WebRTCstatesandcallbacks.pdf ICE States
20:31:15 [anant]
works for me
20:31:15 [fluffy]
sep 10
20:31:23 [fluffy]
"PHone call about ICE states"
20:32:00 [stefanh]
Justin: doc contains Peer states and ICE states
20:32:13 [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
20:32:25 [stefanh]
total state an aggregation of those two
20:33:02 [stefanh]
...compared to previous desc: actual state for candidates orthogonal to peer state
20:33:22 [martin]
q+
20:33:24 [matthew]
+matthew
20:33:24 [stefanh]
...can be in gathering state while starting, connecting, connectied
20:33:32 [ekr]
I take it bz would like the internet to stop working for firefox user?
20:33:36 [dom]
q+ matthew
20:33:49 [matthew]
why does zakim wonder where i am, i wonder
20:34:03 [stefanh]
...typical progressing starting, getting candidates, checking, valid pairs, connected,
20:34:16 [stefanh]
Ekr: valid pair for every stream?
20:34:23 [martin]
q-
20:34:27 [stefanh]
Justing: talking for a specific component
20:34:35 [matthew]
what a strange user interface. ok.
20:34:53 [stefanh]
....should anything go wrong -> failed state, restart can be triggered by app
20:35:18 [matthew]
if only there were some sort of technology that allowed for user interfaces to be exposed to generic "browsers"
20:35:18 [stefanh]
....same if in connected, getting time out, ->disconnected state
20:35:27 [stefanh]
...finally closed state.
20:35:35 [stefanh]
...then aggregation part
20:36:00 [stefanh]
...checking: any component being checked
20:36:09 [stefanh]
...connected: all components working
20:36:25 [stefanh]
....some more which scribe missed.
20:36:35 [stefanh]
....callbacks indicating changes
20:37:01 [ekr]
q+
20:37:11 [martin]
q+
20:37:13 [stefanh]
.....discussed in phone call last week: per stream ice state machine
20:37:14 [fluffy]
q?
20:37:20 [fluffy]
q+
20:37:44 [stefanh]
Matthew: why is all this necessary?
20:37:48 [dom]
ack matthew
20:38:07 [stefanh]
Justin: use case where the app needs to know
20:38:34 [stefanh]
Matthew: you could just expose primitives....no diagrams needed.
20:38:41 [Zakim]
-ekr
20:38:51 [stefanh]
....message I sent on Aug 27
20:39:05 [stefanh]
Justin: this assumes we do ICE machine in browser.
20:39:10 [dom]
-> http://lists.w3.org/Archives/Public/public-webrtc/2012Aug/0193.html Matthew suggesting not having an ICE machine
20:39:17 [hta]
+hta
20:39:26 [hta]
q+
20:39:27 [Zakim]
+ekr
20:39:35 [ekr]
q?
20:39:41 [ekr]
Wow, I made it back in time
20:39:51 [stefanh]
(scribe missed a part of what Matthew said)
20:40:13 [stefanh]
Matthew: this is going to fall back to the IETF side
20:40:41 [stefanh]
...interoperability, cycle around, change API
20:40:46 [matthew]
-q
20:41:10 [stefanh]
Justin: on the other hand we can have this API in the browser quite soon
20:42:00 [stefanh]
Matthew: the question is if we're going to design a flexible API or a solid one
20:42:10 [stefanh]
....for the interop cases
20:42:51 [stefanh]
Justin: are there use cases that need interop with non-ICE end-points?
20:43:15 [stefanh]
Ekr: don't understand Matthew? What we do will interop with ICE.
20:43:43 [fluffy]
q?
20:44:09 [stefanh]
Ekr: I'm happy to listen to Matthew or talk (talk)
20:44:40 [stefanh]
...question: state for each component, and a global state, right?
20:44:51 [stefanh]
...how do I find the state for each comp?
20:44:56 [hta]
q?
20:44:59 [dom]
ack ekr
20:45:01 [dom]
ack martin
20:45:03 [stefanh]
Justin: yo dont, only global state
20:45:19 [stefanh]
Martin: why not only expose success and fail?
20:45:42 [stefanh]
Justing: some things you can do with more info (info to user and so on).
20:45:53 [stefanh]
s/Justing/Justin/
20:46:18 [stefanh]
Martin: why not go the whole way: broken, working, or in-between
20:46:51 [stefanh]
Martin: not-working, working, in-progress
20:47:16 [stefanh]
Justin: there are differences between disconnected and failed'
20:47:50 [stefanh]
...low cost having more states
20:48:06 [stefanh]
Martin: can't send an offer unless completed?
20:48:17 [stefanh]
Justin: you can always send a new offer.
20:48:38 [stefanh]
Martin: unnecessarly restrictive, we should discuss more
20:49:03 [martin]
q-
20:49:14 [stefanh]
...what uses are seen for the in-between states. Not clear what use-cases that drive them.
20:49:31 [stefanh]
Justin: let's discuss more.
20:49:58 [stefanh]
Fluffy: q for chairs: ICE in browser or not is not on the agenda.
20:50:33 [ekr]
q+
20:50:42 [dom]
ack fluffy
20:50:42 [stefanh]
...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).
20:51:18 [stefanh]
...in the same way as gathering is separable, checking is also separatble, collapse into the same state.
20:51:58 [stefanh]
Justin: May be collapsed, need to think a bit more.
20:52:22 [stefanh]
Fluffy: the only that moves you into checking is setRemote.
20:52:38 [dom]
ack hta
20:53:16 [stefanh]
hta: two points: one important difference is that you can ignore all states if you want a simple app
20:53:35 [stefanh]
...second point: many people on the call, give room to others.
20:53:56 [stefanh]
Ekr: Not sure I understand Fluffys points.
20:55:11 [stefanh]
Fluffy: I think the enum thing - we could only event, but would like to be able to check state
20:55:14 [martin]
+1 to having state exposed via an enumeration
20:55:31 [stefanh]
Ekr: would like a consistent model. enums or callbacks.
20:55:42 [martin]
as long as both are the same
20:56:02 [stefanh]
....merging starting and checking: I don't like that
20:56:13 [stefanh]
...would not like to merge them.
20:56:31 [stefanh]
...having to remember seems not like the right thing.
20:56:46 [stefanh]
Justin: agree on the gathering part.
20:57:08 [stefanh]
q?
20:57:13 [dom]
ack ekr
20:57:15 [martin]
for later consideration, how does this interact with something like the ice mobility stuff?
20:57:41 [stefanh]
Justin: don't have much more right now.
20:58:08 [stefanh]
....how to expose per component state can be discussed next.
20:58:49 [stefanh]
hta: seems to me that we have two separate comments. One: this is the wrong approach, the other: this seems reasonable.
20:59:28 [stefanh]
....seems reasonable to accept this as first draft, and that we ask editors to start editing it into the spec.
20:59:57 [stefanh]
Fluffy: we have time, can resolve some tweaks now. But agree overall.
21:00:06 [stefanh]
Ekr: agree to Fluffy.
21:00:16 [stefanh]
...some making a list?
21:00:30 [martin]
merging states that are driven by application actions (Starting > Checking)
21:00:31 [ekr]
q+
21:00:37 [martin]
adding status for gathering
21:01:00 [stefanh]
Fluffy: enums vs callbacks
21:01:19 [martin]
+1 to ekr as a general design
21:01:23 [fluffy]
q+
21:01:28 [stefanh]
Ekr: enums that reflct state, events that reflects changes
21:01:38 [stefanh]
...is what we should go with.
21:01:54 [stefanh]
Fluffy: agree, and is what develpers are used to
21:02:10 [martin]
q+
21:02:24 [jesup]
+1 to ekr
21:02:26 [dom]
ack ekr
21:02:37 [stefanh]
Justin: we may end up with some extra gathering info state
21:03:13 [stefanh]
Fluffy: agree with enums + events for changes; seems like consensus
21:03:35 [stefanh]
Martin: on-icechange does not seem approp.
21:03:44 [stefanh]
....sorry made a mistake
21:04:00 [martin]
q-
21:04:02 [stefanh]
Justin clarified
21:04:03 [martin]
good
21:04:15 [dom]
ack fluffy
21:04:15 [fluffy]
So will add an enum that indicates the state of gathering. Will have some callback that indicates when this changes.
21:04:39 [martin]
You should use the new WebIDL stuff for callbacks. "Function?" is very old-fashioned.
21:04:41 [stefanh]
hta: Justin: do you haveinfo enough to change the prop and send out?
21:04:50 [Zakim]
-ekr
21:04:54 [stefanh]
Justin: yes (some details missed)
21:05:20 [hta]
Martin, send text - the conventions of WebIDL are obscure enough (and change often enough) that I have a hard time keeping track.
21:05:25 [martin]
+1 to Adam, these aren't callbacks, you have event handlers (that take Event arguments)
21:05:25 [stefanh]
Adam: for the record: event+event-listeners - not callbacks
21:05:27 [Zakim]
+ekr
21:05:30 [dom]
+1 to adambe
21:05:32 [ekr]
q+
21:05:46 [martin]
hta: you mean http://html5labs.com/cu-rtc-web/cu-rtc-web.htm ?
21:05:56 [stefanh]
Justin: following up on that: all callbacks are defined as callbacks
21:06:08 [stefanh]
Adam: a terminology question.
21:06:10 [dom]
s/hta:/hta,/
21:06:14 [ekr]
what is the difference between event handler and a callback?
21:06:16 [stefanh]
...the IDLs are correct
21:06:32 [martin]
callbacks are passed to functions, event handlers are the "on*" attributes
21:06:38 [stefanh]
...just a clarification
21:06:43 [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"
21:06:49 [ekr]
OK. I'm one of those cavemen who thinks they are both callbacks
21:06:57 [stefanh]
...we should be consistent with the wording.
21:07:06 [stefanh]
q?
21:07:06 [hta]
q?
21:07:16 [dom]
ack ekr
21:07:23 [stefanh]
Ekr: should we have independent access to each component?
21:07:34 [stefanh]
....the answer is yes.
21:07:48 [stefanh]
....but which API should be used?
21:07:55 [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...
21:08:03 [fluffy]
+1 to EKR on detailed per companied access to state should b via stats api
21:08:06 [stefanh]
...I think the stats API
21:08:07 [timpanton]
q+
21:08:21 [adambe]
+q
21:08:22 [matthew]
q+
21:08:27 [martin]
fluffy, English please ?
21:08:52 [stefanh]
Timpanton: seems like a slight mis-use of a stats API. SHould not be used for controlling behaviour.
21:09:10 [fluffy]
second try, +1 to EKR on detailed per component access to ICE state should b via stats api
21:09:15 [stefanh]
Ekr: would you be happier if we changed the name?
21:09:33 [martin]
fluffy, thanks, I thought that was what you meant
21:09:36 [stefanh]
Timpanton: does it allow setting?
21:09:41 [stefanh]
hta: no
21:10:02 [stefanh]
Justin: we may want to mutate, need a new surface for this
21:10:17 [adambe]
q?
21:10:23 [timpanton]
q-
21:10:23 [ekr]
q+
21:10:34 [stefanh]
Ekr: I'n not sure I want to allow the app to be able to interfer with ICE
21:10:54 [fluffy]
q?
21:10:58 [ekr]
q-
21:11:05 [fluffy]
q+
21:11:32 [stefanh]
adambe: I heard a lot of time that we look for an API surface, I posted a proposal for that last week
21:11:35 [dom]
-> http://lists.w3.org/Archives/Public/public-webrtc/2012Sep/0025.html PeerConnection representation of MediaStreams that are sent/received, Adam B
21:11:58 [dom]
ack adambe
21:12:00 [stefanh]
....a MediaStream surface on PeerConn, could solve a lot of the cases we discuss
21:12:01 [ekr]
I had missed this. I will try to read it
21:12:12 [dom]
ack matthew
21:12:13 [jesup]
It's on my list
21:13:13 [stefanh]
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
21:13:36 [stefanh]
....that asks the ICE amchine to stop checking. Where does that go?
21:14:07 [stefanh]
Justin: could be a list of transports just as we have a list of MediaStream.
21:14:35 [stefanh]
Matthew: SDP is not the right API for this, and stats is not. need something else
21:14:44 [ekr]
q+
21:14:59 [dom]
ack fluffy
21:15:00 [stefanh]
...need we need to figure out the API for this
21:15:34 [stefanh]
Fluffy: We do need to get some info from JS down to hte browser: reveal local IP or not.
21:15:56 [stefanh]
...we had used hints for this. Can be used for more.
21:16:14 [timpanton]
q
21:16:19 [stefanh]
....we can use hints to change, use stats to check
21:16:41 [martin]
I discovered a problem with our IP hiding solution. http://tools.ietf.org/html/rfc5245#appendix-B.2
21:16:49 [stefanh]
Ekr: Vague on use-cases that need deep control ICE. Plus one on using hints.
21:17:13 [stefanh]
...if someone have a public IP address checks will be seen anyway
21:17:17 [timpanton]
q+
21:18:01 [dom]
ack ekr
21:18:02 [ekr]
ack ekr
21:18:03 [matthew]
q+
21:18:08 [stefanh]
...difficult to affect ICE without breaking things.
21:18:47 [stefanh]
Timpanton: I'm good with hints for some uses, but struggle with somethign that is symmetrical (read - change)
21:19:00 [stefanh]
...if we come across we're in trouble.
21:19:00 [timpanton]
q-
21:19:01 [hta]
q?
21:19:41 [dom]
ack matthew
21:19:47 [fluffy]
I assure you I am focused on the web to legacy case
21:19:48 [stefanh]
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.
21:20:02 [stefanh]
....misses interop cases.
21:20:06 [matthew]
q-
21:20:15 [hta]
q?
21:20:20 [stefanh]
hta: looking forward to a write down on the use cases.
21:20:57 [stefanh]
hta: Justin: can you make new version?
21:21:21 [stefanh]
Justin: absolutely. (detailed question that can be deferred missed)
21:21:47 [hta]
question was whether we want to retain the onopen callback now that we have anohter calllback that fires at the same time.
21:22:16 [stefanh]
Ekr: we have 9 minutes left.
21:22:30 [fluffy]
q+
21:22:35 [stefanh]
....I suggest we pull stats and IdP into the doc now
21:22:42 [dom]
Topic: Stats API
21:22:50 [fluffy]
I think it is a good idea
21:22:50 [stefanh]
hta: anyone objecting pulling stats into the doc?
21:22:57 [stefanh]
...no-one objected.
21:23:01 [dom]
Topic: IdP
21:23:12 [stefanh]
Ekr: does anyone object putting IdP in?
21:23:13 [fluffy]
put it in
21:23:45 [stefanh]
Justin: what about hierarciacal stats? Open issue?
21:23:56 [stefanh]
Fluffy: we put a note in the doc.
21:24:03 [martin]
+1 ekr
21:24:24 [dom]
Topic: Round up
21:24:43 [hta]
scribenick: hta
21:25:04 [hta]
Actions: Rephrase the bullet mentioning "low level API" in the plan moving ahead.
21:25:11 [fluffy]
1) should change "low level" in chair writeup
21:25:16 [fluffy]
2) just change api propsoal
21:25:26 [fluffy]
3) editor will take etas api and put in to draft
21:25:28 [hta]
fluffy, are you scribing?
21:25:40 [fluffy]
4) editors will take IdP and put in editor draft
21:26:01 [martin]
Justin also agreed to describe possible application actions for each of the ice states
21:26:11 [fluffy]
am I sill here ?
21:26:11 [hta]
action: Justin to change States proposal in accordance with discussion.
21:26:12 [trackbot]
Created ACTION-51 - Change States proposal in accordance with discussion. [on Justin Uberti - due 2012-09-24].
21:26:16 [ekr]
fluyy, you are still here
21:26:22 [martin]
it could just be part of the second one here
21:26:28 [juberti]
I will also discuss the fate of onopen() on the list.
21:26:32 [fluffy]
on 2 "just" should be justin
21:26:56 [Zakim]
-ekr
21:26:57 [Zakim]
-Andy.a
21:26:58 [Zakim]
- +1.561.923.aamm
21:27:00 [Zakim]
-Harald_Alvestrand
21:27:01 [Zakim]
-Dom
21:27:02 [Zakim]
- +1.215.681.aaqq
21:27:03 [Zakim]
-adambe
21:27:04 [Zakim]
-timpanton
21:27:04 [Zakim]
-fluffy
21:27:04 [Zakim]
-Dan_Burnett
21:27:06 [Zakim]
-??P33
21:27:09 [Zakim]
-richard.ejzak
21:27:10 [Zakim]
-juberti
21:27:11 [dom]
Zakim, list attendees
21:27:13 [Zakim]
-gmandyam
21:27:15 [Zakim]
-stefanh
21:27:16 [Zakim]
-ganesh
21:27:18 [Zakim]
- +49.441.6.aakk
21:27:21 [Zakim]
-[IPcaller]
21:27:23 [Zakim]
-anant
21:27:24 [Zakim]
-li
21:27:26 [Zakim]
As of this point the attendees have been +1.403.244.aaaa, fluffy, +1.215.681.aabb, Harald_Alvestrand, Dan_Druta, +1.610.889.aacc, juberti, +1.858.651.aadd, jesup, Dom,
21:27:29 [Zakim]
... +46.1.07.14.aaee, +46.1.07.14.aaff, +972.9.957.aagg, Dan_Burnett, timpanton, gmandyam, +1.503.264.aahh, adam?, stefan?, +1.630.423.aaii, adambe, stefanh, +44.190.881.aajj,
21:27:33 [Zakim]
... anant, +49.441.6.aakk, +1.908.541.aall, 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,
21:27:35 [Zakim]
... +1.215.681.aaqq
21:27:37 [Zakim]
- +972.9.957.aagg
21:27:39 [Zakim]
-Dan_Druta
21:27:41 [Zakim]
- +1.831.426.aann
21:27:44 [Zakim]
-[Mozilla]
21:27:45 [Zakim]
- +91.80.33.41.aaoo
21:27:57 [dom]
RRSAgent, draft minutes
21:27:57 [RRSAgent]
I have made the request to generate http://www.w3.org/2012/09/17-webrtc-minutes.html dom
21:28:01 [dom]
Zakim, who's on the call?
21:28:01 [Zakim]
On the phone I see jesup
21:28:29 [dom]
Chair: hta, stefanh
21:28:32 [dom]
Zakim, drop jesup
21:28:32 [Zakim]
jesup is being disconnected
21:28:33 [Zakim]
UW_Web RTC()4:00PM has ended
21:28:33 [Zakim]
Attendees were +1.403.244.aaaa, fluffy, +1.215.681.aabb, Harald_Alvestrand, Dan_Druta, +1.610.889.aacc, juberti, +1.858.651.aadd, jesup, Dom, +46.1.07.14.aaee, +46.1.07.14.aaff,
21:28:33 [Zakim]
... +972.9.957.aagg, Dan_Burnett, timpanton, gmandyam, +1.503.264.aahh, adam?, stefan?, +1.630.423.aaii, adambe, stefanh, +44.190.881.aajj, anant, +49.441.6.aakk, +1.908.541.aall,
21:28:35 [Zakim]
... 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
21:28:51 [dom]
RRSAgent, draft minutes
21:28:51 [RRSAgent]
I have made the request to generate http://www.w3.org/2012/09/17-webrtc-minutes.html dom
21:29:11 [jesup]
jesup has left #webrtc
21:31:51 [anant]
anant has joined #webrtc
21:32:32 [matthew]
matthew has left #webrtc
21:34:01 [anant]
anant has joined #webrtc
21:36:40 [anant]
anant has joined #webrtc
21:36:57 [AndyH]
test
21:38:01 [AndyH]
AndyH has left #webrtc
21:57:11 [hta]
hta has joined #webrtc
22:03:15 [hta]
hta has left #webrtc
22:05:49 [Jerome]
Jerome has left #webrtc
22:30:26 [ekr]
ekr has joined #webrtc
22:38:10 [anant]
anant has joined #webrtc
22:42:54 [mreavy_]
mreavy_ has joined #webrtc