Repository navigation
Document, test and fix call-related messages/events for multi-device caller/callee #8635
Description
There are ongoing call-related issues/PRs at #8631 #8633 #7840 #8576 and several older closed ones, including #7842, whose fix (#7946) is what #8633 now may partly revert?
I find it pretty hard to understand what's actually going on, on all the participating devices of caller/callees. There is some summarizing documentation in deltachat.h but it talks about parties, not devices. Still the best we have currently, but it may have drifted from the code (it eg says ringing timeout is "after 1 minute" while RINGING_SECONDS is 120).
The lack of a comprehensive overview and joint understanding stating invariants, mechanisms, and the sending/receiving of call related messages, makes it hard for me to review PR #8633 so i suggest:
-
calls.rsgrows a module docstring, where both core and UI developers can understand what's going on in multi-device calls on both sides, including core-internal state changes, events and wire messages. Even if some code lives in the receiving and sending rust code,calls.rsshould still provide a comprehensive reference. -
calls_tests.rscovers all accept/decline/ended cases on both the "active" caller/callee devices and their other devices, to begin to develop certainty that things work as expected.
I suspect working on this issue will also involve fixing things, but even if not, we need a joint understanding, so everyone can go to one place to understand the mechanics and events.
Activity
link2xt commentedon Aug 28, 2026
I'll write some overview. Don't want to duplicate the code as it will not be updated and even if updated you cannot be sure it is correct/up-to-date anyway. Fixed 120 seconds in #8633, but maybe it is better not to add such details in the API and overview documentation.
I think details like whether MDNs are sent, what gets marked as seen etc. are best not documented in detail, as long as they result in expected outcome that is tested it does not really matter if the message gets marked as seen by MDN or by end-call message. Things that are outside the core (what SDP is, what to do with "ICE servers", when should the notification be displayed and what buttons it is expected to have, when the user can decide on audio/video etc.) and internals that are unlikely to change (call states and state transitions) are probably good candidates for the module docs.
This is already the case,
CallSetuphas two devices for both Alice and Bob, and there are teststest_accept_call_callee_ends(accept),test_accept_call_caller_ends(ended),test_callee_rejects_call(decline),test_caller_cancels_calland then some other tests. So if something does not work as expected, it is missing assertions or even wrong assertions, e.g. in #8633 there are assertions checking that second device marks the call as "seen" replaced with assertions that calls are marked as "noticed".