From ce31297837a52972000a2dee5e9da868c81c7c1c Mon Sep 17 00:00:00 2001
From: alexlapa <lapa.alex@ex.ua>
Date: Sun, 16 Dec 2018 20:49:44 -0600
Subject: [PATCH 01/24] init

---
 docs/rfc/0002-webrc-client-api.md | 230 ++++++++++++++++++++++++++++++
 1 file changed, 230 insertions(+)
 create mode 100644 docs/rfc/0002-webrc-client-api.md

diff --git a/docs/rfc/0002-webrc-client-api.md b/docs/rfc/0002-webrc-client-api.md
new file mode 100644
index 000000000..2f730a8c8
--- /dev/null
+++ b/docs/rfc/0002-webrc-client-api.md
@@ -0,0 +1,230 @@
+- Feature Name: `client_webrtc_signalling_api`
+- Start Date: 2018-12-13
+- RFC PR: (leave this empty)
+- Tracking Issue: (leave this empty)
+
+
+
+
+## Summary
+[summary]: #summary
+
+Formalize communication protocol between client(browser, mobile apps) and media server regarding WebRTC connection management.
+
+## Motivation
+[motivation]: #motivation
+
+WebRTC allows P2P data exchange, but WebRTC as a protocol comes without signaling. At a minimum signalling protocol must provide ways to exchange Session Description 
+data(SDP offer/answer) and ICE Candidates. But if you think about signalling protocol in terms of interaction with media server things are becoming more complicated.
+You will need to express ways to:
+1. Provide STUN/TURN servers.
+2. Exchange some low-level media metadata(resolution, codecs, media types).
+3. Allow more sophisticated track management(updating video resolution on preview/fullscreen switches, passing multiple video tracks with different settings).
+4. Pass some user metadata to hook business logic on.
+5. Build more complex connection graphs.
+6. Dynamically cancel/begin media publishing/receiving.
+7. Passing erros, connection stats messages.
+8. Cover both P2P mesh and SFU scenarios.
+
+The protocol must be versatile enough to cover all possible use-cases.
+
+## Guide-level explanation
+[guide-level-explanation]: #guide-level-explanation
+
+### What is `WebRTC Client API`? 
+
+It is a part of `Client API` responsible for WebRTC connection management. You can find `Client API` on approximate architecture design. 
+
+```                                                   
+                                                                       .------------Server-----------.
+                                                                       :     .-------------------.   :
+                          .--------------------------------------------+-----o  Control Service  :   :
+                          :                                            :     '--------o----------'   :
+                          :                                            :              |              :
+                          :                                            :        Control Api          :
+.--------Client-----------+------------------------.                   :              |              :
+:  .--------------------. :  .--------------------. :  .-Client-API--. :  .-----------o------------. :
+:  :  User Application  o-'  :  Medea Web Client  o-+--'             '-+--o   Medea Media Server   : :
+:  :                    :----:                    o-+--.             .-+--o                        : :
+:  '--------------------'    '--------------------' :  '----Media----' :  '------------------------' :
+'---------------------------------------------------'                  '-----------------------------'
+                           
+```
+
+So, how it works from `Medea Media Server` point of view:
+1. `Control Service` configures media room via `Control API`.  
+2. `Medea Media Server` provides all necessary information (urls+credentials) for all room members.
+3. `User Application` passes credentials and other necessary stuff (like `<video>` elements) to `Medea Web Client`.
+4. And voila!
+
+### Transport considerations
+Although, signalling can be implemented on top of any transport, WebSocket is suited the most since it provides small overhead reliable duplex connection. Widely used and supported.
+
+### Protocol considerations
+
+Existing best practices are recommended:
+1. Message level ping-pongs.
+2. Reconnects.
+3. Transactions.
+4. Correct usage of close frames.
+
+### Signalling Protocol considerations
+
+One of the main goals, is to make `Medea Web Client` integration as easy as possible. This means less interaction between `User Application` and `Medea Web Client` 
+and more interaction between `Medea Web Client` and `Medea Media Server`, quite verbose `Control Api` design.
+
+Having in mind, that `Medea Media Server` already has user connection graph received from `Control Service` by the moment user connects, 
+it is possible to establish all required connections without bothering `User Application`. Basically connection establishment should not depend on interaction with `User Application`.
+
+On the other hand, some use cases require more manual control over medea exchange process. For example:
+1. User wants to receive lower resolution video.
+2. User wants to stop sending media to specific user.
+3. Mute/unmute.
+
+So API can be divided in two categories:
+1. Preconfigured: where everything works from the box and almost no interaction between `User Application` and `Medea Web Client` required.
+2. Dynamic: when `User Application` needs to express complex use cases.
+
+## Reference-level explanation
+[reference-level-explanation]: #reference-level-explanation
+
+### Used primitives:
+
+```
+   .-------------------------Member---------------------------.
+   : .-----------Peer----------.  .------------Peer---------. :
+   : : .--Track--. .--Track--. :  : .--Track--. .--Track--. : :
+   : : :  video  : :  audio  : :  : :  video  : :  audio  : : :
+   : : :         : :         : :  : :         : :         : : :
+   : : '----o----' '---------' :  : '---------' '----o----' : :
+   : '------|------------------'  '------------------|------' :
+   '--------V----------------------------------------Λ--------'
+            :                                        :
+            :                                        Λ
+            :------->------>-------.                 '---.
+            :                      :                     :
+            V                      :                     Λ
+            :                      :                     :
+   .--------V--------.    .--------V--------.   .--------Λ--------.
+   : .------|------. :    : .------|------. :   : .------|------. :
+   : : .----o----. : :    : : .----o----. : :   : : .----o----. : :
+   : : :  video  : : :    : : :  video  : : :   : : :  audio  : : :
+   : : :         : : :    : : :         : : :   : : :         : : :
+   : : '--Track--' : :    : : '--Track--' : :   : : '--Track--' : :
+   : '-----Peer----' :    : '-----Peer----' :   : '-----Peer----' :
+   '------Member-----'    '------Member-----'   '------Member-----'
+```
+
+#### Member
+
+Just a way to group `Peers` and provide `User Application` with some users meta data.
+
+```
+struct Member {
+    member_id: String,
+    peers: Vec<u64>,
+}
+```
+
+#### Peer
+
+[RTCPeerConnection] representation.
+
+```
+struct Peer {
+    peer_id: u64,
+    p2p: bool,
+    tracks: Vec<Track>,
+}
+```
+
+#### Track
+
+Somewhat [MediaStreamTrack] representation.
+
+```
+struct Track {
+    id: u64,
+    media_type: TrackMediaType,
+    direction: TrackDirection,
+}
+
+enum TrackDirection {
+    Send(Vec<u64>),     // receiver peers
+    Recv(u64),          // sender peer
+}
+
+enum TrackMediaType {
+    Audio(AudioSettings),
+    Video(VideoSettings),
+}
+
+struct AudioSettings {}
+
+struct VideoSettings {}
+```
+
+`P2P` flag implies some logic on `TrackDirection::Send`:
+1. `P2P` send tracks always have only one receiver.
+2. Non `P2P` send tracks can have 0-N receivers. 0 - if media is transmitted to server, but have no actual user receiving it.
+
+### Methods
+
+
+#### AddPeer
+```
+struct AddPeer {
+    peer: Peer,
+    sdp_offer: Option<String>,
+    ice_servers: Vec<String>
+}
+```
+
+Servers requests [RTCPeerConnection] creation.
+
+Params:
+1. `peer` : peer connection settings. The most important part of Peer struct is list of tracks. All `TrackDirection::Send` tracks must be created according to their settings and added to peer. If there is at least one `TrackDirection::Recv` track, then 
+2. `sdp_offer` : if `None`, client should create offer and pass it to the server. If `Some`, client should `setRemoteDescription`, create answer and pass it to the server.
+3. `ice_servers` : just list of ice servers that should be passed to [RTCPeerConnection] constructor.
+
+
+
+## Drawbacks
+[drawbacks]: #drawbacks
+
+Why should we *not* do this?
+
+
+
+
+## Rationale and alternatives
+[rationale-and-alternatives]: #rationale-and-alternatives
+
+- Why is this design the best in the space of possible designs?
+- What other designs have been considered and what is the rationale for not choosing them?
+- What is the impact of not doing this?
+
+
+
+## Unresolved questions
+[unresolved-questions]: #unresolved-questions
+
+Some low-level details 
+
+
+
+
+## Future possibilities
+[future-possibilities]: #future-possibilities
+
+Think about what the natural extension and evolution of your proposal would be and how it would affect the project as a whole in a holistic way. Try to use this section as a tool to more fully consider all possible interactions with the project in your proposal. Also consider how the this all fits into the roadmap for the project and of the relevant sub-team.
+
+This is also a good place to "dump ideas", if they are out of scope for the RFC you are writing but otherwise related.
+
+If you have tried and cannot think of any future possibilities, you may simply state that you cannot think of anything.
+
+Note that having something written down in the future-possibilities section is not a reason to accept the current or a future RFC; such notes should be in the section on [motivation] or [rationale][rationale-and-alternatives] in this or subsequent RFCs. The section merely provides additional information.
+
+
+[RTCPeerConnection]: https://www.w3.org/TR/webrtc/#rtcpeerconnection-interface
+[MediaStreamTrack]: https://www.w3.org/TR/mediacapture-streams/#mediastreamtrack
\ No newline at end of file

From 1648da571934b304d71676e39aa2b3f9fe113e6c Mon Sep 17 00:00:00 2001
From: alexlapa <lapa.alex@ex.ua>
Date: Mon, 17 Dec 2018 23:01:59 -0600
Subject: [PATCH 02/24] extend RFC

---
 docs/rfc/0002-webrc-client-api.md | 825 ++++++++++++++++++++++++++++--
 1 file changed, 787 insertions(+), 38 deletions(-)

diff --git a/docs/rfc/0002-webrc-client-api.md b/docs/rfc/0002-webrc-client-api.md
index 2f730a8c8..c89aa7346 100644
--- a/docs/rfc/0002-webrc-client-api.md
+++ b/docs/rfc/0002-webrc-client-api.md
@@ -9,31 +9,36 @@
 ## Summary
 [summary]: #summary
 
-Formalize communication protocol between client(browser, mobile apps) and media server regarding WebRTC connection management.
+Formalize communication protocol between client(browser, mobile apps) and media server regarding [WebRTC] connection 
+management.
 
 ## Motivation
 [motivation]: #motivation
 
-WebRTC allows P2P data exchange, but WebRTC as a protocol comes without signaling. At a minimum signalling protocol must provide ways to exchange Session Description 
-data(SDP offer/answer) and ICE Candidates. But if you think about signalling protocol in terms of interaction with media server things are becoming more complicated.
+[WebRTC] allows P2P data exchange, but [WebRTC] as a protocol comes without signaling. At a minimum signalling protocol 
+must provide ways to exchange Session Description data([SDP Offer] / [SDP Answer]) and [ICE Candidate]. But if you think about 
+signalling protocol in terms of interaction with media server things are becoming more complicated.
+
 You will need to express ways to:
 1. Provide STUN/TURN servers.
 2. Exchange some low-level media metadata(resolution, codecs, media types).
-3. Allow more sophisticated track management(updating video resolution on preview/fullscreen switches, passing multiple video tracks with different settings).
+3. Allow more sophisticated track management(updating video resolution on preview/fullscreen switches, passing multiple 
+video tracks with different settings).
 4. Pass some user metadata to hook business logic on.
 5. Build more complex connection graphs.
 6. Dynamically cancel/begin media publishing/receiving.
-7. Passing erros, connection stats messages.
+7. Passing errors, connection stats messages.
 8. Cover both P2P mesh and SFU scenarios.
 
-The protocol must be versatile enough to cover all possible use-cases.
+The protocol must be versatile enough to cover all possible use cases.
 
 ## Guide-level explanation
 [guide-level-explanation]: #guide-level-explanation
 
 ### What is `WebRTC Client API`? 
 
-It is a part of `Client API` responsible for WebRTC connection management. You can find `Client API` on approximate architecture design. 
+It is a part of `Client API` responsible for [WebRTC] connection management. You can find `Client API` on approximate 
+architecture design. 
 
 ```                                                   
                                                                        .------------Server-----------.
@@ -58,7 +63,9 @@ So, how it works from `Medea Media Server` point of view:
 4. And voila!
 
 ### Transport considerations
-Although, signalling can be implemented on top of any transport, WebSocket is suited the most since it provides small overhead reliable duplex connection. Widely used and supported.
+
+Although, signalling can be implemented on top of any transport, WebSocket is suited the most since it provides small 
+overhead reliable duplex connection. Widely used and supported.
 
 ### Protocol considerations
 
@@ -66,29 +73,55 @@ Existing best practices are recommended:
 1. Message level ping-pongs.
 2. Reconnects.
 3. Transactions.
-4. Correct usage of close frames.
+4. Using custom Close Frame Status Codes.
+
+Transactions:
+
+Each message is represented as:
+
+```rust
+struct WsMessage<T> {
+    id: i64,
+    payload: Option<Result<Payload<T>, Error>>,
+}
 
+struct Payload<T> {
+    method: String,
+    params: T,
+}
+```
+
+Each message requires answer, answer can carry payload(e.g. answering with [SDP Answer] to [SDP Offer]), error, or nothing, 
+which just means that message reached destination and was processed. 
+ 
 ### Signalling Protocol considerations
 
-One of the main goals, is to make `Medea Web Client` integration as easy as possible. This means less interaction between `User Application` and `Medea Web Client` 
-and more interaction between `Medea Web Client` and `Medea Media Server`, quite verbose `Control Api` design.
+One of the main goals, is to make `Medea Web Client` integration as easy as possible. This means less interaction 
+between `User Application` and `Medea Web Client` and more interaction between `Medea Web Client` and `Medea Media Server`, 
+quite verbose `Control Api` design.
 
-Having in mind, that `Medea Media Server` already has user connection graph received from `Control Service` by the moment user connects, 
-it is possible to establish all required connections without bothering `User Application`. Basically connection establishment should not depend on interaction with `User Application`.
+Having in mind, that `Medea Media Server` already has user connection graph received from `Control Service` by the 
+moment user connects, it is possible to establish all required connections without bothering `User Application`. 
+Basically connection establishment should not depend on interaction with `User Application`.
 
-On the other hand, some use cases require more manual control over medea exchange process. For example:
+On the other hand, some use cases require more manual control over media exchange process. For example:
 1. User wants to receive lower resolution video.
 2. User wants to stop sending media to specific user.
-3. Mute/unmute.
+3. And then start sending media again.
+4. Mute/unmute.
 
 So API can be divided in two categories:
-1. Preconfigured: where everything works from the box and almost no interaction between `User Application` and `Medea Web Client` required.
+1. Preconfigured: where everything works from the box and almost no interaction between `User Application` and 
+`Medea Web Client` required.
 2. Dynamic: when `User Application` needs to express complex use cases.
 
+Current RFC offers combining both ways: everything will be configured automatically, but dynamic API is always there if 
+you need it.
+
 ## Reference-level explanation
 [reference-level-explanation]: #reference-level-explanation
 
-### Used primitives:
+### Data model
 
 ```
    .-------------------------Member---------------------------.
@@ -117,9 +150,9 @@ So API can be divided in two categories:
 
 #### Member
 
-Just a way to group `Peers` and provide `User Application` with some users meta data.
+Just a way to group `Peers` and provide `User Application` with some users meta data. `Member` can have 0-N `Peers`.
 
-```
+```rust
 struct Member {
     member_id: String,
     peers: Vec<u64>,
@@ -128,9 +161,9 @@ struct Member {
 
 #### Peer
 
-[RTCPeerConnection] representation.
+[RTCPeerConnection] representation. `Peer` can have 1-N `Tracks`.
 
-```
+```rust
 struct Peer {
     peer_id: u64,
     p2p: bool,
@@ -142,7 +175,7 @@ struct Peer {
 
 Somewhat [MediaStreamTrack] representation.
 
-```
+```rust
 struct Track {
     id: u64,
     media_type: TrackMediaType,
@@ -164,29 +197,730 @@ struct AudioSettings {}
 struct VideoSettings {}
 ```
 
-`P2P` flag implies some logic on `TrackDirection::Send`:
+`P2P` flag implies some logic on `TrackDirection::Send` tracks:
 1. `P2P` send tracks always have only one receiver.
 2. Non `P2P` send tracks can have 0-N receivers. 0 - if media is transmitted to server, but have no actual user receiving it.
 
 ### Methods
 
+#### 1. AddPeer
 
-#### AddPeer
-```
+```rust
 struct AddPeer {
     peer: Peer,
     sdp_offer: Option<String>,
-    ice_servers: Vec<String>
+    ice_servers: ICEServers
+}
+```
+
+Related objects:
+```rust
+struct ICEServers {
+    urls: Vec<String>,
+    username: String,
+    credential: String,
 }
 ```
 
 Servers requests [RTCPeerConnection] creation.
 
 Params:
-1. `peer` : peer connection settings. The most important part of Peer struct is list of tracks. All `TrackDirection::Send` tracks must be created according to their settings and added to peer. If there is at least one `TrackDirection::Recv` track, then 
-2. `sdp_offer` : if `None`, client should create offer and pass it to the server. If `Some`, client should `setRemoteDescription`, create answer and pass it to the server.
-3. `ice_servers` : just list of ice servers that should be passed to [RTCPeerConnection] constructor.
+1. `peer`: peer connection settings.
+2. `sdp_offer`: if `None`, client should create [SDP Offer] and pass it to the server. If `Some`, client should 
+`setRemoteDescription`, create [SDP Answer] and pass it to the server.
+3. `ice_servers`: just list of ice servers that should be passed to [RTCPeerConnection] constructor.
+
+Peer settings should be discussed in more detail.
+
+The most important part of `Peer` object is list of tracks. All `TrackDirection::Send` tracks must be created according 
+to their settings and added to peer. If there is at least one `TrackDirection::Recv` track, then created 
+[RTCPeerConnection] must be ready to receive tracks(`recvonly`/`sendrecv` SDP). Currently there are multiple ways to 
+achieve this on client side and concrete implementation is not part of this RFC. 
+
+#### Examples
+
+1. Create Audio+Video `sendrecv` p2p `Peer`.
+
+```json
+{
+  "peer": {
+    "peer_id": 1,
+    "p2p": true,
+    "tracks": [
+      {
+        "id": 1,
+        "media_type": {
+          "Audio": {}
+        },
+        "direction": {
+          "Send": {
+            "receivers": [
+              2
+            ]
+          }
+        }
+      },
+      {
+        "id": 2,
+        "media_type": {
+          "Video": {}
+        },
+        "direction": {
+          "Send": {
+            "receivers": [
+              2
+            ]
+          }
+        }
+      },
+      {
+        "id": 3,
+        "media_type": {
+          "Audio": {}
+        },
+        "direction": {
+          "Recv": {
+            "sender": 2
+          }
+        }
+      },
+      {
+        "id": 4,
+        "media_type": {
+          "Video": {}
+        },
+        "direction": {
+          "Recv": {
+            "sender": 2
+          }
+        }
+      }
+    ]
+  },
+  "sdp_offer": null,
+  "ice_servers": {
+    "urls": [
+      "turn:turnserver.com:3478",
+      "turn:turnserver.com:3478?transport=tcp"
+    ],
+    "username": "turn_user",
+    "credential": "turn_credential"
+  }
+}
+```
+
+Client is expected to:
+1. Create [RTCPeerConnection] with provided ice servers and associate it with given `peer_id`.
+2. Initialize Audio and Video tracks without any additional settings.
+3. Add newly created tracks to [RTCPeerConnection].
+4. Create `sendrecv` [SDP Offer].
+5. Set offer as peers local description.
+6. Answer `AddPeer` request with `Offer` request containing [SDP Offer].
+7. Expect remote [SDP Answer] to set it as remote description.
+
+After negotiation is done and media starts flowing, client will receive notification that his media is being sent to 
+`Peer { peer_id = 2 }`, and he is receiving media from `Peer { peer_id = 2 }`.
+
+2. Create Audio `send` to SFU `Peer`.
+
+```json
+{
+  "peer": {
+    "peer_id": 1,
+    "p2p": false,
+    "tracks": [
+      {
+        "id": 1,
+        "media_type": {
+          "Audio": {}
+        },
+        "direction": {
+          "Send": {
+            "receivers": []
+          }
+        }
+      }
+    ]
+  },
+  "sdp_offer": "server_user1_recvonly_offer",
+  "ice_servers": {
+    "urls": [
+      "turn:turnserver.com:3478",
+      "turn:turnserver.com:3478?transport=tcp"
+    ],
+    "username": "turn_user",
+    "credential": "turn_credential"
+  }
+}
+```
+
+Client is expected to:
+1. Create [RTCPeerConnection] with provided ice servers and associate it with given `peer_id`.
+2. Initialize Audio track without any additional settings.
+3. Add newly created track to [RTCPeerConnection].
+4. Set provided offer as peers remote description.
+5. Create `sendonly` [SDP Answer].
+6. Set created [SDP Answer] as local description.
+7. Answer `AddPeer` request with `Answer` request containing [SDP Offer]. 
+
+After negotiation is done and media starts flowing, client will receive notification that his media is being sent to 
+server.
+
+
+#### 2. RemovePeers
+
+```rust
+struct RemovePeers {
+    peer_ids: Vec<u64>,
+}
+```
+
+Server's/Client's request to dispose(close) specified `Peers`.
+
+If Server => Client, then Client must dispose specified `Peers`.
+If Client => Server, then Client requests Server's permission to dispose specified `Peers`. Server may give permission 
+in answer.
+
+Probably, Server will always give his permission on any Client's request. This kind of request flow will allow Server 
+to do any request related stuff that Server needs to do, and distinguish between abnormal and normal events.
+
+#### Examples
+
+1. Server tells client to dispose specified `Peers` / Client requests Server's permission to dispose specified `Peers`.
+
+```json
+{
+  "peer_ids": [
+    1, 2, 3
+  ]
+}
+```
+
+#### 3. UpdateTracks
+
+```rust
+struct UpdateTracks {
+    peer_id: u64,
+    tracks: Vec<Track>,
+}
+```
+
+Server's/Client's request to update tracks in specified `Peer`.
+
+If Server => Client, then it can be used to:
+1. Add new track.
+2. Update existing track settings (e.g. change to lower video resolution, mute audio).
+3. Update send track receivers list (add/remove).
+
+If Client => Server, then it can be used to express Clients intentions to:
+1. Update existing track settings.
+2. Cancel sending media to specific receiver (only remove).
+
+#### Examples 
+
+Assuming such `Peer` exists on Clients end:
+
+```json
+{
+  "peer_id": 1,
+  "p2p": false,
+  "tracks": [
+    {
+      "id": 1,
+      "media_type": {
+        "Audio": {}
+      },
+      "direction": {
+        "Send": {
+          "receivers": []
+        }
+      }
+    },
+    {
+      "id": 2,
+      "media_type": {
+        "Video": {}
+      },
+      "direction": {
+        "Send": {
+          "receivers": []
+        }
+      }
+    }
+  ]
+}
+```
+
+Meaning that media is being published to server but has no actual receivers.
+
+1. Server notifies Client that video is being received by other `Peer {peer_id = 2}`.
+
+Server => Client
+
+```json
+{
+  "peer_id": 1,
+  "tracks": [
+    {
+      "id": 1,
+      "media_type": {
+        "Audio": {}
+      },
+      "direction": {
+        "Send": {
+          "receivers": [
+            2
+          ]
+        }
+      }
+    },
+    {
+      "id": 2,
+      "media_type": {
+        "Video": {}
+      },
+      "direction": {
+        "Send": {
+          "receivers": [
+            2
+          ]
+        }
+      }
+    }
+  ]
+}
+```
+
+2. Client wants to unsubscribe `Peer {peer_id = 2}` from specified tracks.
+
+Client => Server
+
+```json
+{
+  "peer_id": 1,
+  "tracks": [
+    {
+      "id": 1,
+      "media_type": {
+        "Audio": {}
+      },
+      "direction": {
+        "Send": {
+          "receivers": []
+        }
+      }
+    },
+    {
+      "id": 2,
+      "media_type": {
+        "Video": {}
+      },
+      "direction": {
+        "Send": {
+          "receivers": []
+        }
+      }
+    }
+  ]
+}
+```
+
+
+#### 4. RemoveTracks
+
+```rust
+struct RemoveTracks {
+    peer_id: u64,
+    tracks: Vec<u64>,
+}
+```
+
+Server's/Client's request to dispose specified `Tracks`.
+
+If Server => Client, then Client must dispose(stop and remove).
+If Client => Server, then Client requests Server's permission to dispose specified `Peers`.
+
+#### Examples
+
+1. Server tells client to dispose specified `Tracks` / Client requests Server's permission to dispose specified `Tracks`.
 
+```json
+{
+  "peer_id": 1,
+  "tracks": [1, 2]
+}
+```
+
+#### 5. Offer
+
+```rust
+struct Offer {
+    peer_id: u64,
+    sdp_offer: String,
+}
+```
+
+Server's / Client's [SDP Offer] sent during SDP negotiation between peers.
+
+Client can send it:
+1. As answer to `AddPeer {sdp_offer: None}`
+2. As answer to `UpdateTracks` if update requires SDP renegotiation.
+
+Server can send it:
+1. If server triggers renegotiation.
+2. Retransmission from peer that triggered renegotiation.
+
+#### Examples
+
+1. Client sends `Peers` [SDP Offer]
+
+```json
+{
+  "peer_id": 1,
+  "sdp_offer": "sdp_offer_body"
+}
+```
+
+#### 6. Answer
+
+```rust
+struct Answer {
+    peer_id: u64,
+    sdp_answer: String,
+}
+```
+
+Server's / Client's [SDP Answer]  sent during SDP negotiation between peers.
+
+Client can send it:
+1. As answer to `AddPeer {sdp_offer: Some}`.
+2. As answer to `Offer`.
+
+Server can send it only as answer to `Offer`.
+
+#### Examples
+
+1. Client sends `Peers` [SDP Answer]
+
+```json
+{
+  "peer_id": 1,
+  "sdp_offer": "sdp_answer_body"
+}
+```
+
+#### 7. Candidate
+
+```rust
+struct Candidate {
+    peer_id: u64,
+    candidate: String,
+}
+```
+
+Server's / Client's [ICE Candidate] sent during ICE negotiation.
+
+Just send each [ICE Candidate] discovered by underlying [RTCPeerConnection] to remote `Peer`. It's as simple as that.
+
+#### 8. RemotePeers
+
+```rust
+struct RemotePeers {
+    peers: Vec<RemotePeer>
+}
+```
+
+Related objects:
+
+```rust
+struct RemotePeer {
+    remote_peer_id: Option<u64>,
+    remote_member_id: Option<String>,
+    can_rx: Option<RemotePeerTrackType>,
+    can_tx: Option<RemotePeerTrackType>,
+}
+
+enum RemotePeerTrackType {
+    Audio {
+        audio_settings: Option<AudioSettings>,
+    },
+    Video {
+        video_settings: Option<VideoSettings>,
+    },
+    AudioVideo {
+        audio_settings: Option<AudioSettings>,
+        video_settings: Option<VideoSettings>,
+    },
+}
+```
+
+Server notifies Client of any remote peers that Client can connect to. This is a key method when talking about Dynamic API mentioned in `Signalling Protocol considerations`. 
+
+#### Examples:
+
+1. Notify Client that it is possible subscribe to `Member {id = 2}` Video and Audio tracks.
+
+```json
+{
+  "peers": [
+    {
+      "peer_id": 2,
+      "member_id": "User2",
+      "can_rx": {
+        "AudioVideo": {
+          "audio_settings": {},
+          "video_settings": {}
+        }
+      },
+      "can_tx": null
+    }
+  ]
+}
+```
+
+#### 8. RequestTracks
+
+```rust
+struct RequestTracks {
+    local_peer_id: Option<u64>,
+    remote_peer_id: u64,
+    rx: Option<RemotePeerTrackType>,
+    tx: Option<RemotePeerTrackType>,
+}
+```
+
+
+
+### Extended examples
+
+#### 1. 1 <=> 1 p2p with unpublish and republish
+
+```
+.----user1----.    .->-->-->--. .----user2----.
+:             o(1)=:          :=o(2)          :
+'-------------'    '-<--<--<--' '-------------'
+```
+
+1. Server send `AddPeer` to user1.
+```json
+{
+  "method": "AddPeer",
+  "payload": {
+    "peer": {
+      "peer_id": 1,
+      "p2p": true,
+      "tracks": [
+        {
+          "id": 1,
+          "media_type": {
+            "Audio": {}
+          },
+          "direction": {
+            "Send": {
+              "receivers": [
+                2
+              ]
+            }
+          }
+        },
+        {
+          "id": 2,
+          "media_type": {
+            "Video": {}
+          },
+          "direction": {
+            "Send": {
+              "receivers": [
+                2
+              ]
+            }
+          }
+        },
+        {
+          "id": 3,
+          "media_type": {
+            "Audio": {}
+          },
+          "direction": {
+            "Recv": {
+              "sender": 2
+            }
+          }
+        },
+        {
+          "id": 4,
+          "media_type": {
+            "Video": {}
+          },
+          "direction": {
+            "Recv": {
+              "sender": 2
+            }
+          }
+        }
+      ]
+    },
+    "sdp_offer": null,
+    "ice_servers": {
+      "urls": [
+        "turn:turnserver.com:3478",
+        "turn:turnserver.com:3478?transport=tcp"
+      ],
+      "username": "turn_user",
+      "credential": "turn_credential"
+    }
+  }
+}
+```
+
+2. User1 answers with [SDP Offer].
+```json
+{
+  "method": "Offer",
+  "payload": {
+    "peer_id": 1,
+    "sdp_offer": "user1_sendrecv_offer"
+  }
+}
+```
+
+3. Server send `AddPeer` with user1 [SDP Offer] to user2.
+```json
+{
+  "method": "AddPeer",
+  "payload": {
+    "peer": {
+      "peer_id": 2,
+      "p2p": true,
+      "tracks": [
+        {
+          "id": 1,
+          "media_type": {
+            "Audio": {}
+          },
+          "direction": {
+            "Recv": {
+              "sender": 1
+            }
+          }
+        },
+        {
+          "id": 2,
+          "media_type": {
+            "Audio": {}
+          },
+          "direction": {
+            "Recv": {
+              "sender": 1
+            }
+          }
+        },
+        {
+          "id": 3,
+          "media_type": {
+            "Audio": {}
+          },
+          "direction": {
+            "Send": {
+              "receivers": [
+                1
+              ]
+            }
+          }
+        },
+        {
+          "id": 4,
+          "media_type": {
+            "Video": {}
+          },
+          "direction": {
+            "Send": {
+              "receivers": [
+                1
+              ]
+            }
+          }
+        }
+      ]
+    },
+    "sdp_offer": "user1_sendrecv_offer",
+    "ice_servers": {
+      "urls": [
+        "turn:turnserver.com:3478",
+        "turn:turnserver.com:3478?transport=tcp"
+      ],
+      "username": "turn_user",
+      "credential": "turn_credential"
+    }
+  }
+}
+```
+
+3. User2 answers with [SDP Answer]
+```json
+{
+  "method": "Answer",
+  "payload": {
+    "peer_id": 2,
+    "sdp_answer": "user2_sendrecv_answer"
+  }
+}
+```
+
+4. Both peers exchange discovered [ICE Candidate]'s. TODO
+
+```json
+
+```
+
+5. At this point connection is supposed to be established.
+
+```
+.----user1----.    .->-->-->--. .----user2----.
+:             o(1)=:          :=o(2)          :
+'-------------'    '-<--<--<--' '-------------'
+```
+
+6. User1 wants to unpublish his tracks, so he sends `RemoveTracks` Server.
+
+```json
+{
+  "method": "RemoveTracks",
+  "payload": {
+    "peer_id": 1,
+    "tracks": [
+      1,
+      2
+    ]
+  }
+}
+```
+
+7. Server approves 
+
+```json
+
+```
+
+```json
+
+```
+
+```json
+
+```
+
+```json
+
+```
+
+```json
+
+```
+
+```json
+
+```
 
 
 ## Drawbacks
@@ -206,25 +940,40 @@ Why should we *not* do this?
 
 
 
-## Unresolved questions
+## Unresolved questions and future possibilities
 [unresolved-questions]: #unresolved-questions
 
-Some low-level details 
+### Data channels
 
+[WebRTC] spec introduces [RTCDataChannel] - a bi-directional data channel between two peers which allows arbitrary data 
+exchange. It is an amazing feature with huge potential, but, at this point it is quite useless for our use cases.
 
+As the project develops, requirements will change, and we might consider adding data channels. Although, they are not 
+mentioned in this protocol, only minor tweaks will be required to support them.
 
+### Multiple recv tracks from different senders
 
-## Future possibilities
-[future-possibilities]: #future-possibilities
+There are two general ways to manage Client's peer connections when using SFU server:
+1. Having only one pair of [RTCPeerConnection]'s (one at Client end and one at Server) and passing all send/recv tracks 
+through this connection.
+2. Having a separate [RTCPeerConnection] pair for each track group.
 
-Think about what the natural extension and evolution of your proposal would be and how it would affect the project as a whole in a holistic way. Try to use this section as a tool to more fully consider all possible interactions with the project in your proposal. Also consider how the this all fits into the roadmap for the project and of the relevant sub-team.
+First way is preferable since it allows to reduce resources usage on both ends. But track management is very unclear in 
+this case and gstreamers [webrtcbin] currently does not support dynamic addition/removal of streams and needs major 
+updates to be able to do so.
 
-This is also a good place to "dump ideas", if they are out of scope for the RFC you are writing but otherwise related.
+Current protocol assumes that there will be separate [RTCPeerConnection] pair for each track group. 
+At the same time, it does not forbid having all the tracks in single [RTCPeerConnection] pair, but it will require some 
+minor changes to make this work.
 
-If you have tried and cannot think of any future possibilities, you may simply state that you cannot think of anything.
 
-Note that having something written down in the future-possibilities section is not a reason to accept the current or a future RFC; such notes should be in the section on [motivation] or [rationale][rationale-and-alternatives] in this or subsequent RFCs. The section merely provides additional information.
 
 
 [RTCPeerConnection]: https://www.w3.org/TR/webrtc/#rtcpeerconnection-interface
-[MediaStreamTrack]: https://www.w3.org/TR/mediacapture-streams/#mediastreamtrack
\ No newline at end of file
+[MediaStreamTrack]: https://www.w3.org/TR/mediacapture-streams/#mediastreamtrack
+[webrtcbin]: https://gstreamer.freedesktop.org/data/doc/gstreamer/head/gst-plugins-bad/html/gst-plugins-bad-plugins-webrtcbin.html
+[RTCDataChannel]:https://www.w3.org/TR/webrtc/#rtcdatachannel
+[WebRTC]:https://www.w3.org/TR/webrtc/
+[SDP Offer]:https://tools.ietf.org/html/rfc3264
+[SDP Answer]:https://tools.ietf.org/html/rfc3264
+[ICE Candidate]:https://tools.ietf.org/html/rfc8445
\ No newline at end of file

From 41f800080a0993d46b04f7447b30704a45bc04a5 Mon Sep 17 00:00:00 2001
From: alexlapa <lapa.alex@ex.ua>
Date: Tue, 18 Dec 2018 12:29:46 -0600
Subject: [PATCH 03/24] extend RFC

---
 docs/rfc/0002-webrc-client-api.md | 769 ++++++++++++++++++++++++++++--
 1 file changed, 720 insertions(+), 49 deletions(-)

diff --git a/docs/rfc/0002-webrc-client-api.md b/docs/rfc/0002-webrc-client-api.md
index c89aa7346..025f4ce39 100644
--- a/docs/rfc/0002-webrc-client-api.md
+++ b/docs/rfc/0002-webrc-client-api.md
@@ -239,7 +239,7 @@ achieve this on client side and concrete implementation is not part of this RFC.
 
 #### Examples
 
-1. Create Audio+Video `sendrecv` p2p `Peer`.
+1\. Create Audio+Video `sendrecv` p2p `Peer`.
 
 ```json
 {
@@ -254,9 +254,7 @@ achieve this on client side and concrete implementation is not part of this RFC.
         },
         "direction": {
           "Send": {
-            "receivers": [
-              2
-            ]
+            "receivers": [ 2 ]
           }
         }
       },
@@ -267,9 +265,7 @@ achieve this on client side and concrete implementation is not part of this RFC.
         },
         "direction": {
           "Send": {
-            "receivers": [
-              2
-            ]
+            "receivers": [ 2 ]
           }
         }
       },
@@ -321,7 +317,7 @@ Client is expected to:
 After negotiation is done and media starts flowing, client will receive notification that his media is being sent to 
 `Peer { peer_id = 2 }`, and he is receiving media from `Peer { peer_id = 2 }`.
 
-2. Create Audio `send` to SFU `Peer`.
+2\. Create Audio `send` to SFU `Peer`.
 
 ```json
 {
@@ -390,9 +386,7 @@ to do any request related stuff that Server needs to do, and distinguish between
 
 ```json
 {
-  "peer_ids": [
-    1, 2, 3
-  ]
+  "peer_ids": [ 1, 2, 3 ]
 }
 ```
 
@@ -453,7 +447,7 @@ Assuming such `Peer` exists on Clients end:
 
 Meaning that media is being published to server but has no actual receivers.
 
-1. Server notifies Client that video is being received by other `Peer {peer_id = 2}`.
+1\. Server notifies Client that video is being received by other `Peer {peer_id = 2}`.
 
 Server => Client
 
@@ -468,9 +462,7 @@ Server => Client
       },
       "direction": {
         "Send": {
-          "receivers": [
-            2
-          ]
+          "receivers": [ 2 ]
         }
       }
     },
@@ -481,9 +473,7 @@ Server => Client
       },
       "direction": {
         "Send": {
-          "receivers": [
-            2
-          ]
+          "receivers": [ 2 ]
         }
       }
     }
@@ -491,7 +481,7 @@ Server => Client
 }
 ```
 
-2. Client wants to unsubscribe `Peer {peer_id = 2}` from specified tracks.
+2\. Client wants to unsubscribe `Peer {peer_id = 2}` from specified tracks.
 
 Client => Server
 
@@ -654,7 +644,15 @@ enum RemotePeerTrackType {
 }
 ```
 
-Server notifies Client of any remote peers that Client can connect to. This is a key method when talking about Dynamic API mentioned in `Signalling Protocol considerations`. 
+Server notifies Client of any remote peers that Client can connect to. This is a key method when talking about Dynamic 
+API mentioned in `Signalling Protocol considerations`. Any Client's request to subscriber/publish will be based on data
+provided by this request.
+
+Params:
+1. ```remote_peer_id```: if `Some`, then represents specific remote `Peer` associated with some `Member`. If `None`, then represents Servers peer connection.
+2. ```remote_member_id```: if `Some`, then represents specific remote `Member` associated with some . If `None`, then represents Servers peer connection.
+3. ```can_rx```: if `Some` then Client can subscribe to specified media.
+4. ```can_tx```: if `Some` then Client can publish specified media to remote `Peer`.
 
 #### Examples:
 
@@ -678,22 +676,169 @@ Server notifies Client of any remote peers that Client can connect to. This is a
 }
 ```
 
+2. Notify Client that it is possible to publish Audio to specified `Peers`.
+
+```json
+{
+  "peers": [
+    {
+      "peer_id": 2,
+      "member_id": "User2",
+      "can_rx": null,
+      "can_tx": {
+        "Audio": {
+          "audio_settings": {}
+        }
+      }
+    },
+    {
+      "peer_id": 3,
+      "member_id": "User3",
+      "can_rx": null,
+      "can_tx": {
+        "Audio": {
+          "audio_settings": {}
+        }
+      }
+    }
+  ]
+}
+```
+
+Params:
+1. ```remote_peer_id```: if `Some`, then represents specific remote `Peer` associated with some `Member`. If `None`, 
+then represents Servers peer connection (only SFU).
+2. ```remote_member_id```: if `Some`, then represents specific remote `Member`. If `None`, then represents Server's peer 
+connection (only SFU).
+3. ```can_rx```: if `Some` then Client can subscribe to specified media.
+4. ```can_tx```: if `Some` then Client can publish specified media to remote `Peer`.
+
 #### 8. RequestTracks
 
 ```rust
 struct RequestTracks {
-    local_peer_id: Option<u64>,
-    remote_peer_id: u64,
+    peer_id: Option<u64>,
+    remote_peer_id: Option<u64>,
     rx: Option<RemotePeerTrackType>,
     tx: Option<RemotePeerTrackType>,
 }
 ```
 
+Related objects:
+
+```rust
+enum RemotePeerTrackType {
+    Audio {
+        audio_settings: Option<AudioSettings>,
+    },
+    Video {
+        video_settings: Option<VideoSettings>,
+    },
+    AudioVideo {
+        audio_settings: Option<AudioSettings>,
+        video_settings: Option<VideoSettings>,
+    },
+}
+```
+
+Client requests to send or receive media to/from remote peer.
+
+Params:
+1. ```peer_id```: if `Some` then Client wants to connect specified local `Peer` to remote. If `None`then it us to server
+to decide which of Client's `Peers` will be connected.
+2. ```remote_peer_id```: if `Some`, then represents specific remote `Member` associated with some . If `None`, then 
+represents Server's peer connection (only SFU).
+3. ```rx```: if `Some` then Client requests to subscribe to specified media.
+4. ```tx```: if `Some` then Client requests to publish specified media to remote `Peer`.
+
+#### Examples
+
+1\. Client requests to subscribe to remote `Peer {peer_id = 2}` audio and video.
+
+```json
+{
+  "peer_id": 1,
+  "remote_peer_id": 2,
+  "rx": null,
+  "tx": {
+    "AudioVideo": {
+      "audio_settings": {},
+      "video_settings": {}
+    }
+  }
+}
+```
+
+2\. Client requests to publish to Server's peer connection.
+
+```json
+{
+  "peer_id": 1,
+  "remote_peer_id": null,
+  "rx": null,
+  "tx": {
+    "AudioVideo": {
+      "audio_settings": {},
+      "video_settings": {}
+    }
+  }
+}
+```
+
+#### 9. GetMembers, Members
+
+```rust
+struct GetMembers {
+    peer_ids: Vec<u64>,
+}
+```
+
+Client requests `Member` ids.
+
+```rust
+struct Members {
+    members: Vec<Member>
+}
+```
+
+Server provides `Member`'s list according to user request.
 
+It is recommended to cache `Peer` id - `Member` id relation in Web Client. Probably, in two maps: `HashMap<peer_id, member_id>`, `HashMap<member_id, peer_id>`.
+
+#### Examples
+
+1\. Client request `Member`'s that own specified `Peer`'s.
+```json
+{
+  "peer_ids": [
+    2, 3, 4
+  ]
+}
+```
+
+2\. Server provides `Member`'s that own specified `Peers`'s.
+```json
+{
+  "members": [
+    {
+      "member_id": "user_2",
+      "peers": [ 1 ]
+    },
+    {
+      "member_id": "user_2",
+      "peers": [ 2 ]
+    },
+    {
+      "member_id": "user_3",
+      "peers": [ 3, 4 ]
+    }
+  ]
+}
+```
 
 ### Extended examples
 
-#### 1. 1 <=> 1 p2p with unpublish and republish
+#### 1. 1 <=> 1 p2p with unpublish and republish.   
 
 ```
 .----user1----.    .->-->-->--. .----user2----.
