All devices keep ringing except on the device that answered the call, never stop ringing until manually told to

[BloodyIron]

Steps to reproduce

1. I'm logged into multiple devices, android, desktop, whatever
2. Person calls me, and I answer on one of them
3. All other devices (generally most noticed on Android devices) keep on ringing until the end of the universe, or the battery dies, whichever comes first

Outcome

What did you expect?

All other devices to stop ringing and know that the call has been answered

What happened instead?

Every device keeps ringing

Your phone model

Any device

Operating system version

Multiple Android versions, Linux desktop OS

Application version and app store

Has been going on for years, so current, and many versions back

Homeserver

Public matrix.org

Will you send logs?

No

Are you willing to provide a PR?

No

[MadLittleMods]

👍 Also experienced this by starting a call from a test user on Element Web, answering on another Element Web session, but the Element Android app keeps with incoming call ringing forever. Even after the call ends, I have to manually decline on Element Android to make it stop.

Here are rageshake logs if it even matters: https://github.com/matrix-org/element-android-rageshakes/issues/50619

[systemoperator]

I have the same problem. It's extremely annoying. If e.g. one of the devices is in another room, my Android smartphone rings/vibrates forever until the battery is empty. There is no workaround. Furthermore, this is a long-term issue. It already happened e.g. a year ago. No improvement so far. 😞

[waclaw66]

I experience this very often, same symptoms as above. Nobody can fix it?

[BloodyIron]

Yeah this is tagged as frequent and major, but have seen nothing done on this matter since Feb... what's going on here?

[BloodyIron]

I just came home to find that my tablet was still ringing... FOUR HOURS after I had already answered and completed the Element VoIP call on another device away from my home. This burned about 40% of my tablet's device right before a weekend vacation travel where I really do need the battery.

This is tagged as Frequent and Major... yet I don't see any actual action on this issue. What's going on here??? >:|

[YamatoRyou]

I just came home to find that my tablet was still ringing... FOUR HOURS after I had already answered and completed the Element VoIP call on another device away from my home. This burned about 40% of my tablet's device right before a weekend vacation travel where I really do need the battery.

This is tagged as Frequent and Major... yet I don't see any actual action on this issue. What's going on here??? >:|

This issue has been around for a long time but has not been solved by the development team or contributors. I tried to solve it through some indirect methods. If you are interested please see: https://github.com/YamatoRyou/element-android-incoming-call-fix-for-macrodroid#english

[bmarty]

There are multiple root causes:

• technical cause (spec): a Push is sent for m.call.invite, so the device can start ringing. But there is no push for m.call.answer or m.call.reject, so the device cannot know if the call has been answered elsewhere. If another event is triggering a push, the device sync and the device stops ringing. Anyway, even if pushes were receive for such events, it would not be enough. The connectivity can be lost, and in this case, the device will never stop ringing.
• implementation: the call should just not ring forever. An internal timeout (one minute) have to be implemented.

So the solution is to limit by design the duration of the ringing call. the call can stop ringing earlier, if the m.call.answer/reject is detected, like today.

[bmarty]

Actually for point 1, there is this code which mitigate the lack of Push. The network can still be lost.

[YamatoRyou]

There are multiple root causes:

• technical cause (spec): a Push is sent for m.call.invite, so the device can start ringing. But there is no push for m.call.answer or m.call.reject, so the device cannot know if the call has been answered elsewhere. If another event is triggering a push, the device sync and the device stops ringing. Anyway, even if pushes were receive for such events, it would not be enough. The connectivity can be lost, and in this case, the device will never stop ringing.
• implementation: the call should just not ring forever. An internal timeout (one minute) have to be implemented.

So the solution is to limit by design the duration of the ringing call. the call can stop ringing earlier, if the m.call.answer/reject is detected, like today.

I have been troubled by this problem for a long time. Based on my long-term observations (user perspective), I have drawn some conclusions:

Occasion 1:

1. Make the Element appear on the screen;
2. Press the Home button (optional);
3. Press the power button to turn off and lock the screen;
4. Call this device to light up the screen and ring

In this case, the device will stop ringing for 1 minute after receiving an incoming call, and then a prompt will pop up on the screen.
After the prompt pops up, the screen still cannot be turned off automatically. Unless the battery is exhausted or manually terminated after being discovered by the user. For details, see #7107

Occasion 2:

1. Make the Element appear on the screen;
2. Press the Recent Task key to remove Element;
3. Press the power button to turn off and lock the screen;
4. Call the device, causing it to light up the screen and ring.

In this case, the ringtone will continue to play and the screen will stay on until the battery is exhausted or manually terminated when discovered by the user.
BTW: On some systems, Element's ringtone will only play once.

---

I wanted to take some time to make a video recreating the above occasion.
Here's a video that recreates the above occasion: https://www.youtube.com/watch?v=EkLDkCgP8Nc
Battery optimization has been lifted for Element in the above two situations, and Element is allowed to run persistently when the screen is locked. Element version is 1.6.5, and the push method is self-hosted ntfy.