Issues Handling Multiple Incoming Calls in CallKit

1. Is there a documented system-imposed limit on the number of calls per group or total calls, even if maximumCallGroups and maximumCallsPerCallGroup are set higher?

There is not, however, you're also not really close to any limit. If you directly create a CXProviderConfiguration, you'll find that its default configuration is actually:

configuration.maximumCallsPerCallGroup = 5
configuration.maximumCallGroups = 2

...and the internal unit tests for CXProviderConfiguration itself (not the call UI) are much higher than that.

Moving to here:

Observed Behavior: Despite the configuration, the system UI seems to limit the number of calls per group, often defaulting to "End & Accept" instead of "Hold & Accept" when a third call comes in.

After playing around with this in Speakerbox, I think this is actually a quirk/bug in the call UI itself, not with CallKit's larger infrastructure. CallKit will happily let you have more than two live calls, but you need to put the "current" call on hold before you report the new call. If you haven't already, please file a bug on this, then post the bug number back here.

1. How does the system UI behave when these limits are exceeded? Are there known UI constraints or fallback behaviors?
2. Are there best practices for handling scenarios where the system UI cannot display all calls, such as gracefully managing incoming calls or providing alternative UI solutions?

My main suggestion here is to try it out for yourself. Speakerbox is perfect for this, since it lets you mock up and experiment with things without dealing with multiple devices/networking/etc.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

I filed a bug in feedback assistant , is there another way to file a bug to get a faster resolution?

FB20985796 (Issues Handling Multiple Incoming Calls in CallKit)

FB20985796 (Issues Handling Multiple Incoming Calls in CallKit)

Perfect, thank you.

I filed a bug in Feedback Assistant. Is there another way to file a bug to get a faster resolution?

No, not really. In this particular case, I think you should plan on working around the issue instead of waiting for the system to address this. This is a VERY longstanding issue (I suspect it's basically "always" done this), which makes it hard to justify as a high-priority fix.

In terms of working around this, two tools I'd highlight here:

1. The direct workaround is to put your active call on hold before you report the "next" call.

2. In case you're not aware, you can safely "hide" new call reports while on an active call by reporting your new call using the same UUID as your currently active call. If your call is still active, you'll get CXErrorCodeIncomingCallErrorCallUUIDAlreadyExists (which you can ignore). If the existing call has ended (this can happen due to communication race conditions in the call infrastructure), then you'll get a new call started. Either way, you won't crash.

Combining those two tools, here is what I'd do to make 3+ calls work:

• When the incoming call report arrives, use #2 to "hide" the call.

• Play some kind of tone/sound to the user so that they know a new call will arrive "soon" (something like the call waiting tone).

• After a few seconds/some number of tones, put the call on hold and then call reportNewIncomingCall again to push the new call report for the user to answer.

Of course, that's just one option among many. For example, you could also post a notification yourself (along with the tone) and let the user tell you what to do from that point.

That leads to my final point, which is that CallKit is fundamentally an interface framework, not a “VoIP" framework. What I mean by this is that you ultimately have FULL control over the audio a user actually hears and how you present/manage that. Many conferencing apps support user counts FAR above what CallKit could ever conceivably report (think "100s" or even "1000s"). They do that by reporting a single "call" to the system (which represents the active meeting/call)... and then just adding/removing users to that audio stream as they see fit. There's nothing wrong with that approach.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware