I have not seen any issues with didActivateAudioSession not getting called by iOS in many many years with many thousands of devices.
However with iOS27 beta code I have seen a few times that when making an outgoing call it never gets called.
All subsequent outgoing calls fail until I dismiss and relaunch the App.
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.
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
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