@@ -701,7 +846,8 @@ struct RequestTracks {
 '-------------'    '-<--<--<--' '-------------'
 ```
 
-1. Server send `AddPeer` to user1.
+1\. Server send `AddPeer` to user1. 
+
 ```json
 {
   "method": "AddPeer",
@@ -772,8 +918,9 @@ struct RequestTracks {
   }
 }
 ```
+ 
+2\. User1 answers with [SDP Offer]. 
 
-2. User1 answers with [SDP Offer].
 ```json
 {
   "method": "Offer",
@@ -783,8 +930,9 @@ struct RequestTracks {
   }
 }
 ```
+ 
+3\. Server send `AddPeer` with user1 [SDP Offer] to user2.
 
-3. Server send `AddPeer` with user1 [SDP Offer] to user2.
 ```json
 {
   "method": "AddPeer",
@@ -822,9 +970,7 @@ struct RequestTracks {
           },
           "direction": {
             "Send": {
-              "receivers": [
-                1
-              ]
+              "receivers": [ 1 ]
             }
           }
         },
@@ -835,9 +981,7 @@ struct RequestTracks {
           },
           "direction": {
             "Send": {
-              "receivers": [
-                1
-              ]
+              "receivers": [ 1 ]
             }
           }
         }
@@ -856,7 +1000,8 @@ struct RequestTracks {
 }
 ```
 
-3. User2 answers with [SDP Answer]
+4\. User2 answers with [SDP Answer]
+
 ```json
 {
   "method": "Answer",
@@ -867,13 +1012,29 @@ struct RequestTracks {
 }
 ```
 
-4. Both peers exchange discovered [ICE Candidate]'s. TODO
+5\. Both peers exchange discovered [ICE Candidate]'s.
 
 ```json
+{
+  "method": "Candidate",
+  "payload": {
+    "peer_id": 1,
+    "candidate": "user1_ice_candidate"
+  }
+}
+```
 
+```json
+{
+  "method": "Candidate",
+  "payload": {
+    "peer_id": 2,
+    "candidate": "user1_ice_candidate"
+  }
+}
 ```
 
-5. At this point connection is supposed to be established.
+6\. At this point connection is supposed to be established.
 
 ```
 .----user1----.    .->-->-->--. .----user2----.
@@ -881,67 +1042,577 @@ struct RequestTracks {
 '-------------'    '-<--<--<--' '-------------'
 ```
 
-6. User1 wants to unpublish his tracks, so he sends `RemoveTracks` Server.
+7\. User1 wants to unpublish his tracks, so he sends `RemoveTracks` Server.
 
 ```json
 {
   "method": "RemoveTracks",
   "payload": {
     "peer_id": 1,
+    "tracks": [1, 2]
+  }
+}
+```
+
+8\. Server updates User2 tracks.
+
+```json
+{
+  "method": "RemoveTracks",
+  "payload": {
+    "peer_id": 2,
+    "tracks": [ 1, 2 ]
+  }
+}
+```
+
+9\. Server approves User1 `RemoveTracks` request.
+
+10\. User1 initiates SDP renegotiation
+
+```
+.----user1----.         .----user2----.
+:             o(1)-<--<-o(2)          :
+'-------------'         '-------------'
+```
+
+11\. Server notifies User1 that he can publish to User2
+
+```json
+{
+  "method": "RemotePeer",
+  "payload": {
+    "peers": [
+      {
+        "peer_id": 2,
+        "member_id": "user_2",
+        "can_rx": null,
+        "can_tx": {
+          "AudioVideo": {
+            "audio_settings": {},
+            "video_settings": {}
+          }
+        }
+      }
+    ]
+  }
+}
+```
+
+12\. Server notifies User2 that he can subscriber to User1.
+
+```json
+{
+  "method": "RemotePeers",
+  "payload": {
+    "peers": [
+      {
+        "peer_id": 1,
+        "member_id": "user_1",
+        "can_rx": {
+          "AudioVideo": {
+            "audio_settings": {},
+            "video_settings": {}
+          }
+        },
+        "can_tx": null
+      }
+    ]
+  }
+}
+```
+
+13\. User1 requests to publish to User2.
+
+```json
+{
+  "method": "RequestTracks",
+  "payload": {
+    "peer_id": 1,
+    "remote_peer_id": 2,
+    "rx": null,
+    "tx": {
+      "AudioVideo": {
+        "audio_settings": {},
+        "video_settings": {}
+      }
+    }
+  }
+}
+```
+
+14\. Server updates User2 tracks.
+
+```json
+{
+  "method": "UpdateTracks",
+  "payload": {
+    "peer_id": 2,
     "tracks": [
-      1,
-      2
+      {
+        "id": 1,
+        "media_type": {
+          "Audio": {}
+        },
+        "direction": {
+          "Recv": {
+            "sender": 1
+          }
+        }
+      },
+      {
+        "id": 2,
+        "media_type": {
+          "Audio": {}
+        },
+        "direction": {
+          "Recv": {
+            "sender": 1
+          }
+        }
+      }
     ]
   }
 }
 ```
 
-7. Server approves 
+15\. Server updates User1 tracks.
 
 ```json
+{
+  "method": "UpdateTracks",
+  "payload": {
+    "peer_id": 1,
+    "tracks": [
+      {
+        "id": 1,
+        "media_type": {
+          "Audio": {}
+        },
+        "direction": {
+          "Send": {
+            "receivers": [ 2 ]
+          }
+        }
+      },
+      {
+        "id": 2,
+        "media_type": {
+          "Video": {}
+        },
+        "direction": {
+          "Send": {
+            "receivers": [ 2 ]
+          }
+        }
+      }
+    ]
+  }
+}
+```
+
+16\. SDP Renegotiation
+
+```
+.----user1----.    .->-->-->--. .----user2----.
+:             o(1)=:          :=o(2)          :
+'-------------'    '-<--<--<--' '-------------'
+```
+
+#### 2. 1 => 2 SFU.
+
+```
+                                                       .-------user2------.
+                          .-------SFU-------.    .-->--o      pc_id = 2   :
+.------user1------.       :       .---->----o-->-'     '------------------'
+:     pc_id = 1   o-->-->-o--->---:         :
+'-----------------'       :       '---->----o-->-.     .-------user3------.
+                          '-----------------'    '-->--o      pc_id = 3   :
+                                                       '------------------'
+```
+
+1\. Server requests User1 to create `sendonly` `Peer` passing Server's [SDP Offer].
 
+```json
+{
+  "method": "AddPeer",
+  "payload": {
+    "peer": {
+      "peer_id": 1,
+      "p2p": false,
+      "tracks": [
+        {
+          "id": 1,
+          "media_type": {
+            "Audio": {}
+          },
+          "direction": {
+            "Send": {
+              "receivers": []
+            }
+          }
+        },
+        {
+          "id": 2,
+          "media_type": {
+            "Video": {}
+          },
+          "direction": {
+            "Send": {
+              "receivers": []
+            }
+          }
+        }
+      ]
+    },
+    "sdp_offer": "server_user1_recvonly_offer",
+    "ice_servers": {
+      "urls": [
+        "turn:turnserver.com:3478",
+        "turn:turnserver.com:3478?transport=tcp"
+      ],
+      "username": "turn_user",
+      "credential": "turn_credential"
+    }
+  }
+}
 ```
 
+2\. User1 creates peer and answeres with [SDP Answer].
+
 ```json
+{
+  "method": "Answer",
+  "payload": {
+    "peer_id": 1,
+    "sdp_answer": "user_1_sendonly_answer"
+  }
+}
+```
+
+3\. Server and User1 exchange [ICE Candidate]'s.
 
+```json
+{
+  "method": "Candidate",
+  "payload": {
+    "peer_id": 1,
+    "candidate": "user1_ice_candidate"
+  }
+}
 ```
 
 ```json
+{
+  "method": "Candidate",
+  "payload": {
+    "peer_id": 1,
+    "candidate": "servers_ice_candidate"
+  }
+}
+```
+
+4\. Connection is established
+
+```
+                          .-------SFU-------.
+.------user1------.       :                 ;
+:     pc_id = 1   o-->-->-o                 :
+'-----------------'       :                 ;
+                          '-----------------'
+```
 
+5\. Server requests User2 to create `recvonly` `Peer` passing Server's [SDP Offer]. 
+
+```json
+{
+  "method": "AddPeer",
+  "payload": {
+    "peer": {
+      "peer_id": 2,
+      "p2p": false,
+      "tracks": [
+        {
+          "id": 1,
+          "media_type": {
+            "Audio": {}
+          },
+          "direction": {
+            "Recv": {
+              "sender": 1
+            }
+          }
+        },
+        {
+          "id": 2,
+          "media_type": {
+            "Video": {}
+          },
+          "direction": {
+            "Recv": {
+              "sender": 1
+            }
+          }
+        }
+      ]
+    },
+    "sdp_offer": "server_user2_sendonly_offer",
+    "ice_servers": {
+      "urls": [
+        "turn:turnserver.com:3478",
+        "turn:turnserver.com:3478?transport=tcp"
+      ],
+      "username": "turn_user",
+      "credential": "turn_credential"
+    }
+  }
+}
 ```
 
+6\. User2 answers with [SDP Answer].
+
 ```json
+{
+  "method": "Answer",
+  "payload": {
+    "peer_id": 2,
+    "sdp_answer": "user_2_recvonly_answer"
+  }
+}
+```
 
+7\. Server and User2 exchange [ICE Candidate]'s.
+
+```json
+{
+  "method": "Candidate",
+  "payload": {
+    "peer_id": 2,
+    "candidate": "user1_ice_candidate"
+  }
+}
 ```
 
 ```json
+{
+  "method": "Candidate",
+  "payload": {
+    "peer_id": 2,
+    "candidate": "servers_ice_candidate"
+  }
+}
+```
+
+8\. User2 is connected to Server's peer connection.
 
 ```
+                                                       .-------user2------.
+                          .-------SFU-------.    .-->--o      pc_id = 2   :
+.------user1------.       :                 o-->-'     '------------------'
+:     pc_id = 1   o-->-->-o-                :
+'-----------------'       :                 :
+                          '-----------------'
+```
+
+9\. Server notifies User1 that he has new subscriber.
 
 ```json
+{
+  "method": "UpdateTracks",
+  "payload": {
+    "peer_id": 1,
+    "tracks": [
+      {
+        "id": 1,
+        "media_type": {
+          "Audio": {}
+        },
+        "direction": {
+          "Send": {
+            "receivers": [ 2 ]
+          }
+        }
+      },
+      {
+        "id": 2,
+        "media_type": {
+          "Video": {}
+        },
+        "direction": {
+          "Send": {
+            "receivers": [2]
+          }
+        }
+      }
+    ]
+  }
+}
+```
+
+10\. Server sends User1 `Peer {peer_id = 1 }` media to User2 `Peer {peer_id = 2 }`.
+
+ ```
+                                                        .-------user2------.
+                           .-------SFU-------.    .-->--o      pc_id = 2   :
+ .------user1------.       :         .->-->--o-->-'     '------------------'
+ :     pc_id = 1   o-->-->-o--->-->--'       :
+ '-----------------'       :                 :
+                           '-----------------'
+ ```
+ 
+11\. Server requests User3 to create `recvonly` `Peer` passing Server's [SDP Offer]. 
 
+```json
+{
+  "method": "AddPeer",
+  "payload": {
+    "peer": {
+      "peer_id": 3,
+      "p2p": false,
+      "tracks": [
+        {
+          "id": 1,
+          "media_type": {
+            "Audio": {}
+          },
+          "direction": {
+            "Recv": {
+              "sender": 1
+            }
+          }
+        },
+        {
+          "id": 2,
+          "media_type": {
+            "Video": {}
+          },
+          "direction": {
+            "Recv": {
+              "sender": 1
+            }
+          }
+        }
+      ]
+    },
+    "sdp_offer": "server_user3_sendonly_offer",
+    "ice_servers": {
+      "urls": [
+        "turn:turnserver.com:3478",
+        "turn:turnserver.com:3478?transport=tcp"
+      ],
+      "username": "turn_user",
+      "credential": "turn_credential"
+    }
+  }
+}
 ```
 
+12\. User3 answers with [SDP Answer].
 
-## Drawbacks
-[drawbacks]: #drawbacks
+```json
+{
+  "method": "Answer",
+  "payload": {
+    "peer_id": 3,
+    "sdp_answer": "user_3_recvonly_answer"
+  }
+}
+```
 
-Why should we *not* do this?
+13\. Server and User3 exchange [ICE Candidate]'s.
 
+```json
+{
+  "method": "Candidate",
+  "payload": {
+    "peer_id": 3,
+    "candidate": "user1_ice_candidate"
+  }
+}
+```
 
+```json
+{
+  "method": "Candidate",
+  "payload": {
+    "peer_id": 3,
+    "candidate": "servers_ice_candidate"
+  }
+}
+```
+
+14\. User3 is connected to Server's peer connection.
 
+```
+                                                       .-------user2------.
+                          .-------SFU-------.    .-->--o      pc_id = 2   :
+.------user1------.       :       .---->----o-->-'     '------------------'
+:     pc_id = 1   o-->-->-o--->---'         :
+'-----------------'       :                 o-->-.     .-------user3------.
+                          '-----------------'    '-->--o      pc_id = 3   :
+                                                       '------------------'
+```
 
-## Rationale and alternatives
-[rationale-and-alternatives]: #rationale-and-alternatives
+15\. Server notifies User1 that he has new subscriber.
 
-- Why is this design the best in the space of possible designs?
-- What other designs have been considered and what is the rationale for not choosing them?
-- What is the impact of not doing this?
+```json
+{
+  "method": "UpdateTracks",
+  "payload": {
+    "peer_id": 1,
+    "tracks": [
+      {
+        "id": 1,
+        "media_type": {
+          "Audio": {}
+        },
+        "direction": {
+          "Send": {
+            "receivers": [ 2,3 ]
+          }
+        }
+      },
+      {
+        "id": 2,
+        "media_type": {
+          "Video": {}
+        },
+        "direction": {
+          "Send": {
+            "receivers": [ 2,3 ]
+          }
+        }
+      }
+    ]
+  }
+}
+```
+
+16\. Server sends User1 `Peer {peer_id = 1 }` media to User2 `Peer {peer_id = 3 }`.
+
+```
+                                                     .-------user2------.
+                          .-------SFU-------.    .->-o      pc_id = 2   :
+.------user1------.       :       .---->----o-->-'   '------------------'
+:     pc_id = 1   o-->-->-o--->---:         :
+'-----------------'       :       '---->----o-->-.   .-------user3------.
+                          '-----------------'    '->-o      pc_id = 3   :
+                                                     '------------------'
+```
 
+## Drawbacks and alternatives
+[drawbacks-and-alternatives]: #drawbacks-and-alternatives
 
+This RFC design tries to be a "silver bullet": cover all possible use-cases and combine them in single protocol. Such 
+versatility increases complexity. Simplifications can be achieved by imposing some general constraints:
+1. Divide current protocl protocol in two separate protocols: one for SFU and one for P2P.
+2. Reject future possibilities of using 1 `Peer` for all inbound/outbound tracks.
+3. Limit number of outbound streams in single `Peer` to 1.
+4. Remove publishers acknowledgement of every receiver on each track.
+5. Remove subscribers acknowledgement of every publisher that is not publishing at the moment.
 
 ## Unresolved questions and future possibilities
-[unresolved-questions]: #unresolved-questions
+[unresolved-questions-and-future-possibilities]: #unresolved-questions-and-future-possibilities
 
 ### Data channels
 
@@ -951,7 +1622,7 @@ exchange. It is an amazing feature with huge potential, but, at this point it is
 As the project develops, requirements will change, and we might consider adding data channels. Although, they are not 
 mentioned in this protocol, only minor tweaks will be required to support them.
 
-### Multiple recv tracks from different senders
+### Receiving tracks form multiple senders in single peer connection
 
 There are two general ways to manage Client's peer connections when using SFU server:
 1. Having only one pair of [RTCPeerConnection]'s (one at Client end and one at Server) and passing all send/recv tracks 

From ffe1c79ede64290b21cb2d3fcc50f380d112ae6c Mon Sep 17 00:00:00 2001
From: alexlapa <lapa.alex@ex.ua>
Date: Tue, 18 Dec 2018 13:01:35 -0600
Subject: [PATCH 04/24] some fixes

---
 docs/rfc/0002-webrc-client-api.md | 22 +++++++++++-----------
 1 file changed, 11 insertions(+), 11 deletions(-)

diff --git a/docs/rfc/0002-webrc-client-api.md b/docs/rfc/0002-webrc-client-api.md
index 025f4ce39..5bc8bf37e 100644
--- a/docs/rfc/0002-webrc-client-api.md
+++ b/docs/rfc/0002-webrc-client-api.md
@@ -64,12 +64,12 @@ So, how it works from `Medea Media Server` point of view:
 
 ### Transport considerations
 
-Although, signalling can be implemented on top of any transport, WebSocket is suited the most since it provides small 
-overhead reliable duplex connection. Widely used and supported.
+Although, signalling can be implemented on top of any transport, WebSocket suits the most since it provides small 
+overhead reliable duplex connection, widely used and supported.
 
 ### Protocol considerations
 
-Existing best practices are recommended:
+Existing best practices are recommended for final implementation:
 1. Message level ping-pongs.
 2. Reconnects.
 3. Transactions.
@@ -91,8 +91,8 @@ struct Payload<T> {
 }
 ```
 
-Each message requires answer, answer can carry payload(e.g. answering with [SDP Answer] to [SDP Offer]), error, or nothing, 
-which just means that message reached destination and was processed. 
+Each message requires answer. Answer can carry some payload(e.g. answering with [SDP Answer] to [SDP Offer]), Error, or 
+just noting nothing, which just means that message reached destination and was processed. 
  
 ### Signalling Protocol considerations
 
@@ -102,7 +102,7 @@ quite verbose `Control Api` design.
 
 Having in mind, that `Medea Media Server` already has user connection graph received from `Control Service` by the 
 moment user connects, it is possible to establish all required connections without bothering `User Application`. 
-Basically connection establishment should not depend on interaction with `User Application`.
+Basically connection establishment may not depend on interaction with `User Application` at all.
 
 On the other hand, some use cases require more manual control over media exchange process. For example:
 1. User wants to receive lower resolution video.
@@ -115,7 +115,7 @@ So API can be divided in two categories:
 `Medea Web Client` required.
 2. Dynamic: when `User Application` needs to express complex use cases.
 
-Current RFC offers combining both ways: everything will be configured automatically, but dynamic API is always there if 
+Current RFC offers combining both ways: everything will be configured automagically, but dynamic API is always there if 
 you need it.
 
 ## Reference-level explanation
@@ -227,7 +227,7 @@ Servers requests [RTCPeerConnection] creation.
 Params:
 1. `peer`: peer connection settings.
 2. `sdp_offer`: if `None`, client should create [SDP Offer] and pass it to the server. If `Some`, client should 
-`setRemoteDescription`, create [SDP Answer] and pass it to the server.
+set it as remote description, create [SDP Answer], set it as local description, and pass it to the server.
 3. `ice_servers`: just list of ice servers that should be passed to [RTCPeerConnection] constructor.
 
 Peer settings should be discussed in more detail.
@@ -314,7 +314,7 @@ Client is expected to:
 6. Answer `AddPeer` request with `Offer` request containing [SDP Offer].
 7. Expect remote [SDP Answer] to set it as remote description.
 
-After negotiation is done and media starts flowing, client will receive notification that his media is being sent to 
+After negotiation is done and media starts flowing, client might receive notification that his media is being sent to 
 `Peer { peer_id = 2 }`, and he is receiving media from `Peer { peer_id = 2 }`.
 
 2\. Create Audio `send` to SFU `Peer`.
@@ -359,7 +359,7 @@ Client is expected to:
 6. Set created [SDP Answer] as local description.
 7. Answer `AddPeer` request with `Answer` request containing [SDP Offer]. 
 
-After negotiation is done and media starts flowing, client will receive notification that his media is being sent to 
+After negotiation is done and media starts flowing, client might receive notification that his media is being sent to 
 server.
 
 
@@ -1605,7 +1605,7 @@ It is recommended to cache `Peer` id - `Member` id relation in Web Client. Proba
 
 This RFC design tries to be a "silver bullet": cover all possible use-cases and combine them in single protocol. Such 
 versatility increases complexity. Simplifications can be achieved by imposing some general constraints:
-1. Divide current protocl protocol in two separate protocols: one for SFU and one for P2P.
+1. Divide current protocol in two separate protocols: one for SFU and one for P2P.
 2. Reject future possibilities of using 1 `Peer` for all inbound/outbound tracks.
 3. Limit number of outbound streams in single `Peer` to 1.
 4. Remove publishers acknowledgement of every receiver on each track.

From e602faff1f325f303be29141617e3b0c76e219b5 Mon Sep 17 00:00:00 2001
From: alexlapa <lapa.alex@ex.ua>
Date: Fri, 21 Dec 2018 10:54:14 -0600
Subject: [PATCH 05/24] wrap examples in details

---
 docs/rfc/0002-webrc-client-api.md | 88 +++++++++++++++++++++++++------
 1 file changed, 71 insertions(+), 17 deletions(-)

diff --git a/docs/rfc/0002-webrc-client-api.md b/docs/rfc/0002-webrc-client-api.md
index 5bc8bf37e..714b23df4 100644
--- a/docs/rfc/0002-webrc-client-api.md
+++ b/docs/rfc/0002-webrc-client-api.md
@@ -239,7 +239,8 @@ achieve this on client side and concrete implementation is not part of this RFC.
 
 #### Examples
 
-1\. Create Audio+Video `sendrecv` p2p `Peer`.
+<details>
+<summary>Create Audio+Video `sendrecv` p2p `Peer`</summary>
 
 ```json
 {
@@ -317,7 +318,10 @@ Client is expected to:
 After negotiation is done and media starts flowing, client might receive notification that his media is being sent to 
 `Peer { peer_id = 2 }`, and he is receiving media from `Peer { peer_id = 2 }`.
 
-2\. Create Audio `send` to SFU `Peer`.
+</details>
+
+<details>
+<summary>Create Audio `send` to SFU `Peer`</summary>
 
 ```json
 {
@@ -362,6 +366,7 @@ Client is expected to:
 After negotiation is done and media starts flowing, client might receive notification that his media is being sent to 
 server.
 
+</details>
 
 #### 2. RemovePeers
 
@@ -382,7 +387,8 @@ to do any request related stuff that Server needs to do, and distinguish between
 
 #### Examples
 
-1. Server tells client to dispose specified `Peers` / Client requests Server's permission to dispose specified `Peers`.
+<details>
+<summary>Server tells client to dispose specified `Peers` / Client requests Server's permission to dispose specified `Peers`</summary>
 
 ```json
 {
@@ -390,6 +396,8 @@ to do any request related stuff that Server needs to do, and distinguish between
 }
 ```
 
+</details>
+
 #### 3. UpdateTracks
 
 ```rust
@@ -412,7 +420,8 @@ If Client => Server, then it can be used to express Clients intentions to:
 
 #### Examples 
 
-Assuming such `Peer` exists on Clients end:
+<details>
+<summary>Assuming such `Peer` exists on Client's end</summary>
 
 ```json
 {
@@ -447,7 +456,10 @@ Assuming such `Peer` exists on Clients end:
 
 Meaning that media is being published to server but has no actual receivers.
 
-1\. Server notifies Client that video is being received by other `Peer {peer_id = 2}`.
+</details>
+
+<details>
+<summary>Server notifies Client that video is being received by other `Peer {peer_id = 2}`</summary>
 
 Server => Client
 
@@ -481,7 +493,10 @@ Server => Client
 }
 ```
 
-2\. Client wants to unsubscribe `Peer {peer_id = 2}` from specified tracks.
+</details>
+
+<details>
+<summary>Client wants to unsubscribe `Peer {peer_id = 2}` from specified track</summary>
 
 Client => Server
 
@@ -515,6 +530,7 @@ Client => Server
 }
 ```
 
+</details>
 
 #### 4. RemoveTracks
 
@@ -532,7 +548,8 @@ If Client => Server, then Client requests Server's permission to dispose specifi
 
 #### Examples
 
-1. Server tells client to dispose specified `Tracks` / Client requests Server's permission to dispose specified `Tracks`.
+<details>
+<summary>Server tells client to dispose specified `Tracks` / Client requests Server's permission to dispose specified `Tracks`</summary>
 
 ```json
 {
@@ -541,6 +558,8 @@ If Client => Server, then Client requests Server's permission to dispose specifi
 }
 ```
 
+</details>
+
 #### 5. Offer
 
 ```rust
@@ -562,7 +581,8 @@ Server can send it:
 
 #### Examples
 
-1. Client sends `Peers` [SDP Offer]
+<details>
+<summary>Client sends `Peers` [SDP Offer]</summary>
 
 ```json
 {
@@ -571,6 +591,8 @@ Server can send it:
 }
 ```
 
+</details>
+
 #### 6. Answer
 
 ```rust
@@ -590,7 +612,8 @@ Server can send it only as answer to `Offer`.
 
 #### Examples
 
-1. Client sends `Peers` [SDP Answer]
+<details>
+<summary>Client sends `Peers` [SDP Answer]</summary>
 
 ```json
 {
@@ -599,6 +622,9 @@ Server can send it only as answer to `Offer`.
 }
 ```
 
+</details>
+
+
 #### 7. Candidate
 
 ```rust
@@ -656,7 +682,8 @@ Params:
 
 #### Examples:
 
-1. Notify Client that it is possible subscribe to `Member {id = 2}` Video and Audio tracks.
+<details>
+<summary>Notify Client that it is possible to subscribe to `Member {id = 2}` Video and Audio tracks</summary>
 
 ```json
 {
@@ -676,7 +703,10 @@ Params:
 }
 ```
 
-2. Notify Client that it is possible to publish Audio to specified `Peers`.
+</details>
+
+<details>
+<summary>Notify Client that it is possible to publish Audio to specified `Peers`</summary>
 
 ```json
 {
@@ -713,6 +743,9 @@ connection (only SFU).
 3. ```can_rx```: if `Some` then Client can subscribe to specified media.
 4. ```can_tx```: if `Some` then Client can publish specified media to remote `Peer`.
 
+</details>
+
+
 #### 8. RequestTracks
 
 ```rust
@@ -753,7 +786,8 @@ represents Server's peer connection (only SFU).
 
 #### Examples
 
-1\. Client requests to subscribe to remote `Peer {peer_id = 2}` audio and video.
+<details>
+<summary>Client requests to subscribe to remote `Peer {peer_id = 2}` audio and video</summary>
 
 ```json
 {
@@ -769,7 +803,10 @@ represents Server's peer connection (only SFU).
 }
 ```
 
-2\. Client requests to publish to Server's peer connection.
+</details>
+
+<details>
+<summary>Client requests to publish to Server's peer connection</summary>
 
 ```json
 {
@@ -785,6 +822,8 @@ represents Server's peer connection (only SFU).
 }
 ```
 
+</details>
+
 #### 9. GetMembers, Members
 
 ```rust
@@ -807,7 +846,9 @@ It is recommended to cache `Peer` id - `Member` id relation in Web Client. Proba
 
 #### Examples
 
-1\. Client request `Member`'s that own specified `Peer`'s.
+<details>
+<summary>Client request `Member`'s that own specified `Peer`'s</summary>
+
 ```json
 {
   "peer_ids": [
@@ -816,7 +857,11 @@ It is recommended to cache `Peer` id - `Member` id relation in Web Client. Proba
 }
 ```
 
-2\. Server provides `Member`'s that own specified `Peers`'s.
+</details>
+
+<details>
+<summary>Server provides `Member`'s that own specified `Peers`'s</summary>
+
 ```json
 {
   "members": [
@@ -836,9 +881,12 @@ It is recommended to cache `Peer` id - `Member` id relation in Web Client. Proba
 }
 ```
 
+</details>
+
 ### Extended examples
 
-#### 1. 1 <=> 1 p2p with unpublish and republish.   
+<details>
+<summary>1 <=> 1 p2p with unpublish and republish. </summary>
 
 ```
 .----user1----.    .->-->-->--. .----user2----.
@@ -1219,7 +1267,11 @@ It is recommended to cache `Peer` id - `Member` id relation in Web Client. Proba
 '-------------'    '-<--<--<--' '-------------'
 ```
 
-#### 2. 1 => 2 SFU.
+</details>
+
+
+<details>
+<summary>1 => 2 SFU</summary>
 
 ```
                                                        .-------user2------.
@@ -1600,6 +1652,8 @@ It is recommended to cache `Peer` id - `Member` id relation in Web Client. Proba
                                                      '------------------'
 ```
 
+</details>
+
 ## Drawbacks and alternatives
 [drawbacks-and-alternatives]: #drawbacks-and-alternatives
 

From 53696b00a9b68cdf4f558532de573a1e47e57a5e Mon Sep 17 00:00:00 2001
From: alexlapa <lapa.alex@ex.ua>
Date: Fri, 21 Dec 2018 10:58:38 -0600
Subject: [PATCH 06/24] fix formatting

---
 docs/rfc/0002-webrc-client-api.md | 30 +++++++++++++++---------------
 1 file changed, 15 insertions(+), 15 deletions(-)

diff --git a/docs/rfc/0002-webrc-client-api.md b/docs/rfc/0002-webrc-client-api.md
index 714b23df4..61e914b8e 100644
--- a/docs/rfc/0002-webrc-client-api.md
+++ b/docs/rfc/0002-webrc-client-api.md
@@ -240,7 +240,7 @@ achieve this on client side and concrete implementation is not part of this RFC.
 #### Examples
 
 <details>
-<summary>Create Audio+Video `sendrecv` p2p `Peer`</summary>
+<summary>Create Audio+Video sendrecv p2p Peer</summary>
 
 ```json
 {
@@ -321,7 +321,7 @@ After negotiation is done and media starts flowing, client might receive notific
 </details>
 
 <details>
-<summary>Create Audio `send` to SFU `Peer`</summary>
+<summary>Create Audio send to SFU Peer</summary>
 
 ```json
 {
@@ -388,7 +388,7 @@ to do any request related stuff that Server needs to do, and distinguish between
 #### Examples
 
 <details>
-<summary>Server tells client to dispose specified `Peers` / Client requests Server's permission to dispose specified `Peers`</summary>
+<summary>Server tells client to dispose specified Peers / Client requests Server's permission to dispose specified Peers</summary>
 
 ```json
 {
@@ -421,7 +421,7 @@ If Client => Server, then it can be used to express Clients intentions to:
 #### Examples 
 
 <details>
-<summary>Assuming such `Peer` exists on Client's end</summary>
+<summary>Assuming such Peer exists on Client's end</summary>
 
 ```json
 {
@@ -459,7 +459,7 @@ Meaning that media is being published to server but has no actual receivers.
 </details>
 
 <details>
-<summary>Server notifies Client that video is being received by other `Peer {peer_id = 2}`</summary>
+<summary>Server notifies Client that video is being received by other Peer {peer_id = 2}</summary>
 
 Server => Client
 
@@ -496,7 +496,7 @@ Server => Client
 </details>
 
 <details>
-<summary>Client wants to unsubscribe `Peer {peer_id = 2}` from specified track</summary>
+<summary>Client wants to unsubscribe Peer {peer_id = 2} from specified track</summary>
 
 Client => Server
 
@@ -549,7 +549,7 @@ If Client => Server, then Client requests Server's permission to dispose specifi
 #### Examples
 
 <details>
-<summary>Server tells client to dispose specified `Tracks` / Client requests Server's permission to dispose specified `Tracks`</summary>
+<summary>Server tells client to dispose specified Tracks / Client requests Server's permission to dispose specified Tracks</summary>
 
 ```json
 {
@@ -582,7 +582,7 @@ Server can send it:
 #### Examples
 
 <details>
-<summary>Client sends `Peers` [SDP Offer]</summary>
+<summary>Client sends Peers SDP Offer</summary>
 
 ```json
 {
@@ -613,7 +613,7 @@ Server can send it only as answer to `Offer`.
 #### Examples
 
 <details>
-<summary>Client sends `Peers` [SDP Answer]</summary>
+<summary>Client sends Peers SDP Answer</summary>
 
 ```json
 {
@@ -683,7 +683,7 @@ Params:
 #### Examples:
 
 <details>
-<summary>Notify Client that it is possible to subscribe to `Member {id = 2}` Video and Audio tracks</summary>
+<summary>Notify Client that it is possible to subscribe to Member {id = 2} Video and Audio tracks</summary>
 
 ```json
 {
@@ -706,7 +706,7 @@ Params:
 </details>
 
 <details>
-<summary>Notify Client that it is possible to publish Audio to specified `Peers`</summary>
+<summary>Notify Client that it is possible to publish Audio to specified Peers</summary>
 
 ```json
 {
@@ -787,7 +787,7 @@ represents Server's peer connection (only SFU).
 #### Examples
 
 <details>
-<summary>Client requests to subscribe to remote `Peer {peer_id = 2}` audio and video</summary>
+<summary>Client requests to subscribe to remote Peer {peer_id = 2} audio and video</summary>
 
 ```json
 {
@@ -847,7 +847,7 @@ It is recommended to cache `Peer` id - `Member` id relation in Web Client. Proba
 #### Examples
 
 <details>
-<summary>Client request `Member`'s that own specified `Peer`'s</summary>
+<summary>Client request Member's that own specified Peer's</summary>
 
 ```json
 {
@@ -860,7 +860,7 @@ It is recommended to cache `Peer` id - `Member` id relation in Web Client. Proba
 </details>
 
 <details>
-<summary>Server provides `Member`'s that own specified `Peers`'s</summary>
+<summary>Server provides Member's that own specified Peers's</summary>
 
 ```json
 {
@@ -886,7 +886,7 @@ It is recommended to cache `Peer` id - `Member` id relation in Web Client. Proba
 ### Extended examples
 
 <details>
-<summary>1 <=> 1 p2p with unpublish and republish. </summary>
+<summary>1 <=> 1 p2p with unpublish and republish</summary>
 
 ```
 .----user1----.    .->-->-->--. .----user2----.

From 17bde85ae337052cba8cb410e5bde452df1fb6a5 Mon Sep 17 00:00:00 2001
From: tyranron <tyranron@gmail.com>
Date: Mon, 24 Dec 2018 15:16:59 +0200
Subject: [PATCH 07/24] Style corrections

---
 docs/rfc/0001-control-api.md      |    2 +-
 docs/rfc/0002-webrc-client-api.md | 1025 +++++++++++++----------------
 2 files changed, 466 insertions(+), 561 deletions(-)

diff --git a/docs/rfc/0001-control-api.md b/docs/rfc/0001-control-api.md
index da9a8fe8d..f1c98433a 100644
--- a/docs/rfc/0001-control-api.md
+++ b/docs/rfc/0001-control-api.md
@@ -1,6 +1,6 @@
 - Feature Name: `control_api`
 - Start Date: 2018-11-21
-- RFC PR: [instrumentisto/medea#6](https://github.com/instrumentisto/medea/issues/6)
+- RFC PR: [instrumentisto/medea#5](https://github.com/instrumentisto/medea/pull/5)
 - Tracking Issue: [instrumentisto/medea#4](https://github.com/instrumentisto/medea/issues/4)
 
 
diff --git a/docs/rfc/0002-webrc-client-api.md b/docs/rfc/0002-webrc-client-api.md
index 61e914b8e..75a33e8ff 100644
--- a/docs/rfc/0002-webrc-client-api.md
+++ b/docs/rfc/0002-webrc-client-api.md
@@ -1,7 +1,7 @@
-- Feature Name: `client_webrtc_signalling_api`
+- Feature Name: `client_webrtc_api`
 - Start Date: 2018-12-13
-- RFC PR: (leave this empty)
-- Tracking Issue: (leave this empty)
+- RFC PR: [instrumentisto/medea#7](https://github.com/instrumentisto/medea/pull/7)
+- Tracking Issue: [instrumentisto/medea#4](https://github.com/instrumentisto/medea/issues/6)
 
 
 
@@ -9,38 +9,39 @@
 ## Summary
 [summary]: #summary
 
-Formalize communication protocol between client(browser, mobile apps) and media server regarding [WebRTC] connection 
-management.
+Formalize communication protocol between client (browser, mobile apps) and media server regarding [WebRTC] connection management.
+
+
+
 
 ## Motivation
 [motivation]: #motivation
 
-[WebRTC] allows P2P data exchange, but [WebRTC] as a protocol comes without signaling. At a minimum signalling protocol 
-must provide ways to exchange Session Description data([SDP Offer] / [SDP Answer]) and [ICE Candidate]. But if you think about 
-signalling protocol in terms of interaction with media server things are becoming more complicated.
+[WebRTC] allows P2P data exchange, but [WebRTC] as a protocol comes without signaling. At the minimum signalling protocol must provide ways to exchange Session Description data ([SDP Offer] / [SDP Answer]) and [ICE Candidate]. But if you think about signalling protocol in terms of interaction with media server things become more complicated.
 
 You will need to express ways to:
 1. Provide STUN/TURN servers.
-2. Exchange some low-level media metadata(resolution, codecs, media types).
-3. Allow more sophisticated track management(updating video resolution on preview/fullscreen switches, passing multiple 
-video tracks with different settings).
-4. Pass some user metadata to hook business logic on.
+2. Exchange some low-level media metadata (resolution, codecs, media types).
+3. Allow more sophisticated track management (updating video resolution on preview/fullscreen switches, passing multiple video tracks with different settings).
+4. Pass some user metadata to hook business logic onto.
 5. Build more complex connection graphs.
 6. Dynamically cancel/begin media publishing/receiving.
-7. Passing errors, connection stats messages.
+7. Passing errors, connection statistics.
 8. Cover both P2P mesh and SFU scenarios.
 
 The protocol must be versatile enough to cover all possible use cases.
 
+
+
+
 ## Guide-level explanation
 [guide-level-explanation]: #guide-level-explanation
 
-### What is `WebRTC Client API`? 
 
-It is a part of `Client API` responsible for [WebRTC] connection management. You can find `Client API` on approximate 
-architecture design. 
+### What is `Client WebRTC API`? 
 
-```                                                   
+It is a part of `Client API` responsible for [WebRTC] connection management. You can find `Client API` on the following approximate architecture design:
+```
                                                                        .------------Server-----------.
                                                                        :     .-------------------.   :
                           .--------------------------------------------+-----o  Control Service  :   :
@@ -49,23 +50,23 @@ architecture design.
                           :                                            :        Control Api          :
 .--------Client-----------+------------------------.                   :              |              :
 :  .--------------------. :  .--------------------. :  .-Client-API--. :  .-----------o------------. :
-:  :  User Application  o-'  :  Medea Web Client  o-+--'             '-+--o   Medea Media Server   : :
+:  :  User Application  o-'  :     Web Client     o-+--'             '-+--o      Media Server      : :
 :  :                    :----:                    o-+--.             .-+--o                        : :
 :  '--------------------'    '--------------------' :  '----Media----' :  '------------------------' :
 '---------------------------------------------------'                  '-----------------------------'
-                           
 ```
 
-So, how it works from `Medea Media Server` point of view:
+So, how it works from `Media Server` point of view:
 1. `Control Service` configures media room via `Control API`.  
-2. `Medea Media Server` provides all necessary information (urls+credentials) for all room members.
-3. `User Application` passes credentials and other necessary stuff (like `<video>` elements) to `Medea Web Client`.
-4. And voila!
+2. `Media Server` provides all necessary information (URLs + credentials) for all room members.
+3. `User Application` passes credentials and other necessary stuff (like `<video>` elements) to `Web Client`.
+4. And voilà!
+
 
 ### Transport considerations
 
-Although, signalling can be implemented on top of any transport, WebSocket suits the most since it provides small 
-overhead reliable duplex connection, widely used and supported.
+Although, signalling can be implemented on top of any transport, WebSocket suits the most since it provides small overhead reliable duplex connection, is widely adopted and supported.
+
 
 ### Protocol considerations
 
@@ -91,36 +92,35 @@ struct Payload<T> {
 }
 ```
 
-Each message requires answer. Answer can carry some payload(e.g. answering with [SDP Answer] to [SDP Offer]), Error, or 
-just noting nothing, which just means that message reached destination and was processed. 
- 
+Each message requires answer. Answer can carry some payload(e.g. answering with [SDP Answer] to [SDP Offer]), Error, or just noting, which just means that message reached destination and was processed. 
+
+
 ### Signalling Protocol considerations
+[signalling-protocol-considerations]: #signalling-protocol-considerations
 
-One of the main goals, is to make `Medea Web Client` integration as easy as possible. This means less interaction 
-between `User Application` and `Medea Web Client` and more interaction between `Medea Web Client` and `Medea Media Server`, 
-quite verbose `Control Api` design.
+One of the main goals, is to make `Web Client` integration as easy as possible. This means less interaction between `User Application` and `Web Client`, and more interaction between `Web Client` and `Media Server`, quite verbose `Control Api` design.
 
-Having in mind, that `Medea Media Server` already has user connection graph received from `Control Service` by the 
-moment user connects, it is possible to establish all required connections without bothering `User Application`. 
-Basically connection establishment may not depend on interaction with `User Application` at all.
+Having in mind, that `Media Server` already has user connection graph received from `Control Service` by the moment user connects, it is possible to establish all required connections without bothering `User Application`. Basically, connection establishment may not depend on interaction with `User Application` at all.
 
 On the other hand, some use cases require more manual control over media exchange process. For example:
 1. User wants to receive lower resolution video.
 2. User wants to stop sending media to specific user.
 3. And then start sending media again.
-4. Mute/unmute.
+4. Mute or unmute.
 
 So API can be divided in two categories:
-1. Preconfigured: where everything works from the box and almost no interaction between `User Application` and 
-`Medea Web Client` required.
+1. Preconfigured: where everything works out-of-the-box and almost no interaction between `User Application` and `Web Client` required.
 2. Dynamic: when `User Application` needs to express complex use cases.
 
-Current RFC offers combining both ways: everything will be configured automagically, but dynamic API is always there if 
-you need it.
+Current RFC offers combining both ways: everything will be configured automagically, but dynamic API is always there if you need it.
+
+
+
 
 ## Reference-level explanation
 [reference-level-explanation]: #reference-level-explanation
 
+
 ### Data model
 
 ```
@@ -150,7 +150,7 @@ you need it.
 
 #### Member
 
-Just a way to group `Peers` and provide `User Application` with some users meta data. `Member` can have 0-N `Peers`.
+Just a way to group `Peers` and provide `User Application` with some user metadata. `Member` can have 0-N `Peers`.
 
 ```rust
 struct Member {
@@ -198,8 +198,9 @@ struct VideoSettings {}
 ```
 
 `P2P` flag implies some logic on `TrackDirection::Send` tracks:
-1. `P2P` send tracks always have only one receiver.
-2. Non `P2P` send tracks can have 0-N receivers. 0 - if media is transmitted to server, but have no actual user receiving it.
+1. `P2P` `Send` tracks always have only one receiver.
+2. Non-`P2P` `Send` tracks can have 0-N receivers. 0 - if media is transmitted to server, but have no actual user receiving it.
+
 
 ### Methods
 
@@ -209,7 +210,7 @@ struct VideoSettings {}
 struct AddPeer {
     peer: Peer,
     sdp_offer: Option<String>,
-    ice_servers: ICEServers
+    ice_servers: ICEServers,
 }
 ```
 
@@ -226,18 +227,12 @@ Servers requests [RTCPeerConnection] creation.
 
 Params:
 1. `peer`: peer connection settings.
-2. `sdp_offer`: if `None`, client should create [SDP Offer] and pass it to the server. If `Some`, client should 
-set it as remote description, create [SDP Answer], set it as local description, and pass it to the server.
+2. `sdp_offer`: if `None`, client should create [SDP Offer] and pass it to the server. If `Some`, client should set it as remote description, then create [SDP Answer], set it as local description, and pass it to the server.
 3. `ice_servers`: just list of ice servers that should be passed to [RTCPeerConnection] constructor.
 
-Peer settings should be discussed in more detail.
+The most important part of `Peer` object is list of tracks. All `TrackDirection::Send` tracks must be created according to their settings and added to the `Peer`. If there is at least one `TrackDirection::Recv` track, then created [RTCPeerConnection] must be ready to receive tracks (`recvonly`/`sendrecv` SDP). Currently, there are multiple ways to achieve this on client side and concrete implementation is not part of this RFC. 
 
-The most important part of `Peer` object is list of tracks. All `TrackDirection::Send` tracks must be created according 
-to their settings and added to peer. If there is at least one `TrackDirection::Recv` track, then created 
-[RTCPeerConnection] must be ready to receive tracks(`recvonly`/`sendrecv` SDP). Currently there are multiple ways to 
-achieve this on client side and concrete implementation is not part of this RFC. 
-
-#### Examples
+##### Examples
 
 <details>
 <summary>Create Audio+Video sendrecv p2p Peer</summary>
@@ -247,53 +242,48 @@ achieve this on client side and concrete implementation is not part of this RFC.
   "peer": {
     "peer_id": 1,
     "p2p": true,
-    "tracks": [
-      {
-        "id": 1,
-        "media_type": {
-          "Audio": {}
-        },
-        "direction": {
-          "Send": {
-            "receivers": [ 2 ]
-          }
-        }
+    "tracks": [{
+      "id": 1,
+      "media_type": {
+        "Audio": {}
       },
-      {
-        "id": 2,
-        "media_type": {
-          "Video": {}
-        },
-        "direction": {
-          "Send": {
-            "receivers": [ 2 ]
-          }
+      "direction": {
+        "Send": {
+          "receivers": [2]
         }
+      }
+    }, {
+      "id": 2,
+      "media_type": {
+        "Video": {}
       },
-      {
-        "id": 3,
-        "media_type": {
-          "Audio": {}
-        },
-        "direction": {
-          "Recv": {
-            "sender": 2
-          }
+      "direction": {
+        "Send": {
+          "receivers": [2]
         }
+      }
+    }, {
+      "id": 3,
+      "media_type": {
+        "Audio": {}
       },
-      {
-        "id": 4,
+      "direction": {
+        "Recv": {
+          "sender": 2
+        }
+      }
+    }, {
+      "id": 4,
         "media_type": {
-          "Video": {}
-        },
-        "direction": {
-          "Recv": {
-            "sender": 2
-          }
+        "Video": {}
+      },
+      "direction": {
+        "Recv": {
+          "sender": 2
         }
       }
-    ]
-  },
+    }
+  ]},
   "sdp_offer": null,
   "ice_servers": {
     "urls": [
@@ -307,7 +297,7 @@ achieve this on client side and concrete implementation is not part of this RFC.
 ```
 
 Client is expected to:
-1. Create [RTCPeerConnection] with provided ice servers and associate it with given `peer_id`.
+1. Create [RTCPeerConnection] with provided ICE servers and associate it with given `peer_id`.
 2. Initialize Audio and Video tracks without any additional settings.
 3. Add newly created tracks to [RTCPeerConnection].
 4. Create `sendrecv` [SDP Offer].
@@ -315,9 +305,7 @@ Client is expected to:
 6. Answer `AddPeer` request with `Offer` request containing [SDP Offer].
 7. Expect remote [SDP Answer] to set it as remote description.
 
-After negotiation is done and media starts flowing, client might receive notification that his media is being sent to 
-`Peer { peer_id = 2 }`, and he is receiving media from `Peer { peer_id = 2 }`.
-
+After negotiation is done and media starts flowing, the client might receive notification that his media is being sent to `Peer { peer_id = 2 }`, and he is receiving media from `Peer { peer_id = 2 }`.
 </details>
 
 <details>
@@ -328,19 +316,17 @@ After negotiation is done and media starts flowing, client might receive notific
   "peer": {
     "peer_id": 1,
     "p2p": false,
-    "tracks": [
-      {
-        "id": 1,
-        "media_type": {
-          "Audio": {}
-        },
-        "direction": {
-          "Send": {
-            "receivers": []
-          }
+    "tracks": [{
+      "id": 1,
+      "media_type": {
+        "Audio": {}
+      },
+      "direction": {
+        "Send": {
+          "receivers": []
         }
       }
-    ]
+    }]
   },
   "sdp_offer": "server_user1_recvonly_offer",
   "ice_servers": {
@@ -355,7 +341,7 @@ After negotiation is done and media starts flowing, client might receive notific
 ```
 
 Client is expected to:
-1. Create [RTCPeerConnection] with provided ice servers and associate it with given `peer_id`.
+1. Create [RTCPeerConnection] with provided ICE servers and associate it with given `peer_id`.
 2. Initialize Audio track without any additional settings.
 3. Add newly created track to [RTCPeerConnection].
 4. Set provided offer as peers remote description.
@@ -363,9 +349,7 @@ Client is expected to:
 6. Set created [SDP Answer] as local description.
 7. Answer `AddPeer` request with `Answer` request containing [SDP Offer]. 
 
-After negotiation is done and media starts flowing, client might receive notification that his media is being sent to 
-server.
-
+After negotiation is done and media starts flowing, client might receive notification that his media is being sent to server.
 </details>
 
 #### 2. RemovePeers
@@ -376,26 +360,24 @@ struct RemovePeers {
 }
 ```
 
-Server's/Client's request to dispose(close) specified `Peers`.
+Server's/Client's request to dispose (close) specified `Peers`.
 
 If Server => Client, then Client must dispose specified `Peers`.
-If Client => Server, then Client requests Server's permission to dispose specified `Peers`. Server may give permission 
-in answer.
 
-Probably, Server will always give his permission on any Client's request. This kind of request flow will allow Server 
-to do any request related stuff that Server needs to do, and distinguish between abnormal and normal events.
+If Client => Server, then Client requests Server's permission to dispose specified `Peers`. Server may give permission in answer.
 
-#### Examples
+Probably, Server will always give his permission on any Client's request. This kind of request flow will allow Server to do any request related stuff that Server needs to do, and distinguish between abnormal and normal events.
+
+##### Examples
 
 <details>
 <summary>Server tells client to dispose specified Peers / Client requests Server's permission to dispose specified Peers</summary>
 
 ```json
 {
-  "peer_ids": [ 1, 2, 3 ]
+  "peer_ids": [1, 2, 3]
 }
 ```
-
 </details>
 
 #### 3. UpdateTracks
@@ -418,7 +400,7 @@ If Client => Server, then it can be used to express Clients intentions to:
 1. Update existing track settings.
 2. Cancel sending media to specific receiver (only remove).
 
-#### Examples 
+##### Examples 
 
 <details>
 <summary>Assuming such Peer exists on Client's end</summary>
@@ -427,35 +409,31 @@ If Client => Server, then it can be used to express Clients intentions to:
 {
   "peer_id": 1,
   "p2p": false,
-  "tracks": [
-    {
-      "id": 1,
-      "media_type": {
-        "Audio": {}
-      },
-      "direction": {
-        "Send": {
-          "receivers": []
-        }
+  "tracks": [{
+    "id": 1,
+    "media_type": {
+      "Audio": {}
+    },
+    "direction": {
+      "Send": {
+        "receivers": []
       }
+    }
+  }, {
+    "id": 2,
+    "media_type": {
+      "Video": {}
     },
-    {
-      "id": 2,
-      "media_type": {
-        "Video": {}
-      },
-      "direction": {
-        "Send": {
-          "receivers": []
-        }
+    "direction": {
+      "Send": {
+        "receivers": []
       }
     }
-  ]
+  }]
 }
 ```
 
 Meaning that media is being published to server but has no actual receivers.
-
 </details>
 
 <details>
@@ -466,33 +444,29 @@ Server => Client
 ```json
 {
   "peer_id": 1,
-  "tracks": [
-    {
-      "id": 1,
-      "media_type": {
-        "Audio": {}
-      },
-      "direction": {
-        "Send": {
-          "receivers": [ 2 ]
-        }
+  "tracks": [{
+    "id": 1,
+    "media_type": {
+      "Audio": {}
+    },
+    "direction": {
+      "Send": {
+        "receivers": [2]
       }
+    }
+  }, {
+    "id": 2,
+    "media_type": {
+      "Video": {}
     },
-    {
-      "id": 2,
-      "media_type": {
-        "Video": {}
-      },
-      "direction": {
-        "Send": {
-          "receivers": [ 2 ]
-        }
+    "direction": {
+      "Send": {
+        "receivers": [2]
       }
     }
-  ]
+  }]
 }
 ```
-
 </details>
 
 <details>
@@ -503,33 +477,29 @@ Client => Server
 ```json
 {
   "peer_id": 1,
-  "tracks": [
-    {
-      "id": 1,
-      "media_type": {
-        "Audio": {}
-      },
-      "direction": {
-        "Send": {
-          "receivers": []
-        }
+  "tracks": [{
+    "id": 1,
+    "media_type": {
+      "Audio": {}
+    },
+    "direction": {
+      "Send": {
+        "receivers": []
       }
+    }
+  }, {
+    "id": 2,
+    "media_type": {
+      "Video": {}
     },
-    {
-      "id": 2,
-      "media_type": {
-        "Video": {}
-      },
-      "direction": {
-        "Send": {
-          "receivers": []
-        }
+    "direction": {
+      "Send": {
+        "receivers": []
       }
     }
-  ]
+  }]
 }
 ```
-
 </details>
 
 #### 4. RemoveTracks
@@ -541,12 +511,13 @@ struct RemoveTracks {
 }
 ```
 
-Server's/Client's request to dispose specified `Tracks`.
+Server's/Client's request to dispose (close) specified `Tracks`.
+
+If Server => Client, then Client must dispose (stop and remove).
 
-If Server => Client, then Client must dispose(stop and remove).
 If Client => Server, then Client requests Server's permission to dispose specified `Peers`.
 
-#### Examples
+##### Examples
 
 <details>
 <summary>Server tells client to dispose specified Tracks / Client requests Server's permission to dispose specified Tracks</summary>
@@ -557,7 +528,6 @@ If Client => Server, then Client requests Server's permission to dispose specifi
   "tracks": [1, 2]
 }
 ```
-
 </details>
 
 #### 5. Offer
@@ -579,7 +549,7 @@ Server can send it:
 1. If server triggers renegotiation.
 2. Retransmission from peer that triggered renegotiation.
 
-#### Examples
+##### Examples
 
 <details>
 <summary>Client sends Peers SDP Offer</summary>
@@ -590,7 +560,6 @@ Server can send it:
   "sdp_offer": "sdp_offer_body"
 }
 ```
-
 </details>
 
 #### 6. Answer
@@ -602,7 +571,7 @@ struct Answer {
 }
 ```
 
-Server's / Client's [SDP Answer]  sent during SDP negotiation between peers.
+Server's / Client's [SDP Answer] sent during SDP negotiation between peers.
 
 Client can send it:
 1. As answer to `AddPeer {sdp_offer: Some}`.
@@ -621,7 +590,6 @@ Server can send it only as answer to `Offer`.
   "sdp_offer": "sdp_answer_body"
 }
 ```
-
 </details>
 
 
@@ -670,9 +638,7 @@ enum RemotePeerTrackType {
 }
 ```
 
-Server notifies Client of any remote peers that Client can connect to. This is a key method when talking about Dynamic 
-API mentioned in `Signalling Protocol considerations`. Any Client's request to subscriber/publish will be based on data
-provided by this request.
+Server notifies Client of any remote peers that Client can connect to. This is a key method when talking about Dynamic API mentioned in [Signalling Protocol considerations][signalling-protocol-considerations]. Any Client's request to subscribe/publish will be based on data provided by this request.
 
 Params:
 1. ```remote_peer_id```: if `Some`, then represents specific remote `Peer` associated with some `Member`. If `None`, then represents Servers peer connection.
@@ -687,22 +653,19 @@ Params:
 
 ```json
 {
-  "peers": [
-    {
-      "peer_id": 2,
-      "member_id": "User2",
-      "can_rx": {
-        "AudioVideo": {
-          "audio_settings": {},
-          "video_settings": {}
-        }
-      },
-      "can_tx": null
-    }
-  ]
+  "peers": [{
+    "peer_id": 2,
+    "member_id": "User2",
+    "can_rx": {
+      "AudioVideo": {
+        "audio_settings": {},
+        "video_settings": {}
+      }
+    },
+    "can_tx": null
+  }]
 }
 ```
-
 </details>
 
 <details>
@@ -710,42 +673,29 @@ Params:
 
 ```json
 {
-  "peers": [
-    {
-      "peer_id": 2,
-      "member_id": "User2",
-      "can_rx": null,
-      "can_tx": {
-        "Audio": {
-          "audio_settings": {}
-        }
+  "peers": [{
+    "peer_id": 2,
+    "member_id": "User2",
+    "can_rx": null,
+    "can_tx": {
+      "Audio": {
+        "audio_settings": {}
       }
-    },
-    {
-      "peer_id": 3,
-      "member_id": "User3",
-      "can_rx": null,
-      "can_tx": {
-        "Audio": {
-          "audio_settings": {}
-        }
+    }
+  }, {
+    "peer_id": 3,
+    "member_id": "User3",
+    "can_rx": null,
+    "can_tx": {
+      "Audio": {
+        "audio_settings": {}
       }
     }
-  ]
+  }]
 }
 ```
-
-Params:
-1. ```remote_peer_id```: if `Some`, then represents specific remote `Peer` associated with some `Member`. If `None`, 
-then represents Servers peer connection (only SFU).
-2. ```remote_member_id```: if `Some`, then represents specific remote `Member`. If `None`, then represents Server's peer 
-connection (only SFU).
-3. ```can_rx```: if `Some` then Client can subscribe to specified media.
-4. ```can_tx```: if `Some` then Client can publish specified media to remote `Peer`.
-
 </details>
 
-
 #### 8. RequestTracks
 
 ```rust
@@ -784,7 +734,7 @@ represents Server's peer connection (only SFU).
 3. ```rx```: if `Some` then Client requests to subscribe to specified media.
 4. ```tx```: if `Some` then Client requests to publish specified media to remote `Peer`.
 
-#### Examples
+##### Examples
 
 <details>
 <summary>Client requests to subscribe to remote Peer {peer_id = 2} audio and video</summary>
@@ -802,7 +752,6 @@ represents Server's peer connection (only SFU).
   }
 }
 ```
-
 </details>
 
 <details>
@@ -821,7 +770,6 @@ represents Server's peer connection (only SFU).
   }
 }
 ```
-
 </details>
 
 #### 9. GetMembers, Members
@@ -832,7 +780,7 @@ struct GetMembers {
 }
 ```
 
-Client requests `Member` ids.
+Client requests `Member` IDs.
 
 ```rust
 struct Members {
@@ -844,7 +792,7 @@ Server provides `Member`'s list according to user request.
 
 It is recommended to cache `Peer` id - `Member` id relation in Web Client. Probably, in two maps: `HashMap<peer_id, member_id>`, `HashMap<member_id, peer_id>`.
 
-#### Examples
+##### Examples
 
 <details>
 <summary>Client request Member's that own specified Peer's</summary>
@@ -856,7 +804,6 @@ It is recommended to cache `Peer` id - `Member` id relation in Web Client. Proba
   ]
 }
 ```
-
 </details>
 
 <details>
@@ -864,25 +811,21 @@ It is recommended to cache `Peer` id - `Member` id relation in Web Client. Proba
 
 ```json
 {
-  "members": [
-    {
-      "member_id": "user_2",
-      "peers": [ 1 ]
-    },
-    {
-      "member_id": "user_2",
-      "peers": [ 2 ]
-    },
-    {
-      "member_id": "user_3",
-      "peers": [ 3, 4 ]
-    }
-  ]
+  "members": [{
+    "member_id": "user_2",
+    "peers": [ 1 ]
+  }, {
+    "member_id": "user_2",
+    "peers": [ 2 ]
+  }, {
+    "member_id": "user_3",
+    "peers": [ 3, 4 ]
+  }]
 }
 ```
-
 </details>
 
+
 ### Extended examples
 
 <details>
@@ -894,7 +837,7 @@ It is recommended to cache `Peer` id - `Member` id relation in Web Client. Proba
 '-------------'    '-<--<--<--' '-------------'
 ```
 
-1\. Server send `AddPeer` to user1. 
+1\. Server send `AddPeer` to `user1`:
 
 ```json
 {
@@ -903,56 +846,47 @@ It is recommended to cache `Peer` id - `Member` id relation in Web Client. Proba
     "peer": {
       "peer_id": 1,
       "p2p": true,
-      "tracks": [
-        {
-          "id": 1,
-          "media_type": {
-            "Audio": {}
-          },
-          "direction": {
-            "Send": {
-              "receivers": [
-                2
-              ]
-            }
+      "tracks": [{
+        "id": 1,
+        "media_type": {
+          "Audio": {}
+        },
+        "direction": {
+          "Send": {
+            "receivers": [2]
           }
+        }
+      }, {
+        "id": 2,
+        "media_type": {
+          "Video": {}
         },
-        {
-          "id": 2,
-          "media_type": {
-            "Video": {}
-          },
-          "direction": {
-            "Send": {
-              "receivers": [
-                2
-              ]
-            }
+        "direction": {
+          "Send": {
+            "receivers": [2]
           }
+        }
+      }, {
+        "id": 3,
+        "media_type": {
+          "Audio": {}
         },
-        {
-          "id": 3,
-          "media_type": {
-            "Audio": {}
-          },
-          "direction": {
-            "Recv": {
-              "sender": 2
-            }
+        "direction": {
+          "Recv": {
+            "sender": 2
           }
+        }
+      }, {
+        "id": 4,
+        "media_type": {
+          "Video": {}
         },
-        {
-          "id": 4,
-          "media_type": {
-            "Video": {}
-          },
-          "direction": {
-            "Recv": {
-              "sender": 2
-            }
+        "direction": {
+          "Recv": {
+            "sender": 2
           }
         }
-      ]
+      }]
     },
     "sdp_offer": null,
     "ice_servers": {
@@ -967,7 +901,7 @@ It is recommended to cache `Peer` id - `Member` id relation in Web Client. Proba
 }
 ```
  
-2\. User1 answers with [SDP Offer]. 
+2\. `user1` answers with [SDP Offer]:
 
 ```json
 {
@@ -979,7 +913,7 @@ It is recommended to cache `Peer` id - `Member` id relation in Web Client. Proba
 }
 ```
  
-3\. Server send `AddPeer` with user1 [SDP Offer] to user2.
+3\. Server send `AddPeer` with `user1`'s [SDP Offer] to `user2`:
 
 ```json
 {
@@ -988,52 +922,47 @@ It is recommended to cache `Peer` id - `Member` id relation in Web Client. Proba
     "peer": {
       "peer_id": 2,
       "p2p": true,
-      "tracks": [
-        {
-          "id": 1,
-          "media_type": {
-            "Audio": {}
-          },
-          "direction": {
-            "Recv": {
-              "sender": 1
-            }
+      "tracks": [{
+        "id": 1,
+        "media_type": {
+          "Audio": {}
+        },
+        "direction": {
+          "Recv": {
+            "sender": 1
           }
+        }
+      }, {
+        "id": 2,
+        "media_type": {
+          "Audio": {}
         },
-        {
-          "id": 2,
-          "media_type": {
-            "Audio": {}
-          },
-          "direction": {
-            "Recv": {
-              "sender": 1
-            }
+        "direction": {
+          "Recv": {
+            "sender": 1
           }
+        }
+      }, {
+        "id": 3,
+        "media_type": {
+          "Audio": {}
         },
-        {
-          "id": 3,
-          "media_type": {
-            "Audio": {}
-          },
-          "direction": {
-            "Send": {
-              "receivers": [ 1 ]
-            }
+        "direction": {
+          "Send": {
+            "receivers": [1]
           }
+        }
+      }, {
+        "id": 4,
+        "media_type": {
+          "Video": {}
         },
-        {
-          "id": 4,
-          "media_type": {
-            "Video": {}
-          },
-          "direction": {
-            "Send": {
-              "receivers": [ 1 ]
-            }
+        "direction": {
+          "Send": {
+            "receivers": [1]
           }
         }
-      ]
+      }]
     },
     "sdp_offer": "user1_sendrecv_offer",
     "ice_servers": {
@@ -1048,7 +977,7 @@ It is recommended to cache `Peer` id - `Member` id relation in Web Client. Proba
 }
 ```
 
-4\. User2 answers with [SDP Answer]
+4\. `user2` answers with [SDP Answer]:
 
 ```json
 {
@@ -1060,7 +989,7 @@ It is recommended to cache `Peer` id - `Member` id relation in Web Client. Proba
 }
 ```
 
-5\. Both peers exchange discovered [ICE Candidate]'s.
+5\. Both peers exchange discovered [ICE Candidate]'s:
 
 ```json
 {
@@ -1082,7 +1011,7 @@ It is recommended to cache `Peer` id - `Member` id relation in Web Client. Proba
 }
 ```
 
-6\. At this point connection is supposed to be established.
+6\. At this point connection is supposed to be established:
 
 ```
 .----user1----.    .->-->-->--. .----user2----.
@@ -1090,7 +1019,7 @@ It is recommended to cache `Peer` id - `Member` id relation in Web Client. Proba
 '-------------'    '-<--<--<--' '-------------'
 ```
 
-7\. User1 wants to unpublish his tracks, so he sends `RemoveTracks` Server.
+7\. `user1` wants to unpublish his tracks, so he sends `RemoveTracks` to the server:
 
 ```json
 {
@@ -1102,21 +1031,21 @@ It is recommended to cache `Peer` id - `Member` id relation in Web Client. Proba
 }
 ```
 
-8\. Server updates User2 tracks.
+8\. Server updates `user2` tracks:
 
 ```json
 {
   "method": "RemoveTracks",
   "payload": {
     "peer_id": 2,
-    "tracks": [ 1, 2 ]
+    "tracks": [1, 2]
   }
 }
 ```
 
-9\. Server approves User1 `RemoveTracks` request.
+9\. Server approves `user1` `RemoveTracks` request.
 
-10\. User1 initiates SDP renegotiation
+10\. `user1` initiates SDP renegotiation:
 
 ```
 .----user1----.         .----user2----.
@@ -1124,53 +1053,49 @@ It is recommended to cache `Peer` id - `Member` id relation in Web Client. Proba
 '-------------'         '-------------'
 ```
 
-11\. Server notifies User1 that he can publish to User2
+11\. Server notifies `user1` that he can publish to `user2`:
 
 ```json
 {
   "method": "RemotePeer",
   "payload": {
-    "peers": [
-      {
-        "peer_id": 2,
-        "member_id": "user_2",
-        "can_rx": null,
-        "can_tx": {
-          "AudioVideo": {
-            "audio_settings": {},
-            "video_settings": {}
-          }
+    "peers": [{
+      "peer_id": 2,
+      "member_id": "user_2",
+      "can_rx": null,
+      "can_tx": {
+        "AudioVideo": {
+          "audio_settings": {},
+          "video_settings": {}
         }
       }
-    ]
+    }]
   }
 }
 ```
 
-12\. Server notifies User2 that he can subscriber to User1.
+12\. Server notifies `user2` that he can subscribe to `user1`:
 
 ```json
 {
   "method": "RemotePeers",
   "payload": {
-    "peers": [
-      {
-        "peer_id": 1,
-        "member_id": "user_1",
-        "can_rx": {
-          "AudioVideo": {
-            "audio_settings": {},
-            "video_settings": {}
-          }
-        },
-        "can_tx": null
-      }
-    ]
+    "peers": [{
+      "peer_id": 1,
+      "member_id": "user_1",
+      "can_rx": {
+        "AudioVideo": {
+          "audio_settings": {},
+          "video_settings": {}
+        }
+      },
+      "can_tx": null
+    }]
   }
 }
 ```
 
-13\. User1 requests to publish to User2.
+13\. `user1` requests to publish to `user2`:
 
 ```json
 {
@@ -1189,84 +1114,77 @@ It is recommended to cache `Peer` id - `Member` id relation in Web Client. Proba
 }
 ```
 
-14\. Server updates User2 tracks.
+14\. Server updates `user2` tracks:
 
 ```json
 {
   "method": "UpdateTracks",
   "payload": {
     "peer_id": 2,
-    "tracks": [
-      {
-        "id": 1,
-        "media_type": {
-          "Audio": {}
-        },
-        "direction": {
-          "Recv": {
-            "sender": 1
-          }
+    "tracks": [{
+      "id": 1,
+      "media_type": {
+        "Audio": {}
+      },
+      "direction": {
+        "Recv": {
+          "sender": 1
         }
+      }
+    }, {
+      "id": 2,
+      "media_type": {
+        "Audio": {}
       },
-      {
-        "id": 2,
-        "media_type": {
-          "Audio": {}
-        },
-        "direction": {
-          "Recv": {
-            "sender": 1
-          }
+      "direction": {
+        "Recv": {
+          "sender": 1
         }
       }
-    ]
+    }]
   }
 }
 ```
 
-15\. Server updates User1 tracks.
+15\. Server updates `user1` tracks:
 
 ```json
 {
   "method": "UpdateTracks",
   "payload": {
     "peer_id": 1,
-    "tracks": [
-      {
-        "id": 1,
-        "media_type": {
-          "Audio": {}
-        },
-        "direction": {
-          "Send": {
-            "receivers": [ 2 ]
-          }
+    "tracks": [{
+      "id": 1,
+      "media_type": {
+        "Audio": {}
+      },
+      "direction": {
+        "Send": {
+          "receivers": [2]
         }
+      }
+    }, {
+      "id": 2,
+      "media_type": {
+        "Video": {}
       },
-      {
-        "id": 2,
-        "media_type": {
-          "Video": {}
-        },
-        "direction": {
-          "Send": {
-            "receivers": [ 2 ]
-          }
+      "direction": {
+        "Send": {
+          "receivers": [2]
         }
       }
-    ]
+    }]
   }
 }
 ```
 
-16\. SDP Renegotiation
+16\. SDP re-negotiation:
 
 ```
 .----user1----.    .->-->-->--. .----user2----.
 :             o(1)=:          :=o(2)          :
 '-------------'    '-<--<--<--' '-------------'
 ```
-
 </details>
 
 
@@ -1283,7 +1201,7 @@ It is recommended to cache `Peer` id - `Member` id relation in Web Client. Proba
                                                        '------------------'
 ```
 
-1\. Server requests User1 to create `sendonly` `Peer` passing Server's [SDP Offer].
+1\. Server requests `user1` to create `sendonly` `Peer` passing Server's [SDP Offer]:
 
 ```json
 {
@@ -1292,30 +1210,27 @@ It is recommended to cache `Peer` id - `Member` id relation in Web Client. Proba
     "peer": {
       "peer_id": 1,
       "p2p": false,
-      "tracks": [
-        {
-          "id": 1,
-          "media_type": {
-            "Audio": {}
-          },
-          "direction": {
-            "Send": {
-              "receivers": []
-            }
+      "tracks": [{
+        "id": 1,
+        "media_type": {
+          "Audio": {}
+        },
+        "direction": {
+          "Send": {
+            "receivers": []
           }
+        }
+      }, {
+        "id": 2,
+        "media_type": {
+          "Video": {}
         },
-        {
-          "id": 2,
-          "media_type": {
-            "Video": {}
-          },
-          "direction": {
-            "Send": {
-              "receivers": []
-            }
+        "direction": {
+          "Send": {
+            "receivers": []
           }
         }
-      ]
+      }]
     },
     "sdp_offer": "server_user1_recvonly_offer",
     "ice_servers": {
@@ -1330,7 +1245,7 @@ It is recommended to cache `Peer` id - `Member` id relation in Web Client. Proba
 }
 ```
 
-2\. User1 creates peer and answeres with [SDP Answer].
+2\. `user1` creates peer and answers with [SDP Answer]:
 
 ```json
 {
@@ -1342,7 +1257,7 @@ It is recommended to cache `Peer` id - `Member` id relation in Web Client. Proba
 }
 ```
 
-3\. Server and User1 exchange [ICE Candidate]'s.
+3\. Server and `user1` exchange [ICE Candidate]s:
 
 ```json
 {
@@ -1364,7 +1279,7 @@ It is recommended to cache `Peer` id - `Member` id relation in Web Client. Proba
 }
 ```
 
-4\. Connection is established
+4\. Connection is established:
 
 ```
                           .-------SFU-------.
@@ -1374,7 +1289,7 @@ It is recommended to cache `Peer` id - `Member` id relation in Web Client. Proba
                           '-----------------'
 ```
 
-5\. Server requests User2 to create `recvonly` `Peer` passing Server's [SDP Offer]. 
+5\. Server requests `user2` to create `recvonly` `Peer` passing Server's [SDP Offer]:
 
 ```json
 {
@@ -1383,30 +1298,27 @@ It is recommended to cache `Peer` id - `Member` id relation in Web Client. Proba
     "peer": {
       "peer_id": 2,
       "p2p": false,
-      "tracks": [
-        {
-          "id": 1,
-          "media_type": {
-            "Audio": {}
-          },
-          "direction": {
-            "Recv": {
-              "sender": 1
-            }
+      "tracks": [{
+        "id": 1,
+        "media_type": {
+          "Audio": {}
+        },
+        "direction": {
+          "Recv": {
+            "sender": 1
           }
+        }
+      }, {
+        "id": 2,
+        "media_type": {
+          "Video": {}
         },
-        {
-          "id": 2,
-          "media_type": {
-            "Video": {}
-          },
-          "direction": {
-            "Recv": {
-              "sender": 1
-            }
+        "direction": {
+          "Recv": {
+            "sender": 1
           }
         }
-      ]
+      }]
     },
     "sdp_offer": "server_user2_sendonly_offer",
     "ice_servers": {
@@ -1421,7 +1333,7 @@ It is recommended to cache `Peer` id - `Member` id relation in Web Client. Proba
 }
 ```
 
-6\. User2 answers with [SDP Answer].
+6\. `user2` answers with [SDP Answer]:
 
 ```json
 {
@@ -1433,7 +1345,7 @@ It is recommended to cache `Peer` id - `Member` id relation in Web Client. Proba
 }
 ```
 
-7\. Server and User2 exchange [ICE Candidate]'s.
+7\. Server and `user2` exchange [ICE Candidate]s:
 
 ```json
 {
@@ -1455,7 +1367,7 @@ It is recommended to cache `Peer` id - `Member` id relation in Web Client. Proba
 }
 ```
 
-8\. User2 is connected to Server's peer connection.
+8\. `user2` is connected to Server's peer connection:
 
 ```
                                                        .-------user2------.
@@ -1466,53 +1378,50 @@ It is recommended to cache `Peer` id - `Member` id relation in Web Client. Proba
                           '-----------------'
 ```
 
-9\. Server notifies User1 that he has new subscriber.
+9\. Server notifies `user1` that he has new subscriber:
 
 ```json
 {
   "method": "UpdateTracks",
   "payload": {
     "peer_id": 1,
-    "tracks": [
-      {
-        "id": 1,
-        "media_type": {
-          "Audio": {}
-        },
-        "direction": {
-          "Send": {
-            "receivers": [ 2 ]
-          }
+    "tracks": [{
+      "id": 1,
+      "media_type": {
+        "Audio": {}
+      },
+      "direction": {
+        "Send": {
+          "receivers": [ 2 ]
         }
+      }
+    }, {
+      "id": 2,
+      "media_type": {
+        "Video": {}
       },
-      {
-        "id": 2,
-        "media_type": {
-          "Video": {}
-        },
-        "direction": {
-          "Send": {
-            "receivers": [2]
-          }
+      "direction": {
+        "Send": {
+          "receivers": [2]
         }
       }
-    ]
+    }]
   }
 }
 ```
 
-10\. Server sends User1 `Peer {peer_id = 1 }` media to User2 `Peer {peer_id = 2 }`.
+10\. Server sends `user1` `Peer {peer_id = 1}` media to `user2` `Peer {peer_id = 2}`:
 
- ```
+```
                                                         .-------user2------.
                            .-------SFU-------.    .-->--o      pc_id = 2   :
  .------user1------.       :         .->-->--o-->-'     '------------------'
  :     pc_id = 1   o-->-->-o--->-->--'       :
  '-----------------'       :                 :
                            '-----------------'
- ```
- 
-11\. Server requests User3 to create `recvonly` `Peer` passing Server's [SDP Offer]. 
+```
+
+11\. Server requests `user3` to create `recvonly` `Peer` passing Server's [SDP Offer]: 
 
 ```json
 {
@@ -1521,30 +1430,27 @@ It is recommended to cache `Peer` id - `Member` id relation in Web Client. Proba
     "peer": {
       "peer_id": 3,
       "p2p": false,
-      "tracks": [
-        {
-          "id": 1,
-          "media_type": {
-            "Audio": {}
-          },
-          "direction": {
-            "Recv": {
-              "sender": 1
-            }
+      "tracks": [{
+        "id": 1,
+        "media_type": {
+          "Audio": {}
+        },
+        "direction": {
+          "Recv": {
+            "sender": 1
           }
+        }
+      }, {
+        "id": 2,
+        "media_type": {
+          "Video": {}
         },
-        {
-          "id": 2,
-          "media_type": {
-            "Video": {}
-          },
-          "direction": {
-            "Recv": {
-              "sender": 1
-            }
+        "direction": {
+          "Recv": {
+            "sender": 1
           }
         }
-      ]
+      }]
     },
     "sdp_offer": "server_user3_sendonly_offer",
     "ice_servers": {
@@ -1559,7 +1465,7 @@ It is recommended to cache `Peer` id - `Member` id relation in Web Client. Proba
 }
 ```
 
-12\. User3 answers with [SDP Answer].
+12\. `user2` answers with [SDP Answer]:
 
 ```json
 {
@@ -1571,7 +1477,7 @@ It is recommended to cache `Peer` id - `Member` id relation in Web Client. Proba
 }
 ```
 
-13\. Server and User3 exchange [ICE Candidate]'s.
+13\. Server and `user3` exchange [ICE Candidate]s:
 
 ```json
 {
@@ -1593,7 +1499,7 @@ It is recommended to cache `Peer` id - `Member` id relation in Web Client. Proba
 }
 ```
 
-14\. User3 is connected to Server's peer connection.
+14\. `user3` is connected to Server's peer connection:
 
 ```
                                                        .-------user2------.
@@ -1605,42 +1511,39 @@ It is recommended to cache `Peer` id - `Member` id relation in Web Client. Proba
                                                        '------------------'
 ```
 
-15\. Server notifies User1 that he has new subscriber.
+15\. Server notifies `user1` that he has new subscriber:
 
 ```json
 {
   "method": "UpdateTracks",
   "payload": {
     "peer_id": 1,
-    "tracks": [
-      {
-        "id": 1,
-        "media_type": {
-          "Audio": {}
-        },
-        "direction": {
-          "Send": {
-            "receivers": [ 2,3 ]
-          }
+    "tracks": [{
+      "id": 1,
+      "media_type": {
+        "Audio": {}
+      },
+      "direction": {
+        "Send": {
+          "receivers": [2, 3]
         }
+      }
+    }, {
+      "id": 2,
+      "media_type": {
+        "Video": {}
       },
-      {
-        "id": 2,
-        "media_type": {
-          "Video": {}
-        },
-        "direction": {
-          "Send": {
-            "receivers": [ 2,3 ]
-          }
+      "direction": {
+        "Send": {
+          "receivers": [2, 3]
         }
       }
-    ]
+    }]
   }
 }
 ```
 
-16\. Server sends User1 `Peer {peer_id = 1 }` media to User2 `Peer {peer_id = 3 }`.
+16\. Server sends `user1` `Peer {peer_id = 1}` media to `user2` `Peer {peer_id = 3}`:
 
 ```
                                                      .-------user2------.
@@ -1651,54 +1554,56 @@ It is recommended to cache `Peer` id - `Member` id relation in Web Client. Proba
                           '-----------------'    '->-o      pc_id = 3   :
                                                      '------------------'
 ```
-
 </details>
 
+
+
+
 ## Drawbacks and alternatives
 [drawbacks-and-alternatives]: #drawbacks-and-alternatives
 
-This RFC design tries to be a "silver bullet": cover all possible use-cases and combine them in single protocol. Such 
-versatility increases complexity. Simplifications can be achieved by imposing some general constraints:
+This RFC design tries to be a "silver bullet": cover all possible use-cases and combine them into a single protocol. Such versatility increases complexity. Simplifications can be achieved by imposing some general constraints:
 1. Divide current protocol in two separate protocols: one for SFU and one for P2P.
 2. Reject future possibilities of using 1 `Peer` for all inbound/outbound tracks.
-3. Limit number of outbound streams in single `Peer` to 1.
+3. Limit the number of outbound streams in single `Peer` to 1.
 4. Remove publishers acknowledgement of every receiver on each track.
 5. Remove subscribers acknowledgement of every publisher that is not publishing at the moment.
 
+
+
+
 ## Unresolved questions and future possibilities
 [unresolved-questions-and-future-possibilities]: #unresolved-questions-and-future-possibilities
 
+
 ### Data channels
 
-[WebRTC] spec introduces [RTCDataChannel] - a bi-directional data channel between two peers which allows arbitrary data 
-exchange. It is an amazing feature with huge potential, but, at this point it is quite useless for our use cases.
+[WebRTC] spec introduces [RTCDataChannel] - a bi-directional data channel between two peers which allows arbitrary data exchange. It is an amazing feature with huge potential, but, at this point it is quite useless for our use cases.
 
-As the project develops, requirements will change, and we might consider adding data channels. Although, they are not 
+As the project grows, requirements will change, and we might consider adding data channels. Although, they are not 
 mentioned in this protocol, only minor tweaks will be required to support them.
 
-### Receiving tracks form multiple senders in single peer connection
+
+### Receiving tracks from multiple senders in single peer connection
 
 There are two general ways to manage Client's peer connections when using SFU server:
-1. Having only one pair of [RTCPeerConnection]'s (one at Client end and one at Server) and passing all send/recv tracks 
-through this connection.
-2. Having a separate [RTCPeerConnection] pair for each track group.
+1. Having only one pair of [RTCPeerConnection]'s (one at Client's end and one at Server) and pass all send/recv tracks through this connection.
+2. Or having a separate [RTCPeerConnection] pair for each track group.
 
-First way is preferable since it allows to reduce resources usage on both ends. But track management is very unclear in 
-this case and gstreamers [webrtcbin] currently does not support dynamic addition/removal of streams and needs major 
-updates to be able to do so.
+First way is preferable since it allows to reduce resources usage on both ends. But track management is very unclear in this case and [webrtcbin] module of [GStreamer] currently does not support dynamic addition/removal of streams and needs major updates to be able to do so.
 
-Current protocol assumes that there will be separate [RTCPeerConnection] pair for each track group. 
-At the same time, it does not forbid having all the tracks in single [RTCPeerConnection] pair, but it will require some 
-minor changes to make this work.
+Current protocol assumes that there will be separate [RTCPeerConnection] pair for each track group. At the same time, it does not forbid having all the tracks in single [RTCPeerConnection] pair, but it will require some minor changes to make this work.
 
 
 
 
-[RTCPeerConnection]: https://www.w3.org/TR/webrtc/#rtcpeerconnection-interface
+
+[GStreamer]: https://gstreamer.freedesktop.org
+[ICE Candidate]:https://tools.ietf.org/html/rfc8445
 [MediaStreamTrack]: https://www.w3.org/TR/mediacapture-streams/#mediastreamtrack
-[webrtcbin]: https://gstreamer.freedesktop.org/data/doc/gstreamer/head/gst-plugins-bad/html/gst-plugins-bad-plugins-webrtcbin.html
 [RTCDataChannel]:https://www.w3.org/TR/webrtc/#rtcdatachannel
-[WebRTC]:https://www.w3.org/TR/webrtc/
-[SDP Offer]:https://tools.ietf.org/html/rfc3264
+[RTCPeerConnection]: https://www.w3.org/TR/webrtc/#rtcpeerconnection-interface
 [SDP Answer]:https://tools.ietf.org/html/rfc3264
-[ICE Candidate]:https://tools.ietf.org/html/rfc8445
\ No newline at end of file
+[SDP Offer]:https://tools.ietf.org/html/rfc3264
+[WebRTC]:https://www.w3.org/TR/webrtc
+[webrtcbin]: https://gstreamer.freedesktop.org/data/doc/gstreamer/head/gst-plugins-bad/html/gst-plugins-bad-plugins-webrtcbin.html

From e565ec0d286662d33051ec964f848766e1f89208 Mon Sep 17 00:00:00 2001
From: alexlapa <lapa.alex@ex.ua>
Date: Mon, 24 Dec 2018 12:03:53 -0500
Subject: [PATCH 08/24] post-review fixes

---
 docs/rfc/0002-webrc-client-api.md | 43 +++++++++++++++++--------------
 1 file changed, 24 insertions(+), 19 deletions(-)

diff --git a/docs/rfc/0002-webrc-client-api.md b/docs/rfc/0002-webrc-client-api.md
index 75a33e8ff..c8508cd7e 100644
--- a/docs/rfc/0002-webrc-client-api.md
+++ b/docs/rfc/0002-webrc-client-api.md
@@ -26,8 +26,8 @@ You will need to express ways to:
 4. Pass some user metadata to hook business logic onto.
 5. Build more complex connection graphs.
 6. Dynamically cancel/begin media publishing/receiving.
-7. Passing errors, connection statistics.
-8. Cover both P2P mesh and SFU scenarios.
+7. Passing errors, [RTCPeerConnection]'s [RTCStatsReport]'s.
+8. Cover both [P2P full mesh] and [Hub Server(SFU, MCU)] scenarios.
 
 The protocol must be versatile enough to cover all possible use cases.
 
@@ -71,10 +71,12 @@ Although, signalling can be implemented on top of any transport, WebSocket suits
 ### Protocol considerations
 
 Existing best practices are recommended for final implementation:
-1. Message level ping-pongs.
-2. Reconnects.
-3. Transactions.
-4. Using custom Close Frame Status Codes.
+1. Message level ping-pongs, since it is the most reliable way to detect connection loss.
+2. Reconnects, since [RTCPeerConnection] always outlives WebSocket connection in cases of network issues, and both parts
+ should know when to dispose related resources.
+3. Transactions, so each part will receive answers to all request sent, and be able to know if request was processed 
+correctly or caused some kind of error.
+4. Using custom Close Frame Status Codes, to implement reliable send-and-close.
 
 Transactions:
 
@@ -204,10 +206,10 @@ struct VideoSettings {}
 
 ### Methods
 
-#### 1. AddPeer
+#### 1. CreatePeer
 
 ```rust
-struct AddPeer {
+struct CreatePeer {
     peer: Peer,
     sdp_offer: Option<String>,
     ice_servers: ICEServers,
@@ -302,7 +304,7 @@ Client is expected to:
 3. Add newly created tracks to [RTCPeerConnection].
 4. Create `sendrecv` [SDP Offer].
 5. Set offer as peers local description.
-6. Answer `AddPeer` request with `Offer` request containing [SDP Offer].
+6. Answer `CreatePeer` request with `Offer` request containing [SDP Offer].
 7. Expect remote [SDP Answer] to set it as remote description.
 
 After negotiation is done and media starts flowing, the client might receive notification that his media is being sent to `Peer { peer_id = 2 }`, and he is receiving media from `Peer { peer_id = 2 }`.
@@ -347,7 +349,7 @@ Client is expected to:
 4. Set provided offer as peers remote description.
 5. Create `sendonly` [SDP Answer].
 6. Set created [SDP Answer] as local description.
-7. Answer `AddPeer` request with `Answer` request containing [SDP Offer]. 
+7. Answer `CreatePeer` request with `Answer` request containing [SDP Offer]. 
 
 After negotiation is done and media starts flowing, client might receive notification that his media is being sent to server.
 </details>
@@ -542,7 +544,7 @@ struct Offer {
 Server's / Client's [SDP Offer] sent during SDP negotiation between peers.
 
 Client can send it:
-1. As answer to `AddPeer {sdp_offer: None}`
+1. As answer to `CreatePeer {sdp_offer: None}`
 2. As answer to `UpdateTracks` if update requires SDP renegotiation.
 
 Server can send it:
@@ -574,7 +576,7 @@ struct Answer {
 Server's / Client's [SDP Answer] sent during SDP negotiation between peers.
 
 Client can send it:
-1. As answer to `AddPeer {sdp_offer: Some}`.
+1. As answer to `CreatePeer {sdp_offer: Some}`.
 2. As answer to `Offer`.
 
 Server can send it only as answer to `Offer`.
@@ -837,11 +839,11 @@ It is recommended to cache `Peer` id - `Member` id relation in Web Client. Proba
 '-------------'    '-<--<--<--' '-------------'
 ```
 
-1\. Server send `AddPeer` to `user1`:
+1\. Server send `CreatePeer` to `user1`:
 
 ```json
 {
-  "method": "AddPeer",
+  "method": "CreatePeer",
   "payload": {
     "peer": {
       "peer_id": 1,
@@ -913,11 +915,11 @@ It is recommended to cache `Peer` id - `Member` id relation in Web Client. Proba
 }
 ```
  
-3\. Server send `AddPeer` with `user1`'s [SDP Offer] to `user2`:
+3\. Server send `CreatePeer` with `user1`'s [SDP Offer] to `user2`:
 
 ```json
 {
-  "method": "AddPeer",
+  "method": "CreatePeer",
   "payload": {
     "peer": {
       "peer_id": 2,
@@ -1205,7 +1207,7 @@ It is recommended to cache `Peer` id - `Member` id relation in Web Client. Proba
 
 ```json
 {
-  "method": "AddPeer",
+  "method": "CreatePeer",
   "payload": {
     "peer": {
       "peer_id": 1,
@@ -1293,7 +1295,7 @@ It is recommended to cache `Peer` id - `Member` id relation in Web Client. Proba
 
 ```json
 {
-  "method": "AddPeer",
+  "method": "CreatePeer",
   "payload": {
     "peer": {
       "peer_id": 2,
@@ -1425,7 +1427,7 @@ It is recommended to cache `Peer` id - `Member` id relation in Web Client. Proba
 
 ```json
 {
-  "method": "AddPeer",
+  "method": "CreatePeer",
   "payload": {
     "peer": {
       "peer_id": 3,
@@ -1607,3 +1609,6 @@ Current protocol assumes that there will be separate [RTCPeerConnection] pair fo
 [SDP Offer]:https://tools.ietf.org/html/rfc3264
 [WebRTC]:https://www.w3.org/TR/webrtc
 [webrtcbin]: https://gstreamer.freedesktop.org/data/doc/gstreamer/head/gst-plugins-bad/html/gst-plugins-bad-plugins-webrtcbin.html
+[P2P full mesh]: https://webrtcglossary.com/mesh/
+[Hub Server(SFU, MCU)]: https://webrtcglossary.com/sfu/
+[RTCStatsReport]: https://developer.mozilla.org/en-US/docs/Web/API/RTCStatsReport
\ No newline at end of file

From c15528843572f5cdd5351084870768606a1e7703 Mon Sep 17 00:00:00 2001
From: tyranron <tyranron@gmail.com>
Date: Tue, 25 Dec 2018 13:24:07 +0200
Subject: [PATCH 09/24] Style corrections

---
 docs/rfc/0002-webrc-client-api.md | 20 +++++++++-----------
 1 file changed, 9 insertions(+), 11 deletions(-)

diff --git a/docs/rfc/0002-webrc-client-api.md b/docs/rfc/0002-webrc-client-api.md
index c8508cd7e..a94d3b7ee 100644
--- a/docs/rfc/0002-webrc-client-api.md
+++ b/docs/rfc/0002-webrc-client-api.md
@@ -26,8 +26,8 @@ You will need to express ways to:
 4. Pass some user metadata to hook business logic onto.
 5. Build more complex connection graphs.
 6. Dynamically cancel/begin media publishing/receiving.
-7. Passing errors, [RTCPeerConnection]'s [RTCStatsReport]'s.
-8. Cover both [P2P full mesh] and [Hub Server(SFU, MCU)] scenarios.
+7. Passing errors, [RTCPeerConnection]s, [RTCStatsReport]s.
+8. Cover both [p2p full mesh] and [hub server (SFU, MCU)] scenarios.
 
 The protocol must be versatile enough to cover all possible use cases.
 
@@ -71,11 +71,9 @@ Although, signalling can be implemented on top of any transport, WebSocket suits
 ### Protocol considerations
 
 Existing best practices are recommended for final implementation:
-1. Message level ping-pongs, since it is the most reliable way to detect connection loss.
-2. Reconnects, since [RTCPeerConnection] always outlives WebSocket connection in cases of network issues, and both parts
- should know when to dispose related resources.
-3. Transactions, so each part will receive answers to all request sent, and be able to know if request was processed 
-correctly or caused some kind of error.
+1. Message level `ping`/`pong`, since it is the most reliable way to detect connection loss (protocol level WebSocket `ping`/`pong` may disfunct due to browser implementation and is not exposed to `Web Client`).
+2. Reconnects, since [RTCPeerConnection] always outlives WebSocket connection in cases of network issues, and both parts should know when to dispose related resources.
+3. Transactions, so each part will receive answers to all request sent, and be able to know if request was processed correctly or caused some kind of error.
 4. Using custom Close Frame Status Codes, to implement reliable send-and-close.
 
 Transactions:
@@ -94,7 +92,7 @@ struct Payload<T> {
 }
 ```
 
-Each message requires answer. Answer can carry some payload(e.g. answering with [SDP Answer] to [SDP Offer]), Error, or just noting, which just means that message reached destination and was processed. 
+Each message requires answer. Answer can carry some payload (e.g. answering with [SDP Answer] to [SDP Offer]), error, or just noting, which just means that message reached destination and was processed.
 
 
 ### Signalling Protocol considerations
@@ -1601,14 +1599,14 @@ Current protocol assumes that there will be separate [RTCPeerConnection] pair fo
 
 
 [GStreamer]: https://gstreamer.freedesktop.org
+[hub server (SFU, MCU)]: https://webrtcglossary.com/sfu
 [ICE Candidate]:https://tools.ietf.org/html/rfc8445
 [MediaStreamTrack]: https://www.w3.org/TR/mediacapture-streams/#mediastreamtrack
+[p2p full mesh]: https://webrtcglossary.com/mesh
 [RTCDataChannel]:https://www.w3.org/TR/webrtc/#rtcdatachannel
 [RTCPeerConnection]: https://www.w3.org/TR/webrtc/#rtcpeerconnection-interface
+[RTCStatsReport]: https://developer.mozilla.org/en-US/docs/Web/API/RTCStatsReport
 [SDP Answer]:https://tools.ietf.org/html/rfc3264
 [SDP Offer]:https://tools.ietf.org/html/rfc3264
 [WebRTC]:https://www.w3.org/TR/webrtc
 [webrtcbin]: https://gstreamer.freedesktop.org/data/doc/gstreamer/head/gst-plugins-bad/html/gst-plugins-bad-plugins-webrtcbin.html
-[P2P full mesh]: https://webrtcglossary.com/mesh/
-[Hub Server(SFU, MCU)]: https://webrtcglossary.com/sfu/
-[RTCStatsReport]: https://developer.mozilla.org/en-US/docs/Web/API/RTCStatsReport
\ No newline at end of file

From d533d50ca6524136bad15918dea6a161094baab8 Mon Sep 17 00:00:00 2001
From: alexlapa <lapa.alex@ex.ua>
Date: Tue, 25 Dec 2018 09:53:30 -0500
Subject: [PATCH 10/24] post-review fixes 2

---
 docs/rfc/0002-webrc-client-api.md | 196 +++++++++++++++---------------
 1 file changed, 97 insertions(+), 99 deletions(-)

diff --git a/docs/rfc/0002-webrc-client-api.md b/docs/rfc/0002-webrc-client-api.md
index a94d3b7ee..d20e54e5c 100644
--- a/docs/rfc/0002-webrc-client-api.md
+++ b/docs/rfc/0002-webrc-client-api.md
@@ -73,12 +73,10 @@ Although, signalling can be implemented on top of any transport, WebSocket suits
 Existing best practices are recommended for final implementation:
 1. Message level `ping`/`pong`, since it is the most reliable way to detect connection loss (protocol level WebSocket `ping`/`pong` may disfunct due to browser implementation and is not exposed to `Web Client`).
 2. Reconnects, since [RTCPeerConnection] always outlives WebSocket connection in cases of network issues, and both parts should know when to dispose related resources.
-3. Transactions, so each part will receive answers to all request sent, and be able to know if request was processed correctly or caused some kind of error.
+3. Share common identifier across multiple messages, so each part will receive answers to all request sent, and be able to know if request was processed correctly or caused some kind of error.
 4. Using custom Close Frame Status Codes, to implement reliable send-and-close.
 
-Transactions:
-
-Each message is represented as:
+Each message could be represented as:
 
 ```rust
 struct WsMessage<T> {
@@ -166,7 +164,6 @@ struct Member {
 ```rust
 struct Peer {
     peer_id: u64,
-    p2p: bool,
     tracks: Vec<Track>,
 }
 ```
@@ -197,26 +194,21 @@ struct AudioSettings {}
 struct VideoSettings {}
 ```
 
-`P2P` flag implies some logic on `TrackDirection::Send` tracks:
-1. `P2P` `Send` tracks always have only one receiver.
-2. Non-`P2P` `Send` tracks can have 0-N receivers. 0 - if media is transmitted to server, but have no actual user receiving it.
-
-
 ### Methods
 
-#### 1. CreatePeer
+#### 1. SetPeer
 
 ```rust
-struct CreatePeer {
+struct SetPeer {
     peer: Peer,
     sdp_offer: Option<String>,
-    ice_servers: ICEServers,
+    ice_servers: Vec<ICEServer>,
 }
 ```
 
 Related objects:
 ```rust
-struct ICEServers {
+struct ICEServer {
     urls: Vec<String>,
     username: String,
     credential: String,
@@ -241,7 +233,6 @@ The most important part of `Peer` object is list of tracks. All `TrackDirection:
 {
   "peer": {
     "peer_id": 1,
-    "p2p": true,
     "tracks": [{
       "id": 1,
       "media_type": {
@@ -285,14 +276,16 @@ The most important part of `Peer` object is list of tracks. All `TrackDirection:
     }
   ]},
   "sdp_offer": null,
-  "ice_servers": {
-    "urls": [
-      "turn:turnserver.com:3478",
-      "turn:turnserver.com:3478?transport=tcp"
-    ],
-    "username": "turn_user",
-    "credential": "turn_credential"
-  }
+  "ice_servers":[
+      {
+      "urls":[
+        "turn:turnserver.com:3478",
+        "turn:turnserver.com:3478?transport=tcp"
+      ],
+      "username":"turn_user",
+      "credential":"turn_credential"
+      }
+  ]
 }
 ```
 
@@ -302,7 +295,7 @@ Client is expected to:
 3. Add newly created tracks to [RTCPeerConnection].
 4. Create `sendrecv` [SDP Offer].
 5. Set offer as peers local description.
-6. Answer `CreatePeer` request with `Offer` request containing [SDP Offer].
+6. Answer `SetPeer` request with `Offer` request containing [SDP Offer].
 7. Expect remote [SDP Answer] to set it as remote description.
 
 After negotiation is done and media starts flowing, the client might receive notification that his media is being sent to `Peer { peer_id = 2 }`, and he is receiving media from `Peer { peer_id = 2 }`.
@@ -315,7 +308,6 @@ After negotiation is done and media starts flowing, the client might receive not
 {
   "peer": {
     "peer_id": 1,
-    "p2p": false,
     "tracks": [{
       "id": 1,
       "media_type": {
@@ -329,14 +321,16 @@ After negotiation is done and media starts flowing, the client might receive not
     }]
   },
   "sdp_offer": "server_user1_recvonly_offer",
-  "ice_servers": {
-    "urls": [
-      "turn:turnserver.com:3478",
-      "turn:turnserver.com:3478?transport=tcp"
-    ],
-    "username": "turn_user",
-    "credential": "turn_credential"
-  }
+  "ice_servers":[
+      {
+      "urls":[
+        "turn:turnserver.com:3478",
+        "turn:turnserver.com:3478?transport=tcp"
+      ],
+      "username":"turn_user",
+      "credential":"turn_credential"
+      }
+  ]
 }
 ```
 
@@ -347,7 +341,7 @@ Client is expected to:
 4. Set provided offer as peers remote description.
 5. Create `sendonly` [SDP Answer].
 6. Set created [SDP Answer] as local description.
-7. Answer `CreatePeer` request with `Answer` request containing [SDP Offer]. 
+7. Answer `SetPeer` request with `Answer` request containing [SDP Offer]. 
 
 After negotiation is done and media starts flowing, client might receive notification that his media is being sent to server.
 </details>
@@ -380,10 +374,10 @@ Probably, Server will always give his permission on any Client's request. This k
 ```
 </details>
 
-#### 3. UpdateTracks
+#### 3. SetTracks
 
 ```rust
-struct UpdateTracks {
+struct SetTracks {
     peer_id: u64,
     tracks: Vec<Track>,
 }
@@ -408,7 +402,6 @@ If Client => Server, then it can be used to express Clients intentions to:
 ```json
 {
   "peer_id": 1,
-  "p2p": false,
   "tracks": [{
     "id": 1,
     "media_type": {
@@ -542,8 +535,8 @@ struct Offer {
 Server's / Client's [SDP Offer] sent during SDP negotiation between peers.
 
 Client can send it:
-1. As answer to `CreatePeer {sdp_offer: None}`
-2. As answer to `UpdateTracks` if update requires SDP renegotiation.
+1. As answer to `SetPeer {sdp_offer: None}`
+2. As answer to `SetTracks` if update requires SDP renegotiation.
 
 Server can send it:
 1. If server triggers renegotiation.
@@ -574,7 +567,7 @@ struct Answer {
 Server's / Client's [SDP Answer] sent during SDP negotiation between peers.
 
 Client can send it:
-1. As answer to `CreatePeer {sdp_offer: Some}`.
+1. As answer to `SetPeer {sdp_offer: Some}`.
 2. As answer to `Offer`.
 
 Server can send it only as answer to `Offer`.
@@ -696,10 +689,10 @@ Params:
 ```
 </details>
 
-#### 8. RequestTracks
+#### 8. RequestRemoteTracks
 
 ```rust
-struct RequestTracks {
+struct RequestRemoteTracks {
     peer_id: Option<u64>,
     remote_peer_id: Option<u64>,
     rx: Option<RemotePeerTrackType>,
@@ -837,15 +830,14 @@ It is recommended to cache `Peer` id - `Member` id relation in Web Client. Proba
 '-------------'    '-<--<--<--' '-------------'
 ```
 
-1\. Server send `CreatePeer` to `user1`:
+1\. Server send `SetPeer` to `user1`:
 
 ```json
 {
-  "method": "CreatePeer",
+  "method": "SetPeer",
   "payload": {
     "peer": {
       "peer_id": 1,
-      "p2p": true,
       "tracks": [{
         "id": 1,
         "media_type": {
@@ -889,14 +881,16 @@ It is recommended to cache `Peer` id - `Member` id relation in Web Client. Proba
       }]
     },
     "sdp_offer": null,
-    "ice_servers": {
-      "urls": [
-        "turn:turnserver.com:3478",
-        "turn:turnserver.com:3478?transport=tcp"
-      ],
-      "username": "turn_user",
-      "credential": "turn_credential"
-    }
+    "ice_servers":[
+        {
+        "urls":[
+          "turn:turnserver.com:3478",
+          "turn:turnserver.com:3478?transport=tcp"
+        ],
+        "username":"turn_user",
+        "credential":"turn_credential"
+        }
+    ]
   }
 }
 ```
@@ -913,15 +907,14 @@ It is recommended to cache `Peer` id - `Member` id relation in Web Client. Proba
 }
 ```
  
-3\. Server send `CreatePeer` with `user1`'s [SDP Offer] to `user2`:
+3\. Server send `SetPeer` with `user1`'s [SDP Offer] to `user2`:
 
 ```json
 {
-  "method": "CreatePeer",
+  "method": "SetPeer",
   "payload": {
     "peer": {
       "peer_id": 2,
-      "p2p": true,
       "tracks": [{
         "id": 1,
         "media_type": {
@@ -965,14 +958,16 @@ It is recommended to cache `Peer` id - `Member` id relation in Web Client. Proba
       }]
     },
     "sdp_offer": "user1_sendrecv_offer",
-    "ice_servers": {
-      "urls": [
-        "turn:turnserver.com:3478",
-        "turn:turnserver.com:3478?transport=tcp"
-      ],
-      "username": "turn_user",
-      "credential": "turn_credential"
-    }
+    "ice_servers":[
+        {
+        "urls":[
+          "turn:turnserver.com:3478",
+          "turn:turnserver.com:3478?transport=tcp"
+        ],
+        "username":"turn_user",
+        "credential":"turn_credential"
+        }
+    ]
   }
 }
 ```
@@ -1099,7 +1094,7 @@ It is recommended to cache `Peer` id - `Member` id relation in Web Client. Proba
 
 ```json
 {
-  "method": "RequestTracks",
+  "method": "RequestRemoteTracks",
   "payload": {
     "peer_id": 1,
     "remote_peer_id": 2,
@@ -1118,7 +1113,7 @@ It is recommended to cache `Peer` id - `Member` id relation in Web Client. Proba
 
 ```json
 {
-  "method": "UpdateTracks",
+  "method": "SetTracks",
   "payload": {
     "peer_id": 2,
     "tracks": [{
@@ -1150,7 +1145,7 @@ It is recommended to cache `Peer` id - `Member` id relation in Web Client. Proba
 
 ```json
 {
-  "method": "UpdateTracks",
+  "method": "SetTracks",
   "payload": {
     "peer_id": 1,
     "tracks": [{
@@ -1205,11 +1200,10 @@ It is recommended to cache `Peer` id - `Member` id relation in Web Client. Proba
 
 ```json
 {
-  "method": "CreatePeer",
+  "method": "SetPeer",
   "payload": {
     "peer": {
       "peer_id": 1,
-      "p2p": false,
       "tracks": [{
         "id": 1,
         "media_type": {
@@ -1233,14 +1227,16 @@ It is recommended to cache `Peer` id - `Member` id relation in Web Client. Proba
       }]
     },
     "sdp_offer": "server_user1_recvonly_offer",
-    "ice_servers": {
-      "urls": [
-        "turn:turnserver.com:3478",
-        "turn:turnserver.com:3478?transport=tcp"
-      ],
-      "username": "turn_user",
-      "credential": "turn_credential"
-    }
+    "ice_servers":[
+        {
+        "urls":[
+          "turn:turnserver.com:3478",
+          "turn:turnserver.com:3478?transport=tcp"
+        ],
+        "username":"turn_user",
+        "credential":"turn_credential"
+        }
+    ]
   }
 }
 ```
@@ -1293,11 +1289,10 @@ It is recommended to cache `Peer` id - `Member` id relation in Web Client. Proba
 
 ```json
 {
-  "method": "CreatePeer",
+  "method": "SetPeer",
   "payload": {
     "peer": {
       "peer_id": 2,
-      "p2p": false,
       "tracks": [{
         "id": 1,
         "media_type": {
@@ -1321,14 +1316,16 @@ It is recommended to cache `Peer` id - `Member` id relation in Web Client. Proba
       }]
     },
     "sdp_offer": "server_user2_sendonly_offer",
-    "ice_servers": {
-      "urls": [
-        "turn:turnserver.com:3478",
-        "turn:turnserver.com:3478?transport=tcp"
-      ],
-      "username": "turn_user",
-      "credential": "turn_credential"
-    }
+    "ice_servers":[
+        {
+        "urls":[
+          "turn:turnserver.com:3478",
+          "turn:turnserver.com:3478?transport=tcp"
+        ],
+        "username":"turn_user",
+        "credential":"turn_credential"
+        }
+    ]
   }
 }
 ```
@@ -1382,7 +1379,7 @@ It is recommended to cache `Peer` id - `Member` id relation in Web Client. Proba
 
 ```json
 {
-  "method": "UpdateTracks",
+  "method": "SetTracks",
   "payload": {
     "peer_id": 1,
     "tracks": [{
@@ -1425,11 +1422,10 @@ It is recommended to cache `Peer` id - `Member` id relation in Web Client. Proba
 
 ```json
 {
-  "method": "CreatePeer",
+  "method": "SetPeer",
   "payload": {
     "peer": {
       "peer_id": 3,
-      "p2p": false,
       "tracks": [{
         "id": 1,
         "media_type": {
@@ -1453,14 +1449,16 @@ It is recommended to cache `Peer` id - `Member` id relation in Web Client. Proba
       }]
     },
     "sdp_offer": "server_user3_sendonly_offer",
-    "ice_servers": {
-      "urls": [
-        "turn:turnserver.com:3478",
-        "turn:turnserver.com:3478?transport=tcp"
-      ],
-      "username": "turn_user",
-      "credential": "turn_credential"
-    }
+    "ice_servers":[
+        {
+        "urls":[
+          "turn:turnserver.com:3478",
+          "turn:turnserver.com:3478?transport=tcp"
+        ],
+        "username":"turn_user",
+        "credential":"turn_credential"
+        }
+    ]
   }
 }
 ```
@@ -1515,7 +1513,7 @@ It is recommended to cache `Peer` id - `Member` id relation in Web Client. Proba
 
 ```json
 {
-  "method": "UpdateTracks",
+  "method": "SetTracks",
   "payload": {
     "peer_id": 1,
     "tracks": [{

From b25524342f62e83f738ca7638363205941db5618 Mon Sep 17 00:00:00 2001
From: alexlapa <lapa.alex@ex.ua>
Date: Thu, 27 Dec 2018 12:20:02 -0500
Subject: [PATCH 11/24] events

---
 docs/rfc/0002-webrc-client-api.md | 230 +++++++++++++-----------------
 1 file changed, 100 insertions(+), 130 deletions(-)

diff --git a/docs/rfc/0002-webrc-client-api.md b/docs/rfc/0002-webrc-client-api.md
index d20e54e5c..6b12c9d26 100644
--- a/docs/rfc/0002-webrc-client-api.md
+++ b/docs/rfc/0002-webrc-client-api.md
@@ -73,25 +73,7 @@ Although, signalling can be implemented on top of any transport, WebSocket suits
 Existing best practices are recommended for final implementation:
 1. Message level `ping`/`pong`, since it is the most reliable way to detect connection loss (protocol level WebSocket `ping`/`pong` may disfunct due to browser implementation and is not exposed to `Web Client`).
 2. Reconnects, since [RTCPeerConnection] always outlives WebSocket connection in cases of network issues, and both parts should know when to dispose related resources.
-3. Share common identifier across multiple messages, so each part will receive answers to all request sent, and be able to know if request was processed correctly or caused some kind of error.
-4. Using custom Close Frame Status Codes, to implement reliable send-and-close.
-
-Each message could be represented as:
-
-```rust
-struct WsMessage<T> {
-    id: i64,
-    payload: Option<Result<Payload<T>, Error>>,
-}
-
-struct Payload<T> {
-    method: String,
-    params: T,
-}
-```
-
-Each message requires answer. Answer can carry some payload (e.g. answering with [SDP Answer] to [SDP Offer]), error, or just noting, which just means that message reached destination and was processed.
-
+3. Using custom Close Frame Status Codes, to implement reliable send-and-close.
 
 ### Signalling Protocol considerations
 [signalling-protocol-considerations]: #signalling-protocol-considerations
@@ -112,7 +94,11 @@ So API can be divided in two categories:
 
 Current RFC offers combining both ways: everything will be configured automagically, but dynamic API is always there if you need it.
 
+All WS messages sent by `Server` are called `Events`. `Event` means a fact that already has happened, so client cannot reject `Event` in any way (you cannot reject the happened past), it can only adopt itself to the received `Events`. So, `Server` just notifies `Client` about happened facts and `Clients` reacts on them to make the proper state. This also emphasizes the indisputable authority of the `Server`.
+The naming for `Events` follows the convention `<entity><passive-verb>`, for example: `PeerCreated`, `TracksApplied`, `PeersRemoved`.
 
+All WS messages sent by `Client` are called `Commands`. `Command` is basically a request/desire/intention of client to change the state on `Server`.
+The naming for `Commands` follows the convention `<infinitive-verb><entity>`, for example: `TracksApplied`, `MakeSdpOffer`, `MakeSdpAnswer`.
 
 
 ## Reference-level explanation
@@ -196,10 +182,14 @@ struct VideoSettings {}
 
 ### Methods
 
-#### 1. SetPeer
+### Events
+
+I.e. `Server` => `Client` requests.
+
+#### 1. PeerCreated
 
 ```rust
-struct SetPeer {
+struct PeerCreated {
     peer: Peer,
     sdp_offer: Option<String>,
     ice_servers: Vec<ICEServer>,
@@ -227,7 +217,7 @@ The most important part of `Peer` object is list of tracks. All `TrackDirection:
 ##### Examples
 
 <details>
-<summary>Create Audio+Video sendrecv p2p Peer</summary>
+<summary>Create Audio+Video sendrecv Peer</summary>
 
 ```json
 {
@@ -295,7 +285,7 @@ Client is expected to:
 3. Add newly created tracks to [RTCPeerConnection].
 4. Create `sendrecv` [SDP Offer].
 5. Set offer as peers local description.
-6. Answer `SetPeer` request with `Offer` request containing [SDP Offer].
+6. Answer `PeerCreated` request with `Offer` request containing [SDP Offer].
 7. Expect remote [SDP Answer] to set it as remote description.
 
 After negotiation is done and media starts flowing, the client might receive notification that his media is being sent to `Peer { peer_id = 2 }`, and he is receiving media from `Peer { peer_id = 2 }`.
@@ -341,31 +331,26 @@ Client is expected to:
 4. Set provided offer as peers remote description.
 5. Create `sendonly` [SDP Answer].
 6. Set created [SDP Answer] as local description.
-7. Answer `SetPeer` request with `Answer` request containing [SDP Offer]. 
+7. Answer `PeerCreated` request with `Answer` request containing [SDP Offer]. 
 
 After negotiation is done and media starts flowing, client might receive notification that his media is being sent to server.
 </details>
 
-#### 2. RemovePeers
+#### 2. PeersRemoved
 
 ```rust
-struct RemovePeers {
+struct PeersRemoved {
     peer_ids: Vec<u64>,
 }
 ```
 
-Server's/Client's request to dispose (close) specified `Peers`.
-
-If Server => Client, then Client must dispose specified `Peers`.
+`Server` requests to dispose (close) specified `Peers`.
 
-If Client => Server, then Client requests Server's permission to dispose specified `Peers`. Server may give permission in answer.
-
-Probably, Server will always give his permission on any Client's request. This kind of request flow will allow Server to do any request related stuff that Server needs to do, and distinguish between abnormal and normal events.
 
 ##### Examples
 
 <details>
-<summary>Server tells client to dispose specified Peers / Client requests Server's permission to dispose specified Peers</summary>
+<summary>Server tells Client to dispose specified Peers</summary>
 
 ```json
 {
@@ -374,26 +359,22 @@ Probably, Server will always give his permission on any Client's request. This k
 ```
 </details>
 
-#### 3. SetTracks
+#### 3. TracksApplied
 
 ```rust
-struct SetTracks {
+struct TracksApplied {
     peer_id: u64,
     tracks: Vec<Track>,
 }
 ```
 
-Server's/Client's request to update tracks in specified `Peer`.
+`Server` requests to update tracks in specified `Peer`.
 
-If Server => Client, then it can be used to:
+It can be used to:
 1. Add new track.
 2. Update existing track settings (e.g. change to lower video resolution, mute audio).
 3. Update send track receivers list (add/remove).
 
-If Client => Server, then it can be used to express Clients intentions to:
-1. Update existing track settings.
-2. Cancel sending media to specific receiver (only remove).
-
 ##### Examples 
 
 <details>
@@ -432,8 +413,6 @@ Meaning that media is being published to server but has no actual receivers.
 <details>
 <summary>Server notifies Client that video is being received by other Peer {peer_id = 2}</summary>
 
-Server => Client
-
 ```json
 {
   "peer_id": 1,
@@ -462,58 +441,21 @@ Server => Client
 ```
 </details>
 
-<details>
-<summary>Client wants to unsubscribe Peer {peer_id = 2} from specified track</summary>
-
-Client => Server
-
-```json
-{
-  "peer_id": 1,
-  "tracks": [{
-    "id": 1,
-    "media_type": {
-      "Audio": {}
-    },
-    "direction": {
-      "Send": {
-        "receivers": []
-      }
-    }
-  }, {
-    "id": 2,
-    "media_type": {
-      "Video": {}
-    },
-    "direction": {
-      "Send": {
-        "receivers": []
-      }
-    }
-  }]
-}
-```
-</details>
-
-#### 4. RemoveTracks
+#### 4. TracksRemoved
 
 ```rust
-struct RemoveTracks {
+struct TracksRemoved {
     peer_id: u64,
     tracks: Vec<u64>,
 }
 ```
 
-Server's/Client's request to dispose (close) specified `Tracks`.
-
-If Server => Client, then Client must dispose (stop and remove).
-
-If Client => Server, then Client requests Server's permission to dispose specified `Peers`.
+`Server` requests to dispose (close) specified `Tracks`.
 
 ##### Examples
 
 <details>
-<summary>Server tells client to dispose specified Tracks / Client requests Server's permission to dispose specified Tracks</summary>
+<summary>Server tells client to dispose specified Tracks</summary>
 
 ```json
 {
@@ -523,29 +465,21 @@ If Client => Server, then Client requests Server's permission to dispose specifi
 ```
 </details>
 
-#### 5. Offer
+#### 5. SdpOfferMade
 
 ```rust
-struct Offer {
+struct SdpOfferMade {
     peer_id: u64,
     sdp_offer: String,
 }
 ```
 
-Server's / Client's [SDP Offer] sent during SDP negotiation between peers.
-
-Client can send it:
-1. As answer to `SetPeer {sdp_offer: None}`
-2. As answer to `SetTracks` if update requires SDP renegotiation.
-
-Server can send it:
-1. If server triggers renegotiation.
-2. Retransmission from peer that triggered renegotiation.
+`Server` applies [SDP Offer] to `Client`s [RTCPeerConnection]. Being sent during SDP negotiation/renegotiation.
 
 ##### Examples
 
 <details>
-<summary>Client sends Peers SDP Offer</summary>
+<summary>Server sends SDP Offer to Peer {peer_id = 1}</summary>
 
 ```json
 {
@@ -555,27 +489,21 @@ Server can send it:
 ```
 </details>
 
-#### 6. Answer
+#### 6. SdpAnswerMade
 
 ```rust
-struct Answer {
+struct SdpAnswerMade {
     peer_id: u64,
     sdp_answer: String,
 }
 ```
 
-Server's / Client's [SDP Answer] sent during SDP negotiation between peers.
-
-Client can send it:
-1. As answer to `SetPeer {sdp_offer: Some}`.
-2. As answer to `Offer`.
-
-Server can send it only as answer to `Offer`.
+`Server` applies [SDP Offer] to `Client`s [RTCPeerConnection]. Being sent during SDP negotiation/renegotiation.
 
 #### Examples
 
 <details>
-<summary>Client sends Peers SDP Answer</summary>
+<summary>Server sends SDP Offer to Peer {peer_id = 1}</summary>
 
 ```json
 {
@@ -586,23 +514,34 @@ Server can send it only as answer to `Offer`.
 </details>
 
 
-#### 7. Candidate
+#### 7. IceCandidatesDiscovered
 
 ```rust
-struct Candidate {
+struct IceCandidatesDiscovered {
     peer_id: u64,
     candidate: String,
 }
 ```
 
-Server's / Client's [ICE Candidate] sent during ICE negotiation.
+`Server` applies [ICE Candidate] to `Client`s [RTCPeerConnection]. Being sent during ICE negotiation/renegotiation.
 
-Just send each [ICE Candidate] discovered by underlying [RTCPeerConnection] to remote `Peer`. It's as simple as that.
+#### Examples
 
-#### 8. RemotePeers
+<details>
+<summary>Server sends ICE Candidate to Peer {peer_id = 1}</summary>
+
+```json
+{
+  "peer_id": 1,
+  "candidate": "ice_cadidate"
+}
+```
+</details>
+
+#### 8. RemotePeersUpdated
 
 ```rust
-struct RemotePeers {
+struct RemotePeersUpdated {
     peers: Vec<RemotePeer>
 }
 ```
@@ -689,6 +628,39 @@ Params:
 ```
 </details>
 
+#### 9. MembersUpdated 
+
+```rust
+struct Members {
+    members: Vec<Member>
+}
+```
+
+`Server` updates `Client`s acknowledgement of `Peer`-`Member` associations. It is recommended to cache `Peer` id - `Member` id relation in Web Client. Probably, in two maps: `HashMap<peer_id, member_id>`, `HashMap<member_id, peer_id>`.
+
+#### Examples
+
+<details>
+<summary>Server updates Clients acknowledgement of Peer-Member associations</summary>
+
+```json
+{
+  "members": [{
+    "member_id": "user_2",
+    "peers": [ 1 ]
+  }, {
+    "member_id": "user_2",
+    "peers": [ 2 ]
+  }, {
+    "member_id": "user_3",
+    "peers": [ 3, 4 ]
+  }]
+}
+```
+</details>
+
+#### Commands
+
 #### 8. RequestRemoteTracks
 
 ```rust
@@ -783,8 +755,6 @@ struct Members {
 
 Server provides `Member`'s list according to user request.
 
-It is recommended to cache `Peer` id - `Member` id relation in Web Client. Probably, in two maps: `HashMap<peer_id, member_id>`, `HashMap<member_id, peer_id>`.
-
 ##### Examples
 
 <details>
@@ -830,11 +800,11 @@ It is recommended to cache `Peer` id - `Member` id relation in Web Client. Proba
 '-------------'    '-<--<--<--' '-------------'
 ```
 
-1\. Server send `SetPeer` to `user1`:
+1\. Server send `PeerCreated` to `user1`:
 
 ```json
 {
-  "method": "SetPeer",
+  "method": "PeerCreated",
   "payload": {
     "peer": {
       "peer_id": 1,
@@ -907,11 +877,11 @@ It is recommended to cache `Peer` id - `Member` id relation in Web Client. Proba
 }
 ```
  
-3\. Server send `SetPeer` with `user1`'s [SDP Offer] to `user2`:
+3\. Server send `PeerCreated` with `user1`'s [SDP Offer] to `user2`:
 
 ```json
 {
-  "method": "SetPeer",
+  "method": "PeerCreated",
   "payload": {
     "peer": {
       "peer_id": 2,
@@ -1014,11 +984,11 @@ It is recommended to cache `Peer` id - `Member` id relation in Web Client. Proba
 '-------------'    '-<--<--<--' '-------------'
 ```
 
-7\. `user1` wants to unpublish his tracks, so he sends `RemoveTracks` to the server:
+7\. `user1` wants to unpublish his tracks, so he sends `TracksRemoved` to the server:
 
 ```json
 {
-  "method": "RemoveTracks",
+  "method": "TracksRemoved",
   "payload": {
     "peer_id": 1,
     "tracks": [1, 2]
@@ -1030,7 +1000,7 @@ It is recommended to cache `Peer` id - `Member` id relation in Web Client. Proba
 
 ```json
 {
-  "method": "RemoveTracks",
+  "method": "TracksRemoved",
   "payload": {
     "peer_id": 2,
     "tracks": [1, 2]
@@ -1038,7 +1008,7 @@ It is recommended to cache `Peer` id - `Member` id relation in Web Client. Proba
 }
 ```
 
-9\. Server approves `user1` `RemoveTracks` request.
+9\. Server approves `user1` `TracksRemoved` request.
 
 10\. `user1` initiates SDP renegotiation:
 
@@ -1073,7 +1043,7 @@ It is recommended to cache `Peer` id - `Member` id relation in Web Client. Proba
 
 ```json
 {
-  "method": "RemotePeers",
+  "method": "RemotePeersUpdated",
   "payload": {
     "peers": [{
       "peer_id": 1,
@@ -1113,7 +1083,7 @@ It is recommended to cache `Peer` id - `Member` id relation in Web Client. Proba
 
 ```json
 {
-  "method": "SetTracks",
+  "method": "TracksApplied",
   "payload": {
     "peer_id": 2,
     "tracks": [{
@@ -1145,7 +1115,7 @@ It is recommended to cache `Peer` id - `Member` id relation in Web Client. Proba
 
 ```json
 {
-  "method": "SetTracks",
+  "method": "TracksApplied",
   "payload": {
     "peer_id": 1,
     "tracks": [{
@@ -1200,7 +1170,7 @@ It is recommended to cache `Peer` id - `Member` id relation in Web Client. Proba
 
 ```json
 {
-  "method": "SetPeer",
+  "method": "PeerCreated",
   "payload": {
     "peer": {
       "peer_id": 1,
@@ -1289,7 +1259,7 @@ It is recommended to cache `Peer` id - `Member` id relation in Web Client. Proba
 
 ```json
 {
-  "method": "SetPeer",
+  "method": "PeerCreated",
   "payload": {
     "peer": {
       "peer_id": 2,
@@ -1379,7 +1349,7 @@ It is recommended to cache `Peer` id - `Member` id relation in Web Client. Proba
 
 ```json
 {
-  "method": "SetTracks",
+  "method": "TracksApplied",
   "payload": {
     "peer_id": 1,
     "tracks": [{
@@ -1422,7 +1392,7 @@ It is recommended to cache `Peer` id - `Member` id relation in Web Client. Proba
 
 ```json
 {
-  "method": "SetPeer",
+  "method": "PeerCreated",
   "payload": {
     "peer": {
       "peer_id": 3,
@@ -1513,7 +1483,7 @@ It is recommended to cache `Peer` id - `Member` id relation in Web Client. Proba
 
 ```json
 {
-  "method": "SetTracks",
+  "method": "TracksApplied",
   "payload": {
     "peer_id": 1,
     "tracks": [{

From 1aa4fe56ca935eb731bbd4aec63735ab491ecd50 Mon Sep 17 00:00:00 2001
From: alexlapa <lapa.alex@ex.ua>
Date: Thu, 27 Dec 2018 14:00:09 -0500
Subject: [PATCH 12/24] commands

---
 docs/rfc/0002-webrc-client-api.md | 231 ++++++++++++++++++++++++++++--
 1 file changed, 222 insertions(+), 9 deletions(-)

diff --git a/docs/rfc/0002-webrc-client-api.md b/docs/rfc/0002-webrc-client-api.md
index 6b12c9d26..c7672c3dc 100644
--- a/docs/rfc/0002-webrc-client-api.md
+++ b/docs/rfc/0002-webrc-client-api.md
@@ -659,9 +659,222 @@ struct Members {
 ```
 </details>
 
-#### Commands
+### Commands
 
-#### 8. RequestRemoteTracks
+I.e. `Client` => `Server` requests.
+
+#### 1. RemovePeers
+
+```rust
+struct RemovePeers {
+    peer_ids: Vec<u64>,
+}
+```
+
+`Client` requests `Server` permission to dispose specified `Peers`. Server may give permission by sending `PeersRemoved`.
+
+Probably, Server will always give his permission on any Client's request. This kind of request flow will allow Server to do any request related stuff that Server needs to do, and distinguish between abnormal and normal events.
+
+##### Examples
+
+<details>
+<summary>Client requests Server permission to dispose specified Peers</summary>
+
+```json
+{
+  "peer_ids": [1, 2, 3]
+}
+```
+</details>
+
+#### 2. SetTracks
+
+```rust
+struct SetTracks {
+    peer_id: u64,
+    tracks: Vec<Track>,
+}
+```
+
+`Client` requests to update tracks in specified `Peer`.
+
+It can be used to express Clients intentions to:
+1. Update existing track settings.
+2. Cancel sending media to specific receiver.
+
+##### Examples 
+
+<details>
+<summary>Assuming such Peer exists on Client's end</summary>
+
+```json
+{
+  "peer_id": 1,
+  "tracks": [{
+    "id": 1,
+    "media_type": {
+      "Audio": {}
+    },
+    "direction": {
+      "Send": {
+        "receivers": [2]
+      }
+    }
+  }, {
+    "id": 2,
+    "media_type": {
+      "Video": {}
+    },
+    "direction": {
+      "Send": {
+        "receivers": [2]
+      }
+    }
+  }]
+}
+```
+
+Meaning that media is being published to server and relayed to Peer {peer_id = 2}.
+</details>
+
+<details>
+<summary>Client wants to unsubscribe Peer {peer_id = 2} from specified tracks</summary>
+
+Client => Server
+
+```json
+{
+  "peer_id": 1,
+  "tracks": [{
+    "id": 1,
+    "media_type": {
+      "Audio": {}
+    },
+    "direction": {
+      "Send": {
+        "receivers": []
+      }
+    }
+  }, {
+    "id": 2,
+    "media_type": {
+      "Video": {}
+    },
+    "direction": {
+      "Send": {
+        "receivers": []
+      }
+    }
+  }]
+}
+```
+</details>
+
+#### 3. RemoveTracks
+
+```rust
+struct RemoveTracks {
+    peer_id: u64,
+    tracks: Vec<u64>,
+}
+```
+
+`Client` requests `Server` permission to dispose specified `Peers`.
+
+##### Examples
+
+<details>
+<summary>Client requests Server's permission to dispose specified Tracks</summary>
+
+```json
+{
+  "peer_id": 1,
+  "tracks": [1, 2]
+}
+```
+</details>
+
+#### 4. MakeSdpOffer
+
+```rust
+struct MakeSdpOffer {
+    peer_id: u64,
+    sdp_offer: String,
+}
+```
+
+Client sends [SDP Offer] from one if its `Peers`.
+
+Client can send it:
+1. As answer to `PeerCreated {sdp_offer: None}`
+2. As answer to `TracksApplied` if update requires SDP renegotiation.
+
+##### Examples
+
+<details>
+<summary>Client sends Peers SDP Offer</summary>
+
+```json
+{
+  "peer_id": 1,
+  "sdp_offer": "sdp_offer_body"
+}
+```
+</details>
+
+#### 5. MakeSDPAnswer
+
+```rust
+struct MakeSDPAnswer {
+    peer_id: u64,
+    sdp_answer: String,
+}
+```
+
+Client sends [SDP Answer] from one if its `Peers`.
+
+Client can send it:
+1. As answer to `PeerCreated {sdp_offer: Some}`.
+2. As answer to `SdpOfferMade`.
+
+#### Examples
+
+<details>
+<summary>Client sends Peers SDP Answer</summary>
+
+```json
+{
+  "peer_id": 1,
+  "sdp_offer": "sdp_answer_body"
+}
+```
+</details>
+
+#### 6. SetIceCandidate
+
+```rust
+struct SetIceCandidate {
+    peer_id: u64,
+    candidate: String,
+}
+```
+
+Client sends [ICE Candidate] discovered by underlying [RTCPeerConnection] of one of his `Peers`.
+
+#### Examples
+
+<details>
+<summary>Client sends ICE Candidate from Peer {peer_id = 1}</summary>
+
+```json
+{
+  "peer_id": 1,
+  "candidate": "ice_cadidate"
+}
+```
+</details>
+
+#### 7. RequestRemoteTracks
 
 ```rust
 struct RequestRemoteTracks {
@@ -689,15 +902,15 @@ enum RemotePeerTrackType {
 }
 ```
 
-Client requests to send or receive media to/from remote peer.
+Client requests to send or receive media to/from remote `Peer`.
 
 Params:
-1. ```peer_id```: if `Some` then Client wants to connect specified local `Peer` to remote. If `None`then it us to server
+1. `peer_id`: if `Some` then Client wants to connect specified local `Peer` to remote. If `None`then it us to server
 to decide which of Client's `Peers` will be connected.
-2. ```remote_peer_id```: if `Some`, then represents specific remote `Member` associated with some . If `None`, then 
+2. `remote_peer_id`: if `Some`, then represents specific remote `Member` associated with some . If `None`, then 
 represents Server's peer connection (only SFU).
-3. ```rx```: if `Some` then Client requests to subscribe to specified media.
-4. ```tx```: if `Some` then Client requests to publish specified media to remote `Peer`.
+3. `rx`: if `Some` then Client requests to subscribe to specified media.
+4. `tx`: if `Some` then Client requests to publish specified media to remote `Peer`.
 
 ##### Examples
 
@@ -737,10 +950,10 @@ represents Server's peer connection (only SFU).
 ```
 </details>
 
-#### 9. GetMembers, Members
+#### 9. RequestMembers
 
 ```rust
-struct GetMembers {
+struct RequestMembers {
     peer_ids: Vec<u64>,
 }
 ```

From a78d2a34bc2f442fc5e798a54b2405fa8a43c960 Mon Sep 17 00:00:00 2001
From: alexlapa <lapa.alex@ex.ua>
Date: Thu, 27 Dec 2018 14:38:33 -0500
Subject: [PATCH 13/24] update examples

---
 docs/rfc/0002-webrc-client-api.md | 96 ++++++++++++++++++++++---------
 1 file changed, 68 insertions(+), 28 deletions(-)

diff --git a/docs/rfc/0002-webrc-client-api.md b/docs/rfc/0002-webrc-client-api.md
index c7672c3dc..3ce0a1fe8 100644
--- a/docs/rfc/0002-webrc-client-api.md
+++ b/docs/rfc/0002-webrc-client-api.md
@@ -550,8 +550,8 @@ Related objects:
 
 ```rust
 struct RemotePeer {
-    remote_peer_id: Option<u64>,
-    remote_member_id: Option<String>,
+    peer_id: Option<u64>,
+    member_id: Option<String>,
     can_rx: Option<RemotePeerTrackType>,
     can_tx: Option<RemotePeerTrackType>,
 }
@@ -573,8 +573,8 @@ enum RemotePeerTrackType {
 Server notifies Client of any remote peers that Client can connect to. This is a key method when talking about Dynamic API mentioned in [Signalling Protocol considerations][signalling-protocol-considerations]. Any Client's request to subscribe/publish will be based on data provided by this request.
 
 Params:
-1. ```remote_peer_id```: if `Some`, then represents specific remote `Peer` associated with some `Member`. If `None`, then represents Servers peer connection.
-2. ```remote_member_id```: if `Some`, then represents specific remote `Member` associated with some . If `None`, then represents Servers peer connection.
+1. ```peer_id```: if `Some`, then represents specific remote `Peer` associated with some `Member`. If `None`, then represents Servers peer connection.
+2. ```member_id```: if `Some`, then represents specific remote `Member` associated with some . If `None`, then represents Servers peer connection.
 3. ```can_rx```: if `Some` then Client can subscribe to specified media.
 4. ```can_tx```: if `Some` then Client can publish specified media to remote `Peer`.
 
@@ -1082,7 +1082,7 @@ Server provides `Member`'s list according to user request.
 
 ```json
 {
-  "method": "Offer",
+  "method": "MakeSdpOffer",
   "payload": {
     "peer_id": 1,
     "sdp_offer": "user1_sendrecv_offer"
@@ -1159,7 +1159,7 @@ Server provides `Member`'s list according to user request.
 
 ```json
 {
-  "method": "Answer",
+  "method": "MakeSDPAnswer",
   "payload": {
     "peer_id": 2,
     "sdp_answer": "user2_sendrecv_answer"
@@ -1169,9 +1169,10 @@ Server provides `Member`'s list according to user request.
 
 5\. Both peers exchange discovered [ICE Candidate]'s:
 
+`user1` => `Server`
 ```json
 {
-  "method": "Candidate",
+  "method": "SetIceCandidate",
   "payload": {
     "peer_id": 1,
     "candidate": "user1_ice_candidate"
@@ -1179,9 +1180,10 @@ Server provides `Member`'s list according to user request.
 }
 ```
 
+`Server` => `user2`
 ```json
 {
-  "method": "Candidate",
+  "method": "IceCandidatesDiscovered",
   "payload": {
     "peer_id": 2,
     "candidate": "user1_ice_candidate"
@@ -1189,6 +1191,28 @@ Server provides `Member`'s list according to user request.
 }
 ```
 
+`user2` => `Server`
+```json
+{
+  "method": "SetIceCandidate",
+  "payload": {
+    "peer_id": 2,
+    "candidate": "user2_ice_candidate"
+  }
+}
+```
+
+`Server` => `user1`
+```json
+{
+  "method": "IceCandidatesDiscovered",
+  "payload": {
+    "peer_id": 1,
+    "candidate": "user2_ice_candidate"
+  }
+}
+```
+
 6\. At this point connection is supposed to be established:
 
 ```
@@ -1201,7 +1225,7 @@ Server provides `Member`'s list according to user request.
 
 ```json
 {
-  "method": "TracksRemoved",
+  "method": "RemoveTracks",
   "payload": {
     "peer_id": 1,
     "tracks": [1, 2]
@@ -1221,9 +1245,19 @@ Server provides `Member`'s list according to user request.
 }
 ```
 
-9\. Server approves `user1` `TracksRemoved` request.
+9\. Server updates `user1` tracks:
 
-10\. `user1` initiates SDP renegotiation:
+```json
+{
+  "method": "TracksRemoved",
+  "payload": {
+    "peer_id": 1,
+    "tracks": [1, 2]
+  }
+}
+```
+
+10\. `user1` initiates SDP re-negotiation: `user1` sends `MakeSdpOffer`, `Server` relays `SdpOfferMade` to `user2`, `user2` sends `MakeSDPAnswer`, `Server` relays `SdpAnswerMade` to `user1`.
 
 ```
 .----user1----.         .----user2----.
@@ -1235,7 +1269,7 @@ Server provides `Member`'s list according to user request.
 
 ```json
 {
-  "method": "RemotePeer",
+  "method": "RemotePeersUpdated",
   "payload": {
     "peers": [{
       "peer_id": 2,
@@ -1356,7 +1390,7 @@ Server provides `Member`'s list according to user request.
 }
 ```
 
-16\. SDP re-negotiation:
+16\. SDP re-negotiation: `user1` sends `MakeSdpOffer`, `Server` relays `SdpOfferMade` to `user2`, `user2` sends `MakeSDPAnswer`, `Server` relays `SdpAnswerMade` to `user1`.
 
 ```
 .----user1----.    .->-->-->--. .----user2----.
@@ -1428,7 +1462,7 @@ Server provides `Member`'s list according to user request.
 
 ```json
 {
-  "method": "Answer",
+  "method": "MakeSDPAnswer",
   "payload": {
     "peer_id": 1,
     "sdp_answer": "user_1_sendonly_answer"
@@ -1438,9 +1472,10 @@ Server provides `Member`'s list according to user request.
 
 3\. Server and `user1` exchange [ICE Candidate]s:
 
+`user1` => `Server`
 ```json
 {
-  "method": "Candidate",
+  "method": "SetIceCandidate",
   "payload": {
     "peer_id": 1,
     "candidate": "user1_ice_candidate"
@@ -1448,12 +1483,13 @@ Server provides `Member`'s list according to user request.
 }
 ```
 
+`Server` => `user1`
 ```json
 {
-  "method": "Candidate",
+  "method": "IceCandidatesDiscovered",
   "payload": {
     "peer_id": 1,
-    "candidate": "servers_ice_candidate"
+    "candidate": "server_ice_candidate"
   }
 }
 ```
@@ -1517,7 +1553,7 @@ Server provides `Member`'s list according to user request.
 
 ```json
 {
-  "method": "Answer",
+  "method": "MakeSDPAnswer",
   "payload": {
     "peer_id": 2,
     "sdp_answer": "user_2_recvonly_answer"
@@ -1527,22 +1563,24 @@ Server provides `Member`'s list according to user request.
 
 7\. Server and `user2` exchange [ICE Candidate]s:
 
+`user2` => `Server`
 ```json
 {
-  "method": "Candidate",
+  "method": "SetIceCandidate",
   "payload": {
     "peer_id": 2,
-    "candidate": "user1_ice_candidate"
+    "candidate": "user2_ice_candidate"
   }
 }
 ```
 
+`Server` => `user2`
 ```json
 {
-  "method": "Candidate",
+  "method": "IceCandidatesDiscovered",
   "payload": {
     "peer_id": 2,
-    "candidate": "servers_ice_candidate"
+    "candidate": "server_ice_candidate"
   }
 }
 ```
@@ -1582,7 +1620,7 @@ Server provides `Member`'s list according to user request.
       },
       "direction": {
         "Send": {
-          "receivers": [2]
+          "receivers": [ 2 ]
         }
       }
     }]
@@ -1650,7 +1688,7 @@ Server provides `Member`'s list according to user request.
 
 ```json
 {
-  "method": "Answer",
+  "method": "MakeSDPAnswer",
   "payload": {
     "peer_id": 3,
     "sdp_answer": "user_3_recvonly_answer"
@@ -1660,22 +1698,24 @@ Server provides `Member`'s list according to user request.
 
 13\. Server and `user3` exchange [ICE Candidate]s:
 
+`user3` => `Server`
 ```json
 {
-  "method": "Candidate",
+  "method": "SetIceCandidate",
   "payload": {
     "peer_id": 3,
-    "candidate": "user1_ice_candidate"
+    "candidate": "user3_ice_candidate"
   }
 }
 ```
 
+`Server` => `user3`
 ```json
 {
-  "method": "Candidate",
+  "method": "IceCandidatesDiscovered",
   "payload": {
     "peer_id": 3,
-    "candidate": "servers_ice_candidate"
+    "candidate": "server_ice_candidate"
   }
 }
 ```

From 1a275637846f8b165befca3c6fd32e5375b3b8f1 Mon Sep 17 00:00:00 2001
From: alexlapa <lapa.alex@ex.ua>
Date: Thu, 27 Dec 2018 15:14:28 -0500
Subject: [PATCH 14/24] corrections

---
 docs/rfc/0002-webrc-client-api.md | 62 ++++++++++---------------------
 1 file changed, 19 insertions(+), 43 deletions(-)

diff --git a/docs/rfc/0002-webrc-client-api.md b/docs/rfc/0002-webrc-client-api.md
index 3ce0a1fe8..02a85cf8c 100644
--- a/docs/rfc/0002-webrc-client-api.md
+++ b/docs/rfc/0002-webrc-client-api.md
@@ -26,7 +26,7 @@ You will need to express ways to:
 4. Pass some user metadata to hook business logic onto.
 5. Build more complex connection graphs.
 6. Dynamically cancel/begin media publishing/receiving.
-7. Passing errors, [RTCPeerConnection]s, [RTCStatsReport]s.
+7. Passing errors, [RTCPeerConnection]s [RTCStatsReport]s.
 8. Cover both [p2p full mesh] and [hub server (SFU, MCU)] scenarios.
 
 The protocol must be versatile enough to cover all possible use cases.
@@ -166,8 +166,12 @@ struct Track {
 }
 
 enum TrackDirection {
-    Send(Vec<u64>),     // receiver peers
-    Recv(u64),          // sender peer
+    Send {
+      receivers: Vec<u64>,
+    },
+    Recv {
+      sender: u64,
+    }, 
 }
 
 enum TrackMediaType {
@@ -285,7 +289,7 @@ Client is expected to:
 3. Add newly created tracks to [RTCPeerConnection].
 4. Create `sendrecv` [SDP Offer].
 5. Set offer as peers local description.
-6. Answer `PeerCreated` request with `Offer` request containing [SDP Offer].
+6. Answer `PeerCreated` request with `MakeSdpOffer` request containing [SDP Offer].
 7. Expect remote [SDP Answer] to set it as remote description.
 
 After negotiation is done and media starts flowing, the client might receive notification that his media is being sent to `Peer { peer_id = 2 }`, and he is receiving media from `Peer { peer_id = 2 }`.
@@ -331,7 +335,7 @@ Client is expected to:
 4. Set provided offer as peers remote description.
 5. Create `sendonly` [SDP Answer].
 6. Set created [SDP Answer] as local description.
-7. Answer `PeerCreated` request with `Answer` request containing [SDP Offer]. 
+7. Answer `PeerCreated` request with `MakeSdpAnswer` request containing [SDP Answer]. 
 
 After negotiation is done and media starts flowing, client might receive notification that his media is being sent to server.
 </details>
@@ -455,7 +459,7 @@ struct TracksRemoved {
 ##### Examples
 
 <details>
-<summary>Server tells client to dispose specified Tracks</summary>
+<summary>Server tells Client to dispose specified Tracks</summary>
 
 ```json
 {
@@ -474,7 +478,7 @@ struct SdpOfferMade {
 }
 ```
 
-`Server` applies [SDP Offer] to `Client`s [RTCPeerConnection]. Being sent during SDP negotiation/renegotiation.
+`Server` applies [SDP Offer] to `Client`s [RTCPeerConnection]. Being sent during SDP negotiation/re-negotiation.
 
 ##### Examples
 
@@ -498,7 +502,7 @@ struct SdpAnswerMade {
 }
 ```
 
-`Server` applies [SDP Offer] to `Client`s [RTCPeerConnection]. Being sent during SDP negotiation/renegotiation.
+`Server` applies [SDP Answer] to `Client`s [RTCPeerConnection]. Being sent during SDP negotiation/re-negotiation.
 
 #### Examples
 
@@ -523,7 +527,7 @@ struct IceCandidatesDiscovered {
 }
 ```
 
-`Server` applies [ICE Candidate] to `Client`s [RTCPeerConnection]. Being sent during ICE negotiation/renegotiation.
+`Server` applies [ICE Candidate] to `Client`s [RTCPeerConnection]. Being sent during ICE negotiation/re-negotiation.
 
 #### Examples
 
@@ -581,7 +585,7 @@ Params:
 #### Examples:
 
 <details>
-<summary>Notify Client that it is possible to subscribe to Member {id = 2} Video and Audio tracks</summary>
+<summary>Notify Client that it is possible to subscribe to Member {id = "User2", peer_id = 2} Video and Audio tracks</summary>
 
 ```json
 {
@@ -696,8 +700,8 @@ struct SetTracks {
 }
 ```
 
-`Client` requests to update tracks in specified `Peer`.
-
+`Client` requests to update tracks in specified `Peer`. Server may give permission by sending `TracksApplied`.
+                                                      
 It can be used to express Clients intentions to:
 1. Update existing track settings.
 2. Cancel sending media to specific receiver.
@@ -779,7 +783,7 @@ struct RemoveTracks {
 }
 ```
 
-`Client` requests `Server` permission to dispose specified `Peers`.
+`Client` requests `Server` permission to dispose specified `Peers`. Server may give permission by sending `TracksRemoved`.
 
 ##### Examples
 
@@ -807,7 +811,7 @@ Client sends [SDP Offer] from one if its `Peers`.
 
 Client can send it:
 1. As answer to `PeerCreated {sdp_offer: None}`
-2. As answer to `TracksApplied` if update requires SDP renegotiation.
+2. As answer to `TracksApplied` if update requires SDP re-negotiation.
 
 ##### Examples
 
@@ -902,7 +906,7 @@ enum RemotePeerTrackType {
 }
 ```
 
-Client requests to send or receive media to/from remote `Peer`.
+Client requests to send or receive media to/from remote `Peer`. Server may give permission by sending `TracksApplied`.
 
 Params:
 1. `peer_id`: if `Some` then Client wants to connect specified local `Peer` to remote. If `None`then it us to server
@@ -960,14 +964,6 @@ struct RequestMembers {
 
 Client requests `Member` IDs.
 
-```rust
-struct Members {
-    members: Vec<Member>
-}
-```
-
-Server provides `Member`'s list according to user request.
-
 ##### Examples
 
 <details>
@@ -982,26 +978,6 @@ Server provides `Member`'s list according to user request.
 ```
 </details>
 
-<details>
-<summary>Server provides Member's that own specified Peers's</summary>
-
-```json
-{
-  "members": [{
-    "member_id": "user_2",
-    "peers": [ 1 ]
-  }, {
-    "member_id": "user_2",
-    "peers": [ 2 ]
-  }, {
-    "member_id": "user_3",
-    "peers": [ 3, 4 ]
-  }]
-}
-```
-</details>
-
-
 ### Extended examples
 
 <details>

From 5f6b80e0b116f36d6b4c98d37577d0733293c191 Mon Sep 17 00:00:00 2001
From: tyranron <tyranron@gmail.com>
Date: Fri, 4 Jan 2019 14:25:01 +0200
Subject: [PATCH 15/24] Style corrections

---
 docs/rfc/0002-webrc-client-api.md | 177 ++++++++++++++----------------
 1 file changed, 83 insertions(+), 94 deletions(-)

diff --git a/docs/rfc/0002-webrc-client-api.md b/docs/rfc/0002-webrc-client-api.md
index 02a85cf8c..cbae4a1ed 100644
--- a/docs/rfc/0002-webrc-client-api.md
+++ b/docs/rfc/0002-webrc-client-api.md
@@ -26,7 +26,7 @@ You will need to express ways to:
 4. Pass some user metadata to hook business logic onto.
 5. Build more complex connection graphs.
 6. Dynamically cancel/begin media publishing/receiving.
-7. Passing errors, [RTCPeerConnection]s [RTCStatsReport]s.
+7. Passing errors, [RTCPeerConnection]s and [RTCStatsReport]s.
 8. Cover both [p2p full mesh] and [hub server (SFU, MCU)] scenarios.
 
 The protocol must be versatile enough to cover all possible use cases.
@@ -75,6 +75,7 @@ Existing best practices are recommended for final implementation:
 2. Reconnects, since [RTCPeerConnection] always outlives WebSocket connection in cases of network issues, and both parts should know when to dispose related resources.
 3. Using custom Close Frame Status Codes, to implement reliable send-and-close.
 
+
 ### Signalling Protocol considerations
 [signalling-protocol-considerations]: #signalling-protocol-considerations
 
@@ -94,13 +95,15 @@ So API can be divided in two categories:
 
 Current RFC offers combining both ways: everything will be configured automagically, but dynamic API is always there if you need it.
 
-All WS messages sent by `Server` are called `Events`. `Event` means a fact that already has happened, so client cannot reject `Event` in any way (you cannot reject the happened past), it can only adopt itself to the received `Events`. So, `Server` just notifies `Client` about happened facts and `Clients` reacts on them to make the proper state. This also emphasizes the indisputable authority of the `Server`.
+All WS messages sent by `Server` are called `Event`s. `Event` means a fact that already has happened, so client cannot reject `Event` in any way (you cannot reject the happened past), it can only adopt itself to the received `Events`. So, `Server` just notifies `Client` about happened facts and `Clients` reacts on them to reach the proper state. This also emphasizes the indisputable authority of the `Server`.  
 The naming for `Events` follows the convention `<entity><passive-verb>`, for example: `PeerCreated`, `TracksApplied`, `PeersRemoved`.
 
-All WS messages sent by `Client` are called `Commands`. `Command` is basically a request/desire/intention of client to change the state on `Server`.
+All WS messages sent by `Client` are called `Commands`. `Command` is basically a request/desire/intention of `Client` to change the state on `Server`.  
 The naming for `Commands` follows the convention `<infinitive-verb><entity>`, for example: `TracksApplied`, `MakeSdpOffer`, `MakeSdpAnswer`.
 
 
+
+
 ## Reference-level explanation
 [reference-level-explanation]: #reference-level-explanation
 
@@ -171,7 +174,7 @@ enum TrackDirection {
     },
     Recv {
       sender: u64,
-    }, 
+    },
 }
 
 enum TrackMediaType {
@@ -184,7 +187,6 @@ struct AudioSettings {}
 struct VideoSettings {}
 ```
 
-### Methods
 
 ### Events
 
@@ -270,16 +272,14 @@ The most important part of `Peer` object is list of tracks. All `TrackDirection:
     }
   ]},
   "sdp_offer": null,
-  "ice_servers":[
-      {
-      "urls":[
-        "turn:turnserver.com:3478",
-        "turn:turnserver.com:3478?transport=tcp"
-      ],
-      "username":"turn_user",
-      "credential":"turn_credential"
-      }
-  ]
+  "ice_servers": [{
+    "urls": [
+      "turn:turnserver.com:3478",
+      "turn:turnserver.com:3478?transport=tcp"
+    ],
+    "username": "turn_user",
+    "credential": "turn_credential"
+  }]
 }
 ```
 
@@ -315,16 +315,14 @@ After negotiation is done and media starts flowing, the client might receive not
     }]
   },
   "sdp_offer": "server_user1_recvonly_offer",
-  "ice_servers":[
-      {
-      "urls":[
-        "turn:turnserver.com:3478",
-        "turn:turnserver.com:3478?transport=tcp"
-      ],
-      "username":"turn_user",
-      "credential":"turn_credential"
-      }
-  ]
+  "ice_servers": [{
+    "urls": [
+      "turn:turnserver.com:3478",
+      "turn:turnserver.com:3478?transport=tcp"
+    ],
+    "username": "turn_user",
+    "credential": "turn_credential"
+  }]
 }
 ```
 
@@ -651,18 +649,19 @@ struct Members {
 {
   "members": [{
     "member_id": "user_2",
-    "peers": [ 1 ]
+    "peers": [1]
   }, {
     "member_id": "user_2",
-    "peers": [ 2 ]
+    "peers": [2]
   }, {
     "member_id": "user_3",
-    "peers": [ 3, 4 ]
+    "peers": [3, 4]
   }]
 }
 ```
 </details>
 
+
 ### Commands
 
 I.e. `Client` => `Server` requests.
@@ -1040,16 +1039,14 @@ Client requests `Member` IDs.
       }]
     },
     "sdp_offer": null,
-    "ice_servers":[
-        {
-        "urls":[
-          "turn:turnserver.com:3478",
-          "turn:turnserver.com:3478?transport=tcp"
-        ],
-        "username":"turn_user",
-        "credential":"turn_credential"
-        }
-    ]
+    "ice_servers": [{
+      "urls": [
+        "turn:turnserver.com:3478",
+        "turn:turnserver.com:3478?transport=tcp"
+      ],
+      "username": "turn_user",
+      "credential": "turn_credential"
+    }]
   }
 }
 ```
@@ -1117,16 +1114,14 @@ Client requests `Member` IDs.
       }]
     },
     "sdp_offer": "user1_sendrecv_offer",
-    "ice_servers":[
-        {
-        "urls":[
-          "turn:turnserver.com:3478",
-          "turn:turnserver.com:3478?transport=tcp"
-        ],
-        "username":"turn_user",
-        "credential":"turn_credential"
-        }
-    ]
+    "ice_servers": [{
+      "urls": [
+        "turn:turnserver.com:3478",
+        "turn:turnserver.com:3478?transport=tcp"
+      ],
+      "username": "turn_user",
+      "credential": "turn_credential"
+    }]
   }
 }
 ```
@@ -1381,11 +1376,11 @@ Client requests `Member` IDs.
 
 ```
                                                        .-------user2------.
-                          .-------SFU-------.    .-->--o      pc_id = 2   :
+                          .-------SFU-------.    .-->--o     pc_id = 2    :
 .------user1------.       :       .---->----o-->-'     '------------------'
-:     pc_id = 1   o-->-->-o--->---:         :
+:    pc_id = 1    o-->-->-o--->---:         :
 '-----------------'       :       '---->----o-->-.     .-------user3------.
-                          '-----------------'    '-->--o      pc_id = 3   :
+                          '-----------------'    '-->--o     pc_id = 3    :
                                                        '------------------'
 ```
 
@@ -1420,16 +1415,14 @@ Client requests `Member` IDs.
       }]
     },
     "sdp_offer": "server_user1_recvonly_offer",
-    "ice_servers":[
-        {
-        "urls":[
-          "turn:turnserver.com:3478",
-          "turn:turnserver.com:3478?transport=tcp"
-        ],
-        "username":"turn_user",
-        "credential":"turn_credential"
-        }
-    ]
+    "ice_servers": [{
+      "urls": [
+        "turn:turnserver.com:3478",
+        "turn:turnserver.com:3478?transport=tcp"
+      ],
+      "username": "turn_user",
+      "credential": "turn_credential"
+    }]
   }
 }
 ```
@@ -1475,7 +1468,7 @@ Client requests `Member` IDs.
 ```
                           .-------SFU-------.
 .------user1------.       :                 ;
-:     pc_id = 1   o-->-->-o                 :
+:    pc_id = 1    o-->-->-o                 :
 '-----------------'       :                 ;
                           '-----------------'
 ```
@@ -1511,16 +1504,14 @@ Client requests `Member` IDs.
       }]
     },
     "sdp_offer": "server_user2_sendonly_offer",
-    "ice_servers":[
-        {
-        "urls":[
-          "turn:turnserver.com:3478",
-          "turn:turnserver.com:3478?transport=tcp"
-        ],
-        "username":"turn_user",
-        "credential":"turn_credential"
-        }
-    ]
+    "ice_servers": [{
+      "urls": [
+        "turn:turnserver.com:3478",
+        "turn:turnserver.com:3478?transport=tcp"
+      ],
+      "username": "turn_user",
+      "credential": "turn_credential"
+    }]
   }
 }
 ```
@@ -1565,9 +1556,9 @@ Client requests `Member` IDs.
 
 ```
                                                        .-------user2------.
-                          .-------SFU-------.    .-->--o      pc_id = 2   :
+                          .-------SFU-------.    .-->--o     pc_id = 2    :
 .------user1------.       :                 o-->-'     '------------------'
-:     pc_id = 1   o-->-->-o-                :
+:    pc_id = 1    o-->-->-o-                :
 '-----------------'       :                 :
                           '-----------------'
 ```
@@ -1586,7 +1577,7 @@ Client requests `Member` IDs.
       },
       "direction": {
         "Send": {
-          "receivers": [ 2 ]
+          "receivers": [2]
         }
       }
     }, {
@@ -1596,7 +1587,7 @@ Client requests `Member` IDs.
       },
       "direction": {
         "Send": {
-          "receivers": [ 2 ]
+          "receivers": [2]
         }
       }
     }]
@@ -1608,9 +1599,9 @@ Client requests `Member` IDs.
 
 ```
                                                         .-------user2------.
-                           .-------SFU-------.    .-->--o      pc_id = 2   :
+                           .-------SFU-------.    .-->--o     pc_id = 2    :
  .------user1------.       :         .->-->--o-->-'     '------------------'
- :     pc_id = 1   o-->-->-o--->-->--'       :
+ :    pc_id = 1    o-->-->-o--->-->--'       :
  '-----------------'       :                 :
                            '-----------------'
 ```
@@ -1646,16 +1637,14 @@ Client requests `Member` IDs.
       }]
     },
     "sdp_offer": "server_user3_sendonly_offer",
-    "ice_servers":[
-        {
-        "urls":[
-          "turn:turnserver.com:3478",
-          "turn:turnserver.com:3478?transport=tcp"
-        ],
-        "username":"turn_user",
-        "credential":"turn_credential"
-        }
-    ]
+    "ice_servers": [{
+      "urls": [
+        "turn:turnserver.com:3478",
+        "turn:turnserver.com:3478?transport=tcp"
+      ],
+      "username": "turn_user",
+      "credential": "turn_credential"
+    }]
   }
 }
 ```
@@ -1700,11 +1689,11 @@ Client requests `Member` IDs.
 
 ```
                                                        .-------user2------.
-                          .-------SFU-------.    .-->--o      pc_id = 2   :
+                          .-------SFU-------.    .-->--o     pc_id = 2    :
 .------user1------.       :       .---->----o-->-'     '------------------'
-:     pc_id = 1   o-->-->-o--->---'         :
+:    pc_id = 1    o-->-->-o--->---'         :
 '-----------------'       :                 o-->-.     .-------user3------.
-                          '-----------------'    '-->--o      pc_id = 3   :
+                          '-----------------'    '-->--o     pc_id = 3    :
                                                        '------------------'
 ```
 
@@ -1744,11 +1733,11 @@ Client requests `Member` IDs.
 
 ```
                                                      .-------user2------.
-                          .-------SFU-------.    .->-o      pc_id = 2   :
+                          .-------SFU-------.    .->-o     pc_id = 2    :
 .------user1------.       :       .---->----o-->-'   '------------------'
-:     pc_id = 1   o-->-->-o--->---:         :
+:    pc_id = 1    o-->-->-o--->---:         :
 '-----------------'       :       '---->----o-->-.   .-------user3------.
-                          '-----------------'    '->-o      pc_id = 3   :
+                          '-----------------'    '->-o     pc_id = 3    :
                                                      '------------------'
 ```
 </details>

From 48b3f23bfd6a72909b461f40f2181e729f3f7e41 Mon Sep 17 00:00:00 2001
From: tyranron <tyranron@gmail.com>
Date: Mon, 7 Jan 2019 13:30:52 +0200
Subject: [PATCH 16/24] Motivation and Summary corrections

---
 docs/rfc/0002-webrc-client-api.md | 15 +++++++++------
 1 file changed, 9 insertions(+), 6 deletions(-)

diff --git a/docs/rfc/0002-webrc-client-api.md b/docs/rfc/0002-webrc-client-api.md
index cbae4a1ed..5661ecf50 100644
--- a/docs/rfc/0002-webrc-client-api.md
+++ b/docs/rfc/0002-webrc-client-api.md
@@ -17,17 +17,17 @@ Formalize communication protocol between client (browser, mobile apps) and media
 ## Motivation
 [motivation]: #motivation
 
-[WebRTC] allows P2P data exchange, but [WebRTC] as a protocol comes without signaling. At the minimum signalling protocol must provide ways to exchange Session Description data ([SDP Offer] / [SDP Answer]) and [ICE Candidate]. But if you think about signalling protocol in terms of interaction with media server things become more complicated.
+[WebRTC] allows P2P data exchange, but [WebRTC] as a protocol comes without signaling. At the minimum signalling protocol must provide ways to exchange Session Description data ([SDP Offer] / [SDP Answer]) and [ICE Candidate]s. But if you think about signalling protocol in terms of interaction with media server things become more complicated.
 
 You will need to express ways to:
-1. Provide STUN/TURN servers.
+1. Provide [STUN]/[TURN] servers.
 2. Exchange some low-level media metadata (resolution, codecs, media types).
-3. Allow more sophisticated track management (updating video resolution on preview/fullscreen switches, passing multiple video tracks with different settings).
+3. Allow more sophisticated management of media tracks (updating video resolution on preview/fullscreen switches, passing multiple video tracks with different settings).
 4. Pass some user metadata to hook business logic onto.
 5. Build more complex connection graphs.
 6. Dynamically cancel/begin media publishing/receiving.
 7. Passing errors, [RTCPeerConnection]s and [RTCStatsReport]s.
-8. Cover both [p2p full mesh] and [hub server (SFU, MCU)] scenarios.
+8. Cover both [P2P full mesh] and hub server ([SFU], [MCU]) scenarios.
 
 The protocol must be versatile enough to cover all possible use cases.
 
@@ -1785,14 +1785,17 @@ Current protocol assumes that there will be separate [RTCPeerConnection] pair fo
 
 
 [GStreamer]: https://gstreamer.freedesktop.org
-[hub server (SFU, MCU)]: https://webrtcglossary.com/sfu
 [ICE Candidate]:https://tools.ietf.org/html/rfc8445
+[MCU]: https://webrtcglossary.com/mcu
 [MediaStreamTrack]: https://www.w3.org/TR/mediacapture-streams/#mediastreamtrack
-[p2p full mesh]: https://webrtcglossary.com/mesh
+[P2P full mesh]: https://webrtcglossary.com/mesh
 [RTCDataChannel]:https://www.w3.org/TR/webrtc/#rtcdatachannel
 [RTCPeerConnection]: https://www.w3.org/TR/webrtc/#rtcpeerconnection-interface
 [RTCStatsReport]: https://developer.mozilla.org/en-US/docs/Web/API/RTCStatsReport
 [SDP Answer]:https://tools.ietf.org/html/rfc3264
 [SDP Offer]:https://tools.ietf.org/html/rfc3264
+[SFU]: https://webrtcglossary.com/sfu
+[STUN]: https://tools.ietf.org/html/rfc3489
+[TURN]: https://tools.ietf.org/html/rfc5766
 [WebRTC]:https://www.w3.org/TR/webrtc
 [webrtcbin]: https://gstreamer.freedesktop.org/data/doc/gstreamer/head/gst-plugins-bad/html/gst-plugins-bad-plugins-webrtcbin.html

From 301d2cbdb12f7d14110deccc5976274978a07018 Mon Sep 17 00:00:00 2001
From: tyranron <tyranron@gmail.com>
Date: Mon, 7 Jan 2019 14:02:56 +0200
Subject: [PATCH 17/24] "Guide-level explanation" corrections

---
 docs/rfc/0002-webrc-client-api.md | 32 +++++++++++++++++--------------
 1 file changed, 18 insertions(+), 14 deletions(-)

diff --git a/docs/rfc/0002-webrc-client-api.md b/docs/rfc/0002-webrc-client-api.md
index 5661ecf50..5cc7abed0 100644
--- a/docs/rfc/0002-webrc-client-api.md
+++ b/docs/rfc/0002-webrc-client-api.md
@@ -40,7 +40,7 @@ The protocol must be versatile enough to cover all possible use cases.
 
 ### What is `Client WebRTC API`? 
 
-It is a part of `Client API` responsible for [WebRTC] connection management. You can find `Client API` on the following approximate architecture design:
+`Client WebRTC API` is a part of `Client API` responsible for [WebRTC] connection management. You can find `Client API` on the following approximate architecture design:
 ```
                                                                        .------------Server-----------.
                                                                        :     .-------------------.   :
@@ -57,29 +57,29 @@ It is a part of `Client API` responsible for [WebRTC] connection management. You
 ```
 
 So, how it works from `Media Server` point of view:
-1. `Control Service` configures media room via `Control API`.  
+1. `Control Service` configures media room via [`Control API`][Control API].  
 2. `Media Server` provides all necessary information (URLs + credentials) for all room members.
 3. `User Application` passes credentials and other necessary stuff (like `<video>` elements) to `Web Client`.
-4. And voilà!
+4. ...and voilà!
 
 
 ### Transport considerations
 
-Although, signalling can be implemented on top of any transport, WebSocket suits the most since it provides small overhead reliable duplex connection, is widely adopted and supported.
+Although, signalling can be implemented on top of any transport, [WebSocket] suits the most since it provides small overhead reliable duplex connection, and is widely adopted and supported.
 
 
-### Protocol considerations
+### WebSocket considerations
 
 Existing best practices are recommended for final implementation:
-1. Message level `ping`/`pong`, since it is the most reliable way to detect connection loss (protocol level WebSocket `ping`/`pong` may disfunct due to browser implementation and is not exposed to `Web Client`).
-2. Reconnects, since [RTCPeerConnection] always outlives WebSocket connection in cases of network issues, and both parts should know when to dispose related resources.
+1. Message level `ping`/`pong`, since it is the most reliable way to detect connection loss (protocol level [WebSocket] `ping`/`pong` may disfunct due to browser implementation and is not exposed to `Web Client`).
+2. Reconnects, since [RTCPeerConnection] always outlives [WebSocket] connection in cases of network issues, and both parts should know when to dispose related resources.
 3. Using custom Close Frame Status Codes, to implement reliable send-and-close.
 
 
 ### Signalling Protocol considerations
 [signalling-protocol-considerations]: #signalling-protocol-considerations
 
-One of the main goals, is to make `Web Client` integration as easy as possible. This means less interaction between `User Application` and `Web Client`, and more interaction between `Web Client` and `Media Server`, quite verbose `Control Api` design.
+One of the main goals, is to make `Web Client` integration as easy as possible. This means less interaction between `User Application` and `Web Client`, more interaction between `Web Client` and `Media Server`, and quite verbose [`Control API`][Control API] design.
 
 Having in mind, that `Media Server` already has user connection graph received from `Control Service` by the moment user connects, it is possible to establish all required connections without bothering `User Application`. Basically, connection establishment may not depend on interaction with `User Application` at all.
 
@@ -89,17 +89,19 @@ On the other hand, some use cases require more manual control over media exchang
 3. And then start sending media again.
 4. Mute or unmute.
 
-So API can be divided in two categories:
+So, possible API designs can be divided in two categories:
 1. Preconfigured: where everything works out-of-the-box and almost no interaction between `User Application` and `Web Client` required.
-2. Dynamic: when `User Application` needs to express complex use cases.
+2. Dynamic: when `User Application` needs to express complex use cases and change the topology dynamically.
 
 Current RFC offers combining both ways: everything will be configured automagically, but dynamic API is always there if you need it.
 
-All WS messages sent by `Server` are called `Event`s. `Event` means a fact that already has happened, so client cannot reject `Event` in any way (you cannot reject the happened past), it can only adopt itself to the received `Events`. So, `Server` just notifies `Client` about happened facts and `Clients` reacts on them to reach the proper state. This also emphasizes the indisputable authority of the `Server`.  
-The naming for `Events` follows the convention `<entity><passive-verb>`, for example: `PeerCreated`, `TracksApplied`, `PeersRemoved`.
+#### Messaging
 
-All WS messages sent by `Client` are called `Commands`. `Command` is basically a request/desire/intention of `Client` to change the state on `Server`.  
-The naming for `Commands` follows the convention `<infinitive-verb><entity>`, for example: `TracksApplied`, `MakeSdpOffer`, `MakeSdpAnswer`.
+All [WebSocket] messages sent by `Media Server` are called `Event`s. `Event` means a fact that already has happened, so `Web Client` cannot reject `Event` in any way (you cannot reject the happened past), it can only adopt itself to the received `Event`s. So, `Media Server` just notifies `Web Client` about happened facts and it reacts on them to reach the proper state. This also emphasizes the indisputable authority of the `Media Server`.  
+The naming for `Event` follows the convention `<entity><passive-verb>`, for example: `PeerCreated`, `TracksApplied`, `PeersRemoved`.
+
+All [WebSocket] messages sent by `Web Client` are called `Command`s. `Command` is basically a request/desire/intention of `Web Client` to change the state on `Media Server`.  
+The naming for `Command` follows the convention `<infinitive-verb><entity>`, for example: `ApplyTracks`, `MakeSdpOffer`, `MakeSdpAnswer`.
 
 
 
@@ -1784,6 +1786,7 @@ Current protocol assumes that there will be separate [RTCPeerConnection] pair fo
 
 
 
+[Control API]: https://github.com/instrumentisto/medea/blob/master/docs/rfc/0001-control-api.md
 [GStreamer]: https://gstreamer.freedesktop.org
 [ICE Candidate]:https://tools.ietf.org/html/rfc8445
 [MCU]: https://webrtcglossary.com/mcu
@@ -1799,3 +1802,4 @@ Current protocol assumes that there will be separate [RTCPeerConnection] pair fo
 [TURN]: https://tools.ietf.org/html/rfc5766
 [WebRTC]:https://www.w3.org/TR/webrtc
 [webrtcbin]: https://gstreamer.freedesktop.org/data/doc/gstreamer/head/gst-plugins-bad/html/gst-plugins-bad-plugins-webrtcbin.html
+[WebSocket]: https://en.wikipedia.org/wiki/WebSocket

From 93678fdab7ded441e9ce6e025567e75d1fd0230a Mon Sep 17 00:00:00 2001
From: tyranron <tyranron@gmail.com>
Date: Mon, 7 Jan 2019 14:31:23 +0200
Subject: [PATCH 18/24] "Reference-level explanation" corrections

---
 docs/rfc/0002-webrc-client-api.md | 235 ++++++++++++++++--------------
 1 file changed, 122 insertions(+), 113 deletions(-)

diff --git a/docs/rfc/0002-webrc-client-api.md b/docs/rfc/0002-webrc-client-api.md
index 5cc7abed0..15fa67bfa 100644
--- a/docs/rfc/0002-webrc-client-api.md
+++ b/docs/rfc/0002-webrc-client-api.md
@@ -97,11 +97,9 @@ Current RFC offers combining both ways: everything will be configured automagica
 
 #### Messaging
 
-All [WebSocket] messages sent by `Media Server` are called `Event`s. `Event` means a fact that already has happened, so `Web Client` cannot reject `Event` in any way (you cannot reject the happened past), it can only adopt itself to the received `Event`s. So, `Media Server` just notifies `Web Client` about happened facts and it reacts on them to reach the proper state. This also emphasizes the indisputable authority of the `Media Server`.  
-The naming for `Event` follows the convention `<entity><passive-verb>`, for example: `PeerCreated`, `TracksApplied`, `PeersRemoved`.
+All [WebSocket] messages sent by `Media Server` are called `Event`s. `Event` means a fact that already has happened, so `Web Client` cannot reject `Event` in any way (you cannot reject the happened past), it can only adopt itself to the received `Event`s. So, `Media Server` just notifies `Web Client` about happened facts and it reacts on them to reach the proper state. This also emphasizes the indisputable authority of the `Media Server`.
 
-All [WebSocket] messages sent by `Web Client` are called `Command`s. `Command` is basically a request/desire/intention of `Web Client` to change the state on `Media Server`.  
-The naming for `Command` follows the convention `<infinitive-verb><entity>`, for example: `ApplyTracks`, `MakeSdpOffer`, `MakeSdpAnswer`.
+All [WebSocket] messages sent by `Web Client` are called `Command`s. `Command` is basically a request/desire/intention of `Web Client` to change the state on `Media Server`.
 
 
 
@@ -110,7 +108,7 @@ The naming for `Command` follows the convention `<infinitive-verb><entity>`, for
 [reference-level-explanation]: #reference-level-explanation
 
 
-### Data model
+### Data model and primitives
 
 ```
    .-------------------------Member---------------------------.
@@ -139,7 +137,7 @@ The naming for `Command` follows the convention `<infinitive-verb><entity>`, for
 
 #### Member
 
-Just a way to group `Peers` and provide `User Application` with some user metadata. `Member` can have 0-N `Peers`.
+Just a way to group `Peers` and provide `User Application` with some user metadata. `Member` can have 0-N `Peer`s.
 
 ```rust
 struct Member {
@@ -150,7 +148,7 @@ struct Member {
 
 #### Peer
 
-[RTCPeerConnection] representation. `Peer` can have 1-N `Tracks`.
+[RTCPeerConnection] representation. `Peer` can have 1-N `Track`s.
 
 ```rust
 struct Peer {
@@ -161,7 +159,7 @@ struct Peer {
 
 #### Track
 
-Somewhat [MediaStreamTrack] representation.
+[MediaStreamTrack] representation.
 
 ```rust
 struct Track {
@@ -192,7 +190,9 @@ struct VideoSettings {}
 
 ### Events
 
-I.e. `Server` => `Client` requests.
+[WebSocket] messages from `Media Server` to `Web Client`.
+
+The naming for `Event` follows the convention `<entity><passive-verb>`, for example: `PeerCreated`, `TracksApplied`, `PeersRemoved`.
 
 #### 1. PeerCreated
 
@@ -213,14 +213,16 @@ struct ICEServer {
 }
 ```
 
-Servers requests [RTCPeerConnection] creation.
+`Media Server` notifies about necessity of [RTCPeerConnection] creation.
 
 Params:
 1. `peer`: peer connection settings.
-2. `sdp_offer`: if `None`, client should create [SDP Offer] and pass it to the server. If `Some`, client should set it as remote description, then create [SDP Answer], set it as local description, and pass it to the server.
-3. `ice_servers`: just list of ice servers that should be passed to [RTCPeerConnection] constructor.
+2. `sdp_offer`: if `None`, client should create [SDP Offer] and pass it to the server; if `Some`, client should set it as remote description, then create [SDP Answer], set it as local description, and pass it to the server.
+3. `ice_servers`: list of [ICE server]s that should be used to construct [RTCPeerConnection].
 
-The most important part of `Peer` object is list of tracks. All `TrackDirection::Send` tracks must be created according to their settings and added to the `Peer`. If there is at least one `TrackDirection::Recv` track, then created [RTCPeerConnection] must be ready to receive tracks (`recvonly`/`sendrecv` SDP). Currently, there are multiple ways to achieve this on client side and concrete implementation is not part of this RFC. 
+The most important part of `Peer` object is a list of `Track`s.
+- All `TrackDirection::Send` `Track`s must be created according to their settings and added to the `Peer`. 
+- If there is at least one `TrackDirection::Recv` `Track`, then created [RTCPeerConnection] must be ready to receive `Track`s (`recvonly`/`sendrecv` SDP). Currently, there are multiple ways to achieve this on client side and concrete implementation is not part of this RFC.
 
 ##### Examples
 
@@ -285,16 +287,16 @@ The most important part of `Peer` object is list of tracks. All `TrackDirection:
 }
 ```
 
-Client is expected to:
-1. Create [RTCPeerConnection] with provided ICE servers and associate it with given `peer_id`.
-2. Initialize Audio and Video tracks without any additional settings.
-3. Add newly created tracks to [RTCPeerConnection].
-4. Create `sendrecv` [SDP Offer].
-5. Set offer as peers local description.
-6. Answer `PeerCreated` request with `MakeSdpOffer` request containing [SDP Offer].
+`Web Client` is expected to:
+1. Create [RTCPeerConnection] with provided [ICE server]s and associate it with given `peer_id`.
+2. Initialize `Audio` and `Video` `Track`s without any additional settings.
+3. Add newly created `Track`s to [RTCPeerConnection].
+4. Generate `sendrecv` [SDP Offer].
+5. Set offer as `Peer`'s local description.
+6. Answer with `MakeSdpOffer` command containing generated [SDP Offer].
 7. Expect remote [SDP Answer] to set it as remote description.
 
-After negotiation is done and media starts flowing, the client might receive notification that his media is being sent to `Peer { peer_id = 2 }`, and he is receiving media from `Peer { peer_id = 2 }`.
+After negotiation is done and media starts flowing, `Web Client` might receive notification that his media is being sent to `Peer { peer_id = 2 }` and he is receiving media from `Peer { peer_id = 2 }`.
 </details>
 
 <details>
@@ -328,16 +330,16 @@ After negotiation is done and media starts flowing, the client might receive not
 }
 ```
 
-Client is expected to:
-1. Create [RTCPeerConnection] with provided ICE servers and associate it with given `peer_id`.
-2. Initialize Audio track without any additional settings.
-3. Add newly created track to [RTCPeerConnection].
-4. Set provided offer as peers remote description.
-5. Create `sendonly` [SDP Answer].
+`Web Client` is expected to:
+1. Create [RTCPeerConnection] with provided [ICE server]s and associate it with given `peer_id`.
+2. Initialize `Audio` `Track` without any additional settings.
+3. Add newly created `Track` to [RTCPeerConnection].
+4. Set provided [SDP Offer] as `Peer`'s remote description.
+5. Generate `sendonly` [SDP Answer].
 6. Set created [SDP Answer] as local description.
-7. Answer `PeerCreated` request with `MakeSdpAnswer` request containing [SDP Answer]. 
+7. Answer with `MakeSdpAnswer` command containing generated [SDP Answer]. 
 
-After negotiation is done and media starts flowing, client might receive notification that his media is being sent to server.
+After negotiation is done and media starts flowing, `Web Client` might receive notification that his media is being sent to `Media Server`.
 </details>
 
 #### 2. PeersRemoved
@@ -348,13 +350,12 @@ struct PeersRemoved {
 }
 ```
 
-`Server` requests to dispose (close) specified `Peers`.
-
+`Media Server` notifies about necessity to dispose (close and remove) specified `Peer`s.
 
 ##### Examples
 
 <details>
-<summary>Server tells Client to dispose specified Peers</summary>
+<summary>Server tells Web Client to dispose specified Peers</summary>
 
 ```json
 {
@@ -372,17 +373,17 @@ struct TracksApplied {
 }
 ```
 
-`Server` requests to update tracks in specified `Peer`.
+`Media Server` notifies about necessity to update `Track`s in specified `Peer`.
 
 It can be used to:
-1. Add new track.
-2. Update existing track settings (e.g. change to lower video resolution, mute audio).
-3. Update send track receivers list (add/remove).
+1. Add new `Track`.
+2. Update existing `Track` settings (e.g. change to lower video resolution, mute audio).
+3. Update `send` `Track` receivers list (add/remove).
 
 ##### Examples 
 
 <details>
-<summary>Assuming such Peer exists on Client's end</summary>
+<summary>If Peer exists on Web Client's end</summary>
 
 ```json
 {
@@ -411,11 +412,11 @@ It can be used to:
 }
 ```
 
-Meaning that media is being published to server but has no actual receivers.
+Means that media is being published to `Media Server` but has no actual receivers.
 </details>
 
 <details>
-<summary>Server notifies Client that video is being received by other Peer {peer_id = 2}</summary>
+<summary>Media Server notifies Web Client that video is being received by other Peer</summary>
 
 ```json
 {
@@ -454,12 +455,12 @@ struct TracksRemoved {
 }
 ```
 
-`Server` requests to dispose (close) specified `Tracks`.
+`Media Server` notifies about necessity to dispose (close and remove) specified `Track`s.
 
 ##### Examples
 
 <details>
-<summary>Server tells Client to dispose specified Tracks</summary>
+<summary>Media Server tells Web Client to dispose specified Tracks</summary>
 
 ```json
 {
@@ -478,12 +479,14 @@ struct SdpOfferMade {
 }
 ```
 
-`Server` applies [SDP Offer] to `Client`s [RTCPeerConnection]. Being sent during SDP negotiation/re-negotiation.
+`Media Server` notifies about necessity to apply specified [SDP Offer] to `Web Client`'s [RTCPeerConnection].
+
+This event is sent during SDP negotiation/re-negotiation. `Web Client` is expected answer with `MakeSdpAnswer` command.
 
 ##### Examples
 
 <details>
-<summary>Server sends SDP Offer to Peer {peer_id = 1}</summary>
+<summary>Media Server sends SDP Offer to Peer</summary>
 
 ```json
 {
@@ -502,12 +505,14 @@ struct SdpAnswerMade {
 }
 ```
 
-`Server` applies [SDP Answer] to `Client`s [RTCPeerConnection]. Being sent during SDP negotiation/re-negotiation.
+`Media Server` notifies about necessity to apply specified [SDP Answer] to `Web Client`'s [RTCPeerConnection].
 
-#### Examples
+This event is sent during SDP negotiation/re-negotiation.
+
+##### Examples
 
 <details>
-<summary>Server sends SDP Offer to Peer {peer_id = 1}</summary>
+<summary>Media Server sends SDP Answer to Peer</summary>
 
 ```json
 {
@@ -517,8 +522,7 @@ struct SdpAnswerMade {
 ```
 </details>
 
-
-#### 7. IceCandidatesDiscovered
+#### 7. IceCandidateDiscovered
 
 ```rust
 struct IceCandidatesDiscovered {
@@ -527,12 +531,14 @@ struct IceCandidatesDiscovered {
 }
 ```
 
-`Server` applies [ICE Candidate] to `Client`s [RTCPeerConnection]. Being sent during ICE negotiation/re-negotiation.
+`Media Server` notifies about necessity to apply [ICE Candidate] to `Web Client`'s [RTCPeerConnection].
 
-#### Examples
+This event is sent during ICE negotiation/re-negotiation.
+
+##### Examples
 
 <details>
-<summary>Server sends ICE Candidate to Peer {peer_id = 1}</summary>
+<summary>Media Server sends ICE Candidate to Peer</summary>
 
 ```json
 {
@@ -551,7 +557,6 @@ struct RemotePeersUpdated {
 ```
 
 Related objects:
-
 ```rust
 struct RemotePeer {
     peer_id: Option<u64>,
@@ -574,18 +579,20 @@ enum RemotePeerTrackType {
 }
 ```
 
-Server notifies Client of any remote peers that Client can connect to. This is a key method when talking about Dynamic API mentioned in [Signalling Protocol considerations][signalling-protocol-considerations]. Any Client's request to subscribe/publish will be based on data provided by this request.
+`Media Server` notifies about any remote `Peer`s that `Web Client` can connect to.
+
+This is a key event when talking about dynamic API mentioned in [Signalling Protocol considerations][signalling-protocol-considerations]. Any `Web Client`'s commands to subscribe/publish will be based on data provided by this event.
 
 Params:
-1. ```peer_id```: if `Some`, then represents specific remote `Peer` associated with some `Member`. If `None`, then represents Servers peer connection.
-2. ```member_id```: if `Some`, then represents specific remote `Member` associated with some . If `None`, then represents Servers peer connection.
-3. ```can_rx```: if `Some` then Client can subscribe to specified media.
-4. ```can_tx```: if `Some` then Client can publish specified media to remote `Peer`.
+1. `peer_id`: if `Some`, then represents specific remote `Peer` associated with some `Member`; if `None`, then represents `Media Server`'s [RTCPeerConnection].
+2. `member_id`: if `Some`, then represents specific remote `Member`; if `None`, then represents `Media Server`'s [RTCPeerConnection].
+3. `can_rx`: if `Some` then `Web Client` can subscribe to specified media.
+4. `can_tx`: if `Some` then `Web Client` can publish specified media to remote `Peer`.
 
-#### Examples:
+##### Examples
 
 <details>
-<summary>Notify Client that it is possible to subscribe to Member {id = "User2", peer_id = 2} Video and Audio tracks</summary>
+<summary>Notify Web Client that it is possible to subscribe to another Member's Video and Audio Tracks</summary>
 
 ```json
 {
@@ -605,7 +612,7 @@ Params:
 </details>
 
 <details>
-<summary>Notify Client that it is possible to publish Audio to specified Peers</summary>
+<summary>Notify Web Client that it is possible to publish Audio to specified Peers</summary>
 
 ```json
 {
@@ -635,17 +642,19 @@ Params:
 #### 9. MembersUpdated 
 
 ```rust
-struct Members {
+struct MembersUpdated {
     members: Vec<Member>
 }
 ```
 
-`Server` updates `Client`s acknowledgement of `Peer`-`Member` associations. It is recommended to cache `Peer` id - `Member` id relation in Web Client. Probably, in two maps: `HashMap<peer_id, member_id>`, `HashMap<member_id, peer_id>`.
+`Media Server` updates `Web Client`'s knowledge about `Peer`<=>`Member` associations.
+
+It's recommended to cache `Peer` ID and `Member` ID relations in `Web Client`'s local state (for example, in two maps: `HashMap<peer_id, member_id>`, `HashMap<member_id, peer_id>`).
 
-#### Examples
+##### Examples
 
 <details>
-<summary>Server updates Clients acknowledgement of Peer-Member associations</summary>
+<summary>Media Server updates Web Client's knowledge about Peer<=>Member associations</summary>
 
 ```json
 {
@@ -666,7 +675,9 @@ struct Members {
 
 ### Commands
 
-I.e. `Client` => `Server` requests.
+[WebSocket] message from `Web Client` to `Media Server`.
+
+The naming for `Command` follows the convention `<infinitive-verb><entity>`, for example: `ApplyTracks`, `MakeSdpOffer`, `MakeSdpAnswer`.
 
 #### 1. RemovePeers
 
@@ -676,14 +687,14 @@ struct RemovePeers {
 }
 ```
 
-`Client` requests `Server` permission to dispose specified `Peers`. Server may give permission by sending `PeersRemoved`.
+`Web Client` asks permission to dispose (close and remove) specified `Peer`s. `Media Server` gives permission by sending `PeersRemoved` event.
 
-Probably, Server will always give his permission on any Client's request. This kind of request flow will allow Server to do any request related stuff that Server needs to do, and distinguish between abnormal and normal events.
+Probably, `Media Server` will always give this permission on any `Web Client`'s command. This kind of messages flow will allow `Media Server` to do any command-related stuff that `Media Server` needs to do, and distinguish between abnormal and normal events.
 
 ##### Examples
 
 <details>
-<summary>Client requests Server permission to dispose specified Peers</summary>
+<summary>Web Client asks permission to dispose specified Peers</summary>
 
 ```json
 {
@@ -692,25 +703,25 @@ Probably, Server will always give his permission on any Client's request. This k
 ```
 </details>
 
-#### 2. SetTracks
+#### 2. ApplyTracks
 
 ```rust
-struct SetTracks {
+struct ApplyTracks {
     peer_id: u64,
     tracks: Vec<Track>,
 }
 ```
 
-`Client` requests to update tracks in specified `Peer`. Server may give permission by sending `TracksApplied`.
-                                                      
-It can be used to express Clients intentions to:
-1. Update existing track settings.
+`Web Client` asks permission to update `Track`s in specified `Peer`. `Media Server` gives permission by sending `TracksApplied` event.
+
+It can be used to express `Web Client`'s intentions to:
+1. Update existing `Track` settings.
 2. Cancel sending media to specific receiver.
 
 ##### Examples 
 
 <details>
-<summary>Assuming such Peer exists on Client's end</summary>
+<summary>If Peer exists on Web Client's end</summary>
 
 ```json
 {
@@ -739,13 +750,11 @@ It can be used to express Clients intentions to:
 }
 ```
 
-Meaning that media is being published to server and relayed to Peer {peer_id = 2}.
+Means that media is being published to `Media Server` and relayed to `Peer {peer_id = 2}`.
 </details>
 
 <details>
-<summary>Client wants to unsubscribe Peer {peer_id = 2} from specified tracks</summary>
-
-Client => Server
+<summary>Web Client wants to unsubscribe Peer from specified Tracks</summary>
 
 ```json
 {
@@ -784,12 +793,12 @@ struct RemoveTracks {
 }
 ```
 
-`Client` requests `Server` permission to dispose specified `Peers`. Server may give permission by sending `TracksRemoved`.
+`Web Client` asks permission to dispose (close and remove) specified `Track`s. `Media Server` gives permission by sending `TracksRemoved` event.
 
 ##### Examples
 
 <details>
-<summary>Client requests Server's permission to dispose specified Tracks</summary>
+<summary>Web Client asks permission to dispose specified Tracks</summary>
 
 ```json
 {
@@ -808,16 +817,16 @@ struct MakeSdpOffer {
 }
 ```
 
-Client sends [SDP Offer] from one if its `Peers`.
+`Web Client` sends [SDP Offer] to one if its `Peer`s.
 
-Client can send it:
-1. As answer to `PeerCreated {sdp_offer: None}`
-2. As answer to `TracksApplied` if update requires SDP re-negotiation.
+`Web Client` can send it:
+1. As reaction to `PeerCreated {sdp_offer: None}` event.
+2. As reaction to `TracksApplied` event if update requires SDP re-negotiation.
 
 ##### Examples
 
 <details>
-<summary>Client sends Peers SDP Offer</summary>
+<summary>Web Client sends SDP Offer to some Peer</summary>
 
 ```json
 {
@@ -836,16 +845,16 @@ struct MakeSDPAnswer {
 }
 ```
 
-Client sends [SDP Answer] from one if its `Peers`.
+`Web Client` sends [SDP Answer] to one if its `Peer`s.
 
-Client can send it:
-1. As answer to `PeerCreated {sdp_offer: Some}`.
-2. As answer to `SdpOfferMade`.
+`Web Client` can send it:
+1. As reaction to `PeerCreated {sdp_offer: Some}` event.
+2. As reaction to `SdpOfferMade` event.
 
-#### Examples
+##### Examples
 
 <details>
-<summary>Client sends Peers SDP Answer</summary>
+<summary>Web Client sends SDP Answer to some Peer</summary>
 
 ```json
 {
@@ -864,12 +873,12 @@ struct SetIceCandidate {
 }
 ```
 
-Client sends [ICE Candidate] discovered by underlying [RTCPeerConnection] of one of his `Peers`.
+`Web Client` sends [ICE Candidate] discovered by underlying [RTCPeerConnection] for one of his `Peer`s.
 
-#### Examples
+##### Examples
 
 <details>
-<summary>Client sends ICE Candidate from Peer {peer_id = 1}</summary>
+<summary>Web Client sends ICE Candidate for some Peer</summary>
 
 ```json
 {
@@ -891,7 +900,6 @@ struct RequestRemoteTracks {
 ```
 
 Related objects:
-
 ```rust
 enum RemotePeerTrackType {
     Audio {
@@ -907,20 +915,19 @@ enum RemotePeerTrackType {
 }
 ```
 
-Client requests to send or receive media to/from remote `Peer`. Server may give permission by sending `TracksApplied`.
+`Web Client` asks permission to send or receive media to/from specified remote `Peer`. `Media Server` may gives permission by sending `TracksApplied` event.
 
 Params:
-1. `peer_id`: if `Some` then Client wants to connect specified local `Peer` to remote. If `None`then it us to server
-to decide which of Client's `Peers` will be connected.
-2. `remote_peer_id`: if `Some`, then represents specific remote `Member` associated with some . If `None`, then 
-represents Server's peer connection (only SFU).
-3. `rx`: if `Some` then Client requests to subscribe to specified media.
-4. `tx`: if `Some` then Client requests to publish specified media to remote `Peer`.
+1. `peer_id`: if `Some`, then `Web Client` wants to connect specified local `Peer` to remote one; if `None`, then `Media Server`
+decides which of `Web Client`'s `Peer`s will be connected.
+2. `remote_peer_id`: if `Some`, then represents specific remote `Peer`; if `None`, then represents `Media Server`'s [RTCPeerConnection] (only [SFU]).
+3. `rx`: if `Some` then `Web Client` requests to subscribe to specified media.
+4. `tx`: if `Some` then `Web Client` requests to publish specified media to remote `Peer`.
 
 ##### Examples
 
 <details>
-<summary>Client requests to subscribe to remote Peer {peer_id = 2} audio and video</summary>
+<summary>Web Client requests to subscribe to remote Peer audio and video</summary>
 
 ```json
 {
@@ -938,7 +945,7 @@ represents Server's peer connection (only SFU).
 </details>
 
 <details>
-<summary>Client requests to publish to Server's peer connection</summary>
+<summary>Web Client requests to publish to Media Server's RTCPeerConnection</summary>
 
 ```json
 {
@@ -955,20 +962,20 @@ represents Server's peer connection (only SFU).
 ```
 </details>
 
-#### 9. RequestMembers
+#### 9. GetMembers
 
 ```rust
-struct RequestMembers {
+struct GetMembers {
     peer_ids: Vec<u64>,
 }
 ```
 
-Client requests `Member` IDs.
+`Web Client` asks IDs of present `Member`s for specified `Peer`s. `Media Server` answers with `MembersUpdated` event.
 
 ##### Examples
 
 <details>
-<summary>Client request Member's that own specified Peer's</summary>
+<summary>Web Client request Members which own specified Peers</summary>
 
 ```json
 {
@@ -979,6 +986,7 @@ Client requests `Member` IDs.
 ```
 </details>
 
+
 ### Extended examples
 
 <details>
@@ -1788,15 +1796,16 @@ Current protocol assumes that there will be separate [RTCPeerConnection] pair fo
 
 [Control API]: https://github.com/instrumentisto/medea/blob/master/docs/rfc/0001-control-api.md
 [GStreamer]: https://gstreamer.freedesktop.org
-[ICE Candidate]:https://tools.ietf.org/html/rfc8445
+[ICE Candidate]: https://tools.ietf.org/html/rfc8445
+[ICE server]: https://webrtcglossary.com/ice
 [MCU]: https://webrtcglossary.com/mcu
 [MediaStreamTrack]: https://www.w3.org/TR/mediacapture-streams/#mediastreamtrack
 [P2P full mesh]: https://webrtcglossary.com/mesh
-[RTCDataChannel]:https://www.w3.org/TR/webrtc/#rtcdatachannel
+[RTCDataChannel]: https://www.w3.org/TR/webrtc/#rtcdatachannel
 [RTCPeerConnection]: https://www.w3.org/TR/webrtc/#rtcpeerconnection-interface
 [RTCStatsReport]: https://developer.mozilla.org/en-US/docs/Web/API/RTCStatsReport
-[SDP Answer]:https://tools.ietf.org/html/rfc3264
-[SDP Offer]:https://tools.ietf.org/html/rfc3264
+[SDP Answer]: https://tools.ietf.org/html/rfc3264
+[SDP Offer]: https://tools.ietf.org/html/rfc3264
 [SFU]: https://webrtcglossary.com/sfu
 [STUN]: https://tools.ietf.org/html/rfc3489
 [TURN]: https://tools.ietf.org/html/rfc5766

From a1a9dbcdd9bea2b50ca918bb498541bc17663d37 Mon Sep 17 00:00:00 2001
From: tyranron <tyranron@gmail.com>
Date: Mon, 7 Jan 2019 15:49:50 +0200
Subject: [PATCH 19/24] "Drawbacks and alternatives" and "Unresolved questions
 and future possibilities" corrections

---
 docs/rfc/0002-webrc-client-api.md | 19 +++++++++----------
 1 file changed, 9 insertions(+), 10 deletions(-)

diff --git a/docs/rfc/0002-webrc-client-api.md b/docs/rfc/0002-webrc-client-api.md
index 15fa67bfa..1b056b8cc 100644
--- a/docs/rfc/0002-webrc-client-api.md
+++ b/docs/rfc/0002-webrc-client-api.md
@@ -1759,9 +1759,9 @@ struct GetMembers {
 [drawbacks-and-alternatives]: #drawbacks-and-alternatives
 
 This RFC design tries to be a "silver bullet": cover all possible use-cases and combine them into a single protocol. Such versatility increases complexity. Simplifications can be achieved by imposing some general constraints:
-1. Divide current protocol in two separate protocols: one for SFU and one for P2P.
+1. Divide current protocol in two separate protocols: one for [SFU] and one for [P2P full mesh].
 2. Reject future possibilities of using 1 `Peer` for all inbound/outbound tracks.
-3. Limit the number of outbound streams in single `Peer` to 1.
+3. Limit the number of outbound streams in a single `Peer` to 1.
 4. Remove publishers acknowledgement of every receiver on each track.
 5. Remove subscribers acknowledgement of every publisher that is not publishing at the moment.
 
@@ -1776,19 +1776,18 @@ This RFC design tries to be a "silver bullet": cover all possible use-cases and
 
 [WebRTC] spec introduces [RTCDataChannel] - a bi-directional data channel between two peers which allows arbitrary data exchange. It is an amazing feature with huge potential, but, at this point it is quite useless for our use cases.
 
-As the project grows, requirements will change, and we might consider adding data channels. Although, they are not 
-mentioned in this protocol, only minor tweaks will be required to support them.
+As the project grows, requirements will change, and we might consider adding data channels. Although, they are not mentioned in this protocol, only minor tweaks will be required to support them.
 
 
-### Receiving tracks from multiple senders in single peer connection
+### Receiving tracks from multiple senders in a single peer connection
 
-There are two general ways to manage Client's peer connections when using SFU server:
-1. Having only one pair of [RTCPeerConnection]'s (one at Client's end and one at Server) and pass all send/recv tracks through this connection.
-2. Or having a separate [RTCPeerConnection] pair for each track group.
+There are two general ways to manage `Web Client`'s [RTCPeerConnection]s when using [SFU] server:
+1. Having only one pair of [RTCPeerConnection]s (one at `Web Client`'s end and one at `Media Server`) and pass all `send`/`recv` `Track`s through this connection.
+2. Or having a separate [RTCPeerConnection] pair for each `Track` group.
 
-First way is preferable since it allows to reduce resources usage on both ends. But track management is very unclear in this case and [webrtcbin] module of [GStreamer] currently does not support dynamic addition/removal of streams and needs major updates to be able to do so.
+First way is preferable since it allows to reduce resources usage on both ends. But `Track` management is very unclear in this case and [webrtcbin] module of [GStreamer] currently does not support dynamic addition/removal of streams and needs major updates to be able to do so.
 
-Current protocol assumes that there will be separate [RTCPeerConnection] pair for each track group. At the same time, it does not forbid having all the tracks in single [RTCPeerConnection] pair, but it will require some minor changes to make this work.
+Current protocol assumes that there will be separate [RTCPeerConnection] pair for each `Track` group. At the same time, it does not forbid having all the `Track`s in a single [RTCPeerConnection] pair, but it will require some minor changes to make this work.
 
 
 

From a26540270d9d18c81a9f5a47a9fd3e6fa9276634 Mon Sep 17 00:00:00 2001
From: tyranron <tyranron@gmail.com>
Date: Mon, 7 Jan 2019 18:19:18 +0200
Subject: [PATCH 20/24] "Extended examples" corrections

---
 docs/rfc/0002-webrc-client-api.md | 1375 +++++++++++++++--------------
 1 file changed, 700 insertions(+), 675 deletions(-)

diff --git a/docs/rfc/0002-webrc-client-api.md b/docs/rfc/0002-webrc-client-api.md
index 1b056b8cc..63d16ab08 100644
--- a/docs/rfc/0002-webrc-client-api.md
+++ b/docs/rfc/0002-webrc-client-api.md
@@ -525,7 +525,7 @@ This event is sent during SDP negotiation/re-negotiation.
 #### 7. IceCandidateDiscovered
 
 ```rust
-struct IceCandidatesDiscovered {
+struct IceCandidateDiscovered {
     peer_id: u64,
     candidate: String,
 }
@@ -836,10 +836,10 @@ struct MakeSdpOffer {
 ```
 </details>
 
-#### 5. MakeSDPAnswer
+#### 5. MakeSdpAnswer
 
 ```rust
-struct MakeSDPAnswer {
+struct MakeSdpAnswer {
     peer_id: u64,
     sdp_answer: String,
 }
@@ -920,7 +920,7 @@ enum RemotePeerTrackType {
 Params:
 1. `peer_id`: if `Some`, then `Web Client` wants to connect specified local `Peer` to remote one; if `None`, then `Media Server`
 decides which of `Web Client`'s `Peer`s will be connected.
-2. `remote_peer_id`: if `Some`, then represents specific remote `Peer`; if `None`, then represents `Media Server`'s [RTCPeerConnection] (only [SFU]).
+2. `remote_peer_id`: if `Some`, then represents specific remote `Peer`; if `None`, then represents `Media Server`'s [RTCPeerConnection], but only for [SFU].
 3. `rx`: if `Some` then `Web Client` requests to subscribe to specified media.
 4. `tx`: if `Some` then `Web Client` requests to publish specified media to remote `Peer`.
 
@@ -990,7 +990,7 @@ struct GetMembers {
 ### Extended examples
 
 <details>
-<summary>1 <=> 1 p2p with unpublish and republish</summary>
+<summary>1 <=> 1 P2P with unpublish and republish</summary>
 
 ```
 .----user1----.    .->-->-->--. .----user2----.
@@ -998,388 +998,407 @@ struct GetMembers {
 '-------------'    '-<--<--<--' '-------------'
 ```
 
-1\. Server send `PeerCreated` to `user1`:
-
-```json
-{
-  "method": "PeerCreated",
-  "payload": {
-    "peer": {
-      "peer_id": 1,
-      "tracks": [{
-        "id": 1,
-        "media_type": {
-          "Audio": {}
-        },
-        "direction": {
-          "Send": {
-            "receivers": [2]
-          }
-        }
-      }, {
-        "id": 2,
-        "media_type": {
-          "Video": {}
+1. `Media Server` sends `PeerCreated` event to `user1`:
+
+    ```json
+    {
+      "event": "PeerCreated",
+      "data": {
+        "peer": {
+          "peer_id": 1,
+          "tracks": [{
+            "id": 1,
+            "media_type": {
+              "Audio": {}
+            },
+            "direction": {
+              "Send": {
+                "receivers": [2]
+              }
+            }
+          }, {
+            "id": 2,
+            "media_type": {
+              "Video": {}
+            },
+            "direction": {
+              "Send": {
+                "receivers": [2]
+              }
+            }
+          }, {
+            "id": 3,
+            "media_type": {
+              "Audio": {}
+            },
+            "direction": {
+              "Recv": {
+                "sender": 2
+              }
+            }
+          }, {
+            "id": 4,
+            "media_type": {
+              "Video": {}
+            },
+            "direction": {
+              "Recv": {
+                "sender": 2
+              }
+            }
+          }]
         },
-        "direction": {
-          "Send": {
-            "receivers": [2]
-          }
-        }
-      }, {
-        "id": 3,
-        "media_type": {
-          "Audio": {}
-        },
-        "direction": {
-          "Recv": {
-            "sender": 2
-          }
-        }
-      }, {
-        "id": 4,
-        "media_type": {
-          "Video": {}
-        },
-        "direction": {
-          "Recv": {
-            "sender": 2
-          }
-        }
-      }]
-    },
-    "sdp_offer": null,
-    "ice_servers": [{
-      "urls": [
-        "turn:turnserver.com:3478",
-        "turn:turnserver.com:3478?transport=tcp"
-      ],
-      "username": "turn_user",
-      "credential": "turn_credential"
-    }]
-  }
-}
-```
+        "sdp_offer": null,
+        "ice_servers": [{
+          "urls": [
+            "turn:turnserver.com:3478",
+            "turn:turnserver.com:3478?transport=tcp"
+          ],
+          "username": "turn_user",
+          "credential": "turn_credential"
+        }]
+      }
+    }
+    ```
  
-2\. `user1` answers with [SDP Offer]:
-
-```json
-{
-  "method": "MakeSdpOffer",
-  "payload": {
-    "peer_id": 1,
-    "sdp_offer": "user1_sendrecv_offer"
-  }
-}
-```
+2. `user1` answers with [SDP Offer]:
+
+    ```json
+    {
+      "command": "MakeSdpOffer",
+      "data": {
+        "peer_id": 1,
+        "sdp_offer": "user1_sendrecv_offer"
+      }
+    }
+    ```
  
-3\. Server send `PeerCreated` with `user1`'s [SDP Offer] to `user2`:
-
-```json
-{
-  "method": "PeerCreated",
-  "payload": {
-    "peer": {
-      "peer_id": 2,
-      "tracks": [{
-        "id": 1,
-        "media_type": {
-          "Audio": {}
-        },
-        "direction": {
-          "Recv": {
-            "sender": 1
-          }
-        }
-      }, {
-        "id": 2,
-        "media_type": {
-          "Audio": {}
+3. `Media Server` sends `PeerCreated` event with `user1`'s [SDP Offer] to `user2`:
+
+    ```json
+    {
+      "event": "PeerCreated",
+      "data": {
+        "peer": {
+          "peer_id": 2,
+          "tracks": [{
+            "id": 1,
+            "media_type": {
+              "Audio": {}
+            },
+            "direction": {
+              "Recv": {
+                "sender": 1
+              }
+            }
+          }, {
+            "id": 2,
+            "media_type": {
+              "Audio": {}
+            },
+            "direction": {
+              "Recv": {
+                "sender": 1
+              }
+            }
+          }, {
+            "id": 3,
+            "media_type": {
+              "Audio": {}
+            },
+            "direction": {
+              "Send": {
+                "receivers": [1]
+              }
+            }
+          }, {
+            "id": 4,
+            "media_type": {
+              "Video": {}
+            },
+            "direction": {
+              "Send": {
+                "receivers": [1]
+              }
+            }
+          }]
         },
-        "direction": {
-          "Recv": {
-            "sender": 1
-          }
-        }
-      }, {
-        "id": 3,
-        "media_type": {
-          "Audio": {}
-        },
-        "direction": {
-          "Send": {
-            "receivers": [1]
-          }
-        }
-      }, {
-        "id": 4,
-        "media_type": {
-          "Video": {}
-        },
-        "direction": {
-          "Send": {
-            "receivers": [1]
-          }
-        }
-      }]
-    },
-    "sdp_offer": "user1_sendrecv_offer",
-    "ice_servers": [{
-      "urls": [
-        "turn:turnserver.com:3478",
-        "turn:turnserver.com:3478?transport=tcp"
-      ],
-      "username": "turn_user",
-      "credential": "turn_credential"
-    }]
-  }
-}
-```
+        "sdp_offer": "user1_sendrecv_offer",
+        "ice_servers": [{
+          "urls": [
+            "turn:turnserver.com:3478",
+            "turn:turnserver.com:3478?transport=tcp"
+          ],
+          "username": "turn_user",
+          "credential": "turn_credential"
+        }]
+      }
+    }
+    ```
 
-4\. `user2` answers with [SDP Answer]:
+4. `user2` answers with [SDP Answer]:
 
-```json
-{
-  "method": "MakeSDPAnswer",
-  "payload": {
-    "peer_id": 2,
-    "sdp_answer": "user2_sendrecv_answer"
-  }
-}
-```
+    ```json
+    {
+      "command": "MakeSdpAnswer",
+      "data": {
+        "peer_id": 2,
+        "sdp_answer": "user2_sendrecv_answer"
+      }
+    }
+    ```
 
-5\. Both peers exchange discovered [ICE Candidate]'s:
+5. Both peers exchange discovered [ICE Candidate]s:
 
-`user1` => `Server`
-```json
-{
-  "method": "SetIceCandidate",
-  "payload": {
-    "peer_id": 1,
-    "candidate": "user1_ice_candidate"
-  }
-}
-```
+    1. `user1` => `Media Server`:
 
-`Server` => `user2`
-```json
-{
-  "method": "IceCandidatesDiscovered",
-  "payload": {
-    "peer_id": 2,
-    "candidate": "user1_ice_candidate"
-  }
-}
-```
+        ```json
+        {
+          "command": "SetIceCandidate",
+          "data": {
+            "peer_id": 1,
+            "candidate": "user1_ice_candidate"
+          }
+        }
+        ```
 
-`user2` => `Server`
-```json
-{
-  "method": "SetIceCandidate",
-  "payload": {
-    "peer_id": 2,
-    "candidate": "user2_ice_candidate"
-  }
-}
-```
+    2. `Media Server` => `user2`:
 
-`Server` => `user1`
-```json
-{
-  "method": "IceCandidatesDiscovered",
-  "payload": {
-    "peer_id": 1,
-    "candidate": "user2_ice_candidate"
-  }
-}
-```
+        ```json
+        {
+          "event": "IceCandidateDiscovered",
+          "data": {
+            "peer_id": 2,
+            "candidate": "user1_ice_candidate"
+          }
+        }
+        ```
 
-6\. At this point connection is supposed to be established:
+    3. `user2` => `Media Server`:
 
-```
-.----user1----.    .->-->-->--. .----user2----.
-:             o(1)=:          :=o(2)          :
-'-------------'    '-<--<--<--' '-------------'
-```
+        ```json
+        {
+          "command": "SetIceCandidate",
+          "data": {
+            "peer_id": 2,
+            "candidate": "user2_ice_candidate"
+          }
+        }
+        ```
 
-7\. `user1` wants to unpublish his tracks, so he sends `TracksRemoved` to the server:
+    4. `Media Server` => `user1`:
 
-```json
-{
-  "method": "RemoveTracks",
-  "payload": {
-    "peer_id": 1,
-    "tracks": [1, 2]
-  }
-}
-```
+        ```json
+        {
+          "event": "IceCandidateDiscovered",
+          "data": {
+            "peer_id": 1,
+            "candidate": "user2_ice_candidate"
+          }
+        }
+        ```
+
+6. At this point connection is supposed to be established:
+
+    ```
+    .----user1----.    .->-->-->--. .----user2----.
+    :             o(1)=:          :=o(2)          :
+    '-------------'    '-<--<--<--' '-------------'
+    ```
+    
+7. `user1` wants to unpublish his `Track`s, so he sends `RemoveTracks` command to `Media Server`:
+
+    ```json
+    {
+      "command": "RemoveTracks",
+      "data": {
+        "peer_id": 1,
+        "tracks": [1, 2]
+      }
+    }
+    ```
 
-8\. Server updates `user2` tracks:
+8. `Media Server` updates `user2` `Track`s:
 
-```json
-{
-  "method": "TracksRemoved",
-  "payload": {
-    "peer_id": 2,
-    "tracks": [1, 2]
-  }
-}
-```
+    ```json
+    {
+      "event": "TracksRemoved",
+      "data": {
+        "peer_id": 2,
+        "tracks": [1, 2]
+      }
+    }
+    ```
 
-9\. Server updates `user1` tracks:
+9. `Media Server` updates `user1` `Track`s:
 
-```json
-{
-  "method": "TracksRemoved",
-  "payload": {
-    "peer_id": 1,
-    "tracks": [1, 2]
-  }
-}
-```
+    ```json
+    {
+      "event": "TracksRemoved",
+      "data": {
+        "peer_id": 1,
+        "tracks": [1, 2]
+      }
+    }
+    ```
 
-10\. `user1` initiates SDP re-negotiation: `user1` sends `MakeSdpOffer`, `Server` relays `SdpOfferMade` to `user2`, `user2` sends `MakeSDPAnswer`, `Server` relays `SdpAnswerMade` to `user1`.
+10. `user1` initiates SDP re-negotiation: 
 
-```
-.----user1----.         .----user2----.
-:             o(1)-<--<-o(2)          :
-'-------------'         '-------------'
-```
+    1. `user1` sends `MakeSdpOffer` command.
 
-11\. Server notifies `user1` that he can publish to `user2`:
+    2. `Media Server` sends `SdpOfferMade` event to `user2`.
 
-```json
-{
-  "method": "RemotePeersUpdated",
-  "payload": {
-    "peers": [{
-      "peer_id": 2,
-      "member_id": "user_2",
-      "can_rx": null,
-      "can_tx": {
-        "AudioVideo": {
-          "audio_settings": {},
-          "video_settings": {}
-        }
-      }
-    }]
-  }
-}
-```
+    3. `user2` sends `MakeSdpAnswer` command.
 
-12\. Server notifies `user2` that he can subscribe to `user1`:
+    4. `Media Server` sends `SdpAnswerMade` event to `user1`.
 
-```json
-{
-  "method": "RemotePeersUpdated",
-  "payload": {
-    "peers": [{
-      "peer_id": 1,
-      "member_id": "user_1",
-      "can_rx": {
-        "AudioVideo": {
-          "audio_settings": {},
-          "video_settings": {}
-        }
-      },
-      "can_tx": null
-    }]
-  }
-}
-```
+    ```
+    .----user1----.         .----user2----.
+    :             o(1)-<--<-o(2)          :
+    '-------------'         '-------------'
+    ```
 
-13\. `user1` requests to publish to `user2`:
+11. `Media Server` notifies `user1` that he can publish to `user2`:
 
-```json
-{
-  "method": "RequestRemoteTracks",
-  "payload": {
-    "peer_id": 1,
-    "remote_peer_id": 2,
-    "rx": null,
-    "tx": {
-      "AudioVideo": {
-        "audio_settings": {},
-        "video_settings": {}
+    ```json
+    {
+      "event": "RemotePeersUpdated",
+      "data": {
+        "peers": [{
+          "peer_id": 2,
+          "member_id": "user_2",
+          "can_rx": null,
+          "can_tx": {
+            "AudioVideo": {
+              "audio_settings": {},
+              "video_settings": {}
+            }
+          }
+        }]
       }
     }
-  }
-}
-```
-
-14\. Server updates `user2` tracks:
-
-```json
-{
-  "method": "TracksApplied",
-  "payload": {
-    "peer_id": 2,
-    "tracks": [{
-      "id": 1,
-      "media_type": {
-        "Audio": {}
-      },
-      "direction": {
-        "Recv": {
-          "sender": 1
-        }
+    ```
+
+12. `Media Server` notifies `user2` that he can subscribe to `user1`:
+
+    ```json
+    {
+      "event": "RemotePeersUpdated",
+      "data": {
+        "peers": [{
+          "peer_id": 1,
+          "member_id": "user_1",
+          "can_rx": {
+            "AudioVideo": {
+              "audio_settings": {},
+              "video_settings": {}
+            }
+          },
+          "can_tx": null
+        }]
       }
-    }, {
-      "id": 2,
-      "media_type": {
-        "Audio": {}
-      },
-      "direction": {
-        "Recv": {
-          "sender": 1
+    }
+    ```
+
+13. `user1` requests to publish to `user2`:
+
+    ```json
+    {
+      "command": "RequestRemoteTracks",
+      "data": {
+        "peer_id": 1,
+        "remote_peer_id": 2,
+        "rx": null,
+        "tx": {
+          "AudioVideo": {
+            "audio_settings": {},
+            "video_settings": {}
+          }
         }
       }
-    }]
-  }
-}
-```
-
-15\. Server updates `user1` tracks:
-
-```json
-{
-  "method": "TracksApplied",
-  "payload": {
-    "peer_id": 1,
-    "tracks": [{
-      "id": 1,
-      "media_type": {
-        "Audio": {}
-      },
-      "direction": {
-        "Send": {
-          "receivers": [2]
-        }
+    }
+    ```
+
+14. `Media Server` updates `user2` `Track`s:
+
+    ```json
+    {
+      "event": "TracksApplied",
+      "data": {
+        "peer_id": 2,
+        "tracks": [{
+          "id": 1,
+          "media_type": {
+            "Audio": {}
+          },
+          "direction": {
+            "Recv": {
+              "sender": 1
+            }
+          }
+        }, {
+          "id": 2,
+          "media_type": {
+            "Audio": {}
+          },
+          "direction": {
+            "Recv": {
+              "sender": 1
+            }
+          }
+        }]
       }
-    }, {
-      "id": 2,
-      "media_type": {
-        "Video": {}
-      },
-      "direction": {
-        "Send": {
-          "receivers": [2]
-        }
+    }
+    ```
+
+15. `Media Server` updates `user1` `Track`s:
+
+    ```json
+    {
+      "event": "TracksApplied",
+      "data": {
+        "peer_id": 1,
+        "tracks": [{
+          "id": 1,
+          "media_type": {
+            "Audio": {}
+          },
+          "direction": {
+            "Send": {
+              "receivers": [2]
+            }
+          }
+        }, {
+          "id": 2,
+          "media_type": {
+            "Video": {}
+          },
+          "direction": {
+            "Send": {
+              "receivers": [2]
+            }
+          }
+        }]
       }
-    }]
-  }
-}
-```
+    }
+    ```
 
-16\. SDP re-negotiation: `user1` sends `MakeSdpOffer`, `Server` relays `SdpOfferMade` to `user2`, `user2` sends `MakeSDPAnswer`, `Server` relays `SdpAnswerMade` to `user1`.
+16. SDP re-negotiation: 
 
-```
-.----user1----.    .->-->-->--. .----user2----.
-:             o(1)=:          :=o(2)          :
-'-------------'    '-<--<--<--' '-------------'
-```
-</details>
+    1. `user1` sends `MakeSdpOffer` command.
+
+    2. `Media Server` sends `SdpOfferMade` event to `user2`. 
 
+    3. `user2` sends `MakeSdpAnswer` command.
+
+    4. `Media Server` sends `SdpAnswerMade` event to `user1`.
+
+    ```
+    .----user1----.    .->-->-->--. .----user2----.
+    :             o(1)=:          :=o(2)          :
+    '-------------'    '-<--<--<--' '-------------'
+    ```
+</details>
 
 <details>
 <summary>1 => 2 SFU</summary>
@@ -1394,362 +1413,368 @@ struct GetMembers {
                                                        '------------------'
 ```
 
-1\. Server requests `user1` to create `sendonly` `Peer` passing Server's [SDP Offer]:
-
-```json
-{
-  "method": "PeerCreated",
-  "payload": {
-    "peer": {
-      "peer_id": 1,
-      "tracks": [{
-        "id": 1,
-        "media_type": {
-          "Audio": {}
+1. `Media Server` notifies `user1` to create `sendonly` `Peer` passing its [SDP Offer]:
+
+    ```json
+    {
+      "event": "PeerCreated",
+      "data": {
+        "peer": {
+          "peer_id": 1,
+          "tracks": [{
+            "id": 1,
+            "media_type": {
+              "Audio": {}
+            },
+            "direction": {
+              "Send": {
+                "receivers": []
+              }
+            }
+          }, {
+            "id": 2,
+            "media_type": {
+              "Video": {}
+            },
+            "direction": {
+              "Send": {
+                "receivers": []
+              }
+            }
+          }]
         },
-        "direction": {
-          "Send": {
-            "receivers": []
-          }
-        }
-      }, {
-        "id": 2,
-        "media_type": {
-          "Video": {}
-        },
-        "direction": {
-          "Send": {
-            "receivers": []
-          }
-        }
-      }]
-    },
-    "sdp_offer": "server_user1_recvonly_offer",
-    "ice_servers": [{
-      "urls": [
-        "turn:turnserver.com:3478",
-        "turn:turnserver.com:3478?transport=tcp"
-      ],
-      "username": "turn_user",
-      "credential": "turn_credential"
-    }]
-  }
-}
-```
-
-2\. `user1` creates peer and answers with [SDP Answer]:
-
-```json
-{
-  "method": "MakeSDPAnswer",
-  "payload": {
-    "peer_id": 1,
-    "sdp_answer": "user_1_sendonly_answer"
-  }
-}
-```
+        "sdp_offer": "server_user1_recvonly_offer",
+        "ice_servers": [{
+          "urls": [
+            "turn:turnserver.com:3478",
+            "turn:turnserver.com:3478?transport=tcp"
+          ],
+          "username": "turn_user",
+          "credential": "turn_credential"
+        }]
+      }
+    }
+    ```
 
-3\. Server and `user1` exchange [ICE Candidate]s:
+2. `user1` creates `Peer` and answers with [SDP Answer]:
 
-`user1` => `Server`
-```json
-{
-  "method": "SetIceCandidate",
-  "payload": {
-    "peer_id": 1,
-    "candidate": "user1_ice_candidate"
-  }
-}
-```
+    ```json
+    {
+      "command": "MakeSdpAnswer",
+      "data": {
+        "peer_id": 1,
+        "sdp_answer": "user_1_sendonly_answer"
+      }
+    }
+    ```
 
-`Server` => `user1`
-```json
-{
-  "method": "IceCandidatesDiscovered",
-  "payload": {
-    "peer_id": 1,
-    "candidate": "server_ice_candidate"
-  }
-}
-```
+3. `Media Server` and `user1` exchange their [ICE Candidate]s:
 
-4\. Connection is established:
+    1. `user1` => `Media Server`:
 
-```
-                          .-------SFU-------.
-.------user1------.       :                 ;
-:    pc_id = 1    o-->-->-o                 :
-'-----------------'       :                 ;
-                          '-----------------'
-```
+        ```json
+        {
+          "command": "SetIceCandidate",
+          "data": {
+            "peer_id": 1,
+            "candidate": "user1_ice_candidate"
+          }
+        }
+        ```
 
-5\. Server requests `user2` to create `recvonly` `Peer` passing Server's [SDP Offer]:
+    2. `Media Server` => `user1`:
 
-```json
-{
-  "method": "PeerCreated",
-  "payload": {
-    "peer": {
-      "peer_id": 2,
-      "tracks": [{
-        "id": 1,
-        "media_type": {
-          "Audio": {}
-        },
-        "direction": {
-          "Recv": {
-            "sender": 1
+        ```json
+        {
+          "event": "IceCandidateDiscovered",
+          "data": {
+            "peer_id": 1,
+            "candidate": "server_ice_candidate"
           }
         }
-      }, {
-        "id": 2,
-        "media_type": {
-          "Video": {}
+        ```
+
+4. Connection is established:
+
+    ```
+                              .-------SFU-------.
+    .------user1------.       :                 ;
+    :    pc_id = 1    o-->-->-o                 :
+    '-----------------'       :                 ;
+                              '-----------------'
+    ```
+
+5. `Media Server` notifies `user2` to create `recvonly` `Peer` passing its [SDP Offer]:
+
+    ```json
+    {
+      "event": "PeerCreated",
+      "data": {
+        "peer": {
+          "peer_id": 2,
+          "tracks": [{
+            "id": 1,
+            "media_type": {
+              "Audio": {}
+            },
+            "direction": {
+              "Recv": {
+                "sender": 1
+              }
+            }
+          }, {
+            "id": 2,
+            "media_type": {
+              "Video": {}
+            },
+            "direction": {
+              "Recv": {
+                "sender": 1
+              }
+            }
+          }]
         },
-        "direction": {
-          "Recv": {
-            "sender": 1
-          }
-        }
-      }]
-    },
-    "sdp_offer": "server_user2_sendonly_offer",
-    "ice_servers": [{
-      "urls": [
-        "turn:turnserver.com:3478",
-        "turn:turnserver.com:3478?transport=tcp"
-      ],
-      "username": "turn_user",
-      "credential": "turn_credential"
-    }]
-  }
-}
-```
-
-6\. `user2` answers with [SDP Answer]:
-
-```json
-{
-  "method": "MakeSDPAnswer",
-  "payload": {
-    "peer_id": 2,
-    "sdp_answer": "user_2_recvonly_answer"
-  }
-}
-```
-
-7\. Server and `user2` exchange [ICE Candidate]s:
-
-`user2` => `Server`
-```json
-{
-  "method": "SetIceCandidate",
-  "payload": {
-    "peer_id": 2,
-    "candidate": "user2_ice_candidate"
-  }
-}
-```
+        "sdp_offer": "server_user2_sendonly_offer",
+        "ice_servers": [{
+          "urls": [
+            "turn:turnserver.com:3478",
+            "turn:turnserver.com:3478?transport=tcp"
+          ],
+          "username": "turn_user",
+          "credential": "turn_credential"
+        }]
+      }
+    }
+    ```
 
-`Server` => `user2`
-```json
-{
-  "method": "IceCandidatesDiscovered",
-  "payload": {
-    "peer_id": 2,
-    "candidate": "server_ice_candidate"
-  }
-}
-```
+6. `user2` answers with [SDP Answer]:
 
-8\. `user2` is connected to Server's peer connection:
+    ```json
+    {
+      "command": "MakeSdpAnswer",
+      "data": {
+        "peer_id": 2,
+        "sdp_answer": "user_2_recvonly_answer"
+      }
+    }
+    ```
 
-```
-                                                       .-------user2------.
-                          .-------SFU-------.    .-->--o     pc_id = 2    :
-.------user1------.       :                 o-->-'     '------------------'
-:    pc_id = 1    o-->-->-o-                :
-'-----------------'       :                 :
-                          '-----------------'
-```
+7. `Media Server` and `user2` exchange their [ICE Candidate]s:
 
-9\. Server notifies `user1` that he has new subscriber:
+    1. `user2` => `Media Server`:
 
-```json
-{
-  "method": "TracksApplied",
-  "payload": {
-    "peer_id": 1,
-    "tracks": [{
-      "id": 1,
-      "media_type": {
-        "Audio": {}
-      },
-      "direction": {
-        "Send": {
-          "receivers": [2]
-        }
-      }
-    }, {
-      "id": 2,
-      "media_type": {
-        "Video": {}
-      },
-      "direction": {
-        "Send": {
-          "receivers": [2]
+        ```json
+        {
+          "command": "SetIceCandidate",
+          "data": {
+            "peer_id": 2,
+            "candidate": "user2_ice_candidate"
+          }
         }
-      }
-    }]
-  }
-}
-```
+        ```
 
-10\. Server sends `user1` `Peer {peer_id = 1}` media to `user2` `Peer {peer_id = 2}`:
+    2. `Media Server` => `user2`:
 
-```
-                                                        .-------user2------.
-                           .-------SFU-------.    .-->--o     pc_id = 2    :
- .------user1------.       :         .->-->--o-->-'     '------------------'
- :    pc_id = 1    o-->-->-o--->-->--'       :
- '-----------------'       :                 :
-                           '-----------------'
-```
-
-11\. Server requests `user3` to create `recvonly` `Peer` passing Server's [SDP Offer]: 
-
-```json
-{
-  "method": "PeerCreated",
-  "payload": {
-    "peer": {
-      "peer_id": 3,
-      "tracks": [{
-        "id": 1,
-        "media_type": {
-          "Audio": {}
-        },
-        "direction": {
-          "Recv": {
-            "sender": 1
+        ```json
+        {
+          "event": "IceCandidateDiscovered",
+          "data": {
+            "peer_id": 2,
+            "candidate": "server_ice_candidate"
           }
         }
-      }, {
-        "id": 2,
-        "media_type": {
-          "Video": {}
-        },
-        "direction": {
-          "Recv": {
-            "sender": 1
+        ```
+
+8. `user2` is connected to `Media Server`'s [RTCPeerConnection]:
+
+    ```
+                                                           .-------user2------.
+                              .-------SFU-------.    .-->--o     pc_id = 2    :
+    .------user1------.       :                 o-->-'     '------------------'
+    :    pc_id = 1    o-->-->-o-                :
+    '-----------------'       :                 :
+                              '-----------------'
+    ```
+
+9. `Media Server` notifies `user1` that he has new subscriber:
+
+    ```json
+    {
+      "event": "TracksApplied",
+      "data": {
+        "peer_id": 1,
+        "tracks": [{
+          "id": 1,
+          "media_type": {
+            "Audio": {}
+          },
+          "direction": {
+            "Send": {
+              "receivers": [2]
+            }
           }
-        }
-      }]
-    },
-    "sdp_offer": "server_user3_sendonly_offer",
-    "ice_servers": [{
-      "urls": [
-        "turn:turnserver.com:3478",
-        "turn:turnserver.com:3478?transport=tcp"
-      ],
-      "username": "turn_user",
-      "credential": "turn_credential"
-    }]
-  }
-}
-```
-
-12\. `user2` answers with [SDP Answer]:
-
-```json
-{
-  "method": "MakeSDPAnswer",
-  "payload": {
-    "peer_id": 3,
-    "sdp_answer": "user_3_recvonly_answer"
-  }
-}
-```
+        }, {
+          "id": 2,
+          "media_type": {
+            "Video": {}
+          },
+          "direction": {
+            "Send": {
+              "receivers": [2]
+            }
+          }
+        }]
+      }
+    }
+    ```
+
+10. `Media Server` sends `user1` `Peer {peer_id = 1}` media to `user2` `Peer {peer_id = 2}`:
+
+    ```
+                                                            .-------user2------.
+                               .-------SFU-------.    .-->--o     pc_id = 2    :
+     .------user1------.       :         .->-->--o-->-'     '------------------'
+     :    pc_id = 1    o-->-->-o--->-->--'       :
+     '-----------------'       :                 :
+                               '-----------------'
+    ```
+
+11. `Media Server` notifies `user3` to create `recvonly` `Peer` passing its [SDP Offer]: 
+
+    ```json
+    {
+      "event": "PeerCreated",
+      "data": {
+        "peer": {
+          "peer_id": 3,
+          "tracks": [{
+            "id": 1,
+            "media_type": {
+              "Audio": {}
+            },
+            "direction": {
+              "Recv": {
+                "sender": 1
+              }
+            }
+          }, {
+            "id": 2,
+            "media_type": {
+              "Video": {}
+            },
+            "direction": {
+              "Recv": {
+                "sender": 1
+              }
+            }
+          }]
+        },
+        "sdp_offer": "server_user3_sendonly_offer",
+        "ice_servers": [{
+          "urls": [
+            "turn:turnserver.com:3478",
+            "turn:turnserver.com:3478?transport=tcp"
+          ],
+          "username": "turn_user",
+          "credential": "turn_credential"
+        }]
+      }
+    }
+    ```
 
-13\. Server and `user3` exchange [ICE Candidate]s:
+12. `user2` answers with [SDP Answer]:
 
-`user3` => `Server`
-```json
-{
-  "method": "SetIceCandidate",
-  "payload": {
-    "peer_id": 3,
-    "candidate": "user3_ice_candidate"
-  }
-}
-```
+    ```json
+    {
+      "command": "MakeSdpAnswer",
+      "data": {
+        "peer_id": 3,
+        "sdp_answer": "user_3_recvonly_answer"
+      }
+    }
+    ```
 
-`Server` => `user3`
-```json
-{
-  "method": "IceCandidatesDiscovered",
-  "payload": {
-    "peer_id": 3,
-    "candidate": "server_ice_candidate"
-  }
-}
-```
+13. `Media Server` and `user3` exchange their [ICE Candidate]s:
 
-14\. `user3` is connected to Server's peer connection:
+    1. `user3` => `Media Server`:
 
-```
-                                                       .-------user2------.
-                          .-------SFU-------.    .-->--o     pc_id = 2    :
-.------user1------.       :       .---->----o-->-'     '------------------'
-:    pc_id = 1    o-->-->-o--->---'         :
-'-----------------'       :                 o-->-.     .-------user3------.
-                          '-----------------'    '-->--o     pc_id = 3    :
-                                                       '------------------'
-```
+        ```json
+        {
+          "command": "SetIceCandidate",
+          "data": {
+            "peer_id": 3,
+            "candidate": "user3_ice_candidate"
+          }
+        }
+        ```
 
-15\. Server notifies `user1` that he has new subscriber:
+    2. `Media Server` => `user3`:
 
-```json
-{
-  "method": "TracksApplied",
-  "payload": {
-    "peer_id": 1,
-    "tracks": [{
-      "id": 1,
-      "media_type": {
-        "Audio": {}
-      },
-      "direction": {
-        "Send": {
-          "receivers": [2, 3]
-        }
-      }
-    }, {
-      "id": 2,
-      "media_type": {
-        "Video": {}
-      },
-      "direction": {
-        "Send": {
-          "receivers": [2, 3]
+        ```json
+        {
+          "event": "IceCandidateDiscovered",
+          "data": {
+            "peer_id": 3,
+            "candidate": "server_ice_candidate"
+          }
         }
+        ```
+
+14. `user3` is connected to `Media Server`'s [RTCPeerConnection]:
+
+    ```
+                                                           .-------user2------.
+                              .-------SFU-------.    .-->--o     pc_id = 2    :
+    .------user1------.       :       .---->----o-->-'     '------------------'
+    :    pc_id = 1    o-->-->-o--->---'         :
+    '-----------------'       :                 o-->-.     .-------user3------.
+                              '-----------------'    '-->--o     pc_id = 3    :
+                                                           '------------------'
+    ```
+
+15. `Media Server` notifies `user1` that he has new subscriber:
+
+    ```json
+    {
+      "event": "TracksApplied",
+      "data": {
+        "peer_id": 1,
+        "tracks": [{
+          "id": 1,
+          "media_type": {
+            "Audio": {}
+          },
+          "direction": {
+            "Send": {
+              "receivers": [2, 3]
+            }
+          }
+        }, {
+          "id": 2,
+          "media_type": {
+            "Video": {}
+          },
+          "direction": {
+            "Send": {
+              "receivers": [2, 3]
+            }
+          }
+        }]
       }
-    }]
-  }
-}
-```
-
-16\. Server sends `user1` `Peer {peer_id = 1}` media to `user2` `Peer {peer_id = 3}`:
-
-```
-                                                     .-------user2------.
-                          .-------SFU-------.    .->-o     pc_id = 2    :
-.------user1------.       :       .---->----o-->-'   '------------------'
-:    pc_id = 1    o-->-->-o--->---:         :
-'-----------------'       :       '---->----o-->-.   .-------user3------.
-                          '-----------------'    '->-o     pc_id = 3    :
-                                                     '------------------'
-```
+    }
+    ```
+
+16. `Media Server` sends `user1` `Peer {peer_id = 1}` media to `user3` `Peer {peer_id = 3}`:
+
+    ```
+                                                         .-------user2------.
+                              .-------SFU-------.    .->-o     pc_id = 2    :
+    .------user1------.       :       .---->----o-->-'   '------------------'
+    :    pc_id = 1    o-->-->-o--->---:         :
+    '-----------------'       :       '---->----o-->-.   .-------user3------.
+                              '-----------------'    '->-o     pc_id = 3    :
+                                                         '------------------'
+    ```
 </details>
 
 

From bbe80e7f69bd8989f08499319e6e202d2aedab90 Mon Sep 17 00:00:00 2001
From: tyranron <tyranron@gmail.com>
Date: Mon, 7 Jan 2019 18:48:20 +0200
Subject: [PATCH 21/24] Provide event WS message format

---
 docs/rfc/0002-webrc-client-api.md | 13 +++++++++++++
 1 file changed, 13 insertions(+)

diff --git a/docs/rfc/0002-webrc-client-api.md b/docs/rfc/0002-webrc-client-api.md
index 63d16ab08..a2b54132e 100644
--- a/docs/rfc/0002-webrc-client-api.md
+++ b/docs/rfc/0002-webrc-client-api.md
@@ -194,6 +194,19 @@ struct VideoSettings {}
 
 The naming for `Event` follows the convention `<entity><passive-verb>`, for example: `PeerCreated`, `TracksApplied`, `PeersRemoved`.
 
+The format of `Event` [WebSocket] message may be implemented as the following:
+```rust
+struct EventWebSocketMessage {
+    event: String,
+    data: EventData,
+    meta: Option<EventMeta>,
+}
+```
+Where:
+- `event`: name of concrete `Event` (declared below);
+- `data`: data provided by this `Event` (declared below);
+- `meta`: optional metadata of the `Event` for debugging or tracing purposes (may be fully omitted).
+
 #### 1. PeerCreated
 
 ```rust

From 7aae042de0f0a67869923adece5d738aa8617d4b Mon Sep 17 00:00:00 2001
From: tyranron <tyranron@gmail.com>
Date: Mon, 7 Jan 2019 18:50:55 +0200
Subject: [PATCH 22/24] Provide command WS message format

---
 docs/rfc/0002-webrc-client-api.md | 13 +++++++++++++
 1 file changed, 13 insertions(+)

diff --git a/docs/rfc/0002-webrc-client-api.md b/docs/rfc/0002-webrc-client-api.md
index a2b54132e..5a6d0c552 100644
--- a/docs/rfc/0002-webrc-client-api.md
+++ b/docs/rfc/0002-webrc-client-api.md
@@ -692,6 +692,19 @@ It's recommended to cache `Peer` ID and `Member` ID relations in `Web Client`'s
 
 The naming for `Command` follows the convention `<infinitive-verb><entity>`, for example: `ApplyTracks`, `MakeSdpOffer`, `MakeSdpAnswer`.
 
+The format of `Command` [WebSocket] message may be implemented as the following:
+```rust
+struct CommandWebSocketMessage {
+    command: String,
+    data: CommandData,
+    meta: Option<CommandMeta>,
+}
+```
+Where:
+- `command`: name of concrete `Command` (declared below);
+- `data`: data provided by this `Command` (declared below);
+- `meta`: optional metadata of the `Command` for debugging or tracing purposes (may be fully omitted).
+
 #### 1. RemovePeers
 
 ```rust

From f6c7e71fdf9786a7cf2ab4686a77a263f4ee34f0 Mon Sep 17 00:00:00 2001
From: tyranron <tyranron@gmail.com>
Date: Mon, 7 Jan 2019 18:53:55 +0200
Subject: [PATCH 23/24] Fix

---
 docs/rfc/0002-webrc-client-api.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/docs/rfc/0002-webrc-client-api.md b/docs/rfc/0002-webrc-client-api.md
index 5a6d0c552..2f9379cd3 100644
--- a/docs/rfc/0002-webrc-client-api.md
+++ b/docs/rfc/0002-webrc-client-api.md
@@ -1,7 +1,7 @@
 - Feature Name: `client_webrtc_api`
 - Start Date: 2018-12-13
 - RFC PR: [instrumentisto/medea#7](https://github.com/instrumentisto/medea/pull/7)
-- Tracking Issue: [instrumentisto/medea#4](https://github.com/instrumentisto/medea/issues/6)
+- Tracking Issue: [instrumentisto/medea#6](https://github.com/instrumentisto/medea/issues/6)
 
 
 

From c5d23045465cad539aa46ad3597e0a83a5b93a43 Mon Sep 17 00:00:00 2001
From: alexlapa <lapa.alex@ex.ua>
Date: Mon, 7 Jan 2019 12:27:35 -0500
Subject: [PATCH 24/24] fix

---
 docs/rfc/0002-webrc-client-api.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/docs/rfc/0002-webrc-client-api.md b/docs/rfc/0002-webrc-client-api.md
index 2f9379cd3..cbd40f5c2 100644
--- a/docs/rfc/0002-webrc-client-api.md
+++ b/docs/rfc/0002-webrc-client-api.md
@@ -26,7 +26,7 @@ You will need to express ways to:
 4. Pass some user metadata to hook business logic onto.
 5. Build more complex connection graphs.
 6. Dynamically cancel/begin media publishing/receiving.
-7. Passing errors, [RTCPeerConnection]s and [RTCStatsReport]s.
+7. Passing errors, [RTCStatsReport]s of underlying [RTCPeerConnection]s.
 8. Cover both [P2P full mesh] and hub server ([SFU], [MCU]) scenarios.
 
 The protocol must be versatile enough to cover all possible use cases.