When Viewer progress and first-frame confirmations are delayed, an already connected P2P candidate can be discarded at the five-second scheduling boundary if another candidate is available. This can turn a working initial connection into another connection attempt.
Host and relay parents now report transport progress through the existing room router. The router checks the exact participant/session, revision and connection; only the candidate Viewer can confirm first-frame readiness. The total operation deadline and the routing algorithm are unchanged. Browser and Native senders use their existing prepared-child owners, and discarded preparations cannot report progress.
The loopback benchmark now identifies Peer and SFU connections from room signaling, excluding local codec probes and encoding-pool transports from media-edge counts. Its optional old Viewer-only quality canary remains unsuitable for the current sender-owned quality contract and is recorded in TODO.
Validation:
- `npm run check`: type checks, 1,000 tests and production Web build passed.
- `npm run check:go-core`: formatting, Go tests, vet and supported Windows/Linux builds passed; Darwin capture remains a native-runner check.
- Documentation and project-state checks passed.
- Released v1.5.0 versus this candidate, delaying Viewer transport/ready feedback by six seconds: the old candidate connection closed after the scheduling boundary despite 79 decoded frames; the fixed connection stayed intact. Browser Host, Native Host and relay-parent paths were exercised, with another Viewer continuing to play.
- Three-Viewer loopback topology and relay-departure recovery passed; Host and relay copy limits remained valid.
- Actual App public-link signaling, with isolated 1/8/20-second packet loss on one Browser Viewer: playback recovered in all three cases and the control Viewer continued. Every test process, port and isolated profile was cleaned up.
The original reporter's browser/network and paired diagnostics are unavailable. These bounded tests establish the repaired mechanism, not the cause of every brief connection or a representative NAT success rate.
## Release notes
### 中文
这是一次连接稳定性修复，改善进入房间时的 P2P 连接过程。
- 修复观众的连接确认反馈较慢时，已接通的线路可能被提前拆除，造成重复连接或延迟出画的问题。修复覆盖 App 分享、浏览器分享和观众中继。
- 使用 App 公网邀请或本地模式时，房主更新 App 后重新分享即可。使用已部署站点时，请管理员更新 Server，并刷新页面。
### English
This patch improves P2P connection stability when joining a room.
- Fixed an established connection being discarded prematurely when Viewer confirmations arrive late, causing repeated connection attempts or delayed playback. The fix covers App sharing, browser sharing and Viewer relays.
- For App public invitations or Local mode, the Host should update the App and start sharing again. For a deployed site, update the Server and refresh the page.
AAA
083c9273a7