Open Bug 1298994 Opened 9 years ago Updated 3 years ago

incoming trigger checks keep resurrecting the failed clones

Categories

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

Product:
Core
Component:
WebRTC: Networking
Type:
defect

Tracking

()

Tracking Flags:
Tracking Status
firefox51 --- affected
Blocking Flags:
backlog webrtc/webaudio+

People

(Reporter: drno, Unassigned)

Details

The way we handle trigger checks results in two identical pairs getting created one in the state success and the other in the failure state. When a another STUN request comes in which could create trigger check nICEr currently always resurrects the old failed pair, and skips over the succeeded pair because there is nothing left to do. nICEr should not try to resurrect the cloned, failed pair (but still be able to resurrect if necesarry). This just delays successfully finding a working ICE connection.
backlog: --- → webrtc/webaudio+
Rank: 25
Summary: nICEr's trigger checks keep resurrecting the failed clones → incoming trigger checks keep resurrecting the failed clones
Mass change P2->P3 to align with new Mozilla triage process.
Priority: P2 → P3
I don't have the capacity any more to work on this any time soon.
Assignee: drno → nobody
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.