From 134618f4cd8531ceb2df376f6adf6ff391970785 Mon Sep 17 00:00:00 2001 From: "J. Ryan Stinnett" Date: Tue, 9 Mar 2021 13:23:14 +0000 Subject: [PATCH] Remove old conferencing doc This old document from 2015 has no connection to the current state of conferencing, so best to remove it to avoid confusion. --- docs/conferencing.md | 52 -------------------------------------------- 1 file changed, 52 deletions(-) delete mode 100644 docs/conferencing.md diff --git a/docs/conferencing.md b/docs/conferencing.md deleted file mode 100644 index 874ce4cfd0..0000000000 --- a/docs/conferencing.md +++ /dev/null @@ -1,52 +0,0 @@ -# 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.