jami
/
jami-docs
mirror of https://git.jami.net/savoirfairelinux/jami-docs.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity

Update 6.1. Conference Protocol

This commit is contained in:
Adrien Béraud 2021-02-12 16:30:33 -05:00
parent 1bc26fa6d9
commit dfd30ff794
1 changed files with 12 additions and 18 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

30
technical/6.1.-Conference-Protocol.md
View File

@ -1,28 +1,22 @@
# Conference protocol
This document aims to describe evolutions we will do for managing conferences (audio/video). The goal is to improve the current implementation which simply merge SIP calls together and provide a grid view, to a view where participants are listed, can be muted independantly, or the video layout changed (to show only one participant)
This document aims to describe the evolutions we will do for managing conferences (audio/video). The goal is to improve the current implementation which simply merges SIP calls and provide a grid view, to a view where participants are listed, can be muted independently, or the video layout changed (to show only one participant)
## Definitions
+ Host: Is the user which mix the audio/video streams for the others
+ Host: Is the user who mix the audio/video streams for the others
+ Participant: Every user in the conference, even the host
## Disclaimer
This document only describes the first steps for now. This means the identification of participants and position in the video mixer sent to all participants.
## Improve on layouts
Actually, Jami only provides the possibility to show a grid view of the users. We want to be able to only show one member of the conference (the one which shares its screen for example)
### Possible layouts
+ GRID: Every member is shown with the same height/width
+ ONE_BIG_WITH_SMALL: One member is zoomed and the other preview are shown
+ ONE_BIG_WITH_SMALL: One member is zoomed and the other preview is shown
+ ONE_BIG: One member take the full screen rendered
### New API
Two new methods are available to manage the conference Layout in CallManager:
```cpp
@ -43,14 +37,14 @@ void setActiveParticipant(const std::string& confId, const std::string& particip
### Implementation
The implementation is pretty straight forward. Everything is managed by `conference.cpp` (to link participant to sources) and `video_mixer.cpp` (to render the wanted layout).
The implementation is pretty straightforward. Everything is managed by `conference.cpp` (to link participant to sources) and `video_mixer.cpp` (to render the wanted layout).
## Syncing Conferences Informations
Note: Actually, the word participant is used for callId mixed in a conference. This can lead at first to some problems for the API and must be fixed in the furture
Note: Actually, the word participant is used for callId mixed in a conference. This can lead at first to some problems for the API and must be fixed in the future
The goal is to notify all participants the metadatas of the rendered video. This means what participant is in the conference and where the video is located.
The goal is to notify all participants of the metadata of the rendered video. This means what participant is in the conference and where the video is located.
### Layout Info
@ -80,21 +74,21 @@ void onConferenceInfosUpdated(const std::string& confId, const VectorMapStringSt
### Implementation
The `Conference` Object (which only exists if we mix calls, this means that we are the master) manages the informations for the whole conference, based on the LayoutInfos of each `Call` objects. The getConferenceInfos will retrieve infos directly from this object.
The `Conference` Object (which only exists if we mix calls, this means that we are the master) manages the information for the whole conference, based on the LayoutInfos of each `Call` object. The getConferenceInfos will retrieve info directly from this object.
So, every `Call` object now have a LayoutInfo and if updated, ask the `Conference` object to updates its infos.
So, every `Call` object now has a LayoutInfo and if updated, ask the `Conference` object to updates its info.
The master of a conference sends its infos via the SIP channel as a message with the following MIME type:
The master of a conference sends its info via the SIP channel as a message with the following MIME type:
`application/confInfo+json`
So, if a call receives some confInfo, we know that this call is a member of a conference.
To summarize, `Call` manages received layouts, `Conference` managed sent layouts.
To summarize, `Call` manages received layouts, `Conference`-managed sent layouts.
## Moderators
A conference can be controlled (for now, only the layout an be controlled).
A moderator is added if on the same device of the host for now.
A conference can be controlled (for now, only the layout can be controlled).
A moderator is added if on the same device as the host for now.
### Implementation