mirror of
https://github.com/SchildiChat/element-web.git
synced 2024-10-01 01:26:12 -04:00
Merge pull request #16648 from vector-im/jryans/rm-conf-doc
Remove old conferencing doc
This commit is contained in:
commit
d9627cbe67
@ -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.
|
Loading…
Reference in New Issue
Block a user