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

Hi @DTS Engineer I would like to follow up this issue. From our metics, looks like after upgrading to iOS 18.4.1,** the incoming call no audio issue is increased**. we did not observe outbound call increased. Here is the incoming call process in our app incoming call from push notification, app call reportNewIncomingCall after report incoming call success, our app will configure audio session our app will post the configureAudioSession to another thread reportNewIncomingCall callback configureAudioSession in another thread (app will wait for the user press answer button, may take several seconds) user answer the call and AnswerCallAction will callback app will finish the signaling answering logic action.fulfill() callkit shall setActive Audio session didactivate audio session shall be triggerd, but it's not. our app detect no audio for 5 seconds try to setActive(YES) for workaround, sometimes it will success, sometimes it won't if the setActive(YES) failed, it will return "Session Activation failed" error. No more information indicate why it failed. Could you please review the following processes for any potential issues? We are aware of a possible race condition when configuring the AudioSession in step 5 on another thread, which we plan to address. This could occur if the user answers the call quickly in step 6, potentially causing a conflict between the CallKit active audio session and step 5. However, based on user logs, we've observed that most users don't answer calls immediately. This suggests the race condition may not be the root cause, unless CallKit performs additional audio session processes after step 4. Could you confirm this? We've noticed from some user logs that the issue may arise when the app is in the background and awakened by an incoming call push notification. In some instances, once the issue occurs, it affects all subsequent incoming calls. Despite an increase in occurrences, the issue still has a low incidence rate of 0.2%. This leads us to suspect that the problem may be caused by a race condition somewhere in the process. Your insights on these points would be greatly appreciated. Thank you very much for your assistance!