update README for new api

Author: facundoolano

README.md

@@ -45,8 +45,8 @@ var pc = new RTCPeerConnection({
 });
 ```
 
-The [example directory](https://github.com/lambdaclass/webrtc-server/tree/master/example)
-contains a full Cowboy application using `webrtc_server` and a simple
+The [examples/simple](https://github.com/lambdaclass/webrtc-server/tree/master/examples/simple)
+directory contains a full Cowboy application using `webrtc_server` and a
 browser client that establishes a WebRTC connection using the
 Signaling and ICE servers.
 
@@ -106,6 +106,13 @@ Both callbacks receive the same arguments:
   `infinity` to disable idle timeouts.
 
 ## Signaling API reference
+
+The signaling API is used by web socket clients to exchange the
+necessary information to establish a WebRTC peer connection. See
+the
+[examples](https://github.com/lambdaclass/webrtc-server/tree/master/examples)
+for context on how this API is used.
+
 ### Authentication
 After connection, an authentication JSON message should be sent:
 
@@ -119,23 +126,71 @@ After connection, an authentication JSON message should be sent:
 }
 ```
 
-The server will reply with this payload:
+The server will assign a `peer_id` to the client and reply:
+
+``` json
+{
+    "event": "authenticated",
+    "data": {
+        "peer_id": "bxCBrwyL3Ar7Nw=="
+    }
+}
+```
+
+The rest of the peers in the room will receive a `joined` event:
 
 ``` json
 {
     "event": "joined",
     "data": {
         "username": "john",
-        "peer_id": "bxCBrwyL3Ar7Nw==",
-        "peers": ["7nN1q/qarRnejQ=="]
+        "peer_id": "bxCBrwyL3Ar7Nw=="
+    }
+}
+```
+
+Similarly, when a client leaves the room, the rest of the peers will
+receive a `left` event:
+
+``` json
+{
+    "event": "left",
+    "data": {
+        "username": "john",
+        "peer_id": "bxCBrwyL3Ar7Nw=="
     }
 }
 ```
 
-### Room messages
+### Signaling messages
+
+After authentication, all messages sent by the client should be
+signaling messages addressed to a specific peer in the room, including a `to`
+field. The event and data are opaque to the server (they can be
+ice candidates, session descriptions, or whatever clients need to
+exchange). For example:
 
-After authentication, any (non ping) message sent will be forwarded to
-the rest of the clients connected to the room.
+``` json
+{
+    "event": "candidate",
+    "to": "458/53WAkeu+tQ==",
+    "data": {
+        ...
+    }
+}
+```
+
+The addressed peer will receive this payload:
+
+``` json
+{
+    "event": "candidate",
+    "from": "bxCBrwyL3Ar7Nw==",
+    "data": {
+        ...
+    }
+}
+```
 
 ### Ping
 To send a keepalive message to prevent idle connections to be droped

examples/multi/README.md

@@ -1,8 +1,11 @@
-# WebRTC example
-
-Simple Cowboy application that serves an HTML client for WebRTC.
-Connections are established by two peers that enter in the same room URL.
-The client connects to the signaling and ICE servers provided by webrtc_server.
+# WebRTC multi-party example
+
+Cowboy application that serves an HTML client for WebRTC.
+An unlimited number of peers can join a conversation by entering the
+same room URL.
+A mesh topology is used, meaning that if there are N peers, each one
+will maintain N - 1 RTC peer connections. This is CPU intensive and
+will work with a low number of peers.
 
 ## Run in development
 

examples/simple/README.md

@@ -1,4 +1,4 @@
-# WebRTC example
+# WebRTC simple example
 
 Simple Cowboy application that serves an HTML client for WebRTC.
 Connections are established by two peers that enter in the same room URL.

src/webrtc_ws_handler.erl

@@ -128,7 +128,7 @@ join_room(Room, Username, PeerId) ->
   run_callback(join_callback, Room, Username, OtherNames),
 
   %% broadcast peer joined to the rest of the peers in the room
-  Message = reply_text(joined, #{peer_id => PeerId}),
+  Message = reply_text(joined, #{peer_id => PeerId, username => Username}),
   lists:foreach(fun({Pid, _}) -> Pid ! Message end, OtherMembers).
 
 run_callback(Type, Room, Username, CurrentUsers) ->