Device-specific Checkbox to enable/disable calls

SUMMARY
I’m requesting the addition of an option in all DC apps to disable/enable incoming calls on some (but not all) devices associated with an account. Ideally, all accounts in “multi-device” mode would be nudged by the default workflow to only enable calls on 1 device at a time.

ILLUSTRATION
In my case, I use both Android and Linux apps, and all incoming calls ring on both my devices, which very frequently leads to long (> 10 second) delays with calls being connected, failed calls, and other such usability failures. It would be nice if I could set up the apps so all calls would only ring through to my phone, not my desktop (or vice-versa).

WHY IT IS NEEDED
(1) REDUCING COMPLEXITY: Incoming calls ringing on multiple devices leads to various complications given the 1-to-1 nature of WebRTC, coupled with the code complexity and signalling overhead in coordinating which device (IP address) needs to be connected on a WebRTC link after the call is answered. A simple checkbox-like toggle to the effect of “Accept Incoming Calls On This Device” could remedy this issue so incoming calls can be made to only ever be sent to 1 device, and perhaps a WebRTC connection could then be pre-established (without any voice data sent in either direction) before the call notification is even sent to the incoming device.
(2) DELIVERING A COMPETITIVE AND CONSISTENT USER EXPERIENCE: User expectations of a voice/video call reflect the calling experience of a traditional (PSTN/circuit switched) call, where the end to end circuit has to be established BEFORE the incoming device can ring. This is further amplified in the context of today’s VoLTE/VoNR (packet switched) calls, where signalling delays are minimized to the point of users now expecting near-instantaneous ringing of a called phone anywhere in the world, within 1 or 2 seconds of the call first being dialled at the calling device. This is also already the calling experience being offered on the messaging/calling apps within both the Google as well as Apple “walled gardens”. This is what DC is up against if it wishes to compete and bring privacy to the masses.
(3) ELIMINATING FAILED CALLS: A user always setting up only a single device for calls would then make it technically feasible to completely eliminate the possibility of failed calls (of course, as long as the called device is online), by pre-establishing the WebRTC link in advance of the call notification. Of course, voice packets would still only be exchanged after the call is answered or “picked up”.
(4) CALL PREVIEW LOGIC: WebRTC links getting established in advance of an “incoming call” notification will also make it simpler for video previews to be enabled for all incoming video calls.

CONCLUSION
This seems like a solution that would solve many difficult problems at once. What do you think? What are the challenges/roadblocks associated with this?

Most (if not all) of the problems you’re trying to solve do not exist. The signaling code is not that complex. It’s just one message out to all the callee’s devices and one reply from the device where the call was accepted from.

I don’t see how it’s the case. Making a video preview is simple either way.

I personally don’t think that we want to be establishing a P2P connection before the call is accepted, for privacy reasons. Doing that would reveal the “online” status, and possibly the IP address. It’s possible to hide the IP and then reveal it only when the call is accepted, but then it’s simpler not start the WebRTC connection in the first place.

The competitive user experience is to be able to accept the call from any of your devices. See WhatsApp, Signal, Telegram.

Having the feature itself (don’t ring on this device), however, probably makes sense (IIRC it’s present in Telegram at least).

Thanks for chiming in with your thoughts! What do others think?