provider(_:didActivate:) callback intermittently not triggered, causing widespread audio loss for users

Question

Created 1d

Replies 1

Boosts 0

Participants 2

Hi everyone,

I am facing a critical issue where the CallKit provider delegate method provider(_:didActivate:) is intermittently not triggered. This occasionally results in a total loss of audio during some VoIP calls, while other calls work perfectly fine.

Here is the sequence of steps I am currently implementing:

Report Incoming Call: The app receives a VoIP push notification and reports the call using reportNewIncomingCall(with:update:completion:).
Answer Action: The user taps the answer button, and the app processes the CXAnswerCallAction.
Configure Audio Session: Inside the provider delegate, I configure the AVAudioSession category and mode (e.g., setting category to .playAndRecord and mode to .voiceChat). Note: As per Apple's guidelines, I do not call setActive(true) manually, expecting CallKit to activate it automatically.

Despite following this standard flow, there are times when provider(_:didActivate:) is skipped entirely, meaning the audio engine fails to initialize for that specific call session.

We are currently receiving a large volume of user complaints regarding this issue, as it heavily impacts the core calling experience in production.

Could an Apple engineer or anyone from the community look into this? Any insights into what might be causing CallKit to occasionally fail to activate the audio session or how to work around this would be highly appreciated.

Thank you!

Answer 1

DTS Engineer OP

Apple

4h

Could an Apple engineer or anyone from the community look into this? Any insights into what might be causing CallKit to occasionally fail to activate the audio session or how to work around this would be highly appreciated.

So, a few things I'd note. First off, on this point:

Configure Audio Session: Inside the provider delegate,

This is the same point Speakerbox calls "configureAudioSession", however, if you look closely at Speakerbox's implementation you'll realize that it only actually "does" anything the very first time configureAudioSession is called. The rest of the time it does "nothing“ - like most apps, it's audio session configuration never changes so there's no reason to actually do the same configuration all over again.

These details are important because the internal logic of how the session is managed gets very complicated once your app is handling multiple calls. Most apps should probably just reuse Speakerbox’s implementation, but if you're writing your own I would recommend really looking closely at exactly what our code is doing.

Having said that, what you're describing here:

I am facing a critical issue where the CallKit provider delegate method provider(_:didActivate:) is intermittently not triggered.

Sounds like the same issue reported on this thread. I also describe a simple workaround in that same thread here, which is to simply call "setConfiguration" before every call report. I can't promise it will resolve all of these issues, but the reports I have seen show it making a very significant difference.

Finally, if you have a moment I'd appreciate you filing your own bug about this and, if possible, including concrete numbers about the call failure rate/count. I'd like the system to address this and a big part of that is getting more concrete data about the bug’s impact.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware