IRC log of webrtc on 2016-02-25

Timestamps are in UTC.

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