iOS27 Callkit's didActivateAudioSession not being called sometimes

Thank you for the post, when you said iOS 27, what beta are you using at this time? You had the same issue in iOS 14 a few years ago? https://developer.apple.com/forums/thread/711956

To prevent the user from having to force-quit the app, you should implement a timeout mechanism however you are correct CallKit expects the audio session to activate shortly after you fulfill the CXStartCallAction.

https://developer.apple.com/documentation/callkit/cxproviderdelegate/provider(_:didactivate:)?language=objc

May I ask you when that delegate is not trigger, can you request on that device a sysdiagnose press and hold both Volume buttons + Power button for 1-1.5 seconds until you feel a short vibration. Wait a few minutes for the sysdiagnose to compile. Let's see why CXProviderDelegate.provider(_:didActivateAudioSession:) is failing to fire on outgoing calls, wedging the CXProvider. Include the exact timestamp of the failed call and the UUID of the call if you have it logged. Can you post it here to see the reason?

Depending on the reason I’ll ask you to file a bug as you said the same code was working before iOS 27 beta 3 that was released yesterday. Please make sure you test it with that version first.

Looking forward to your reply.

Albert  WWDR

Hi Albert

Many thanks for the reply. I really appreciate it.

The problem

I had installed iOS27 Beta2 on my iPhone and every so often over a few days I was making test calls.

Then one outgoing call failed and every subsequent call failed until I restarted the App.

This was alarming for me because I had never seen such a scenario before.

From my own debug log I could see that didActivateAudioSession had NOT been triggered by iOS.

I then tried to repeat the problem but nearly a week went by before it happened again.

So this is a random bug that I cannot repeat at will.

Is this a new know issue?

Have their been similar reports of this from other VoIP app developers with iOS27?

Has that area of the framework been modified in iOS27?

iOS27 Beta 3

I have installed this version on the iPhone yesterday. I am trying to repeat the problem but it hasn't happened again yet.

If it happens again I will try to get a logfile as you suggest. I wish I could repeat the problem easily but I cannot!

Timeout Mechanism?

You suggest that I use a timeout mechanism so as the App can recover from the lockup.

What should that mechanism do?

For example if didActivateAudioSession does not happen after 10 seconds then what should I do?

Do I need to kill my CXProviderDelegate object and create a new one? Do I need to recreate my Audio Chain?

Historical problems

Back in Oct 2016 (!!) there was a thread for a similar issue https://developer.apple.com/forums/thread/64544?answerId=191868022#191868022

They were "one off failures" rather than the App completely failing for every subsequent call which is what I see now.

Apple's Stuart Montgomery mentioned it was reported in Radar # 28774388 and suggested workarounds at that time.

At that time I found that if I "configureAudioSession" in the completion block of a successful theMDSCXProvider reportNewIncomingCallWithUUID:theUUID update:theCallUpdate completion

then I got no failures of didActivateAudioSession. My code has been like that for 10 years working well with thousands of users. But now I think iOS27 has broken something!!

Thanks for your help

Many Thanks

Dave

@davemaj

Thanks for the detailed follow-up and the historical context.

Any reports of didActivateAudioSession failing to fire are taken seriously. Getting a sysdiagnose from Beta 3 to see if there is an issue can be extremely important.

You should not kill or recreate your CXProviderDelegate object. If didActivateAudioSession does not fire after a reasonable timeout, the goal of the timeout mechanism is to gracefully fail the stuck call so the CallKit state machine resets, allowing subsequent calls to succeed.

Do you have a simple focused project to see the behaviors and you can trigger a sysdiagnose immediately before restarting the app, and attach it to your Feedback report? If you can file a report with all that information, project and sysdiagnose the engineering team will be very happy to take a look to see if there is new regression bug there.

Really appreciate your help.

Once you open the bug report, please post the FB number here for my reference.

If you have any questions about filing a bug report, take a look at Bug Reporting: How and Why?

Albert  WWDR

Hi Albert

It has now happened on iOS27 Beta3. I am running on an iPhone 12.

I am based in Dublin Ireland. So the local time is UTC+1

All times below are "Local"

17:04 Made outgoing call. Successful!

17:55 Made outgoing call. Successful

18:08 Made outgoing call. ActivateAudioSession did not occur so I had no path

I straight away tried to get a sysdiagnose file. I tried to add here as an attachment but it would not attach (Too big maybe!?) so I have added a link to my google drive where I uploaded it

https://drive.google.com/file/d/1yUINaVSzD-OjeYGKoM_vgmANP76yNVGG/view?usp=share_link

Further info (In case relevant)

I then waited till 18:56 and made another outgoing call. But that too has no path

I then made an incoming call at 18:58 and answered the call. In that case I did get a call path !!! So that seemed to kick it out of the locked up state?!

Note?: Unfortunately I cannot repeat this "at will". So I just keep making test calls every so often to try get it to happen.

Thanks @davemaj for your help on this.

If you can't attach the file here because is too large or for privacy concerns

