hi

Thanks for reaching out, hardeep. I'm an AI assistant and I'm here to help. Give me a moment while I research this topic.

[ERROR:flutter/runtime/dart_vm_initializer.cc(40)] Unhandled Exception: Unable to RTCPeerConnection:addTransceiver Error: can't addTransceiver! #0 RTCPeerConnectionNative.addTransceiver (packageflutter webrtc/src/native/rtc peerconnection impl.dart619:7) <asynchronous suspension> #1 EngineInternalMethods.createTransceiverRTCRtpSender (packagelivekit client/src/core/engine.dart1494:25) <asynchronous suspension> #2 LocalParticipant._publishAudioTrack.negotiate (packagelivekit client/src/participant/local.dart201:27) <asynchronous suspension> #3 Future.wait.<anonymous closure> (dartasync/future.dart546:21) <asynchronous suspension> #4 LocalParticipant._publishAudioTrack (packagelivekit client/src/participant/local.dart208:20) <asynchronous suspension> #5 SerialRunner.run (packagelivekit client/src/support/serial runner.dart45:14) <asynchronous suspension> #6 LocalParticipant.publishAudioTrack (packagelivekit client/src/participant/local.dart164:20) <asynchronous suspension> #7 LocalParticipant.rePublishAllTracks (packagelivekit client/src/participant/local.dart622:9) <asynchronous suspension> #8 Room._setUpEngineListeners.<anonymous closure> (packagelivekit client/src/core/room.dart526:7) <asynchronous suspension> #9 EventsListenable.on.<anonymous closure> (packagelivekit client/src/managers/event.dart181:9) <asynchronous suspension> getting this exception from livekit on reconnect.

Thanks — I see the exception you’re hitting while LiveKit tries to rePublish audio tracks after a reconnect: "Unable to RTCPeerConnection:addTransceiver Error: can't addTransceiver!" This comes from the

flutter_webrtc

layer when LiveKit calls

addTransceiver

during

rePublishAllTracks

. I’ll help you narrow this down and try options to fix it. Quick checklist — please tell me these details if you can: • Which versions are you using for

livekit_client

and

flutter_webrtc

? • Platform(s) affected (iOS, Android, web) and OS versions. • Does this happen every reconnect or only sometimes? Any pattern (e.g., after app background/foreground, after network change)? • Are you running any background service plugins such as

flutter_background_service

or others that manage lifecycle/events? • A minimal sequence that reproduces the issue (connect → disconnect → reconnect steps) or a short code snippet around how you handle reconnect/publish. What this error likely means • The WebRTC peer connection is in a state where adding a new transceiver is not allowed (for example, negotiation already pending or the peer connection hasn’t been properly reset before republishing). • Plugin interference or lifecycle/race conditions (for example, background services) can cause native WebRTC calls to fail at reconnect. Practical steps to try now 1. Update packages ◦ Make sure you are on the latest

livekit_client

and

flutter_webrtc

versions. Many native WebRTC issues are resolved in newer plugin releases. 1. Ensure clean peer-connection lifecycle on reconnect ◦ Before reconnecting, ensure previous PeerConnection is fully closed and tracks/transceivers cleaned up so

rePublishAllTracks

doesn’t try to add transceivers onto a partially-open connection. ◦ If you manually manage reconnects, wait for the engine/room to reach a clean disconnected state before calling publish/republish. 1. Avoid calling publish while negotiation is pending ◦ Ensure you do not trigger multiple parallel publishes/negotiations. Serialize publish attempts (the SDK uses a SerialRunner internally, but check your app isn’t also calling publish concurrently). 1. Check background service / lifecycle plugins ◦ If you use

flutter_background_service

