[v0.20.5] Excessive warning log spam: "Cannot find RTP history" and "IsSendable(): Invalid state: Disconnected"

[varohso]

Environment

OME Version: v0.20.5 (Docker image)
Role: Edge (1:N WebRTC streaming)
Scale: ~150 edge nodes
Comparison: v0.16.8 edges running the same workload do NOT produce these warnings

Problem

Two warning messages are flooding the logs at an extremely high rate on v0.20.5 edge servers.

1. RTP history lookup failure (rtc_bandwidth_estimator.cpp:173)

[2026-04-10 13:26:41.645] W [SW-WebRTC:481] WebRTC Publisher | rtc_bandwidth_estimator.cpp:173 | Cannot find RTP history for wide_seq_no(13045)
[2026-04-10 13:26:41.645] W [SW-WebRTC:481] WebRTC Publisher | rtc_bandwidth_estimator.cpp:173 | Cannot find RTP history for wide_seq_no(13046)
[2026-04-10 13:26:41.645] W [SW-WebRTC:481] WebRTC Publisher | rtc_bandwidth_estimator.cpp:173 | Cannot find RTP history for wide_seq_no(13047)

...
Consecutive sequence numbers are missing from the history, suggesting the buffer may be undersized or packets are expiring before TransportCC feedback arrives.

2. Disconnected socket send attempts (socket.cpp:1142)
   [2026-04-10 13:26:44.059] W [SW-WebRTC:475] Socket | socket.cpp:1142 | [#140] [0x7f074a4b7710] IsSendable(): Invalid state: Disconnected (expected: == SocketState::Connected) - <ClientSocket: 0x7f074a4b7710, #140, Disconnected, TCP, Nonblocking, 162.120.194.154:32575>
   This repeats hundreds of times per second for a single disconnected client, indicating the session is not being cleaned up after socket disconnect.

Impact

Log volume is extremely high, causing disk I/O pressure
Potential CPU waste from repeated send attempts to disconnected sockets
May affect streaming performance on busy edge nodes
Expected behavior
RTP history buffer should be large enough to handle normal TransportCC feedback latency
Disconnected sockets should trigger session cleanup promptly, stopping further send attempts

Follow-up questions

We're running an A/B test with many edges on v0.16.8 and ~n edges on v0.20.5 under the same workload. These warnings only appear on v0.20.5 edges.

Regarding the IsSendable(): Disconnected spam
The same socket produces dozens of warnings within a single millisecond, which seems like the media sending thread keeps attempting to push packets to a session whose socket is already disconnected.

Could this be a race condition where the disconnect event doesn't propagate to the sending thread in time, causing the session to remain active indefinitely after socket disconnect?
Was there a change in session lifecycle management between v0.16.8 and v0.20.5 that might explain this?
Regarding Cannot find RTP history for wide_seq_no
The missing sequence numbers are consecutive (13045, 13046, 13047...), suggesting a batch of packets is missing from the history rather than sporadic losses.

Is it possible that this is a cascading effect of the disconnected socket issue above — i.e., TransportCC feedback arriving for a session that's in a broken state?
Or is the RTP history buffer size insufficient for certain network latency conditions?
Any guidance on configuration options to mitigate these in the meantime would also be appreciated.

[getroot]

Thank you for reporting this issue.

While I wasn't able to review the actual log files or Server.xml configuration, based on the information you provided, I believe this can occur when a slow client connects via WebRTC/TCP. I was able to reproduce the excessive log output by simulating a slow client connection, and have submitted a fix in #2072. If you're able to test with this patch, it would be great to get your confirmation that it resolves the issue.

Also, I want to mention that this issue very likely existed in v0.16.8 as well. I spent a significant amount of effort comparing the two versions and found no changes at the WebRTC ICE port level between them. The difference you experienced could be due to different OvenMediaEngine configuration, different kernel tuning, or simply different network conditions of the connecting viewers.

By the way, you mentioned running around 150 Edge servers, which is really impressive and very interesting to us. We'd love to learn more about your service and how you're using OvenMediaEngine at that scale. Understanding real world deployments like yours is incredibly valuable for guiding the project's direction. If you're open to sharing some details, that would be wonderful. And if you'd prefer to keep things private, feel free to reach out to us at support@ovenmedialabs.com. We'd be happy to explore ways to collaborate more closely with your team.