The ring stops when the caller hangs up #161

2026-09-12T13:00:35Z

paulhitt commented

2026-09-12 13:00:35 +00:00

(Migrated from gitlab.com)

Found while testing an Android call to an iPhone.

The ring would not stop

Only a call OFFER was marked time-critical, so only an offer got the VoIP push that reaches a locked, suspended phone. Hanging up sent the end as ordinary traffic, which a sleeping phone does not wake for, so it went on ringing for a caller who had already gone. The end of a call is as time-critical as its start, and both clients now say so.

A second push orphaned the first call

A push arriving for a call already on screen overwrote the id of the ringing call. Nothing held that id afterwards, so nothing could end it. PushKit still demands a reported call out of that handler, so it now reports a throwaway and closes it in the same breath.

"Calling" outlasted the answer

Answering told this account's other devices before it told the caller, putting a key fetch for every one of them in front of the answer on the same actor. The caller sat on "Calling" through all of it. The answer goes first now.

Tests

VoIPCallTests asked whether a call signal was recognisable from its bytes. It now asks the rule what it decides: an offer rings, an end rings, an answer and a reaction do not, and a message never does. Same on Android, where the rule moved to the companion so a test can reach it.

And two things on screen

The sign-in screen showed a letter in a box where the app has a mark of its own. It now shows the artwork and the navy the launcher icon uses, so the screen someone lands on matches the icon they tapped.

Setting up Files asked for the passphrase twice. A second box saying "type it again" is how you confirm a secret somebody is inventing on that screen; this is the passphrase they already sign in with, which the paragraph above the box says in as many words. Asking twice only suggested it was a different one. iOS asks once.

Found while testing an Android call to an iPhone. ## The ring would not stop Only a call OFFER was marked time-critical, so only an offer got the VoIP push that reaches a locked, suspended phone. Hanging up sent the end as ordinary traffic, which a sleeping phone does not wake for, so it went on ringing for a caller who had already gone. The end of a call is as time-critical as its start, and both clients now say so. ## A second push orphaned the first call A push arriving for a call already on screen overwrote the id of the ringing call. Nothing held that id afterwards, so nothing could end it. PushKit still demands a reported call out of that handler, so it now reports a throwaway and closes it in the same breath. ## "Calling" outlasted the answer Answering told this account's other devices before it told the caller, putting a key fetch for every one of them in front of the answer on the same actor. The caller sat on "Calling" through all of it. The answer goes first now. ## Tests `VoIPCallTests` asked whether a call signal was recognisable from its bytes. It now asks the rule what it decides: an offer rings, an end rings, an answer and a reaction do not, and a message never does. Same on Android, where the rule moved to the companion so a test can reach it. ## And two things on screen The sign-in screen showed a letter in a box where the app has a mark of its own. It now shows the artwork and the navy the launcher icon uses, so the screen someone lands on matches the icon they tapped. Setting up Files asked for the passphrase twice. A second box saying "type it again" is how you confirm a secret somebody is inventing on that screen; this is the passphrase they already sign in with, which the paragraph above the box says in as many words. Asking twice only suggested it was a different one. iOS asks once.

paulhitt commented

2026-09-12 13:00:52 +00:00

(Migrated from gitlab.com)

changed the description

paulhitt commented

2026-09-12 13:07:50 +00:00

(Migrated from gitlab.com)

mentioned in commit ca720ce04d

mentioned in commit ca720ce04dd8bb2a6eadc66be29d4036ca334b5f

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

2026-09-12 13:07:50 +00:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: extant2000/flamenet-messenger-android#161