you can to submit a code-level support request so we can discuss this further privately. When you create the request, indicate that you were referred by Albert Pascual at Apple and make sure to include a link to this thread.

Or maybe better because you were able to reproduce it, we can also move to file a bug and you can attach the sysdiagnose there.

Once you open the bug report, please post the FB number here for my reference.

If you have any questions about filing a bug report, take a look at Bug Reporting: How and Why?

But if you want a code level support if you are not sure is an issue, we can start with a code-level support. Your call! But let me know the direction you decide to go.

Albert  WWDR

Thanks Albert

Before I do that .. Just to check....because it seems to only happen for me on beta software is it allowed to actually file a code level support? (Because it's Beta)??

Also just to say you should be able to get the sysdiagnose from the link above.

Thanks

Dave

Dave, maybe better file a bug for that at https://developer.apple.com/forums/thread/712889

Make sure to post the FB number here.

Thanks,

Albert  WWDR

Hi Albert

I will get around to filing the formal bug soon. I'm currently moving to a new MacBook so I've been offline.

However I just had a quick look at the sysdiagnose file that I linked in previous post.

I can see other successful calls preceding the failed call.

The error in log seems to be

error 2026-07-09 18:08:10.408839 +0100 callservicesd SessionCore_Create.mm:92 AudioSession creation failed with an error: <NSError:0x7ccf812160(NSOSStatusErrorDomain:2003329396) - { NSLocalizedDescription = "Session creation failed in server"; }>

Maybe that might be of help?

Thanks

Dave

Thanks so much for the error message, yet the sysdiagnose is great.

I had to look it up a little bit, I can be wrong as I'm not an audio engineers but it seems like the audio recording isn’t starting right when you begin a transmission through the System UI. This might be because the system isn’t properly starting the audio process. So are you using the audio for anything else? Do you have a a simple focused sample showing this issue for any chance?

Definitely an interesting error that will be great to take a look at.

Let me know when you file the bug. Thanks

Albert  WWDR

Hi Albert i have filed the bug

FB23709940

Thanks

Dave

Thank you for doing that Dave. The bug was routed to the correct team and they are reviewing it right now. Thanks!!

You can see the status of your feedback in Feedback Assistant. There, you can track if the report is still being investigated, has a potential identifiable fix, or has been resolved in another way. The status appears beside the label "Resolution." We're unable to share any updates on specific reports on the forums.

For more details on when you'll see updates to your report, please see What to expect after submission.

Albert  WWDR

This is still happening on iOS27 Beta 4. My very first call after iOS27 beta4 installation failed. I cannot repeat it since.

Also a colleague of mine has now seen the same issue.

I have not received any feedback to my FB.

@davemaj Thanks for the post. I know some teams are not very chatty on their bugs, I assure you that is being treated as a bug and they'll let you know when has been fixed.

Albert  WWDR

I have found way where we can repeat this issue as follows in iOS27Beta4

1) Power phone completely off. Black screen.  No power
2) Wait say 10 sec
3) Power phone on
4) Unlock the phone with your passcode
5) IMMEDIATELY Open my App
6) Wait a while (Say 20 sec). You could actually wait here for hours and still see the bug!
7) Make an outgoing call

If I unlock phone and wait 20 sec and then open my App then I will NOT get the bug.

So I think that this is something to do with Phone Unlock

I am presuming this is some type of Race condition after UNLOCK where iOS is setting up something to do with Callkit and if at the same time my App opens and creates instance of CXProvider then something gets messed up.

theMDSCXProvider = [[CXProvider alloc] initWithConfiguration: the_providerconfig];

To try prove this I changed my code so for my first outgoing call (Only) then I will invalidate the instance that I had setup when App powered up (line above)

        [theMDSCXProvider invalidate];
        theMDSCXProvider = nil;

and then I create a brand new theMDSCXProvider.

When I did that I cannot repeat the problem

I do not know if this is the only way this issue happens. When I saw this issue in previous Betas it was happening after other calls had already been made since the phone had been unlocked.

I updated my FB23709940

@davemaj Thanks for the post, looks like you also provided the same information on the bug report for the team. In order to avoid duplicate threads, I would recommend to keep providing all your findings in the bug only.

Thanks again for this. Please keep an eye out for the reply from the team in the Feedback Assistant.

Thanks

Albert  WWDR

Sorry for not following up on this earlier, I didn't see this thread until today.

The rest of this post goes into the details of what's going on; however, two critical points I want to highlight:

1. This issue is a longstanding issue that can happen across a broad range of system releases. I would strongly recommend applying the workaround as a preventative measure.

2. We shipped a fix for this in iOS 27 beta 5, so if an issue like this occurs again after that point, please file a new bug and then file a code-level support request asking for my help. I'd like to close this issue down "for good", so I want to know if anything like it starts happening again.

I have not seen any issues with didActivateAudioSession not getting called by iOS in many, many years with many thousands of devices.

