Commit 9c8b540

This is a draft proposal for a naive voice/video conferencing implementation for

Matrix clients. There are many possible conferencing architectures possible for

Matrix (Multipoint Conferencing Unit (MCU); Stream Forwarding Unit (SFU); Peer-

to-Peer mesh (P2P), etc; events shared in the group room; events shared 1:1;

possibly even out-of-band signalling).

This is a starting point for a naive MCU implementation which could provide one

possible Matrix-wide solution in future, which retains backwards compatibility

with standard 1:1 calling.

* A client chooses to initiate a conference for a given room by starting a

voice or video call with a 'conference focus' user. This is a virtual user

(typically Application Service) which implements a conferencing bridge. It

isn't defined how the client discovers or selects this user.

* The conference focus user MUST join the room in which the client has

initiated the conference - this may require the client to invite the

conference focus user to the room, depending on the room's `join_rules`. The

conference focus user needs to be in the room to let the bridge eject users

from the conference who have left the room in which it was initiated, and aid

discovery of the conference by other users in the room. The bridge

identifies the room to join based on the user ID by which it was invited.

The format of this identifier is implementation dependent for now.

* If a client leaves the group chat room, they MUST be ejected from the

conference. If a client leaves the 1:1 room with the conference focus user,

they SHOULD be ejected from the conference.

* For now, rooms can contain multiple conference focus users - it's left to

user or client implementation to select which to converge on. In future this

could be mediated using a state event (e.g. `im.vector.call.mcu`), but we

can't do that right now as by default normal users can't set arbitrary state

events on a room.

* To participate in the conference, other clients initiates a standard 1:1

voice or video call to the conference focus user.

* For best UX, clients SHOULD show the ongoing voice/video call in the UI

context of the group room rather than 1:1 with the focus user. If a client

recognises a conference user present in the room, it MAY chose to highlight

this in the UI (e.g. with a "conference ongoing" notification, to aid

discovery). Clients MAY hide the 1:1 room with the focus user (although in

future this room could be used for floor control or other direct

communication with the conference focus)

* When all users have left the conference, the 'conference focus' user SHOULD

leave the room.

* If a conference focus user joins a room but does not receive a 1:1 voice or

video call, it SHOULD time out after a period of time and leave the room.