[rcidt]

Fixes #540

[nagyszili]

Tested and I noticed if we remove the setCategory from the getAudioInputs, the availableInputs are not up-to-date, I mean if in the meantime you remove a connected bluetooth device, the availableInputs are not updated

[rcidt]

@nagyszili I am not seeing that issue. Are you relying on the RNCallKeepDidChangeAudioRoute event or are you using the getAudioRoutes method?

[nagyszili]

I'm using the getAudioRoutes , please try it when a call is connected, my suggestion is to set the category in the getAudioInputs when there is no call connected

[Hesowcharov]

@rcidt First of all, thank you for PR!

I found your sumbission when I faced with another issue - #getAudioRoutes seems not working when an incoming call is ringing but not answered yet. The flow is following (iOS only!):

1. displayIncomingCall (i.e. it plays the system ringtone)
2. getAudioRoutes (to output all available audio routes before)
3. answerCall / endCall

Without your fix, I catch the exception at setActive step in getAudioInputs (see here ->

react-native-callkeep/ios/RNCallKeep/RNCallKeep.m

Lines 593 to 598 in 8de84e3

	BOOL isCategoryActivated = [myAudioSession setActive:YES error:&err];
	if (!isCategoryActivated)
	{
	NSLog(@"[RNCallKeep][getAudioInputs] setActive failed");
	[NSException raise:@"setActive failed" format:@"error: %@", err];
	}

):

Log:

2022-06-16 20:30:11.550015+0300 App[82985:4088420] [RNCallKeep][getAudioRoutes]
2022-06-16 20:30:11.560937+0300 App[82985:4088420] [RNCallKeep][getAudioInputs] setActive failed
2022-06-16 20:30:11.564230+0300 App[82985:4088420] [RNCallKeep][getAudioRoutes] exception: error: Error Domain=NSOSStatusErrorDomain Code=561017449 "(null)"
2022-06-16 20:30:11.711591+0300 App[82985:4088421] [javascript] [Error: null]

With your fix, the flow works great!

Several things to mention:

1. please resolve the conflicts because your branch is outdated (I could port your changes on the master in the same manner)
2. your suggested code set category and set the audio session active after getting the audioInputs:

        NSArray *ports = [RNCallKeep getAudioInputs];

        BOOL isCategorySetted = [myAudioSession setCategory:AVAudioSessionCategoryPlayAndRecord withOptions:AVAudioSessionCategoryOptionAllowBluetooth error:&err];
        if (!isCategorySetted)
        {
            NSLog(@"[RNCallKeep][setAudioRoute] setCategory failed");
            [NSException raise:@"setCategory failed" format:@"error: %@", err];
        }

        BOOL isCategoryActivated = [myAudioSession setActive:YES error:&err];
        if (!isCategoryActivated)
        {
            NSLog(@"[RNCallKeep][setAudioRoute] setActive failed");
            [NSException raise:@"setActive failed" format:@"error: %@", err];
        }

        // => may be invoke getAudioInputs here after setting stuff ?
        for (AVAudioSessionPortDescription *port in ports) {

what about get the audio inputs after setting stuff ?

[disco-panda]

Hello, I am still experiencing this issue - can we get this merged / released?

[sboily]

Thanks for this, and sorry it sat for so long. The original problem (#540: getAudioRoutes changing the selected route) is now fixed on master: #481 stopped getAudioInputs from resetting the category during a call, and #863 (merged yesterday) removed the setActive:YES that switched the route and interrupted other apps' audio. Since then this branch has become a fork's master with many unrelated changes, so I'm closing it. Focused PRs for any of the other features are welcome.