iPhone 17 Pro max Bluetooth HFP call audio routing fails, media audio works

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

First off, a warning/concern here:

3 paired devices were present

The nature of how the system manages Bluetooth events means that it's possible for Bluetooth accessories to "interfere" with each other in annoying/unexpected ways. For example, if my car is on and I attempt to listen to audio through my normal Bluetooth headphones, what actually happens is:

• Playback starts to the headphones.

• ~1s later, playback stops.

What's actually happening is that the car head unit is receiving activity notifications from the device and it's then sending a "pause" event BACK to the iPhone because it thinks my phone shouldn't be playing.

Arguably, this is a bug but the problem is that it's not something the system can really "do" anything about- both of the basic system behaviors (sending activity notifications and accepting commands from the inactive route) are long-standing behaviors which are critical to a variety of other features, so changing them would break other useful functionality. Similarly, the range of devices is so broad that special casing individual devices isn't practical. Ultimately, all the system can really do is behave in a predictable way and trust/hope that accessories will do what the user actually wants.

All of that means that this kind of testing HAS to start with ONLY one device involved, then move to multi-device testing if the problem doesn't occur. Keep in mind that one of the ways you'll get multiple device failures like this:

Tested with multiple earbuds: Samsung, OPPO, Huawei and CMF Buds Pro 2.

...is when some OTHER device is generating the same control commands in "reaction" to their actions.

In any case, if multiple devices are involved, then the critical detail is identifying exactly which device is generating the change (like my car head unit above), not the devices that are being disrupted (like my headphones).

I captured a sysdiagnose right after reproducing the issue.

So, I looked at your sysdiagnose and didn't see any obvious cause or explanation; however, it's also very difficult to map audio system activity onto real-world behavior without a lot more detail about what actually "happened". What would actually be most helpful here is a sysdiagnose with a corresponding set of notes that listed out as accurately as possible exactly when and "what" happened. That includes:

• The exact device state at the point the call arrived.
• When the call arrived.
• When the call was answered.
• When the call ended.
• Exactly what and when was heard and experienced in terms of audio routing.

This should also be done on as "clean" a device as possible. Ideally, that would be a factory reset device with nothing installed, but at a minimum, you should power the device off, leave it off for 5-10 min*, power on the device, then begin your testing.

*This creates a clear time "gap" in the log which makes it easier to separate between the new system run and old log data.

Related to the testing side:

The issue affects cellular calls, FaceTime Audio, Telegram, and Signal.

I'd actually recommend doing the test above with our CallKit sample code. That sample is effectively a "fake call" app, which replicates the entire call flow without actually doing any networking. That greatly reduces overall log noise (always a good thing) and generally makes the testing scenario as simple as possible.

Also, looking at the log, it looks like all of this issue was tied to outgoing call reports. Do you see the same behavior with incoming calls?

Tested with multiple earbuds: Samsung, OPPO, Huawei, and CMF Buds Pro 2. The behavior is similar with all of them.

Two other data points:

1. Have you tested this with AirPods?

2. Are you seeing this behavior with more "conventional", single-unit, Bluetooth headsets?

The second test helps show that this is specifically about general HFP handling and not tied to any of the "tricks" that allow "bud" style headphones to function. Similarly, if the problem is happening with AirPods, that completely rules out any third-party hardware issues.

Has anyone seen similar behavior on iPhone 17 / iOS 26 with Bluetooth HFP call audio? Could this be a known iOS 26 / Apple N1 / Bluetooth firmware issue, or does it look more like a hardware defect of this particular device?

I'm not aware of any general issue.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

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?