- Ya
- 3 Septemba 2026, 22:54 UTC
- Mwandishi
- Kamo
- Ahadi ya
- 1d674f9
VoipStompRelayController relayed voip.call.* ringing events to the browser and deliberately never pushed them, reserving incoming-call alerting for 'the future APNS_VOIP/CallKit path'. That path now exists on the device, so this is its server half. INBOUND_RINGING becomes an INCOMING_CALL push; CALL_ANSWERED and CALL_ENDED become CALL_CANCELLED on the same sessionId -- without the cancellation the handset rings on at a call that was picked up on a desk phone. Both types bypass the presence gate and the rate limiter, and neither exemption is cosmetic: - Presence marks a member online for 300s after their socket goes quiet, so a phone backgrounded two minutes ago still reads as live -- and that is exactly the phone whose SIP socket Android has just reclaimed. Gating on presence loses the call. Sending anyway is safe: only the device can tell whether it is already ringing, and it drops the push when its own INVITE beat it there. - The rate limit keys on the collapse key, falling back to the TYPE. A call push has no collapse key, so it would be one ring per member per fifteen seconds with the second caller discarded, and a dropped cancellation leaves a phone ringing at nothing. FCM call messages get ttl=0 and no collapse key: deliver now or discard, and never let a cancellation evict the queued ring it is meant to follow. High priority is load-bearing rather than a nicety -- it is what grants the app its temporary exemption from the Android 12+ ban on starting a foreground service from the background, which is the window the incoming-call service needs to exist at all. APNs splits by kind: calls go only to an APNS_VOIP registration, on the .voip topic with push-type voip, no alert block and a 30s expiry (iOS punishes an app woken for a call it does not report to CallKit). Calls are refused on alert registrations and non-calls stay refused on the voip topic. Inert until an iOS build registers such a token.