Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

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

Đang mở
  • Có gì không ổn?
#1,104 3 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

Chưa có ai nhận issue này.

Đánh giá

Độ khó
4/5
Thời gian dự kiến
3-5 ngày
Mức phù hợp với người mới
35/100
Loại issue
Lỗi
Độ rõ ràng
Khá rõ ràng
Mức độ hoạt động
Ít trao đổi
Công nghệ
flutter
Lĩnh vực
audio-video-rtc, mobile-dev

Hướng nghiên cứu

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.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

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!

Ngôn ngữ chính
Dart
Star
421
Fork
260
Merge trung bình
2 ngày 11 giờ
Pull request đã merge (30 ngày)
21

Chuẩn bị môi trường

Dự án này không cung cấp dev container, Dockerfile hay hướng dẫn đóng góp, nên bạn cần tự thiết lập môi trường: hãy bắt đầu từ README và xem hướng dẫn đóng góp lần đầu của chúng tôi để biết các bước chung.

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của livekit/client-sdk-flutter

Tất cả issue của livekit/client-sdk-flutter

Issue tương tự

Thêm issue về Dart

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.