Hi @DTS Engineer Apologies for the delayed update. Yesterday, we completed the rollout of your workaround solution, and our metrics indicate its effectiveness. The issue count has decreased significantly during the implementation, dropping from 6000 per day to 1000 per day as of today. We would like to express our gratitude for the workaround solution you provided. Currently, we have implemented the workaround only for incoming calls, as these were the primary source of issues observed in our app. We plan to extend the implementation to outbound calls as well. Any other suggestions for this process would be greatly appreciated.

@DTS Engineer Thank you for the confirmation. It will take at least another two weeks before we roll out to production. We will monitor the effectiveness of the workaround and provide the results here.

@DTS Engineer Sure, will do. We have re-implemented the workaround solution and plan to roll it out to production in two weeks. Before proceeding, could you please help double-check if the workaround is implemented as expected in our lab app? Thank you for your assistance. Sysdiagnose log file sysdiagnose_2025.10.28_18-28-20_0800_iPhone-OS_iPhone_23A355.tar.gz has been uploaded in the ticket. FB20789841 (CallKit does not activate audio session, the issue rate increased on iOS 26.)

@DTS Engineer Thank you for reviewing the logs. Upon examination of the solution, we discovered that it was not implemented as expected. Specifically, we did not call setConfiguration before reporting incoming calls each time. We will re-implement the workaround solution, and it will require additional time for verification.

Hi @DTS Engineer After rolling out the workaround solution ("setConfiguration" immediately before reporting a new call), the issue still persists. So looks like the workaround can not resolve this issue. cc @goat_herd Today, we reproduced this issue once on iOS 26, WITH the workaround solution. I have reported a bug. FB20789841 (CallKit does not activate audio session, the issue rate increased on iOS 26.) Base on our metrics, this issue is the primary contributor to one-way audio problems in our app and continues to increase as iOS 26 adoption grows. The occurrence rate seems to be twice as high on iOS 26 compared to iOS 18. Our metrics currently show a 0.67% rate for iOS 26, and this figure is still rising. !!!Given the ineffectiveness of the workaround, we respectfully request that this issue be given higher priority. This is particularly important as iOS 26 is being adopted by an increasing number of iPhone users.!!!

@Sierre Thank you for the information, glad to here that's working. We also have implemented the suggested solution in our app and are awaiting rollout. We hope it will also help resolve the issue with our app.

@DTS Engineer The iOS 26 audio session issue has significantly worsened since the iOS 26 release. Currently, it affects 0.628% of calls, resulting in thousands of impacted calls daily, compared to approximately 300,000 total calls per day with iOS 26. We anticipate this issue to escalate further as iOS 26 adoption increases. Given the critical nature of this problem to our operations, we respectfully request that it be given higher priority or escalated for immediate attention.

Hi @DTS Engineer I would like to update our metrics for iOS 26 regarding this issue. It appears that the problem persists on iOS 26 and has worsened as the iOS 26 call count has increased. We will keep eyes on our metrics and post update here. Has there been any specific change on iOS 26? We start to implement your recommended solution, but we still need time to release it to our production environment.

Hi @DTS Engineer Is this with or with the workaround I recommended? No, we may try your recommended workaround solution. However, it won't be implemented quickly before we release to production.

Hi @DTS Engineer Just to provide an update: Our metrics show that iOS 18.6 is still maintaining a high one-way ratio. BTW, since you've raised this issue to your team, is it possible to share the plan or indicate in which version the issue is expected to be resolved?

Are you absolutely certain of this? If so, then do you have any idea/guess as to how much time was between the last working call and the first failed call? 36 minutes, base on our log, the call at 16:58 have no problem. and the app went into background from 17:00 - 17:36(screen lock), until an incoming call push woke up the app. The issue began to occur on this call and subsequent calls. "My intuition is that #2 will probably solve the issue, but if I'm wrong, then #3 should ensure that the issue is corrected, and the next call will work." So, you recommended we set the configuration before CallKit is first used after the app starts? Will this overwrite the configuration of CallKit? We may give this a try, but it's difficult to determine if it will work or not since it's hard to reproduce. We might need to implement this in our production environment and check the metrics to assess its effectiveness. I will discuss with team.

