Hacktoberfest 2026：维护者为十月标记出来的 issue，仍然开放、适合新手。 浏览 Hacktoberfest issue

[bug] Track published via SDP renegotiation never forwarded to subscribers — server OnTrack doesn't fire, publish times out at 30s (self-hosted)

未关闭
  • 哪里不对？
#1,104 3 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

维护者通常 1 天内回复

还没有人认领这个 Issue。

评估

难度
4/5
预计耗时
3-5 天
新手友好度
35/100
Issue 类型
缺陷
描述清晰度
基本清楚
活跃度
冷清
技术栈
flutter
领域
audio-video-rtc, mobile-dev

调研方向

Start by tracing the SDK's BroadcastManager listener and the screen-share publish flow around setScreenShareEnabled, then compare the client logs and SDP offer/answer with the server's 30-second supervisor timeout. Use the supplied forensic logs and SDP to determine why the server does not forward the track to subscribers; done means identifying a reproducible cause or a confirmed workaround.

由索引模型根据 Issue 内容生成。

描述

Versions

  • livekit_client (Dart): 2.7.0
  • flutter_webrtc: 1.4.0 (libwebrtc m144)
  • livekit-server (self-hosted): 1.11.0 (also reproduced on 1.10.0)
  • Flutter: 3.41.4
  • iOS: 18.2 and 26.0 (both repro)
  • Devices: iPhone 13, iPhone 15 Pro, iPad mini 6
  • Topology: multi-PC (default, not single-PC mode)

What happens

  1. Host connects to Room, publishes camera + mic (initial offer). Works.

  2. Host taps "Share screen" → our native bridge presents RPSystemBroadcastPickerView → user taps Start Broadcast.

  3. iOS Broadcast Upload Extension starts pushing CMSampleBuffers via the Unix socket in the App Group container.

  4. SDK's BroadcastManager fires isBroadcasting=true. Our Dart code does NOT call setScreenShareEnabled(true) — we rely on SDK auto-publish (after removing our manual call, a race condition was resolved in a prior diagnostic loop).

    Room is configured with:

   RoomOptions(
     defaultScreenShareCaptureOptions: ScreenShareCaptureOptions(
       useiOSBroadcastExtension: true,
     ),
   )
  1. Client logs LocalTrackPublishedEvent for screenShareVideo — SDK side believes publish succeeded.
  2. Server side: receives SDP renegotiation (offer/answer pair completes cleanly, NO unhandled RTP, NO ICE errors, mid=3 video VP8 with simulcast layers q;h).
  3. Exactly 30s later: server fires publish time out from the supervisor (SetMaxSubscribedQuality + supervisor state machine). Track removed server-side. Viewer NEVER receives TrackSubscribed for screenShareVideo.

Confirmed NOT the cause

  • Network: UDP 50000-60000 open server-side; camera/mic over the same path work flawlessly.
  • ICE: candidates exchanged, transport stays connected.
  • SDP renegotiation: completes successfully on both sides.
  • Codec: VP8 (also tried H.264 via Room options) — same outcome.
  • Simulcast: reproduces with 1 layer too (manually reduced via defaultVideoPublishOptions).
  • Race condition with our bridge: a prior loop removed our manual setScreenShareEnabled call; SDK auto-publishes via its own BroadcastManager listener. Bug persists.
  • Identity / token permissions: subscriber token has wildcard subscribe permission; server logs show no permission denial.
  • Server version: reproduces identically on 1.10.0 and 1.11.0.

Suspected pattern

This matches webrtc-rs PR #750 ("Handle receiver reuse during renegotiation") in behavior — active receivers (camera) appear to cause the new transceiver for screen share to be marked NOT HANDLED. Is there an equivalent fix in pion-go currently shipping with livekit-server? Or in the SDK's add-track flow?

Questions

  1. Is this a known issue with publishing a 2nd video track via renegotiation while another video track is active in the same Room?
  2. Is singlePeerConnection mode planned for client-sdk-flutter? The Swift SDK exposes it (2.13.0+); we suspect single-PC mode would bypass this entirely.
  3. Is there a recommended workaround (e.g. pre-allocating transceivers at connect time, publish-order tricks, dynacast off, dummy track pre-publish)?
  4. Is there a way to disable the supervisor's hardcoded 30s publish timeout server-side while we diagnose?

Forensic data available on request

  • Full SDP offer + answer of the failing renegotiation
  • Timestamped client logs (both host and viewer side)
  • Server logs at debug level showing the 30s supervisor timeout
  • Confirmation of zero unhandled RTP packets during the broadcast window

Happy to share via secure channel or attach to this issue.

Impact

This blocks shipping screen share in our production live streaming application. We are not in a position to migrate to LiveKit Cloud or rewrite the host to Swift SDK. Looking for a workaround or fix timeline guidance.

Thanks!

主要语言
Dart
星标
421
派生
260
平均合并
2 天 11 小时
30 天内合并 PR
21

环境准备

这个项目没有提供开发容器、Dockerfile 或贡献指南，环境需要你自己搭建：先看它的 README，通用步骤见我们的新手贡献指南。

从这里开始

  1. 先读完整个 Issue，再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库，在一个分支上完成修改。
  4. 提交 Pull Request，并在描述里引用这个 Issue 编号。

livekit/client-sdk-flutter 的其他 Issue

查看 livekit/client-sdk-flutter 的全部 Issue

相似的 Issue

更多 Dart Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。