diff --git a/technical/6.1.-Conference-Protocol.md b/technical/6.1.-Conference-Protocol.md index ad6aab40adfad0dd11227f713744fae3baff70f7..c4e3a38920b482b5a9ebb62033d78cfd9b97979e 100644 --- a/technical/6.1.-Conference-Protocol.md +++ b/technical/6.1.-Conference-Protocol.md @@ -64,6 +64,24 @@ Layout = { } ``` +Possible keys are: + ++ uri = account's uri ++ device = device's id ++ media = media's id ++ active = if the participant is active ++ x = position (x) in the video ++ y = position (y) in the video ++ w = size (width) in the video ++ h = size (height) in the video ++ videoMuted = if the video is muted ++ audioLocalMuted = if the audio is locally muted ++ audioModeratorMuted = if the audio is muted by moderators ++ isModerator = if it's a moderator ++ handRaised = if the hand is raised + +In the future, `isTalking` will probably be added + ### New API A new method (in CallManager) and a new signal to respectively get current conference infos and updates are available: @@ -87,69 +105,65 @@ So, if a call receives some confInfo, we know that this call is a member of a co To summarize, `Call` manages received layouts, `Conference`-managed sent layouts. -## Moderator actions +## Changing the state of the conference -Some actions can be performed on the conference by the moderators such changing the layout or muting a participant. +To change the state of the conference, participants needs to send orders that the host will handle. -### Implementation +The protocol have the following needs: -#### Change video layout -To change a layout, the moderator can send a payload with "application/confOrder+json" as type: +It should handle orders at multiple levels. In fact for a conference the is 3 levels to define a participant: ++ The account which is the identity of the participant ++ Devices, because each account can join via multiple devices ++ Medias, because there can be multiple videos by devices (eg 1 camera and 1 screen sharing) -``` -{ - "layout": int -} -``` +To save bandwidth, clients should be able to send multiple orders at once. + +### General actions +To change a layout, the moderator can send a payload with "application/confOrder+json" as type: where **0** is a grid, **1** is one user in big, others in small, **2** is one in big -#### Set participant to active state +### Account's actions -To set a participant as active, the moderator can send a payload with "application/confOrder+json" as type: +For now, there is no action supported, however, in the future `moderator: true/false` should be handled to change a moderator. -``` -{ - "activeParticipant": "uri" -} -``` +### Device's actions -#### Mute participant ++ `hangup: true` to hangup a device from the conference (only moderators) ++ `raisehand: true/false` to change the raise hand's status. Only doable by the device itself, else dropped. -``` -{ - "muteParticipant": "uri", - "muteState": "true" -} -``` - -#### Hangup participant - -``` -{ - "hangupParticipant": "uri" -} -``` +### Media's actions -## Regular participant actions ++ `muteAudio` only doable by moderators to mute the audio of a participant ++ `muteVideo` not supported yet. ++ `active` to mark the media as active. -Some actions can be performed by all participants, including moderators. +### Example -### Implementation +So, the `application/confOrder+json` will contains: -#### Raise hand actions - -``` +```json { - "handUp": "uri" + "989587609427420" : { + "moderator": true/false + "devices": { + "40940943604396R64363": { + "hangup": true, + "raisehand": true/false, + "media":{ + "3532532662432" : { + "muteAudio": true/false, + "muteVideo": true/false, + "active": true/false + } + } + } + } + } + "layout": 0/1/2, } ``` -``` -{ - "handDown": "uri" -} -``` ### Controlling moderators