Hi @DTS Engineer We attempted to capture a fresh sysdiagnose, but we were unable to reproduce the issue in our lab. We will continue our efforts to replicate the problem. [quote='852684022, DTS Engineer, /thread/783870?answerId=852684022#852684022'] PushKit and CallKit should both be configured in applicationDidFinishLaunching. The goal here is that you want CallKit to be fully configured before your PushKit delegate is called to deliver a VoIP push. I would add an additional call to set the configuration before you call "reportNewIncomingCall" on the first push you receive, as this should ensure that callservicesd has a valid session ID. Note the configuration doesn't need to change, so setting the configuration to the existing value will work fine. [/quote] I believe our app shall have done this correctly, as both incoming and outgoing calls functioned properly before the problem occurred. Our application did not restart or reinitialize during this time. The issue does not happen on the first call(push). Regarding "backstop", Are you referring to the reconfiguration of the audio session? After the issue occurs, our application does attempt to reconfigure the audio session in subsequent calls. However, this approach has not been successful in resolving the problem.

Hi @DTS Engineer Thank you so much for checking this. Regarding "try to setActive(YES) for workaround", this only happen 5 seconds after our app detect Audio Session is not activated call started. We agree the major the key issue is the "SessionID 0x0". I have created a feedback for this issue, and submit sysdiagnose/console logs in it. However, the issue happen at Apr 4, the sysdiagnose was generated at Apr 7. So We are not sure if it could contain the key data at Apr 4. Please help to check it. The issue happen intermediately, and it's hard to reproduce. We can update the feedback again once it can be reproduced again. feedback ticket: FB19429215 (CallKit does not activate audio session with higher probability after upgrading to iOS 18.4.1)

Hi @DTS Engineer Now we can reproduce this issue: When the issue occurs, incoming calls always have no audio (both ways). The "setActive(YES) for workaround" in our app CANNOT fix the issue. For outbound calls, there is no audio (both ways) at the beginning. The "setActive(YES) for workaround" in our app CAN fix the issue. The issue always occurs for subsequent calls, unless the app is restarted. "setActive(YES) for workaround" means our app will force AVAudioSession to setActive when it detects that CallKit did not activate the AVAudioSession. The bug is likely Apple-related. Could you please investigate the console logs? Thank you again for your assistance. Please find the console logs in https://drive.google.com/drive/folders/1Uo7BcS5nzmRPmFaKg7-5_X3s-Tk9cwvt?usp=drive_link incoming call example: file: console-incoming.log 18:44:22 start ring & report incoming call default 18:44:22.512414+0800 Glip Provider <private> was asked to report a new incoming call with UUID: <private> update: <private> 18:44:22 audiomxd start report errors, no audio both ways error 18:44:22.533627+0800 audiomxd AVAudioSessionXPCServer.mm:404 -[AVAudioSessionRemoteXPCClient createProxySession:reply:] failed due to session lookup failure for SessionID 0x0 18:44:28 our app try to active audio session for workaround, doesn't work default 18:44:28.998028+0800 audiomxd AudioSessionServerImp.mm:957 { "action":"activate", "session":{"ID":"0x6b102","name":"Glip(1554)"}, "details":{"->":"entry"} } outgoing call example: file: console-outgoing.log 19:13:27 make call default 19:13:27.738603+0800 callservicesd Dialing new call due to requested start call action: <private> 19:13:27 start report errors, same as incoming call, no audio both ways error 19:13:27.744302+0800 audiomxd AVAudioSessionXPCServer.mm:404 -[AVAudioSessionRemoteXPCClient createProxySession:reply:] failed due to session lookup failure for SessionID 0x0 19:13:33 our app try to active audio session for workaround, audio recovery default 19:13:33.423110+0800 audiomxd AudioSessionServerImp.mm:1056 { "action":"activate", "session":{"ID":"0x6b102","name":"Glip(1554)"}, "details":{"->":"exit"} }

Hi @DTS Engineer, Our new metrics indicate that the one-way issue caused by "audio session not activated" accounts for more than 50% of cases. Given this significant percentage, could you please revisit and reexamine this issue? Thank you