riot-web/docs/conferencing.md

# VoIP Conferencing

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.