ICE processing unfreezes streams too aggressively

NEW
Unassigned

Status

()

P4
normal
Rank:
35
5 years ago
11 months ago

People

(Reporter: abr, Unassigned)

Tracking

Other Branch
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

5 years ago
Currently, when we unfreeze the pairs associated with a stream/foundation (see nr_ice_media_stream_unfreeze_pairs_foundation in ice_media_stream.c), we don't wait for the current stream to have a valid pair before unfreezing the remaining streams. Basically, we need to make sure that invalid_comps is 0 before continuing on to the other streams.

We also need to be careful, when counting invalid components, that we exclude any that have been disabled.
what's the practical impact of this?
backlog: --- → webRTC+
Rank: 35
Flags: needinfo?(adam)
Priority: -- → P3

Comment 2

3 years ago
I'm not sure if this is going to cause any harm in the end, but the behavior is incorrect.
(Reporter)

Comment 3

3 years ago
I don't have enough of ICE left in my head to be able to unpack the full ramifications here (I thought I might have time to research it and say for certain, but that hasn't happened, and I'm going to be out of the office again starting tomorrow).

The basic issue is that we're out of spec. Given the timing considerations in ICE, this might contribute to a higher-than-expected failure rate under certain circumstances.
Flags: needinfo?(adam)
Mass change P3->P4 to align with new Mozilla triage process.
Priority: P3 → P4
You need to log in before you can comment on or make changes to this bug.