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