Handle overlapping VoIP calls correctly with 'busy local' and 'busy everywhere'.

[ara4n]

Currently if you have a device that (correctly or otherwise - see #1963) thinks it is on a call, it apparently sends m.call.hangup to all inbound calls.

This is a major issue because:

• The call still rings on other devices, but when they try to answer it the call instantly clears with "Matthew ended the call" message without realising it's from another device.
• Just because i have a device already on a call doesn't mean I don't want to receive other calls on other devices.

To solve it, we need to distinguish between 'busy local' versus 'busy everywhere' hangup reasons. A device which rejects a call because it is already on a call should reject with 'busy local', which shouldn't kill the call elsewhere. A call which is rejected by the user hitting the 'hangup' button should reject it with 'busy everywhere', which /should/ kill the call elsewhere.

[ara4n]

Having spoken to @dbkr a bit, suggestion is that we could skip 'busy local' for now and simply ignore calls which arrive whilst we are already on a call.

'Busy local' is only meaningful if every device associated with an account declares 'busy local' and we need to interpret that as 'busy everywhere'. However, this is typically quite an edge case. It might still be useful from error reporting though (e.g. "Warning: the user is already in a call on some devices").

As a first cut, let's just avoid automatically sending m.call.hangup if a user is already on a call.

[jfrederickson]

You might also want to take the new call from the same device, if the client supported e.g. putting one call on hold. (And maybe eventually conferencing both of them together would be an option?)

[ara4n]

@dbkr did this get fixed with MSC2746?

[SimonBrandner]

@dbkr did this get fixed with MSC2746?

Yes, that MSC fixed this by having m.call.hangup and m.call.reject