It would be better if the caller could know for sure which of these states..
A request has been sent to the target’s relays, but it’s uncertain whether it has yet arrived to any device (Searching?)
At least one target device has now acknowledged the call and responded with its own candidates, negotiating is now taking place (Connnecting?)
Direct connection has successfully been established with at least one target device which is now ringing, waiting to pick up the call (Ringing?)
That would make a difference because if stuck in Stage 1, there would be no point in waiting too long. If stuck at Stage 2, something is probably wrong related to NAT or codecs. And only if reaching Stage 3 would it make sense to wait a long time. Or if aborting, being certain that the other person will eventually know about the missed call.
Actual behavior
When making a call, the status immediately goes to say “ringing” and there are ringing tones, suggesting that the target device has been reached and is playing ringtones. However this is not always true. In fact, this will happen even if either endpoint is offline.
I would say that it’s not great for privacy to tell the caller if the callee’s device is online unless there is a setting for that.
IIRC WhatsApp is also “ringing” even if the callee is offline.
But as I heard DC Android is already in the process of implementing the “line is busy” feature. So if we don’t care about not exposing the “online” status then might as well display proper “ringing” status.
Here I think we also should not try to establish a non-relayed P2P connection before the user has accepted the call. This “acknowledgement” message can be an email.
Indeed the current call state reporting is a bit misleading, but I would personally would not go beyond detecting whether the “start call” message has been successfully transferred to a mail server.
I agree that privacy issues should be thorougly considered. I don’t know exactly how the current implementation works, it might be that the WebRTC implementation already reveals the online status at protocol level.
I also suspect that if going for the very private scheme that you suggest, there will be a considerable delay from when the callee presses the Answer button, until the call has been fully set up and talking may begin. So that could impact the user experience and needs to be considered in relation to privacy issues.