912750 - ICE processing unfreezes streams too aggressively

Status: NEW

(Core :: WebRTC: Networking, defect, P4)

Description

[Adam Roach [:abr]]

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.

Comment 1

[Maire Reavy [:mreavy]]

what's the practical impact of this?

Comment 2

[Byron Campen [:bwc]]

I'm not sure if this is going to cause any harm in the end, but the behavior is incorrect.

Comment 3

[Adam Roach [:abr]]

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.

Comment 4

[Bulk Bug Changes for mreavy's org]

Mass change P3->P4 to align with new Mozilla triage process.