or similar, try reproducing without them. Those plugins have been known to interfere with native channels and WebRTC behavior. ◦ On mobile, handle app pause/resume carefully so WebRTC isn’t manipulated while the app is backgrounding. 1. Add defensive retry ◦ If addTransceiver fails transiently, retry the publish after a short delay (and only after confirming the PeerConnection is stable). This can mitigate race conditions while you investigate root cause. If the issue persists • Share the version numbers, platform, and a short reproducible flow or snippet. With that I can suggest a more specific code-level approach (for example, how to wait for clean state before republishing, or where to add a safe retry). If you’d like, paste your pubspec versions and the sequence that triggers reconnect and I’ll propose exact checks/patches you can apply. Sources: [Flutter iOS] SoundWaveformWidget / AudioVisualizerWidget Not Working (Miss..., with interactive elements

im using livekit_client version 2.6.3 on macos. app is in foreground, app got disconnected from network for around 1 minute and then it reconnected.

Thanks — that’s helpful. You said you’re on macOS, LiveKit

2.6.3

, app in foreground, and the network dropped for ~1 minute before reconnecting. I’ll focus on that reconnect scenario and what you can try next. Quick clarifying question • Which version of

flutter_webrtc

are you using? (That matters for known native behavior fixes.) What’s likely happening • The failure comes from the native WebRTC layer when LiveKit tries to add a transceiver while republishing audio during reconnect. After a prolonged network loss, the PeerConnection can be left in a state where adding transceivers is not allowed (negotiation pending, ICE state not ready, or the connection hasn’t been fully reset). Recommended steps to try now 1. Confirm dependency versions ◦ Tell me your

flutter_webrtc

version. If it’s not up to date, update it along with

livekit_client

to the latest compatible releases and test again. 1. Ensure the PeerConnection is fully cleaned/recreated on reconnect ◦ Before calling republish, make sure the engine/PeerConnection has been closed or fully reinitialized after the disconnect. This avoids trying to add transceivers to a connection in an invalid state. 1. Serialize and delay republish attempts ◦ Avoid firing republish immediately when the network returns. Add a short delay (e.g., 500–1500 ms) and ensure no concurrent negotiations are in progress before calling

rePublishAllTracks

. ◦ If you have custom reconnect logic, ensure you wait until the room/engine signals it’s in a stable connected state. 1. Add a defensive retry for addTransceiver failures ◦ Catch the error from publish/republish and retry once after a short backoff (and only if the PeerConnection is stable). This mitigates transient race conditions. 1. Reproduce without other plugins running ◦ Even though you’re on macOS and app is foreground, confirm there are no other plugins or app code that might manipulate lifecycle or native channels during reconnect. 1. Collect more signals if it reoccurs ◦ If you hit it again, capture: ▪︎

flutter_webrtc

version ▪︎ Exact sequence: when disconnect is detected, any callbacks you run, when you call publish/republish ▪︎ Logs around ICE/peer-connection state transitions (before and after network loss) ◦ That will help pinpoint whether the connection is being left in a state that forbids adding transceivers. If you want, next steps I can help with • If you share your

flutter_webrtc

version and a short snippet of how you handle reconnect/publish, I can suggest a concrete code pattern to ensure a clean peer connection lifecycle (where to wait/close/recreate, where to add retry/backoff). • I can also suggest an exact defensive retry snippet to place around

rePublishAllTracks

. Send the

flutter_webrtc

version and a small excerpt of your reconnect/publish logic and I’ll propose a concrete change you can try. , with interactive elements

which webRtc is shall use with livekit_client 2.6.3

Thanks — great question. I don’t have a specific recommended

flutter_webrtc

version for

livekit_client

2.6.3 available here. The Flutter SDK does depend on

flutter_webrtc

, but no explicit version constraint or compatibility matrix is provided. What I recommend next • Tell me the

flutter_webrtc

version you currently have in your pubspec.yaml so I can check whether that’s likely to be the cause. • If you don’t know the version, run

flutter pub deps --style=compact | grep flutter_webrtc

in your project root to show the installed version. Practical guidance while we confirm versions • Update both

livekit_client

and

flutter_webrtc

to the latest compatible releases you can safely use, then test reconnect behavior. Newer

flutter_webrtc

releases often include native fixes that resolve addTransceiver/peer-connection issues. • If you cannot update right now, try the reconnect workarounds I suggested earlier (ensure peer connection is fully cleaned/recreated, delay/serialize republish, and add a short retry/backoff around republish). If you paste your current

flutter_webrtc

version (or the output from the

flutter pub deps

command), I’ll tell you whether that version is likely to be problematic and suggest the next concrete steps. Sources: client-sdk-flutter | livekit/livekit_composite | DeepWiki, with interactive elements

- livekit_client 2.6.5 [flutter_web_plugins flutter async collection connectivity_plus fixnum meta http logging uuid synchronized protobuf device_info_plus sdp_transform web mime_type path dart_jsonwebtoken json_annotation flutter_webrtc dart_webrtc] - flutter_webrtc 1.3.0 [collection dart_webrtc flutter logger path_provider web webrtc_interface]

Thanks — this is helpful. You’re on macOS and using: • livekit_client 2.6.5 • flutter_webrtc 1.3.0 Acknowledging your original error (addTransceiver failure on reconnect), here’s a clear next-step plan based on those versions and the reconnect scenario you described. What to try next 1. Update to latest patch releases if possible ◦ Use the newest compatible releases of both

livekit_client

and

flutter_webrtc

you can safely adopt, then re-test reconnects. Newer

flutter_webrtc

releases often include native fixes that affect transceiver/peer-connection behavior. 1. Add a short delay + serialize republish on reconnect ◦ When network returns, wait ~500–1500 ms before calling

rePublishAllTracks

. Ensure you do not start multiple publish/negotiation attempts in parallel. 1. Ensure peer connection was reset before republishing ◦ Confirm the engine/PeerConnection is fully closed or reinitialized after the long network drop so LiveKit isn’t adding transceivers to a partially-damaged connection. 1. Add defensive retry around republish ◦ If

rePublishAllTracks

throws this addTransceiver error, catch it and retry once after a short backoff (only if the PeerConnection appears stable). 1. Capture extra logs if it reoccurs ◦ If the issue still happens after the above steps, capture logs showing peer connection/ICE state transitions and the exact timing of your reconnect/publish calls so we can pinpoint whether the peer connection is in an invalid state. If you want, I can suggest a small code pattern to: • wait for a stable state before calling

rePublishAllTracks

• serialize/queue republish attempts • implement a single retry with backoff Would you like that snippet? If so, tell me whether you prefer a simple pseudo-code pattern or an actual Dart example integrated with the LiveKit client calls. , with interactive elements

im unable to hear the meeting sound. i have updated to latest version of livekit to 2.6.5. still same issue

Thanks — I know this is frustrating, and I appreciate you sticking with the troubleshooting. You’ve updated to LiveKit 2.6.5 with

flutter_webrtc

1.3.0 and still can’t hear meeting audio after a reconnect. I’ll help you narrow this down and get audio back. Quick clarifying questions • Is the problem on macOS only, or do other platforms (iOS, Android) show the same silent audio? • Are remote participants visible in the UI (their tracks appear) but you hear nothing, or do their audio tracks not show as subscribed/received at all? • Do you see any WebRTC or LiveKit logs mentioning subscription, trackPublished, trackSubscribed, or audio playback errors around the reconnect? • Can you confirm microphone/speaker permissions are granted for the app on macOS? • Does refreshing the UI or reloading the room (full disconnect + connect) restore audio temporarily? Immediate things to check and try 1. Verify tracks are actually received ◦ Look for LiveKit events:

participantPublished

,

trackSubscribed

, and

trackUnsubscribed

. If you never see

trackSubscribed

, the client isn’t receiving the remote audio. ◦ If you do see

trackSubscribed

, the track is present but playback may be blocked. 1. Confirm audio output and permissions on macOS ◦ Ensure the app’s audio output device is correct (System Preferences > Sound > Output). ◦ Confirm the app has mic/speaker access in System Preferences > Security & Privacy > Microphone (and Accessibility if applicable). 1. Check subscription state after reconnect ◦ After the network returns, ensure the SDK completes subscription negotiation. If negotiation fails (or is skipped), you won’t receive active audio even if participants remain visible. ◦ Wait a bit after reconnect (500–1500 ms) and monitor logs for subscription events. 1. Try a forced re-subscribe or full re-attach ◦ If you see participants but no audio, try forcing a re-subscribe to the remote audio track or temporarily leave and rejoin the room to confirm whether full reconnect restores audio. 1. Verify audio element / playback on macOS ◦ If your app uses platform audio APIs, ensure audio playback is not muted and volume is non-zero. ◦ If you render audio via an

AudioElement

(web) or native audio path, verify that the audio sink is properly attached. 1. Add logging around reconnect/publish/subscribe ◦ Capture engine/peer connection logs, and watch for ICE state changes and negotiation: ▪︎ PeerConnection state transitions (new, connecting, connected, disconnected, failed) ▪︎ Any errors around

addTransceiver

, negotiation, or subscription failures Defensive workaround to try now • After reconnect completes, perform a short sequence: a. Wait ~800 ms b. Call a single forced re-subscribe or call

rePublishAllTracks

for local and then ensure remote

trackSubscribed

triggers c. If subscription still doesn’t happen, programmatically leave and rejoin the room (this fully recreates PeerConnection) as a test to see if audio returns If it still fails, please paste these items and I’ll propose a focused fix: • Recent log excerpt around disconnect → reconnect (include events like

trackSubscribed

, ICE states, and the addTransceiver error) • Confirmation whether remote participants appear and whether

trackSubscribed

events fire • macOS audio output device status and permission screenshots or descriptions If you want, I can also provide a small Dart snippet showing how to wait for stable connection state then force re-subscribe/rejoin — tell me if you prefer a quick pseudo-code or a concrete Dart example. , with interactive elements

is there any issue related to this open on github?

Good question — I checked what I have here and there isn’t a known, specific GitHub issue in my sources that matches the

addTransceiver

error + macOS silent-audio-after-reconnect problem you’re seeing. What I recommend next • Check the LiveKit Flutter repo issues directly and search for keywords like: ◦ addTransceiver ◦ flutter_webrtc ◦ reconnect ◦ rePublishAllTracks ◦ macos audio • If you don’t find a matching issue, open a new issue and include: ◦ LiveKit client version (you said 2.6.5) ◦ flutter_webrtc version (1.3.0) ◦ Platform (macOS) and OS version ◦ Full stack trace you posted earlier ◦ A short reproduction scenario (network drop ~1 minute, reconnect while app foreground) ◦ Logs around ICE/peer-connection state transitions and subscription events (trackSubscribed, etc.) ◦ Any workarounds you tried (delays, retries, full rejoin) Why that helps • A clear issue with reproduction steps and logs makes it much easier for maintainers to identify whether it’s a plugin/native WebRTC bug, a LiveKit client bug, or a lifecycle/race condition in your app. If you’d like, I can draft a concise issue body for you to paste into GitHub (including the stack trace and the troubleshooting steps you’ve tried). Would you like me to prepare that? , with interactive elements

[ERROR:flutter/runtime/dart_vm_initializer.cc(40)] Unhandled Exception: Unable to RTCPeerConnection:addTransceiver Error: can't addTransceiver! #0 RTCPeerConnectionNative.addTransceiver (packageflutter webrtc/src/native/rtc peerconnection impl.dart619:7) <asynchronous suspension> #1 EngineInternalMethods.createTransceiverRTCRtpSender (packagelivekit client/src/core/engine.dart1494:25) <asynchronous suspension> #2 LocalParticipant._publishAudioTrack.negotiate (packagelivekit client/src/participant/local.dart201:27) <asynchronous suspension> #3 Future.wait.<anonymous closure> (dartasync/future.dart546:21) <asynchronous suspension> #4 LocalParticipant._publishAudioTrack (packagelivekit client/src/participant/local.dart208:20) <asynchronous suspension> #5 SerialRunner.run (packagelivekit client/src/support/serial runner.dart45:14) <asynchronous suspension> #6 LocalParticipant.publishAudioTrack (packagelivekit client/src/participant/local.dart164:20) <asynchronous suspension> #7 LocalParticipant.rePublishAllTracks (packagelivekit client/src/participant/local.dart622:9) <asynchronous suspension> #8 Room._setUpEngineListeners.<anonymous closure> (packagelivekit client/src/core/room.dart526:7) <asynchronous suspension> #9 EventsListenable.on.<anonymous closure> (packagelivekit client/src/managers/event.dart181:9) <asynchronous suspension> this is the error log

Thanks — I can see the exact stack trace you’re hitting during reconnect, and I know you’re also missing meeting audio. I’ll walk through the most actionable troubleshooting and a practical defensive code pattern you can try right away to avoid the

addTransceiver

failure and restore audio after reconnect. Acknowledgement of the error • The crash originates in

flutter_webrtc

when LiveKit calls

addTransceiver

during

LocalParticipant.rePublishAllTracks

after reconnect. • That means the PeerConnection is in a state where adding transceivers is not allowed (negotiation pending, not stable, or partially torn down), which can also prevent audio from resuming. Immediate steps to try 1. Short delay before republishing ◦ After network returns, wait ~800–1500 ms before calling republish. This reduces race conditions while the native peer connection finishes state transitions. 1. Ensure the PeerConnection is reset or stable ◦ Make sure your client fully closes/recreates the PeerConnection (or waits until the engine reports a stable connected state) before republishing local tracks. 1. Serialize publish/negotiation attempts ◦ Avoid triggering multiple publish calls at once. Keep publish/republish calls serialized. 1. Defensive retry on addTransceiver failure ◦ Catch the error when republishing and retry once after a short backoff (300–800 ms) only if the PeerConnection looks ready. This often recovers from transient native race conditions. 1. Quick test: full leave + rejoin ◦ If audio doesn’t return, test doing a full leave and join. If audio returns after a full reconnect, this points to a peer connection state/race during republish rather than an upstream media problem. Suggested Dart pattern (conceptual + safe) • Use this pattern around your reconnect handling to delay, check connection state, and retry republish. Replace the pseudo-method names with your actual LiveKit calls.

// Pseudo-code / pattern to adapt in your reconnect handler

Future<void> handleReconnectAndRepublish(Room room) async {
  // 1) small delay to allow native PeerConnection to settle
  await Future.delayed(Duration(milliseconds: 800));

  // 2) optional: ensure room/engine is in a connected/stable state
  if (!room.connected) {
    // wait up to a short timeout for connected state
    final ok = await waitForCondition(() => room.connected, timeout: 3000);
    if (!ok) {
      // fallback: perform full rejoin if the engine never becomes stable
      await forceRejoin(room);
      return;
    }
  }

  // 3) attempt republish with a single retry/backoff on failure
  try {
    await room.localParticipant.rePublishAllTracks();
  } catch (e) {
    // If addTransceiver fails, wait a bit and retry once.
    await Future.delayed(Duration(milliseconds: 500));
    try {
      await room.localParticipant.rePublishAllTracks();
    } catch (e2) {
      // If it still fails, fallback to full rejoin to restore audio
      await forceRejoin(room);
    }
  }
}

// Helper stubs
Future<bool> waitForCondition(bool Function() cond, {int timeout = 3000}) async {
  final end = DateTime.now().add(Duration(milliseconds: timeout));
  while (DateTime.now().isBefore(end)) {
    if (cond()) return true;
    await Future.delayed(Duration(milliseconds: 100));
  }
  return false;
}

Future<void> forceRejoin(Room room) async {
  // implement a safe leave and join sequence for your app
  await room.disconnect();
  // small delay to ensure full cleanup
  await Future.delayed(Duration(milliseconds: 300));
  await joinRoomAgain(); // your join logic
}

What to capture if this continues • PeerConnection / ICE state transitions around the disconnect and reconnect (logs showing connecting → connected → disconnected → etc.). • Events:

trackSubscribed

,

participantPublished

,

trackUnsubscribed

. • Exact timing of when you call

rePublishAllTracks

relative to network restoration. • Confirm macOS audio device/permissions (Sound output, mic access) although your stack indicates a transceiver/native WebRTC issue first. Version note • You are on livekit_client 2.6.5 and flutter_webrtc 1.3.0 — if you can safely try a newer

flutter_webrtc

patch release, do so; it may include native WebRTC fixes. If you can’t upgrade, the defensive pattern above is the best mitigation. If you want, I can: • Draft a ready-to-copy GitHub issue body (include stack trace, versions, repro steps, logs) for you to paste into the LiveKit repo. • Help adapt the code snippet into your actual reconnect logic if you paste the short snippet of how you currently handle reconnect/publish. Which would you like next — a GitHub issue draft or help integrating the retry/delay pattern into your code? , with interactive elements

issue is on macos, working fine on windows

Thanks — that’s a useful detail: macOS only, Windows is fine. I know that narrows the scope and points toward a platform-specific WebRTC/native behavior or macOS audio/session handling during reconnect. What this suggests • The

addTransceiver

failure during rePublishAllTracks is a native WebRTC/macOS issue (or a macOS-specific lifecycle/race). Because Windows works, the problem is unlikely to be LiveKit logic itself and more likely related to the macOS WebRTC implementation, audio device/session state, or a plugin/native race that only appears on macOS. Immediate things to try (highest value first) 1. Delay + serialize republish on reconnect ◦ After network returns, wait ~800–1500 ms before calling

rePublishAllTracks

. This gives the native PeerConnection and audio device time to settle and often prevents addTransceiver errors. 1. Defensive retry + fallback rejoin ◦ Wrap

rePublishAllTracks

in a try/catch and retry once after ~500 ms if it fails. If retry still fails, do a full leave + rejoin (this recreates the PeerConnection cleanly and typically restores audio). 1. Verify macOS audio session / output device ◦ Confirm the system audio output is set correctly and the app has audio access. On macOS, audio device changes or system-level audio session quirks during network interruption can block playback. ◦ System Preferences > Sound > Output: ensure correct device and volume; Security & Privacy > Microphone: verify permissions. 1. Test a controlled reconnection sequence ◦ Reproduce with a short script: connect → disable network for 60s → re-enable → wait 1s → call republish. Try variations of delay (500ms, 1s, 2s) to find a safe window that avoids the error. 1. Try a newer flutter_webrtc patch if available ◦ You’re on flutter_webrtc 1.3.0 — if there’s a newer patch in the 1.x line, try it. Native WebRTC fixes often land in patch updates. If upgrading isn’t possible, the delay/retry/fallback pattern is the recommended mitigation. Logs and signals to capture (if it recurs) • PeerConnection / ICE state transitions around disconnect and reconnect. • Time and content of

rePublishAllTracks

call relative to reconnection. •

trackSubscribed

/

participantPublished

events after reconnect. • Any macOS system logs about audio device changes. • The addTransceiver stack trace you already provided (keep this in the GitHub issue). Would you like a ready-to-post GitHub issue body? • I can draft a concise issue you can paste into the LiveKit or flutter_webrtc repo (depending on where you want to file it). Include versions, macOS version, the stack trace, reproduction steps (network drop ~1 minute), and logs. I’ll include the troubleshooting steps you’ve tried. Or would you prefer a concrete Dart snippet to integrate the delay + retry + fallback pattern into your reconnect logic? Paste the small reconnect/publish snippet you currently use and I’ll adapt the exact code for you. , with interactive elements