Unfortunately, I think this is mostly a case of timing and luck. There's a longstanding issue that I only recently came to understand that causes exactly the behavior you're seeing. There's an extended forum thread on the issue here, but the workaround is fairly simple— just call "setConfiguration" before you report a call.

Internally, this pushes your app’s latest AudioSession ID into callservicesd, ensuring that it's able to then activate the call.

Covering a few details:

Then one outgoing call failed, and every subsequent call failed until I restarted the app.

This is standard behavior for the bug above. callservicesd has an invalid session ID for your app, so it stays "stuck" in that state until it gets a new ID, which is what "setConfiguration" does.

Looking at your bug:

FB23709940

In the console log archive, searching for "failed due to session lookup failure for SessionID" will find many messages like this:

2026-07-09 18:08:10.401677+0100 audiomxd: (AudioSessionServer) [com.apple.coreaudio:as_server] AVAudioSessionXPCServer.mm:231   -[AVAudioSessionRemoteXPCClient createProxySession:reply:] failed due to session lookup failure for SessionID 0x0

Have there been similar reports of this from other VoIP app developers with iOS27?

I'm not aware of any specific issue tied to iOS 27 (note that the thread about is about iOS 18). Having said that, the exact circumstances that create the bug are not well understood and it's very likely that changes within the OS can make the issue more or less likely, particularly when combined with changes to your own implementation.

Has that area of the framework been modified in iOS27?

CallKit hasn't, but the problem here is that CallKit isn't where the problem originates. The problem actually "starts" with your app getting an invalid session ID from the audio system, which it then hands to CallKit. The audio system is basically "always" changing, which is what's made identifying the exact underlying cause somewhat challenging.

For example, if didActivateAudioSession does not happen after 10 seconds, then what should I do?

So, I strongly suspect that the setConfiguration workaround I mentioned above will resolve all/most of these issues. However, if it DOESN'T work, then my suggestion would be that you inform the user there’s a problem and that they need to restart your app. I think what I would actually do is:

• Collect any diagnostic data you want to collect.

• Post an alert telling the user there's an issue.

• When the user touches “OK", call abort() and intentionally crash your app. Do this in a "distinctly" named function ("SessionActivateFAIL_CrashingNow()") so you can clearly identify this particular crash from any other app issue.

My expectation is that this will rarely, if ever, occur, as my workaround has been extremely successful (see the reports in the thread above). However, if the setConfiguration fails, then I'm not confident your app will really be able to recover.

Notably, the issue on this thread:

Back in Oct 2016 (!!) there was a thread for a similar issue https://developer.apple.com/forums/thread/64544?answerId=191868022#191868022

They were “one-off failures" rather than the app completely failing for every subsequent call, which is what I see now.

Apple's Stuart Montgomery mentioned it was reported in Radar # 28774388 and suggested workarounds at that time.

...was related to a very specific timing issue between CallKit's calling process, audio initialization, and app start-up. More the point, it was actually reported against iOS 10, which is when CallKit was originally introduced. That particular bug was addressed years ago, but, more importantly, most of this code was reworked when we redesigned the call UI a few years ago.

The critical point here is that the reason the problem persists is that the problem is with callservicesd's management of your audio session, NOT your app’s side of the session. If setConfiguration doesn't fix the issue, then I wouldn't expect anything else to fix it.

At that time I found that if I "configureAudioSession" in the completion block of a successful theMDSCXProvider reportNewIncomingCallWithUUID:theUUID update:theCallUpdate completion

My longstanding advice on this issue has been to "do what Speakerbox does", which means configuring your audio session just before you fulfil CXStartCallAction and CXAnswerCallAction. Timing-wise, that's similar to the point you'd be when reportNewIncomingCallWithUUID completes, but audio session configuration issues are common enough that I would still recommend simply copying what our sample does.

I have found a way where we can repeat this issue as follows in iOS27Beta4

Interesting. That's the first repeatable case I've seen for this. Please let me know if this also happens on beta 5 and later.

I am presuming this is some type of race condition after UNLOCK where iOS is setting up something to do with Callkit and if at the same time my App opens and creates an instance of CXProvider then something gets messed up.

Sort of. I believe you’re actually managing to initialize your app’s provider stack before the audio system is "live", which then hands a bad session ID to callservicesd. My guess is that significant audio initialization is being triggered at first unlock, which makes it easier to win the race.

When do you actually create your provider? And do you initialize your audio session before you create your provider?

and then I create a brand new theMDSCXProvider. When I did that I cannot repeat the problem

Creating a new provider implicitly means that you're calling setConfiguration, which pushes the current session ID.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

Minor correction to this:

We shipped a fix for this in iOS 27 beta 5, so if an issue like this occurs again after that point,

After a bit more investigation, the "immediately after" unlock issue you reported is a slightly different variation of the larger issue and, it appears, the fix we shipped in beta5 does prevent that particular edge case. The team is looking into possible fixes but, in the meantime, the "setConfiguration" workaround I described should still work.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware