+ 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
+ voiceActivity = if the stream has voice activity
### New API
...
...
@@ -107,7 +106,7 @@ To summarize, `Call` manages received layouts, `Conference`-managed sent layouts
## Changing the state of the conference
To change the state of the conference, participants needs to send orders that the host will handle.
To change the state of the conference, participants needs to send orders that the host will handle.
The protocol have the following needs:
...
...
@@ -137,6 +136,7 @@ For now, there is no action supported, however, in the future `moderator: true/f
+`muteAudio` only doable by moderators to mute the audio of a participant
+`muteVideo` not supported yet.
+`active` to mark the media as active.
+`voiceActivity` to indiciate a media stream's voice activity status (only relevant for audio)
### Example
...
...
@@ -145,7 +145,7 @@ So, the `application/confOrder+json` will contains:
```json
{
"989587609427420":{
"moderator":true/false
"moderator":true/false,
"devices":{
"40940943604396R64363":{
"hangup":true,
...
...
@@ -154,12 +154,13 @@ So, the `application/confOrder+json` will contains:
"3532532662432":{
"muteAudio":true/false,
"muteVideo":true/false,
"active":true/false
"active":true/false,
"voiceActivity":true/false
}
}
}
}
}
},
"layout":0/1/2,
}
```
...
...
@@ -181,4 +182,4 @@ There is actually 3 possibilities:
+ Separate streams to allow more controls?
## Notes/Comments
It's likely that the protocol will evolve for future needs. I believe it's best if we have a "version" field. The older version will be recognized if this field is missing.
It's likely that the protocol will evolve for future needs. I believe it's best if we have a "version" field. The older version will be recognized if this field is missing.
