Bug: twilio-video keeps audio/video streams alive after room.disconnect() when accepting a second call on iOS (Capacitor + React)

[Abhiranjanchaurasia]

Description
We are facing an issue with twilio-video.js on iOS where audio and video streams remain active even after calling room.disconnect() and removing all published tracks.
This issue consistently occurs when accepting a second call after a previous call, especially when the app is backgrounded and foregrounded. As a result, iOS continues to show the microphone/camera usage indicator in the status bar, even though no active room exists.

Environment

• twilio-video: (2.34.0)
• Platform: iOS (iOS v26.2)
• Framework: React (v19)
• Wrapper: Capacitor (v8)
• Build: Production build (npm run build)
• iOS WebView: WKWebView (via Capacitor)

Steps to Reproduce

1. Clone and configure the provided React sample project. Repository link: https://github.com/Abhiranjanchaurasia/TwilioVideoReactSample

2. Make sure the root folder has backend and frontend.
   Configure the backend environment variables:

3. Create a .env file and add the following:

• TWILIO_ACCOUNT_SID="XXXXXXX"
• TWILIO_API_KEY="XXXXXXX"
• TWILIO_API_SECRET="XXXXXXX"

4. Important: Update the backend API base URL to use your local machine IP address

• Open app.jsx and replace http://192.168.1.42:3001 and with http://<YOUR_LOCAL_IP>:3001
• Example:

- ❌ http://192.168.1.42:3001
- ✅ http://<YOUR_LOCAL_IP>:3001

5. Start backend

- cd backend
- npm install
- npm run start:dev

6. Start frontend, build and sync the app:

- npm install
- npm run build
- npx cap sync
- npx cap open ios

7. Run the app on a real iOS device
8. Start the first video/audio call
9. Move the app to the background, i.e., try to open another app while the call is in progress, and make sure the app is still in the recent menu
10. Bring the app back to the foreground, i.e., come to react app again
11. Tap the “+” icon to start a second call, and wait for the video of yourself
12. End the second call
13. Move the app to the background, and try to open another app while the call is in progress, and make sure the app is still in the recent menu
14. Bring the app back to the foreground

Expected Behaviour

After calling the room.disconnect(), and stopping/unpublishing all tracks:

• All audio and video streams should be fully released
• iOS should not show microphone or camera usage indicators
• No active media session should remain

Actual Behaviour

• iOS continues to show the microphone and/or camera usage indicator at the top of the screen
• Indicates that audio/video streams are still alive
• This happens even though:
  • room.disconnect() is called
  • Tracks are unpublished and stopped
  • No active room reference exists

Additional Notes

• Issue occurs only on iOS
• Android behaves as expected
• Reproducible when:
  • Accepting a second call
  • After background → foreground transitions
• All local tracks are explicitly stopped and removed from publications

Attempted Workarounds / Reproduction Scenarios
We attempted multiple approaches to ensure that the previous audio/video streams are fully stopped before starting a second call. The following scenarios were tested, but the issue persists.

1. Steps to reproduce Audio / Video Stream Stuck

   1. Run the app on a real iOS device
   2. Start the first video/audio call
   3. Move the app to the background, i.e., try to open another app while the call is in progress, and make sure the app is still in the recent menu
   4. Bring the app back to the foreground, i.e., come to react app again
   5. Tap the “+” icon to start a second call, and wait for the video of yourself
   6. End the second call
   7. Move the app to the background, and try to open another app while the call is in progress, and make sure the app is still in the recent menu
   8. Bring the app back to the foreground

2. Hard Reload the Component Route
   Scenario 1
   1. Accept the second incoming call
   2. Decline the previous call
   3. Perform a hard reload of the video component route

   Scenario 2
   1. Accept the second incoming call
   2. Wait ~10 seconds to allow reconnection of the first call
   3. Decline the first call
   4. Start the second call with a hard reload of the component route

3. Restart Audio / Video Tracks
   1. Accept the second incoming call
   2. Decline the previous call
   3. Start the second call
   4. Explicitly stop and restart audio and video tracks

Result
Despite the above steps:

1. Audio and/or video streams from the previous call remain active
2. room.disconnect() and track cleanup do not fully release media resources
3. The issue consistently reproduces when handling consecutive calls

Question

Is this a known issue with twilio-video.js on iOS WKWebView, or is there a recommended approach to fully release media streams when handling consecutive calls?

Any guidance or fix would be greatly appreciated.

[Abhiranjanchaurasia]

We are still facing this issue, and haven’t received any response or update from the Twilio team on this thread.
To clarify, we have already implemented all recommended cleanup and interruption-handling steps, including:

• Explicitly stopping, disabling, detaching, and removing all local audio/video tracks
• Calling room.disconnect() only after full track cleanup
• Handling iOS background/foreground interruptions
• Adding delays before initiating a second Video.connect()

Despite this, twilio-video continues to keep audio/video capture sessions alive at the WebRTC / WKWebView layer on iOS, especially when accepting a second call in a Capacitor + React (WKWebView) environment.

This results in broken or missing audio/video streams on the second call.

Please provide an update, as this issue is still reproducible on the latest twilio-video.js versions and continues to block production use cases.

[charliesantos]

@Abhiranjanchaurasia thanks for the ping and sorry for not responding sooner. Are you able to reproduce this issue on iOS chrome or safari browser?

[Abhiranjanchaurasia]

@charliesantos Thanks for the response.
Yes, the issue is reproducible in our Capacitor iOS app using WKWebView. Since iOS Safari and Chrome both use WKWebView, this should be equivalent to reproducing it in Safari/Chrome on iOS.

The problem occurs when accepting or starting a second video call while in the same WKWebView session—audio/video capture remains active at the WebRTC/WKWebView layer despite full cleanup and room.disconnect(), resulting in broken media on the next call.

This is still reproducible on the latest twilio-video.js and blocks production use.

[charliesantos]

Thanks for the additional details, @Abhiranjanchaurasia. Although both Safari and Chrome on iOS use WKWebView, their behavior can differ due to browser-specific handling of certain features. Could you please test this on the native Safari and Chrome browsers on iOS and let us know whether the issue still occurs?

[Abhiranjanchaurasia]

@charliesantos I’ve tested the same flow on native Safari and Chrome on iOS, and it works correctly on both.

The issue only occurs when running inside WKWebView in our Capacitor iOS app, where the React application is rendered inside the WKWebView.

Could you please suggest the appropriate WKWebView-specific solution or configuration to address this issue?

[charliesantos]

@Abhiranjanchaurasia thanks for the additional details. This issue appears to be isolated to the WebView. We may need additional account-specific information to investigate further.

Could you please submit a support ticket? If you have an account manager, feel free to escalate through them as well. They can help route this to the appropriate team.

[Abhiranjanchaurasia]

@charliesantos, I’ve created a support ticket with ID #24902036. Please let me know if you need any additional information from my side.