David Baker

> @dbkr The subscriber side's traffic looks like ice-lite that only response to the client but no request sent, do you enable it in sfu? I do see it sending...

Ah, that makes sense about ICE lite. We've just re-tested with debug logging enabled - here are the logs (these are filtered for lines that just contain the failing participant's...

Thanks for the new build with trace logging enabled - here's a log from it: [tracelogs-redacted.log](https://github.com/livekit/livekit/files/12578904/tracelogs-redacted.log) at first glance I don't see much more though, other than a few lines...

Oh, we were setting the pion level to trace so that would be why! Here goes: [tracelogs2.log](https://github.com/livekit/livekit/files/12589254/tracelogs2.log) I see pion transport logs in there now!

Huh, I guess something must have gone wrong with my building of the binary. Either way, here's a log from a fresh binary. This is also a different instance and...

Another development: we tried with ice-lite enabled out of curiosity and this works! Seems like it must be some bug in pion ice controlling that's triggered in certain network conditions....

Update: it's now also failed in exactly the same way with ice-lite enabled, so perhaps it is less frequent with ice-lite but does still happen.

Fair enough, I'll leave it as a draft until then.

This has just flaked for me (kicking my js-sdk PR out of the merge queue) and accordingly has reached its two strikes. Failure: https://github.com/matrix-org/matrix-js-sdk/actions/runs/6706755472/job/18223868253

This seems to be causing a read receipts test to not request a read marker which is a distinctly non-obvious and subtle failure mode...