19:46:09 RRSAgent has joined #webrtc 19:46:09 logging to http://www.w3.org/2012/09/17-webrtc-irc 19:46:11 RRSAgent, make logs world 19:46:11 Zakim has joined #webrtc 19:46:13 Zakim, this will be RTC 19:46:13 ok, trackbot; I see UW_Web RTC()4:00PM scheduled to start in 14 minutes 19:46:14 Meeting: Web Real-Time Communications Working Group Teleconference 19:46:14 Date: 17 September 2012 19:52:04 UW_Web RTC()4:00PM has now started 19:52:11 + +1.403.244.aaaa 19:52:45 hta1 has joined #webrtc 19:53:00 fluffy has joined #webrtc 19:53:23 +[Google] 19:53:37 zakim, [google] is me 19:53:37 +hta1; got it 19:53:59 zakim, who is on? 19:53:59 I don't understand your question, hta. 19:54:10 zakim, help 19:54:10 Please refer to http://www.w3.org/2001/12/zakim-irc-bot for more detailed help. 19:54:13 Some of the commands I know are: 19:54:13 xxx is yyy - establish yyy as the name of unknown party xxx 19:54:13 if yyy is 'me' or 'I', your nick is substituted 19:54:13 xxx may be yyy - establish yyy as possibly the name of unknown party xxx 19:54:13 I am xxx - establish your nick as the name of unknown party xxx 19:54:13 xxx holds yyy [, zzz ...] - establish xxx as a group name and yyy, etc. as participants within that group 19:54:16 xxx also holds yyy - add yyy to the list of participants in group xxx 19:54:17 who's here? - lists the participants on the phone 19:54:20 who's muted? - lists the participants who are muted 19:54:21 mute xxx - mutes party xxx (like pressing 61#) 19:54:23 unmute xxx - reverses the effect of "mute" and of 61# 19:54:26 is xxx here? - reports whether a party named like xxx is present 19:54:27 list conferences - reports the active conferences 19:54:28 zakim, who's here? 19:54:29 zakim, who is here? 19:54:29 this is xxx - associates this channel with conference xxx 19:54:31 excuse us - disconnects from the irc channel 19:54:33 I last learned something new on $Date: 2012/02/01 21:15:02 $ 19:54:35 On the phone I see +1.403.244.aaaa, hta1 19:54:42 On the phone I see +1.403.244.aaaa, hta1 19:54:42 stefanh has joined #webrtc 19:54:49 DanD has joined #webrtc 19:54:50 zakim, aaa is me 19:54:52 sorry, fluffy, I do not recognize a party named 'aaa' 19:54:56 Zakim, aaaa is fluffy 19:54:56 +fluffy; got it 19:54:58 zakim, aaaa is me 19:54:58 sorry, fluffy, I do not recognize a party named 'aaaa' 19:55:08 timpanton has joined #webrtc 19:55:14 + +1.215.681.aabb 19:55:17 zakim, hta1 is Harald_Alvestrand 19:55:17 +Harald_Alvestrand; got it 19:55:33 +Dan_Druta 19:55:38 jesup has joined #webrtc 19:56:17 + +1.610.889.aacc 19:56:18 +[GVoice] 19:56:25 juberti has joined #webrtc 19:56:30 Zakim, who's here 19:56:30 juberti, you need to end that query with '?' 19:56:33 Zakim, who's here? 19:56:33 On the phone I see fluffy, Harald_Alvestrand, +1.215.681.aabb, Dan_Druta, +1.610.889.aacc, [GVoice] 19:56:44 zackim: aacc is me 19:56:49 Zakim, [GVoice] is juberti 19:56:49 +juberti; got it 19:57:00 +??P21 19:57:01 zackim, aacc is me 19:57:11 zakim, who is talking? 19:57:21 zakim +??P21 is me 19:57:24 hta, listening for 12 seconds I could not identify any sounds 19:57:33 dan_romascanu has joined #webrtc 19:57:38 zackim, +1.610.889.aacc is me 19:57:47 zakim ??P21 is me 19:57:49 zackim: aacc is jesup 19:57:50 + +1.858.651.aadd 19:57:57 Zakim, aacc is jesup 19:57:57 +jesup; got it 19:58:01 finally 19:58:06 burn has joined #webrtc 19:58:12 Need better AI 19:58:15 gmandyam has joined #webrtc 19:58:23 Zakim, call dom-mobile 19:58:23 ok, dom; the call is being made 19:58:24 +Dom 19:58:24 Zakim, who's here ? 19:58:24 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 Zakim, mute me 19:58:37 Dom should now be muted 19:58:42 + +46.1.07.14.aaee 19:58:42 + +46.1.07.14.aaff 19:58:44 Zakim ??P21 is me 19:58:50 + +972.9.957.aagg 19:58:50 +Dan_Burnett 19:58:52 Giri Mandyam from Qualcomm Innovation Center (QuIC), calling in from (858) area code. I am joining the call as an observer. 19:58:52 Zakim, ??P21 is timpanton 19:58:52 +timpanton; got it 19:58:55 +??P33 19:58:57 adambe has joined #webrtc 19:59:02 Zakim, aadd is gmandyam 19:59:02 +gmandyam; got it 19:59:09 Dom, thanks. 19:59:32 +972.9.957.aagg must be me 19:59:33 + +1.503.264.aahh 19:59:35 Zakim, aaee is probably adam 19:59:35 +adam?; got it 19:59:42 Zakim, aaff is probably stefan 19:59:43 +stefan?; got it 19:59:50 Zakim, mute stefan 19:59:50 stefan? should now be muted 19:59:53 + +1.630.423.aaii 19:59:54 Zakim, unmute stefan 19:59:54 stefan? should no longer be muted 20:00:00 martin has joined #webrtc 20:00:02 Zakim, stefan is really adambe 20:00:02 +adambe; got it 20:00:10 Zakim, adam is really stefanh 20:00:10 +stefanh; got it 20:00:15 anant has joined #webrtc 20:00:43 +[Mozilla] 20:00:43

Li has joined #webrtc 20:00:49 Richard has joined #webrtc 20:00:53 Zakim: Mozilla is anant 20:01:02 + +44.190.881.aajj 20:01:13 Zakim, Mozilla is anant 20:01:13 +anant; got it 20:01:24 + +49.441.6.aakk 20:01:29 I can scribe for the non-IceState parts of the call 20:01:50 + +1.908.541.aall 20:02:02 Zakim, who's on the call? 20:02:02 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 ScribeNick: juberti 20:02:05 ... +1.503.264.aahh, +1.630.423.aaii, anant, +44.190.881.aajj, +49.441.6.aakk, +1.908.541.aall 20:02:15 -anant 20:02:27 roger has joined #webrtc 20:02:28 Zakim, unmute me 20:02:28 Dom should no longer be muted 20:02:40

zakim, aall is li 20:02:40 +li; got it 20:02:49 Zakim, mute me 20:02:49 Dom should now be muted 20:03:00 Jerome has joined #webrtc 20:03:19 +[Mozilla] 20:03:22 Zakim, Mozilla is anant 20:03:22 +anant; got it 20:03:27 Zakim, aaii is richard.ejzak 20:03:27 +richard.ejzak; got it 20:03:36 I am a +1 something, so I'm probably the +1.503 number 20:03:43 OK, that's not me 20:03:50 Zakim, aahh is ganesh 20:03:50 +ganesh; got it 20:03:54 mreavy has joined #webrtc 20:04:02 + +1.561.923.aamm 20:04:04 +ekr 20:04:23 andy will be 44 20:04:25 ekr has joined #webrtc 20:04:34 zakim, who is here? 20:04:34 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 ... ganesh, richard.ejzak, +44.190.881.aajj, +49.441.6.aakk, li, anant, +1.561.923.aamm, ekr 20:04:39 Zakim, aajj is Andy 20:04:39 +Andy; got it 20:04:52 stefanh: Propose to approve the minutes. 20:04:58 Minutes Aug 28: http://lists.w3.org/Archives/Public/public-webrtc/2012Aug/0238.html 20:04:58 Zajim, aabb is martin 20:04:59 hta: Any comments? 20:05:03 + +1.831.426.aann 20:05:11 +49 ist tuexen 20:05:14 +[IPcaller] 20:05:15 hta: Hearing none, they are approved. 20:05:40 stefanh: Candidate plan sent out in email. 20:05:52 stefanh: Continuing use of SDP and PeerConnection. 20:05:55 + +91.80.33.41.aaoo 20:05:57 Topic: Plan for moving forward 20:06:03 Agenda: http://lists.w3.org/Archives/Public/public-webrtc/2012Sep/0141.html 20:06:15 stefanh: Enumerating the open items that have been raised, but not necessarily in the first version. (ex: congestion control) 20:06:28 AndyH has joined #webrtc 20:06:34 matthew has joined #webrtc 20:06:35 stefanh: Aim to provide all tools needed for implementation. 20:06:45 -> http://lists.w3.org/Archives/Public/public-webrtc/2012Sep/0142.html Sorting possible technical issues into categories, Stefan H 20:06:55 stefanh: List of desired items has been made 20:07:11 stefanh: Once PeerConnection work is done, we can revisit the idea of a lower-level interface. 20:07:22 stefanh: Those are the main points of this plan. 20:07:25 q+ 20:07:29 -> http://lists.w3.org/Archives/Public/public-webrtc/2012Sep/ WebRTC Poll Result Analysis and Next Steps, Stefan H 20:08:15 q+ 20:08:19 fluffy: Some of these proposals, e.g. coming up with a replacement for SDP, would be out of scope for W3C. 20:08:21 q+ 20:08:25 q+ 20:08:38 fluffy: We would need to work closely with the IETF for something like that. 20:08:55 matthew: Really not in IETF's purview if it's just an API surface. 20:09:49 fluffy: Well, W3C and IETF have agreed to work together on this work. 20:10:06 Matthew: I think maybe we agree to disagree. 20:10:37 fluffy: The W3C can make the choices it wants. (Matthew agrees) 20:10:48 q? 20:10:53 ack fluffy 20:11:25 ack matthew 20:11:27 ack timpanton 20:11:28 matthew: The SDP being used by W3C in its API only somewhat resembles SDP as understood by IETF 20:11:54 timpanton: It will be much clearer what the scope of the W3C API needs to be once implementations stabilize. 20:11:57 - +1.215.681.aabb 20:12:11 timpanton: Perhaps we should revisit in December once Firefox exists as a second implementation. 20:12:37 + +1.215.681.aapp 20:12:55 martin: I disagree with the term "low-level". 20:12:58 Ganesh_Venkatesan has joined #webrtc 20:13:13 q- 20:13:55 stefanh: any more comments? 20:14:04 +[Mozilla] 20:14:35 stefanh: Discussing the various categories of requests from Matthew/Martin. 20:14:48 items in categories: http://lists.w3.org/Archives/Public/public-webrtc/2012Sep/0142.html 20:14:49 hta: Yes, we should review this and find someone who can work on each item. 20:14:56 q+ 20:15:33 martin: I responded to this email with descriptions of the particular items that were unclear. 20:15:36 Zakim, [Mozilla] contains me 20:15:36 +derf; got it 20:15:46 stefanh: I haven't had a chance to read that mail yet. 20:15:53 q? 20:16:07 q- 20:16:24 Clarifications for the "underspecified" items: http://lists.w3.org/Archives/Public/public-webrtc/2012Sep/0146.html 20:16:25 stefanh: We didn't address removing SDP since the poll result to support SDP was clear. 20:16:59 stefanh: Certain items that were deemed to be IETF items were also not included (e.g. H.264-SVC, ICE interop) 20:17:09 stefanh: Items that we think _are_ being addressed now. 20:17:28 stefanh: ICE candidates. 20:17:36 stefanh: This would be part of stats. 20:17:37 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 hta: We still need to figure out the details here. 20:18:01 stefanh: Pausing amd muting of streams - there is ongoing work here. 20:18:20 +Andy.a 20:18:30 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 -Andy 20:18:40 stefanh: I hope we will discuss some of these items later in this call. 20:19:11 stefanh: Are MediaStreams mutable objects? No, not according to latest version of specs. 20:19:23 stefanh: Category of "needs to be addressed" 20:19:30 Zakim, who's noisy? 20:19:33 stefanh: Rollback of offers - mentioned but not discussed 20:19:42 dom, listening for 10 seconds I heard sound from the following: stefanh (28%), +49.441.6.aakk (39%) 20:19:47 Zakim, mute aakk 20:19:47 +49.441.6.aakk should now be muted 20:19:58 stefanh: BWE feedback - discussed but have not come around 20:20:06 stefanh: Needs more discussion - DTMF onTone callback 20:20:28 stefanh: SDES setting API - we are waiting for that discussion in the IETF to stabilize 20:20:44 stefanh: Learning of network change events - need to figure out role of app versus role of user agent 20:20:50 stefanh: Priority allocation... 20:21:05 fluffy: Network change events is being handled by another W3C WG. 20:21:12 martin: The network information API. 20:21:48 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 stefanh: API for discovering capabilities. 20:21:57 As Harald observes, we would need to examine the consequences on our API. 20:22:14 stefanh: Capabilities could be used for fingerprinting. 20:22:38 ekr: I'd like the chairs to schedule time to discuss fingerprinting. We're running into it everywhere. 20:22:42 martin: +1 to that 20:22:44 +1 20:22:48 also +1 20:23:05 +1 from juberti 20:23:07 +1 to EKR doing an intro to inform the discussion 20:23:17 [we discussed it somewhat back in Mountain view IIRC] 20:23:18 stefanh: Those are the items for discussions 20:23:20 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 stefanh: Martin, perhaps you could provide additional insight on these. 20:23:50 [we could also arrange a meeting with people from the Privacy Interest Group if that's useful] 20:23:57 martin: I think we already addressed duped tracks. 20:24:21 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 martin: Splitting SDP between PC and MS. 20:24:58 ekr: I think the cert stuff sounds reasonable 20:25:13 martin: Splitting streams from transport, we still want to deal with that 20:25:37 martin: programmatic description of streams before they are created (i.e. introspect SDP) 20:25:47 hta: What is the problem you are trying to solve? 20:26:04 martin: Want to make sure I don't lose capabilities in mid-session. 20:26:41 martin: Want to let user know, prior to acting on anything, that the remote side has multiple video streams 20:26:48 stefanh: Thank you for the input. 20:26:52 hta: Anything to add?> 20:27:03 hta: Nothing more to add. 20:27:12 Topic: States in PeerConnection 20:27:12 stefanh: Next topic, states. 20:27:41 [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 just screenshare into IRC 20:28:39 scribe stefanh 20:28:47 ScribeNick: stefanh 20:29:11 (Justin looking for document) 20:29:22 re: fingerprinting, the high order bit seems to be whether it's already a lost cause 20:29:55 - +1.215.681.aapp 20:30:06 https://docs.google.com/document/d/1iTpbMCD9QI7gCLlnhXq7T8P-zT-r982JLZcRyyvo55w/edit 20:30:16 + +1.215.681.aaqq 20:30:47 blank here 20:31:14 -> http://lists.w3.org/Archives/Public/public-webrtc/2012Sep/att-0097/WebRTCstatesandcallbacks.pdf ICE States 20:31:15 works for me 20:31:15 sep 10 20:31:23 "PHone call about ICE states" 20:32:00 Justin: doc contains Peer states and ICE states 20:32:13 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 total state an aggregation of those two 20:33:02 ...compared to previous desc: actual state for candidates orthogonal to peer state 20:33:22 q+ 20:33:24 +matthew 20:33:24 ...can be in gathering state while starting, connecting, connectied 20:33:32 I take it bz would like the internet to stop working for firefox user? 20:33:36 q+ matthew 20:33:49 why does zakim wonder where i am, i wonder 20:34:03 ...typical progressing starting, getting candidates, checking, valid pairs, connected, 20:34:16 Ekr: valid pair for every stream? 20:34:23 q- 20:34:27 Justing: talking for a specific component 20:34:35 what a strange user interface. ok. 20:34:53 ....should anything go wrong -> failed state, restart can be triggered by app 20:35:18 if only there were some sort of technology that allowed for user interfaces to be exposed to generic "browsers" 20:35:18 ....same if in connected, getting time out, ->disconnected state 20:35:27 ...finally closed state. 20:35:35 ...then aggregation part 20:36:00 ...checking: any component being checked 20:36:09 ...connected: all components working 20:36:25 ....some more which scribe missed. 20:36:35 ....callbacks indicating changes 20:37:01 q+ 20:37:11 q+ 20:37:13 .....discussed in phone call last week: per stream ice state machine 20:37:14 q? 20:37:20 q+ 20:37:44 Matthew: why is all this necessary? 20:37:48 ack matthew 20:38:07 Justin: use case where the app needs to know 20:38:34 Matthew: you could just expose primitives....no diagrams needed. 20:38:41 -ekr 20:38:51 ....message I sent on Aug 27 20:39:05 Justin: this assumes we do ICE machine in browser. 20:39:10 -> http://lists.w3.org/Archives/Public/public-webrtc/2012Aug/0193.html Matthew suggesting not having an ICE machine 20:39:17 +hta 20:39:26 q+ 20:39:27 +ekr 20:39:35 q? 20:39:41 Wow, I made it back in time 20:39:51 (scribe missed a part of what Matthew said) 20:40:13 Matthew: this is going to fall back to the IETF side 20:40:41 ...interoperability, cycle around, change API 20:40:46 -q 20:41:10 Justin: on the other hand we can have this API in the browser quite soon 20:42:00 Matthew: the question is if we're going to design a flexible API or a solid one 20:42:10 ....for the interop cases 20:42:51 Justin: are there use cases that need interop with non-ICE end-points? 20:43:15 Ekr: don't understand Matthew? What we do will interop with ICE. 20:43:43 q? 20:44:09 Ekr: I'm happy to listen to Matthew or talk (talk) 20:44:40 ...question: state for each component, and a global state, right? 20:44:51 ...how do I find the state for each comp? 20:44:56 q? 20:44:59 ack ekr 20:45:01 ack martin 20:45:03 Justin: yo dont, only global state 20:45:19 Martin: why not only expose success and fail? 20:45:42 Justing: some things you can do with more info (info to user and so on). 20:45:53 s/Justing/Justin/ 20:46:18 Martin: why not go the whole way: broken, working, or in-between 20:46:51 Martin: not-working, working, in-progress 20:47:16 Justin: there are differences between disconnected and failed' 20:47:50 ...low cost having more states 20:48:06 Martin: can't send an offer unless completed? 20:48:17 Justin: you can always send a new offer. 20:48:38 Martin: unnecessarly restrictive, we should discuss more 20:49:03 q- 20:49:14 ...what uses are seen for the in-between states. Not clear what use-cases that drive them. 20:49:31 Justin: let's discuss more. 20:49:58 Fluffy: q for chairs: ICE in browser or not is not on the agenda. 20:50:33 q+ 20:50:42 ack fluffy 20:50:42 ...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 ...in the same way as gathering is separable, checking is also separatble, collapse into the same state. 20:51:58 Justin: May be collapsed, need to think a bit more. 20:52:22 Fluffy: the only that moves you into checking is setRemote. 20:52:38 ack hta 20:53:16 hta: two points: one important difference is that you can ignore all states if you want a simple app 20:53:35 ...second point: many people on the call, give room to others. 20:53:56 Ekr: Not sure I understand Fluffys points. 20:55:11 Fluffy: I think the enum thing - we could only event, but would like to be able to check state 20:55:14 +1 to having state exposed via an enumeration 20:55:31 Ekr: would like a consistent model. enums or callbacks. 20:55:42 as long as both are the same 20:56:02 ....merging starting and checking: I don't like that 20:56:13 ...would not like to merge them. 20:56:31 ...having to remember seems not like the right thing. 20:56:46 Justin: agree on the gathering part. 20:57:08 q? 20:57:13 ack ekr 20:57:15 for later consideration, how does this interact with something like the ice mobility stuff? 20:57:41 Justin: don't have much more right now. 20:58:08 ....how to expose per component state can be discussed next. 20:58:49 hta: seems to me that we have two separate comments. One: this is the wrong approach, the other: this seems reasonable. 20:59:28 ....seems reasonable to accept this as first draft, and that we ask editors to start editing it into the spec. 20:59:57 Fluffy: we have time, can resolve some tweaks now. But agree overall. 21:00:06 Ekr: agree to Fluffy. 21:00:16 ...some making a list? 21:00:30 merging states that are driven by application actions (Starting > Checking) 21:00:31 q+ 21:00:37 adding status for gathering 21:01:00 Fluffy: enums vs callbacks 21:01:19 +1 to ekr as a general design 21:01:23 q+ 21:01:28 Ekr: enums that reflct state, events that reflects changes 21:01:38 ...is what we should go with. 21:01:54 Fluffy: agree, and is what develpers are used to 21:02:10 q+ 21:02:24 +1 to ekr 21:02:26 ack ekr 21:02:37 Justin: we may end up with some extra gathering info state 21:03:13 Fluffy: agree with enums + events for changes; seems like consensus 21:03:35 Martin: on-icechange does not seem approp. 21:03:44 ....sorry made a mistake 21:04:00 q- 21:04:02 Justin clarified 21:04:03 good 21:04:15 ack fluffy 21:04:15 So will add an enum that indicates the state of gathering. Will have some callback that indicates when this changes. 21:04:39 You should use the new WebIDL stuff for callbacks. "Function?" is very old-fashioned. 21:04:41 hta: Justin: do you haveinfo enough to change the prop and send out? 21:04:50 -ekr 21:04:54 Justin: yes (some details missed) 21:05:20 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 +1 to Adam, these aren't callbacks, you have event handlers (that take Event arguments) 21:05:25 Adam: for the record: event+event-listeners - not callbacks 21:05:27 +ekr 21:05:30 +1 to adambe 21:05:32 q+ 21:05:46 hta: you mean http://html5labs.com/cu-rtc-web/cu-rtc-web.htm ? 21:05:56