bug: Mobile app cannot answer incoming external (SIP/drachtio) calls — CallKit/notification vanishes ~2s, desktop works

Describe the Bug

Incoming external (PSTN/SIP) calls cannot be answered on the mobile app — on iOS and Android. The incoming-call UI appears and rings, but tapping answer dismisses it after ~2s and the call never connects. The SIP leg keeps ringing server-side for the full 20s timeout, then our queue retries and the phone rings/vanishes again in a loop. Internal user-to-user calls work fine on the same phones; external calls work fine from desktop browsers

Steps to Reproduce

1. PSTN caller dials our DID → FreeSWITCH IVR answers → caller enters a valid agent extension (1001#)
2. MediaCallsServer creates the call, sends push + ring signal to the mobile (verified in server debug logs)
3. Mobile shows incoming call UI and rings
4. Tap answer → UI vanishes after ~2s, no audio, call never connects
5. Repeatable 100% for any SIP-originated call (inbound trunk AND internal calls routed through SIP); pure WebRTC internal calls on the same device connect normally, open app or locked

Expected Behavior

Tapping answer connects the call with two-way audio, as it does on desktop and as internal calls do on mobile.

Actual Behavior

The answer never leaves the phone: server debug shows push + sendSignal delivered, then zero client response for 20s — no REST POST /api/v1/media-calls.answer hit, no websocket signal, no ICE, no renegotiation — until FreeSWITCH times out (NO_ANSWER) and cancels. MediaCallsServer logs no error; from its view the phone simply never answered.

Rocket.Chat Server Version

8.8.1 (self-hosted, drachtio + rocketchat/freeswitch image, Ooredoo SIP trunk)

Rocket.Chat App Version

4.77.0 (TestFlight, build 109683)

Device Name

iPhone 15 Pro Max

OS Version

iOS 27

Additional Context

• Environment audited against the official SIP-integration guide — all server settings match (drachtio, SIP server, ICE incl. working TURN relay, gathering timeout, mobile ringing, extensions); single-session tested (logged out everywhere except the phone), ruling out session conflicts.
• FreeSWITCH offer SDP is vanilla (m=audio RTP/SAVPF 8 101, PCMA + telephone-event, rtcp-mux, ICE host candidates, DTLS actpass+fingerprint); no SIP re-INVITEs; DTLS/ICE proven end-to-end with desktop on identical calls.
• Looks related to the lock-screen/background accept race family (#7298, reverted in #7521; narrower #7526 shipped in 4.75.0) — but this variant dies before any client→server traffic, so the fix didn't cover it. Both mobile platforms affected identically → shared RN VoIP stack, not CallKit-specific. Can provide full MC debug captures and SIP traces, or test a fix build.

Trace the mobile incoming-call path from push and sendSignal delivery through the client response, including /api/v1/media-calls.answer and websocket signaling. Compare the SIP-originated flow with the working internal WebRTC flow and the related issues #7298, #7521, and #7526; done means answering on iOS and Android sends the expected response and establishes two-way audio before the server timeout.