bwc, drno: any idea what's up here?
Component: WebRTC → WebRTC: Signaling
The test failure complains that the RTCP stats don't reflect reality. PC_LOCAL got connected only via a peer reflexive candidate, because according to the logs the ICE checks were quicker then the signaling. So when the signaling tries to add the ICE candidates they get rejected with: tried to trickle ICE in inappropriate state 4 (= ICE completed) And that seems to result in no candidate pair showing up in the RTCP stats, which throws off the PC_LOCAL_CHECK_ICE_CONNECTION_TYPE and PC_LOCAL_CHECK_ICE_CONNECTIONS checks in the test. Interestingly at the same time PC_LOCAL's RTCP seems to be missing an inbound RTCP stream. Not sure if that is related, or just coincidence (because it simply hasn't received any RTCP from PC_REMOTE yet). Now we could try to make the CHECK_ICE_CONNECTION_TYPE and CHECK_ICE_CONNECTIONS checks smarter so that they handle this corner case of zero ICE candidate pairs, but only a peer reflexive candidate in the stats. But I guess the better solution would be to have the pair which didn't get created through signaling show up in the stats.
I searched a little bit around in the code. I think nICEr properly creates pairs and the required stuff. So my guess is that the special pair which gets created through such a peer reflexive candidate gets dropped for some reason in the reporting code. But I haven't been able to identify the code which causes this.
Hey Nils, at this point, you know more about this bug than anyone else. Can you prioritize this?
Flags: needinfo?(docfaraday) → needinfo?(drno)
backlog: --- → webrtc/webaudio+
Priority: -- → P2
Mass change P3->P4 to align with new Mozilla triage process.
Priority: P3 → P4
Status: NEW → RESOLVED
Last Resolved: 8 months ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.