Closed daniel-abramov closed 1 year ago
One of the reasons why this happens is if there is a video that is muted.
There are possible mitigations for this warning, see: https://github.com/matrix-org/waterfall/pull/137#issue-1596834950
After running it with the OpenTelemetry, so far it looks like these happened in two cases for video tracks only:
@SimonBrandner, do you remember if the Element Call sends the metadata update requests whenever the video gets muted/unmuted? - If it does, we could detect when the track is muted on the SFU side not to trigger false positives for the case (1). If we do so, we can use (2) as a hint that no RTP packets are received and automatically switch the quality to the lower layer preserving the video.
UPD: We receive the update of the metadata when muting/unmuting.
After several sessions with OpenTelemetry it has become clear that these are caused by the browser not publishing higher levels (1) and videos being muted (2).
(2) was addressed by a PR. (1) can't be solved (Pion informs us about tracks, but there is no guarantee that we'll get RTP packets).
See https://github.com/matrix-org/waterfall/issues/131 for the related issue of missing RTP packets.
A log line like this one is not uncommon during normal sessions:
It's not clear why there is an active subscription (with a low layer) that, despite being published, does not receive RTP frames with an intact publisher track. When the publisher track is gone, we remove all subscriptions associated with this track (check if we don't miss any edge cases).
It does not seem like this error has a big practical application (we did not observe any frozen subscription), yet it may point out to some bug in the SFU that must be resolved.