Audio session fixes

[mikaelwills]

iOS CallKit Audio Session Race Condition Fix - PR Description

Incoming calls on iOS with CallKit were failing because of a race condition between WebRTC (used internally by Siprix) and CallKit competing for audio session control. WebRTC needs to initialize audio immediately when the SIP INVITE arrives (to generate the SDP answer), but CallKit expects to control when the audio session activates. When WebRTC wins the race, iOS doesn't call the didActivate callback, which means we never actually accept the call even though the UI shows "connected".

Changes

1. Defer SIP Accept Until didActivate

Instead of accepting the SIP call immediately in CXAnswerCallAction, we now:

• Store the call in _callPendingAnswer
• Wait for didActivate to fire
• Accept the call once audio is ready

Why it's critical: Accepting the call before the audio session is ready leads to no audio routing. iOS needs to know the audio path exists before the SIP connection completes.

2. Fulfill CXAnswerCallAction Immediately

Fulfill the action right away to tell CallKit we're ready to proceed:

action.fulfill()  // Triggers CallKit's audio activation flow

Why it's critical: If we don't fulfill, CallKit won't proceed with audio activation, so didActivate never fires and we're stuck waiting forever.

3. Force Reset Interrupted Audio Sessions

In didActivate, detect when WebRTC has already activated the audio session:

if !audioSession.isInputAvailable || audioSession.isOtherAudioPlaying {
    // Force reset to clear interrupted state
    try audioSession.setActive(false)
    try audioSession.setActive(true)
}

Why it's critical: WebRTC activating audio before CallKit leaves the session in an "interrupted" state. Resetting clears this and lets us reconfigure for VoIP properly.

4. Audio Configuration in didActivate (Not onSipConnected)

Added ensureAudioSessionConfigured() method that sets up VoIP audio settings:

try audioSession.setCategory(.playAndRecord, options: [.allowBluetooth, .allowBluetoothA2DP])
try audioSession.setMode(.voiceChat)
try audioSession.setActive(true)

Called from didActivate (before SIP accept), not onSipConnected (after connection).

Why it's critical: Configuring audio AFTER the SIP connection is too late - iOS has already determined there's no audio path. Must happen in didActivate which fires BEFORE we send the SIP accept.

Why This Approach

We can't prevent WebRTC from initializing early - it's required for SIP to work (needs to check hardware capabilities to generate the SDP answer). So instead, we work around it:

• Let WebRTC initialize when needed (required for SDP)
• Defer SIP accept until CallKit activates audio
• Fulfill CXAnswerCallAction immediately to trigger CallKit's flow
• Detect when WebRTC conflicts with CallKit
• Reset the audio state to fix the conflict
• Configure for VoIP before accepting
• Then proceed with the call

The deferred answer pattern ensures everything happens in the right order: fulfill action → activate session → configure audio → accept call. Doing it any other way leaves the audio routing broken.

@siprix let me know your thoughts on whether this is all appropriate or not. After these changes ive personally noticed a dramatic increase in call reliability when receiving a call from the foreground/background and from an app killed state.

[siprix]

Hi @mikaelwills
Sorry for delay in review/react on suggested fix.
Your suggestion 'deferred answer pattern' is definitely good, but we would like to apply different implementation.

The deferred answer pattern ensures everything happens in the right order:
fulfill action → activate session → configure audio → accept call. Doing it any other way leaves the audio routing broken.

Here is fragment of code from Apple CallKit documentation

func provider(_ provider: CXProvider, perform action: CXStartCallAction) {
    ...
    /*
     Configure the audio session but do not start call audio here.
     Call audio should not be started until the audio session is activated by the system,
     after having its priority elevated.
     */
    configureAudioSession()
...

In contains very usable comment, explaining usage pattern:
configure audio → [fulfill action → activate session] → start call audio (accept call).

Stage 'configure audio' should be first and it's done internally by webrtc;
fulfill action - signals iOS to activate configured session;
didActivate - means that session has been activated and app can start audio (invoke here ensureAudioSessionConfigured seems wrong);

Here is updated source code of plugin, which we testing and going to publish.
Introduced new flag _audioSessionActivated, redesigned existing method proceedCxAnswerAction
to check it and also modified code to invoke that method twice:

• when received INVITE and audio session not activated: fullfill action
• when session activated: accept SIP call/start audio flow

SiprixVoipSdkPlugin.swift.zip

[mikaelwills]

@siprix awesome, Justed tested the new file and it seems to be good so far after repeated calls!

[mikaelwills]

@siprix Well it worked when i first built with the new file, 20 calls in a row were fine. Came back to it latter and now the audio session wont connect at all when receiving and incoming call.

Whats stands out to me is this Config is invalid: min_bitrate_bps=-1; max_bitrate_bps=-1; both expected greater or equal to 0. Inside the audio_send_stream.cc

IwSip.log

[siprix]

Reason of issue is interruption:

143011.655 [2346032] (SiprixModule.cpp:203): CxProvider: didActivate
143011.655 [2346032] (RTCLogging.mm:33): (RTCAudioSession.mm:181 -[RTCAudioSession setIsAudioEnabled:]): 0->1

143011.655 [2347318] (RemoteParticipant.cxx:622): accept handle:203 withVideo:0 prefLocalIP:192.168.1.122
143011.655 [2347312] (RTCLogging.mm:33): (audio_device_ios.mm:514 HandleCanPlayOrRecordChange): Handling CanPlayOrRecord change to: 1
143011.655 [2347312] (RTCLogging.mm:33): (audio_device_ios.mm:720 UpdateAudioUnit): Updating audio unit state. CanPlayOrRecord=1 IsInterrupted=1
143011.655 [2347312] (RTCLogging.mm:33): (audio_device_ios.mm:723 UpdateAudioUnit): Ignoring audio unit update due to interruption.

provided log doesn't contain details when interruption started/ended.

Most probably app was in background and move it to foreground would trigger log like:

231646.508 [34129] (RTCNetworkMonitor.mm:185): appBecomeActive
231646.508 [34129] (RTCLogging.mm:33): (RTCAudioSession.mm:602 -[RTCAudioSession handleApplicationDidBecomeActive:]): Application became active after an interruption. Treating as interruption end. isInterrupted changed from 1 to 0.
231646.514 [34129] (audio_device_ios.mm:343): AudioDeviceIOS::OnInterruptionEnd
231646.516 [34519] (RTCLogging.mm:33): (audio_device_ios.mm:487 HandleInterruptionEnd): Interruption ended. IsInterrupted changed from 1 to 0. Updating audio unit state.

Checking how to handle this automatically.

[siprix]

Published updated version 1.0.33 which includes previously provided impl and also addresses handling interruption.