WebRTC Virtual Interim

25 Feb 2016



See also: IRC log


AdamBe, AdamR, Alan, BernardA, DanD, DanB, Emil, Erik, HTA, Taylor, PeterT, Cullen, Roamn, Stefan, Varun, Vivien, Dom, MathieuH, JanIvar, Randell, ShijunSun, AlexandreG, JustinU
Erik, Harald, Stefan
DanB, Dom


Slides (PDF Version)

<dom> ScribeNick: burn

erik: believe the agenda is complete as agreed previously
... anything need to be added?
... (nothing)

Issue 296: Debugging ICE problems needs more info

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

Issue 457: Non-normative ICE state transitions

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.

Issue 332: Timing of ICE gathering

Timing of ICE gathering #332

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

Issue 442: Impossible to know if ICE agent is “finished” checking & Issue 483: Signaling a=end-of-candidates

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]

Summary of Action Items

Summary of Resolutions

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.144 (CVS log)
$Date: 2016/02/26 10:02:44 $