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