- Ya
- 26 Aprili 2026, 23:45 UTC
- Mwandishi
- kamo
- Ahadi ya
- 86f609c
WebRTC stats from a recent call showed inboundBytes=39680 / receivers unmuted / ICE pair succeeded — the bridge was delivering audio to the browser — yet the operator reported silence. That means the receiver track is fine but the <audio> element itself isn't playing it: paused, muted, volume=0, or routed to a sinkId the operator can't hear (e.g. a disconnected output device selected earlier on a different machine). The 5-second beacon now also captures audio-element state (paused / muted / volume / currentTime / sinkId / srcObject) so we can see which of those four conditions is the cause. And — defensively — if any of the three "easy" failures (paused, muted, volume===0) is observed *while* inbound bytes are flowing, the SDK self-corrects the element right then. That alone may restore audio in the field; the dump still makes it clear what the underlying mis-state was.