Outgoing calls from a newly linked Android tablet remain in DIALING

Guidelines

• I have searched open and closed issues for duplicates
• I am submitting a bug report for existing functionality that does not work as intended
• This isn't a feature request or a discussion topic

Bug description

Outgoing one-to-one audio calls made from Signal on a linked Android tablet never progress beyond DIALING.

On the tablet, the outgoing-call screen appears, but I hear no ringback tone. The recipient may see only a very brief call notification (approximately one second). Attempts to answer have failed with a network error. No stable incoming-call screen is presented to the recipient.

Ordinary Signal messaging with the same recipient continues to work in both directions while the call is stuck. In one recorded attempt, the tablet received a typing event and then an ordinary message from the recipient with 1 ms delivery latency while the outgoing call was still in DIALING.

This is a regression in my setup. Calls previously worked on exactly the same tablet through Molly when it was linked to the same Signal account. I removed Molly to test the official Signal linked-Android-device implementation. The freshly linked official Signal client exhibited this problem. I later removed, reinstalled, and freshly linked Molly again; the freshly linked Molly client then exhibited the same behavior against at least two recipients.

I am not claiming that installing Signal permanently modified the tablet. The common change is that the previously working linked-device identity was deleted and every subsequent test used a newly created linked-device registration.

Steps to reproduce

1. Install Signal 8.25.2 from Google Play on the Android tablet described below.
2. Link it as a secondary Android device to an existing Signal account by scanning the QR code from the primary phone.
3. Open a one-to-one conversation with a recipient for whom messages can be sent and received normally.
4. Start an audio call.
5. Leave the outgoing-call screen open.

The behavior is reproducible after a complete uninstall/reinstall and a fresh association. It is also reproducible after rebooting the tablet.

Actual result

• The local call remains in DIALING until I hang up.
• There is no ringback tone.
• The recipient sees at most a very brief call notification; answering does not establish the call.
• The debug log contains successful outgoing call signaling, but no remote ringing, answer, hangup, busy, or remote ICE event before the local hangup.

Expected result

The recipient should receive a normal incoming-call screen, the caller should receive the remote ringing state, and the audio call should connect when answered.

Reproducibility and tests performed

• Reproduced on all four Signal call attempts contained in the attached debug log.
• Reproduced on the normal Wi-Fi network and on a phone's cellular hotspot.
• Reproduced with "Always relay calls" disabled and enabled.
• Reproduced with the tablet's built-in audio route and with Bluetooth SCO selected.
• Signal was completely uninstalled, reinstalled, and linked again.
• App cache was cleared and the tablet was rebooted.
• Android app freezing and BOOX launch-optimization settings were removed for Signal.
• WhatsApp voice calls work on the same tablet, so general VoIP and audio capture/playback are functional.

Relevant observations from the Signal debug log

For the 2026-09-05 15:42:08 GMT+02:00 attempt:

• RingRTC creates a V4 audio offer and calls send_offer().
• Signal sends the one-to-one call message; the chat connection reports HTTP Success: 200, followed by messageSent().
• With hideIp: true, relay candidates are gathered using UDP, TCP, and TLS and the ICE-candidate message is also accepted with HTTP 200.
• Bluetooth SCO is selected successfully and Android enters MODE_IN_COMMUNICATION.
• While the call is still pending, an incoming typing event is decrypted at 15:42:56 with 1 ms delivery latency, followed by an incoming message at 15:42:59 with 1 ms delivery latency.
• At 15:43:00, the call ends only because of the local hangup and is still reported as state: DIALING.
• No network-loss callback occurs during this call.

All four Signal attempts have the same high-level sequence: outgoing offer and ICE signaling are sent successfully, no remote call-signaling event is logged, and the call ends locally while still in DIALING.

Possibly relevant warning

Every outgoing audio-call offer logs:

No supported VP9 hardware encoder found
No supported VP9 hardware decoder found
Outgoing offer: bidirectional codecs: [], encode codecs: [], decode codecs: []
A required video codec field in outgoing offer is empty

The generated SDP does contain an audio section using Opus. I am reporting this warning because it is consistent across attempts, but I am not asserting that it causes the audio-call failure. The freshly linked Molly client logs a similar empty-video-codec warning.

Device

ONYX BOOX Go 10.3 Gen II, reported model Go103_2Lumi

SoC: Qualcomm SM6350

Android version

Android 15 / API 35

BOOX build: 2026-04-21_15-48_4.2-rel_04212_ce95d3767

Signal version

Signal 8.25.2 (174301, Play production build)

RingRTC 2.71.0

WebRTC v7871f

The installation is a freshly registered linked device. The log reports no VPN, Data Saver disabled, and no Android background restriction. Android battery optimization is not ignored, but every test was performed with Signal open in the foreground and signaling plus message delivery remained active.

Additional cross-client context

After the initial failure in official Signal, Molly 8.19.2-4 was freshly linked on the same tablet. Its log contains five outgoing calls involving two recipient records. None receives a remote ringing or answer event. Three end by local hangup while still in DIALING; two other attempts end in SIGNALING_FAILURE after a coincident Android network-loss callback and are not being relied upon as evidence for the stable-network case.

This cross-client observation may indicate a problem involving a newly created Android linked-device identity or call-signaling routing rather than the media path itself. The caller-side logs alone cannot distinguish a recipient-side rejection from a response that is not routed back to the linked tablet.

Screenshots

No response

Device

ONYX Go103_2Lumi

Android version

15

Signal version

8.25.2

Link to debug log

https://debuglogs.org/android/8.25.2/c22ea5a0ad0140194ae78918dc5fc29cd7fb528e3a922cf061f494136d71ef72

The report names no repository files or tests; start with the linked debug log and the RingRTC send_offer(), ICE-candidate, and call-signaling sequence it describes. Compare the linked-device caller flow with recipient-side ringing and answer events, then reproduce the issue on a freshly linked Android device. Done means the recipient receives a normal incoming-call screen and the call progresses beyond DIALING when answered.