Let CallKit own the call, not just announce it #262

2026-09-10T14:37:22Z

paulhitt commented

2026-09-10 14:37:22 +00:00

(Migrated from gitlab.com)

CallKit was a doorbell. It rang the phone when a VoIP push arrived and took no further part.

Declining from the lock screen did not decline. The end action cleared the local ring and fulfilled itself; nothing told the call manager, so the caller went on listening to a phone that had already said no.
The audio session was never handed over. No didActivate/didDeactivate, and manual audio was Simulator-only, so on a device WebRTC raced CallKit for the session. Doing that first is the documented way to get a call that connects and carries no sound.
Ending a call never told CallKit, and a call left open there holds the phone in an in-call state and refuses the next incoming one.
Outgoing calls were invisible to iOS: no Recents entry, no session ownership.

Tests: 782 XCTest + 99 Swift Testing, zero failures.

Not verified

The audio path is reasoned from Apple and WebRTC contracts and is NOT observed. A Simulator cannot exercise it, which is why none of this was noticed. iPhone call audio has never been proven on hardware; this is the most likely explanation and the change most in need of a real device before it is trusted.

CallKit was a doorbell. It rang the phone when a VoIP push arrived and took no further part. - **Declining from the lock screen did not decline.** The end action cleared the local ring and fulfilled itself; nothing told the call manager, so the caller went on listening to a phone that had already said no. - **The audio session was never handed over.** No didActivate/didDeactivate, and manual audio was Simulator-only, so on a device WebRTC raced CallKit for the session. Doing that first is the documented way to get a call that connects and carries no sound. - **Ending a call never told CallKit**, and a call left open there holds the phone in an in-call state and refuses the next incoming one. - **Outgoing calls were invisible to iOS**: no Recents entry, no session ownership. Tests: 782 XCTest + 99 Swift Testing, zero failures. ## Not verified The audio path is reasoned from Apple and WebRTC contracts and is NOT observed. A Simulator cannot exercise it, which is why none of this was noticed. iPhone call audio has never been proven on hardware; this is the most likely explanation and the change most in need of a real device before it is trusted.

paulhitt (Migrated from gitlab.com) merged commit 12cc5149c5 into main

2026-09-10 16:12:07 +00:00

paulhitt commented

2026-09-10 16:12:08 +00:00

(Migrated from gitlab.com)

mentioned in commit 12cc5149c5

mentioned in commit 12cc5149c58769c91c93b876614537d5c2a28d00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: extant2000/flamenet-messenger-ios#262