After unholding CallKit, the audio does not restore.

Question

Created Mar ’24

Replies 3

Boosts 1

Views 1.3k

Participants 3

In my application, I use CallKit and have supportsHolding = true set. During my phone call, another call comes in (e.g., GSM). I accept the incoming call and put the current call on hold.

If I end the active call myself, everything is fine, and CallKit calls the method provider(_ provider: CXProvider, didActivate audioSession: AVAudioSession).

However, if the other party ends the call, the second call remains on hold. In the application, the user clicks on unhold, and I notify CallKit that the hold has ended.

But in this case, the didActivate method is not called at all. If I try to activate the audio myself after unhold, I receive the error: Domain=NSOSStatusErrorDomain Code=561017449 "Session activation failed" UserInfo={NSLocalizedDescription=Session activation failed}

AVAudioSessionErrorInsufficientPriority == NSOSStatusErrorDomain Code: 561017449

What needs to be done for CallKit to activate my audio?

Boost

Answer 1

raosan OP

Jun ’24

I had a similar experience, https://developer.apple.com/forums/thread/715488. The way i fixed for myself was not to do anything, let the user manually select on the UnHold and then configure the audio session when performSetHeldCallAction is called.

0

Answer 2

marek.labuzik OP

Feb ’25

@Apple any updates?

https://developer.apple.com/documentation/callkit/voip-calling-with-callkit

When using this demo, the exact same situation occurs.

@raosan As stated above, activation failed.

0

Answer 3

DTS Engineer OP

Apple

Feb ’25

@Apple any updates?

The behavior is intentional, with the goal being to avoid any situation when the user could be overheard unintentionally. It also provides a consistent user experience with when more than 2 calls are active, so the "right" call to activate couldn't be determined.

@raosan As stated above, activation failed.

Yes, that's expected behavior.

As background context, the AudioSession configuration CallKit uses is a phone specific audio session type which is similar to PlayAndRecord but has a higher interruption priority and differs in some of it's behavior details (for example, it has a slightly higher maximum volume than PlayAndRecord). However, that AudioSession configuration is also one app are generally unable to activate for themselves*. The model to follow here is how SpeakerBox manages it's audio session- the ONLY call to "setActive" in SpeakerBox is when it receives AVAudioSessionInterruptionTypeEnded, which is what apps should be doing as well.

*As a side note, one of the most common mistakes developers make is calling setActive themselves before reporting or creating new calls. What actually ends up happening in this case is that the system activates a standard PlayAndRecord session and that PlayAndRecord session then prevents the phone session from activating. The dynamics of how CallKit manages calls mean that it isn't immediately obvious that this configuration is wrong, but means that you're not getting the full benefit of the phone session and that you can get edge case failures that would otherwise not occur.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

0