Strange behavior of Speakerbox (or CallKit) with headset operation

Question

Created Jul ’25

Replies 1

Boosts 0

Participants 2

I've run Speakerbox(https://docs-assets.developer.apple.com/published/8e99045a90e2/MakingAndReceivingVoIPCallsWithCallKit.zip) to check the behavior of CallKit. When there was one active call and one on hold and another call was received, the behavior was defferent depending on whether I operated it from a headset or not.

No headset or operated from CallKit screen
- When "End & Accept" tapped: the active call is hung up, and the received call is answered.
- When "End Held & Accept" tapped: the held call is hung up, the active call is held, and the received call is answered.
Operated from headset
- Answer opeation cannot be performed for unknown reasons
- Disconnect operation caused that all calls other than the one on hold are hung up and the held call is unheld.
- Hold operation caused that the active call is held and the received call is answered. (Strangely, there are two held calls.)
  - And when I toggle calls at this time, one of the two on hold is hung up for unknown reasons.

I tried changing the settings of CXProviderConfiguration and CXCallUpdate, and changing the options in the Audio Session category, but it did not improve.

I checked CXActions occurring, and it was as follows.

(Call A = held call, Call B = active call, Call C = received call)

Disconnect (or Answer?) operation
- (lacking CXEndCallAction for Call A)
- CXEndCallAction for Call B
- CXAnswerCallAction for Call C
- CXEndCallAction for Call C <- weird
- CXSetHeldCallAction for Call A onHold=false
Hold operation
- (lacking lacking CXEndCallAction for Call A)
- CXSetHeldCallAction for Call B
- CXAnswerCallAction for Call C
Toggle calls
- CXSetHeldCallAction for Call C onHold=true
- CXSetHeldCallAction for Call A onHold=false
- CXSetHeldCallAction for Call B onHold=false <- weird
- CXEndCallAction for Call B

Boost

Answer 1

DTS Engineer OP

Apple

Jul ’25

I've run Speakerbox(https://docs-assets.developer.apple.com/published/ 8e99045a90e2/MakingAndReceivingVoIPCallsWithCallKit.zip) to check the behavior of CallKit. When there was one active call and one on hold and another call was received, the behavior was different depending on whether I operated it from a headset or not.

SO, the first thing to understand is that what CallKit is actually reacting to are specific commands being sent through the HFP ("Hand Free Profile"), the Bluetooth profile headsets (meaning, devices which can both play and record audio) use. The HFP profile is large and complicated enough that there can be significant differences in the commands headsets send.

The behavior of most "popular" headsets has consolidated around a common set of behavior (which is why this works at all), but if you're testing with older or uncommon headsets, you may see weird behavior.

*Note that "age" isn't reliable here because there are many headsets which are actually still using very old chips/implementation, particularly lower cost headsets.

This also means that trying to directly "fix" these issues yourself is almost always a mistake, as adjusting your behavior for one headset tends to break other headsets. That might be worthwhile if there are external reasons why THIS particular headset must work, but otherwise all you can really do here is file a bug that includes the full details of the hardware you're testing with, as well as whatever is going wrong.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

0