A second device's ring no longer hangs up a call answered on the first #150

Merged
paulhitt merged 2 commits from fix/second-device-hangs-up-answered-call into main 2026-09-11 16:20:59 +00:00
2 Commits
Author SHA1 Message Date
Paul HittandClaude Opus 5 8f0fd77dae Guard the second-device call fix where Android CI actually runs it
The iPhone test reads this repo's CallManager too, but only when the two
checkouts sit side by side under the names it expects, which no CI build
directory has, so its Android half returns early there. This is the copy
that runs on every Android pipeline. Proven able to fail: against the
code before the fix, both checks fail.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-09-11 12:14:43 -04:00
Paul HittandClaude Opus 5 ae84b949a3 A second device's ring no longer hangs up a call answered on the first
With one account signed in on two devices, both ring. Answer on one and
the other keeps ringing, because nothing tells it; when its ring guard
fired it sent the caller an end with reason "timeout", and the caller
hung up the call in progress.

Two halves, both needed.

The ring guard now releases the ring locally and sends nothing. The
caller gives up on its own dial timer long before this fires, so the
message was redundant, and on a shared account it was destructive.

The end handler did not check the call id at all: any end, for any call,
hung up whatever call was current. It now requires the call id to match,
and once a call has connected it ignores an end whose reason means the
ring was never picked up, declined, busy or timeout. Those can only have
come from another device that was ringing: somebody silencing it, or a
build already in people's hands that still announces its timeout. A
plain hang-up carries no such reason and still ends the call.

The iPhone gets the same fix, and its test reads this file so the two
cannot drift apart.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-09-11 12:13:13 -04:00