CallKit does not activate audio session with higher probability after upgrading to iOS 18.4.1

@DTS Engineer Thank you for the confirmation.

It will take at least another two weeks before we roll out to production. We will monitor the effectiveness of the workaround and provide the results here.

Anyone with any luck fixing/improving this ?

Anyone with any luck fixing/improving this ?

Are you calling "setConfiguration" before each call report as I suggested here?

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

Hi @DTS Engineer,

In my practice dealing with CallKit I came to conclusion that changing CXProvider configuration during a call is a bad idea. Sometimes this was causing providerDidReset being called and first call got dropped. Can you confirm or deny my observation? Do you suggest to call setConfiguration even there is an other active call or call on hold?

In my practice dealing with CallKit, I came to the conclusion that changing CXProvider configuration during a call is a bad idea. Sometimes this was causing providerDidReset being called, and the first call got dropped. Can you confirm or deny my observation?

That's hard to say. On its own, I wouldn't expect it to be an issue or, more specifically, it's much more likely to "trigger" a pending failure than it is to create one. As background context, the primary cause of providerDidReset is mediaserverd itself crashing, not "normal" system behavior. I'm sure there are cases where a call to "setConfiguration" was the direct "trigger", but that doesn't mean that NOT calling "setConfiguration" would have prevented the crash. It's also possible/likely that "setConfiguration" DID actually "cause" providerDidReset... because the media system was already in a bad state, and the setConfiguration call is what caused callservicesd to detect a problem.

However, having said all that...

Do you suggest calling setConfiguration even if there is another active call?

There's no reason to call setConfiguration if you already have an active call. One thing to keep in mind here is the difference between the "call" abstraction CallKit provides and the actual behavior of the audio system. Your app only has one "connection" to the audio system, no matter how many calls you have active. An action like switching from one of your calls to another call changes call state, but it doesn't really affect the audio system. As far as the audio system is concerned, your app is just sitting there with an active session.

or call on hold?

This case is a little bit more “grey," but no, I probably wouldn't bother. Jumping back to my original analysis here:

"No, it can't. It's possible that it may mask the issue in some cases; however, it's also very likely to introduce failures somewhere else. In any case, in terms of what the real problem is, the key issue is the "SessionID 0x0" here: ... That session ID is the global identifier callservicesd uses to "find" your app’s audio session so that it can manage and activate it. It's not explicitly set by your app because it's actually included in the configuration payload you configure (and modify) CXProvider with. I'm not sure how it became NULL, but if I had to guess, it was either a side effect of an out-of-order process initialization (creating CXProvider prior to main) or a side effect of a system-wide disruption that wasn't handled properly."

Something that may not be obvious from that analysis is that the issue here is about recovering from a previously bad state, not actually "being" in a bad state. Putting that in more concrete terms, the "setConfiguration" workaround works because it's retrieving a valid session ID from your app and passing it over to callservicesd. The only reason that would "fail"... is because the audio system isn't working properly. If you "know" the audio system is working correctly, then there isn't really any reason to call setConfiguration.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware