21:00:00 RRSAgent has joined #webrtc 21:00:00 logging to http://www.w3.org/2016/02/25-webrtc-irc 21:00:10 RRSAgent, make logs public 21:00:40 Meeting: WebRTC Virtual Interim 21:00:43 stefanh has joined #webrtc 21:01:10 Slides: https://docs.google.com/presentation/d/1R7lQeo4LNGu0KKW9GLdkwJ5x8FUmR4qrnhfPFZO3WS8 21:01:19 Agenda: https://www.w3.org/2011/04/webrtc/wiki/February_25_2016 21:02:08 Present+ AdamBe, AdamR, Alan, BernardA, DanD, DanB, Emil, Erik, HTA, Taylor, PeterT, Cullen, Roamn, Stefan, Varun, Vivien, Dom 21:02:17 Present+ MathieuH 21:03:29 hta has joined #webrtc 21:03:51 jib has joined #webrtc 21:03:51 mreavy has joined #webrtc 21:05:03 Shijun_Sun has joined #webrtc 21:05:34 Present+ JanIvar 21:05:41 Present+ Randell 21:05:54 Present+ ShijunSun 21:06:44 ScribeNick: burn 21:06:44 scribe: burn 21:07:06 erik: believe the agenda is complete as agreed previously 21:07:13 Present+ AlexandreG 21:07:32 Present+ JustinU 21:07:34 ... anything need to be added? 21:07:43 ... (nothing) 21:07:53 https://github.com/w3c/webrtc-pc/issues/296 21:07:57 Dr_Alex has joined #webrtc 21:08:19 Topic: Debugging ICE problems needs more info #296 21:08:26 bernard: (summarizes what's on slide) 21:08:34 -> https://github.com/w3c/webrtc-pc/issues/296 Debugging ICE problems needs more info #296 21:09:00 ... (summarizes what we have in stats as well) 21:09:21 ... differences between attributes and types. should we clean up? 21:09:40 justin: yes, would be nice. would prefer changing in stats. 21:09:56 bernard: do we even need them in stats since they are in candidates? 21:10:13 hta: with ice candidate it is gone after being used, but stats remain 21:10:23 cullen: stats are also atomic time, so you need both 21:10:34 bernard: agreement on cleaning up? 21:10:45 jib: FF already implements stats. 21:11:07 Present+ Varun 21:11:10 justin: best would be to look at who's implemented what to figure out where to make changes. 21:11:27 cullen: actually, which is used more would be better. but let's clean up 21:11:44 bernard: there appears to be consensus to clean up. 21:11:56 adambe: would that include aligning types as well? 21:12:04 justin: not as critical 21:12:23 bernard: moving on to RTCIceCandidatePairStats 21:12:35 summary we agreed to alight names and types and decide which one change by looking at least use in github 21:13:13 asinlamasplural has joined #webrtc 21:13:42 hta: on roundtrip time, would think min would be most useful 21:14:36 roman: for debugging, want over a period over time rather than max for session. usually want min, max, avg, others but that's too much. 21:14:43 justin: can't JS figure this out? 21:14:59 roman: need a histogram 21:15:11 justin: could be computed by polling 21:15:17 roman: not if you just get max. 21:15:39 hta: summing roundtrip times would work. could compute average. 21:15:54 bernard: what about consent request/response? 21:16:00 roman: yes, we need this. 21:16:07 hta: responses received are most important 21:16:27 justin: understand sent and responses received, what about converse? 21:16:45 varun has joined #webrtc 21:16:48 hta: maybe to detect whether other party is doing consent checks 21:17:03 present+ Emil 21:17:18 cullen: it's useful to know what you received from other side. helps in debugging one-way packet loss. 21:18:00 bernard; want roundtrip sum, responses received 21:18:40 s/bernard;/bernard:/ 21:18:55 (missed justin's question) 21:19:22 justin: are retransmits counted as independent sends? 21:19:26 bernard: good point 21:20:03 justin: want to figure out overall loss rate on consent checks. you would transmit with new id 21:20:27 bernard: understand role retransmits play 21:20:41 not using: https://tools.ietf.org/html/draft-ietf-tram-stun-path-data-03#section-3? 21:21:28 bernard: on icecandidateerror codes. should we have connectivity check errors, and should there be counters in the stats? 21:21:53 justin: this would be different from icecandidateerror, since the former is only for gathering 21:22:21 bernard: we don't care enough about connectivity errors to do this. 21:22:35 justin: would need some code indicating why it went to a failed state. 21:22:55 bernard: we have failure, but no code. we have a state that can include failed. 21:23:20 bernard: does anyone else think this matters? 21:23:48 justin: would need these codes plus others codes for timeout and icmp error 21:24:04 ... ICMP would happen on invalid address 21:24:18 adamR: how do we catch this without a connectivity check? 21:24:38 roman: how wolud you even get ICMP 21:24:49 justin: as -1 code in receive from 21:25:09 bernard: should we add this error code? 21:25:24 justin: no one cares. we haven't seen requests for this. 21:25:37 ... or use cases 21:26:31 bernard: not hearing strong support for this. 21:26:45 ... what about counters in the stats? needed? 21:26:56 ... could have counters for gathering errors 21:27:07 justin: count them yourself :) 21:27:18 bernard: will pass on both of these. 21:27:28 stefan: are these codes defined anywhere? 21:27:44 bernard: yes, in the IANA registry. we could add a reference. 21:27:59 hta: yes, we should list the codes with a reference to the registry. 21:28:27 bernard: moving on to checklist state slide. do we want to introduce a checklist state? 21:28:40 justin: depends on what we do with end of candidates later in the meeting. 21:28:47 bernard: will postpone until then 21:28:56 https://github.com/w3c/webrtc-pc/issues/457 21:29:05 Topic: Issue 457: Non-normative ICE state transitions 21:29:19 bernard: now on issue 457 slide. 21:29:35 -> https://github.com/w3c/webrtc-pc/issues/457 Non-normative ICE state transition diagram #457 21:30:43 bernard: no state transition diagram for transports. just to let folks know. 21:31:11 taylor: need to clarify. will talk about a more granular transport state later. 21:31:53 Topic: Timing of ICE gathering 21:31:57 adam: issue 332 21:32:04 -> https://github.com/w3c/webrtc-pc/issues/332 Timing of ICE gathering #332 21:32:44 ... (summarizing slide) proposed solution in PR 510 21:33:20 ... 510 is merged, 515 has fixes (not merged yet) 21:33:32 cullen: ice agent iniatilzed when PC is created? 21:33:37 adambe: yes 21:34:06 ... encourage all of you to review 21:34:34 justin: if candidate pool size is zero, gathering doesn't start until later 21:34:52 hta: need to start gathering if you call setConfiguration and pool size > 0 21:35:18 (missed 2-candidate assumption question) 21:35:38 s/Topic: Timing/Topic: Issue 332: Timing/ 21:35:56 erik: do we need more time/discussion on this? 21:36:11 (general agreement with text including 515) 21:36:28 ScribeNick: dom 21:36:32 Topic: Issue 442 21:36:51 Taylor: a bit of background based on the previous interim 21:36:57 s/442/442: Impossible to know if ICE agent is “finished” checking/ 21:37:02 https://github.com/w3c/webrtc-pc/issues/442 21:37:10 -> https://github.com/w3c/webrtc-pc/issues/442 Impossible to know if ICE agent is "finished checking", for "failed" and "completed" states. #442 21:37:13 ... [read from slide 13] 21:37:57 ... [slide 14] 21:38:20 s/(missed 2-candidate assumption question)/juberti: Where was the assumption about two candidates specified? 21:39:54 adamr: this a matter of telling your side that the other side is finished 21:40:07 taylor: does that provide value to the browser? is there a technical benefit to this? 21:40:23 cullen: while this is going on, the bandwidth/jitter estimates are all over the place 21:40:36 ... when it's done, the estimates are much more reliable; browsers could take advantage of that 21:40:54 ... not sure they do yet, but some audio systems do for sure 21:41:15 XXX: can you clarify what kind of benefits you call "technical"? 21:41:40 taylor: I'll be talking about how app developers would use this later 21:42:12 XXX: I'm not sure if that constitutes a technical benefit — the main reason this is useful is to be able to determine that it has failed 21:42:21 ... e.g. to tell users this won't work 21:42:30 s/XXX/Emil/ 21:42:35 s/XXX/Emil/g 21:42:52 ... Another case is for stats gathering 21:43:31 ... they can be done via signaling, but it seems we should not to have to duplicate it in every signaling system when trickle ICE has the info 21:44:04 JIB: it's already annoying to wait for "end-of-candidates" on your own side 21:44:42 juberti: no question about that; the question here is about the remote side 21:45:08 AdamR: being able to transition to failed sounds useful 21:45:21 Taylor: so there seems to be agreement there is value in this 21:46:12 ... [slide 17] 21:46:46 ... the idea is to delay "completed" and "failed" until both local and remote are done 21:46:56 ... this would match what's in ORTC 21:47:20 https://github.com/w3c/webrtc-pc/issues/442 21:47:28 thx 21:48:10 I have made the request to generate http://www.w3.org/2016/02/25-webrtc-minutes.html vivien 21:48:22 ... [slide 18] offers it as a different perspective 21:48:52 YYY: this looks correct to me 21:49:04 Chair: ErikL, Harald, Stefan 21:49:10 Cullen: this is probably what we thought we would get originally 21:49:16 HTA: so this is a bug fix; this sounds good to me 21:49:42 JIB: what happens if @@@? 21:50:02 AdamR: this means we would never a transition to "failed" 21:50:09 DanB: or "connected" for that matter 21:51:04 Taylor: that's indeed a breaking change; but any way we solve this will lead to such a change 21:51:08 AdamR: unless we use a timer 21:51:13 Taylor: but I'd like to avoid that 21:51:24 AdamR: I think Option A is probably OK 21:51:41 Taylor: we received feedback from app developers, and they seemed OK with updating their app 21:52:06 Erik: any objection to this? 21:52:21 Emil: it would be good to reflect that disconnected is transient while failed is permanent 21:52:35 Taylor: we'll make sure to reflect that in the PR 21:52:40 Varun: there is no "closed" anymore ? 21:52:52 Taylor: no, I've omitted "new" and "closed" since they've not changed 21:53:14 Juberti: I think this is mostly formalizing things we already thought we had 21:53:26 Bernard: these are the same state transitions as ORTC FWIW 21:53:35 Erik: sounds like we have consensus; Taylor, can you create a PR? 21:53:37 Taylor: will do 21:54:01 Bernard: would the transition be the same for the ICE Transport in addition to the ICE Agent? 21:54:18 Taylor: yes 21:54:35 Erik: please summarize the PR on the list when you submit it 21:54:58 Taylor: [slide 19] 21:56:05 ... one possibility is to use a null value to signal end of gathering (in parallel to onicecandidate) 21:56:27 Taylor: Option B was in case nobody cared about "completed" and "failed" 21:56:45 Juberti: we didn't find many people interested in these states when we asked 21:56:55 ZZZ: that may be because they didn't work :) 21:57:48 s/ZZZ/HTA/ 21:58:19 Juberti: still, the use cases for these states aren't exactly clear 21:58:36 ... the jitter/etc estimates are purely internal 21:58:54 Emil: I think stats is a good argument 21:59:12 Cullen: I think with either approach, you get the same stats 21:59:36 Varun: actually, if you're not on the signaling path, detecting "failed" matters quite a bit 21:59:42 ... I don't care much about "completed" 22:00:27 Taylor: if people see value in the "failed" state, there is not much cost to having "completed" 22:00:57 cullen: the current situation is annoying, where you don't necessarily go to "failed" or "completed" 22:01:10 ... either of this approach fixes that problem, which is good 22:01:19 ... I don't feel strongly between the two options 22:01:31 HTA: sounds like moderate amount of consensus with option A, so let's go with that 22:01:55 Bernard: an argument in favor of option A is that it converges us with Option A, so that's nice 22:02:33 Taylor: there is a small difference with ORTC in the case of checking when disconnected 22:02:43 ... but we can discuss that alter 22:02:58 s/Option A,/ORTC,/ 22:03:32 ... We need to go back to the state diagram discussion 22:03:35 s/alter/later/ 22:04:01 [back to slide 11] 22:04:27 Taylor: I would like to propose that the ICE Agent state be defined in terms of the ICE transports state 22:04:47 s/of the ICE/of the aggregation of the ICE/ 22:04:53 ... with a clear algorithm 22:04:57 ... I can write a PR for that 22:05:07 [many +1] 22:06:05 DanB: let's look at the API question since we have extra time 22:06:30 Taylor: right now we only signal gathering is done for all media sections 22:06:50 ... unless we change that, we should not have to look at the media component level 22:07:05 Emil: I don't think there would be much value in that in any case 22:07:19 ... if one m-line fails, we fail the entire agent 22:08:23 Cullen: the only other API I can imagine is that the JSON object we return has some null values 22:08:55 ... which probably means less code change 22:09:29 ... i.e. a candidate that says "end-of-candidate" 22:10:16 emil: but that would still break some code that expects null for local ice candidate 22:10:47 adamr: most apps don't care about that; we should not over-engineer a backwards compatible solution 22:11:20 cullen: I'll go with the solution on the slide 22:11:25 [consensus to go with that] 22:11:54 mreavy has left #webrtc 22:12:00 [end of meeting] 22:12:02 RRSAgent, draft minutes 22:12:02 I have made the request to generate http://www.w3.org/2016/02/25-webrtc-minutes.html dom 22:15:02 stefanh has left #webrtc 22:55:39 asinlamasplural has joined #webrtc