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.

[mikaelwills]

@siprix the v1.0.33 fixes look good

Regarding Apple's pattern: configure → fulfill → activate → start audio.

The issue is that WebRTC's internal configureAudioSession() doesn't always set .playAndRecord. My logs show it configured .playback:

category: AVAudioSessionCategoryPlayback
inputNumberOfChannels: 0

When didActivate fires, iOS has activated that session - the one with no microphone. Calling _siprixModule.activate() at that point can't fix a session that's already activated with the wrong category.

Apple's docs say "configure the audio session" - but WebRTC configured it for playback-only. We need to verify/correct the category before accepting the call. Either:

1. Ensure WebRTC always configures .playAndRecord internally, OR
2. Re-configure in didActivate if the category is wrong (defensive)

Option 2 is what my original PR's ensureAudioSessionConfigured() does - it's not starting audio, it's correcting a misconfigured session before starting audio.

Would it be worth being a bit more aggresive with the category setting, ensuring the audio session is properly configured regardless of what state WebRTC left it in.

IwSip.log

[mikaelwills]

@siprix Happy new year! With testing prior to the break and this morning im seeing this issue a lot less after the recent changes.

[siprix]

Here is fragment from last provided log:

155821.385 [2564179] (RTCNetworkMonitor.mm:180): appDidEnterBackground
155821.735 [2564179] (SiprixModule.cpp:203): CxProvider: CXAnswer uuid:5D272138-9A44-4F4E-8567-D5F9FE286AC4 callId:202
155822.001 [2564179] (SiprixModule.cpp:203): CxProvider: didActivate
155822.306 [2575379] (RTCLogging.mm:33): (audio_device_ios.mm:818 ConfigureAudioSession): Configured audio session.
155822.306 [2575379] (audio_device_ios.mm:655): AudioDeviceIOS::SetupAudioBuffersForActiveAudioSession

ATAudioSessionPropertyManager.mm:363   FAILED to set property 1684431725 on AVAudioSession with error Error Domain=NSOSStatusErrorDomain Code=-50 "(null)"

Something went wrong when app accepts call in background.
Locally it can be reproduced in the following way (not always): received push notif/displayed CallKit window; manually switch to App's window; manually switch back to CallKit window and accept call here;

Internal webrtc impl can't split 'configure' and 'start audio' actions. It has 2 separate methods for manual enable audio and activate session.

Here is one more update (binary + plugin sources).
Plugin's code reverted back to previous state, binary invokes webrtc's method in a bit different way.

siprix_ios_20251230.zip (the same build provided in the 'onTerminated callback..' topic)
SiprixVoipSdkPlugin.swift_20251230.zip

[mikaelwills]

@siprix Yea this issue has started to come back for me now. Over the past couple days i cannot get audio connected with an app killed push first call.

I downloaded the new binary and .swift file you gave me, Call acceptance now works (200 OK sent), but audio still fails.

The category gets overwritten from PlayAndRecord to Playback right after didActivate:

141123.748 Set category to: AVAudioSessionCategoryPlayAndRecord
141123.899 CxProvider: didActivate
141124.192 Audio route changed: CategoryChange to :AVAudioSessionCategoryPlayback

Result: inputNumberOfChannels: 0, VPAU start fails with 561145187.

I also deleted my app and did an entire fresh install when the push came in i got the pop up to accept microphone permissions, granted that but the call still had no audio.

siprix.log