iOS: When Bluetooth device is available, incoming call defaults to receiver/earpiece when answered

[rcidt]

Bug report

• I've checked the example to reproduce the issue.

• Reproduced on:

• Android

• iOS

Description

When a BT device is connected, outbound calls will automatically connect to the BT audio route.

But for inbound calls, the audio gets routed to the receiver/earpiece instead of BT.

When I print out the events for RNCallKeepDidChangeAudioRoute, I receive a bunch of them once I answer the call. Sometimes they start off as BT, but it gets overrode by subsequent events showing receiver as the audio route. These events are triggered outside of my app.

Steps to Reproduce

Connect your device to BT device. Place an inbound call to CallKit app. Answer the call. Notice the audio route is not BT.

Versions

- Callkeep: 4.3.3
- React Native: 0.66.3
- iOS: 15.4.1
- Android: N/A
- Phone model: iPhone 11

Logs

Paste here

[AbdulBsit]

It's the default behaviour of iOS

• After tapping the answer button on iPhone, the default audio route is the iPhone speaker.
• After tapping the answer button on a Bluetooth device, the default audio route is the Bluetooth device.

[vishaldaher]

It's the default behaviour of iOS

• After tapping the answer button on iPhone, the default audio route is the iPhone speaker.
• After tapping the answer button on a Bluetooth device, the default audio route is the Bluetooth device.

@AbdulBsit observed same.
Is there any workaround to route audio to bluetooth device even when user answers call from iPhone?

[AbdulBsit]

@vishaldaher on didActivateAudioSession after call answer you can check for bluetooth device, if present just override it using RNCallKeep.setAudioRoute method, I would suggest to keep it as it is, as this is a default platform behaviour for iOS

[vishaldaher]

Thanks for Quick reply @AbdulBsit :)

I tried RNCallKeep.setAudioRoute but its not working. I am also agree with your suggestion to keep this as is as its default behaviour.

[octaviotastico]

We encountered a similar timing problem in an Expo SDK 56 application using React Native 0.85.3 and CallKit.

When an inbound call was answered, iOS could emit several route changes around didActivateAudioSession. An application-level route request made too early could be overridden by a later CallKit event, leaving the call on the receiver instead of the Bluetooth route.

Our local fix was to queue route changes until didActivateAudioSession, then apply the latest requested route. We also changed RNCallKeep's iOS rejection path to pass e.description as an NSString instead of the caught NSException, because current React Native TurboModules can crash while converting that exception to a JS error. PR #845 addresses the latter library issue.

The activation timing described here is valuable context for making route selection reliable on current React Native versions.