CallKit does not activate audio session with higher probability after upgrading to iOS 18.4.1

Our app uses CallKit with WebRTC to establish VoIP connections. However, on iOS 18.4.1, CallKit no longer triggers: func provider(_ provider: CXProvider, didActivate audioSession: AVAudioSession)

We're currently comparing the occurrence rate across different iOS versions to better understand the impact.

Could you please help analyze the root cause of this issue?

I can't tell you what the exact issue issue is but what typically causes this is that the app itself activated the audio session itself. That can result in "one way" audio because the system ends up allowing playback activation but blocks recording (since that's what the system actually protects against). Having and active audio session means that CallKit cannot activate the audio session (since you can't activate an active audio session), which then means it doesn't call "didActivate".

That leads to here:

Our app uses CallKit with WebRTC to establish VoIP connections.

The biggest issue with using any kind of library that doesn't directly integrate CallKit is that these libraries integrate their own audio session management and activation. If timing means that CallKit activates first, then everything will actually still work fine. What actually happens is that their setActive call fails, but that doesn't actually matter since the session is already active. However, if/when the timing of activation changes even slightly, then the library ends up calling "setActive" first, creating exactly the problem you're seeing.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

Hi @DTS Engineer

Thank you for your response and insights.

We understand your point about AVAudioSession possibly being activated too early by third-party libraries like WebRTC. However, we would like to clarify that our app does not call AVAudioSession.setActive(true) before CallKit triggers didActivate, and we've ensured that WebRTC is initialized only after this delegate method is called.

We've also double-checked and confirmed that there is no early activation of the audio session before CallKit is expected to activate it. Despite this, on iOS 18.4.1, we’re seeing a statistically significant increase in the failure rate of didActivate, as shown in our metrics.

Given that our app version remains unchanged, and the issue correlates strongly with the iOS 18.4.1 system update, could you help us further investigate whether there might be behavior changes in AVAudioSession or CallKit that could explain this?

Any guidance or diagnostic suggestions would be greatly appreciated?

We've also double-checked and confirmed that there is no early activation of the audio session before CallKit is expected to activate it.

How did you make that determination? The problem here is that AVAudioSession does not provide great visibility into it's activation state, which makes "knowing" what happened trickier than it might seem.

More to the point, here are two key points in your original email that I want to expand on:

...result in one-way audio.

The way I understood this is that the receiver of the call can hear audio ("Playback") but cannot be heard ("Record") by the initiator of the call. In other words, your app DOES have an active audio session, the problem is that it either:

1. Is failing to properly start it's own recording "process" (meaning, it could be capturing audio data but simply "isn't").

2. It activated as a Playback session (not PlayAndRecord), so it cannot record.

However, on iOS 18.4.1, CallKit no longer triggers: func provider(_ provider: CXProvider, didActivate audioSession: AVAudioSession)

This would happen for one of two reasons:

1. Audio handling failed entirely.

2. CallKit never activated the audio session.

This is clearly #2 and the proof of that is the same reason activation failed. The audio system is clearly "working" (otherwise you wouldn't be able to play...) and simplest reason CallKit would fail to activate your apps audio session is... that you ALREADY had a playback session active.

That context lead to here:

Given that our app version remains unchanged, and the issue correlates strongly with the iOS 18.4.1 system update, could you help us further investigate whether there might be behavior changes in AVAudioSession or CallKit that could explain this?

It terms of the systems role in this kind of issue, the basic question here is whether you reproduce the issue in Speakerbox, either directly or by modifying the sample in some straightforward way. If you can, then the system clearly has some role* in the issue. If you can't, then the issue isn't in CallKit.

*In the modification case, that role could simply be "the framework doesn't work when used like that".

One point I want to expand on is around this point:

...the issue correlates strongly with the iOS 18.4.1 system update

One thing I didn't explain in my previous post is that it is reasonably likely that changes in the system are in fact what caused the increase. The audio system is an extremely complex pile of code that's under very active development, so "something" is nearly always changing.

However, that doesn't mean you code isn't the problem. The complexity of the audio system also means that it can "hide" problems, so the fact your code used to "work" only means that it happened to not fail, not that it was actually correct. Case in point, your own data shows a failure rate of ~0.1% prior to 18.4. Assuming those represent the same underlying issue, then that says that an existing bug may simply have become more common, not that this is a new issue.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware