Thank you, Kevin. I understand your concern about the original sysdiagnose showing 3 paired devices. That was from my earlier non-clean testing. After your point about possible accessory interaction, I did a cleaner test. I restored the iPhone through a computer, set it up as a new iPhone, did not restore any backup, did not transfer data, and did not pair my Huawei Watch or any other old Bluetooth devices. For the new test, only AirPods Pro were paired. I captured a new sysdiagnose after that clean restore: sysdiagnose_2026_06_10_14_56_45+0300_iPhone_OS_iPhone_23F81.tar.gz I also attached this new sysdiagnose to Feedback Assistant report FB22925597. In this new clean sysdiagnose, the restore appears to have completed successfully. The restore log contains: CHECKPOINT FINISHED-ENGINES:(SUCCESS) It also shows: update_centauri After the clean setup, Bluetooth status shows only one paired audio device: AirPods Pro. No Huawei Watch, no old Bluetooth pairings, and no third-party earbuds were involved in this test. The issue still reproduced. From the log timing: Around 14:51:53, the audio route was HeadphonesBT. Around 14:52:16, when the phone call flow started, the route changed to ReceiverAndMicrophone / PhoneCall instead of staying on HeadsetBT. Around 14:52:20, the call is logged as com.apple.mobilephone with kCallSubTypeVoLTE and callOutgoing. At the same time, the accessory log shows IsConnected = 0. Around 14:52:26, it changes back to IsConnected = 1. Around 14:52:33, the route finally becomes HeadsetBT. This matches the real-world behavior I hear: the call starts, audio falls back to the iPhone receiver/speaker, AirPods disconnect/reconnect, and only after that the route may return to the Bluetooth headset. There is also an idle disconnect in the same clean log. One Bluetooth status snapshot shows AirPods Pro connected, and a later snapshot shows the same AirPods Pro not connected. The powerlog also shows IsConnected = 0 around 14:57:08, after several minutes of accessory usage. So at least for the latest reproduction, this does not appear to be caused by multiple paired accessories or another Bluetooth device sending commands. The device was freshly restored, no backup was restored, and only AirPods Pro were paired. Regarding your other questions: Yes, I tested with AirPods Pro. The issue still reproduced. The latest clean reproduction was with an outgoing cellular VoLTE call. I have not yet completed a clean incoming-call test. I have not yet tested with a conventional single-unit Bluetooth headset. I can also try the CallKit sample if that would still be useful, but the current clean sysdiagnose already reproduces the issue with the stock Phone app and only AirPods Pro paired. Previous sysdiagnose logs also contained CentauriFirmwareEvent / BT firmware crash entries, including subsystem = BT, host-reason = firmware crash, BTMAIN panic, link_manager_thread, LMAC_5G watchdog expired, and SCAN watchdog expired. In one earlier log, Bluetooth state changed to powered=0 / connected=0 and later returned to powered=1 / connected=1 around the Centauri event. But the important update is that after a clean computer restore, with no backup and only AirPods Pro paired, the Bluetooth call audio routing / disconnect-reconnect issue still occurs. Could you please take another look at the new sysdiagnose attached to FB22925597?

https://feedbackassistant.apple.com/feedback/22925597