Callkit returns error code=106 which is not on official document

Question

Created 20h

Replies 1

Boosts 0

Participants 2

Callkit returns error code=106. I can't find what this error code means in official documents. What is this error code? Has anybody seen this error code so far?

My app is VoIP app using APNs VoIP push. Below is log example of my app.

2026/04/26 09:01:45.752 [436:103]CallManager incomingCall(::::_:completion:):228: error Error Domain=com.apple.CallKit.error.incomingcall Code=106 "(null)"

Answered by DTS Engineer in 902792022

Callkit returns error code = 106. I can't find what this error code means in official documents. What is this error code? Has anybody seen this error code so far?

This is actually the first time I've ever seen this error, but it turns out there is a mechanism in place to prevent VERY high frequency call reports from rendering the device inoperable. Error "106" is the error code returned when you trip that mechanism and CallKit starts blocking your calls.

That leads me to the more important question, namely how fast/frequently are you reporting calls? It's not clear to me that the exact trigger is, but it looks to me like you'd need to be reporting calls VERY frequently, well above what "normal" usage patterns would indicate.

One side note on this - I don't think simply reporting two calls "at the same time" (because two different users happened to call the user) would be enough to trigger this, but that doesn't mean it's a great user experience. In practice, your calling app should be staggering simultaneous call reports anyway, simply to ensure the user can see what's occurred and respond "reasonably". Two approaches to that:

On newer devices (26.4+), this is one of the many edge cases the new "didReceiveIncomingVoIPPushWith" delegate was intended to address. When receiving "simultaneous" pushes, you can PKVoIPPushMetadata.mustReport and delay/discard any push that's set to "no".
On older systems, it's also fairly safe to delay or discard "simultaneous" call reports, even without the API above.

Expanding on that second point, this has never been documented, but PushKit has always been significantly more lenient in its call reporting requirements than a strict reading of our call requirements would imply. Case in point, if you experiment with the timing, you'll find that CallKit will allow you to "skip" reporting a call for several seconds after you previously received a call, even if the call we IMMEDIATELY ended. So, you can do the same thing as #1 on older systems (which don't have the new delegate) as long as you keep the timing fairly conservative.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

Answer 1

DTS Engineer OP

Apple

15h

Accepted Answer

Callkit returns error code = 106. I can't find what this error code means in official documents. What is this error code? Has anybody seen this error code so far?

This is actually the first time I've ever seen this error, but it turns out there is a mechanism in place to prevent VERY high frequency call reports from rendering the device inoperable. Error "106" is the error code returned when you trip that mechanism and CallKit starts blocking your calls.

That leads me to the more important question, namely how fast/frequently are you reporting calls? It's not clear to me that the exact trigger is, but it looks to me like you'd need to be reporting calls VERY frequently, well above what "normal" usage patterns would indicate.

One side note on this - I don't think simply reporting two calls "at the same time" (because two different users happened to call the user) would be enough to trigger this, but that doesn't mean it's a great user experience. In practice, your calling app should be staggering simultaneous call reports anyway, simply to ensure the user can see what's occurred and respond "reasonably". Two approaches to that:

On newer devices (26.4+), this is one of the many edge cases the new "didReceiveIncomingVoIPPushWith" delegate was intended to address. When receiving "simultaneous" pushes, you can PKVoIPPushMetadata.mustReport and delay/discard any push that's set to "no".
On older systems, it's also fairly safe to delay or discard "simultaneous" call reports, even without the API above.

Expanding on that second point, this has never been documented, but PushKit has always been significantly more lenient in its call reporting requirements than a strict reading of our call requirements would imply. Case in point, if you experiment with the timing, you'll find that CallKit will allow you to "skip" reporting a call for several seconds after you previously received a call, even if the call we IMMEDIATELY ended. So, you can do the same thing as #1 on older systems (which don't have the new delegate) as long as you keep the timing fairly conservative.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware