-
Notifications
You must be signed in to change notification settings - Fork 474
Open
Description
Description
I am using react-native-callkeep together with jssip, react-native-webrtc, and react-native-incall-manager to build a SIP calling application.
On iOS the integration works fine, but on Android I am running into two major issues:
1. Audio Lost unless I call endCall on answer event
- When I answer a call, audio only flows if I explicitly call endCall(callUUID) inside the answerCall handler.
- On iOS, I don’t need to do this extra endCall and audio works normally.
- This feels like an inconsistency or unintended behavior.
- If endCall is the only solution to make audio work, then on Android it seems CallKeep is only acting as a UI layer, not actually maintaining the call session, which makes its role different from iOS.
2. Lock Screen Call Connect Limitation
- When receiving a call on the Android lock screen, the CallKeep UI shows up.
- If I tap Accept, the call does not actually connect to my app until I unlock the device.
- On iOS, accepting the call from the lock screen launches the app in background and immediately connects the session (expected behavior).
- On Android, I need to manually unlock the phone before the call session actually connects, which is breaking the user flow.
Environment
-
React Native version: 0.78.3
-
react-native-callkeep version: 4.3.16
-
jssip (handles SIP signaling)
-
react-native-webrtc (media streams)
-
react-native-incall-manager (audio routing)
-
Notifications:
- Android: Firebase push notifications
- iOS: VoIP push notifications (PushKit)
-
Platforms affected: Android only (iOS works as expected)
Additional Notes
- My goal is to use CallKeep consistently on both iOS and Android.
- I want to avoid hacks like calling endCall immediately on answer, since that breaks the call lifecycle logic and makes Android behavior diverge from iOS.
- Ideally, accepting a call from the lock screen should:
- Launch the React Native app in the background automatically (like iOS does).
- Initialize the SIP session (via JsSIP + WebRTC) without requiring the user to unlock the device.
- Maintain audio without calling endCall explicitly.
Any guidance on correct integration patterns, workarounds, or whether this is a limitation in Android’s ConnectionService would be highly appreciated.
Metadata
Metadata
Assignees
Labels
No labels