doc: add session WG meeting

doc/meetings/2017-02-21-sessions.md

@@ -0,0 +1,65 @@
+# Sessions WG meeting
+
+Date: 2017-02-21
+
+### Invited:
+
+ * Alexey Orlenko <eaglexrlnk@gmail.com>
+   ([@aqrln](https://github.com/aqrln)) from server team
+ * Mykola Bilochub <nbelochub@gmail.com>
+   ([@belochub](https://github.com/belochub)) from server team
+ * Denys Otrishko <shishugi@gmail.com>
+   ([@lundibundi](https://github.com/lundibundi)) from Android team
+ * Andrew Vysotskyi <firemaaaan@gmail.com>
+   ([@Gagnant](https://github.com/Gagnant)) from iOS team
+
+### Present:
+
+ * Alexey Orlenko <eaglexrlnk@gmail.com>
+   ([@aqrln](https://github.com/aqrln)) from server team
+ * Mykola Bilochub <nbelochub@gmail.com>
+   ([@belochub](https://github.com/belochub)) from server team
+ * Denys Otrishko <shishugi@gmail.com>
+   ([@lundibundi](https://github.com/lundibundi)) from Android team
+
+### Agenda:
+
+ * General way of reconnection to existing sessions;
+ * Session restoration mechanisms architecture;
+ * The problems with reconnection mobile developers encountered in our last
+   project and proper ways to solve them;
+ * Handshake packet formats (for request and response) that will be used to
+   implement reconnection to existing sessions.
+
+### Conclusions:
+
+ * To make packet numbers unique for every session, not connection like it was before;
+ * To send total count of packets sent and received by each side during the session
+   in handshake packet, like this:
+
+   ```javascript
+   { handshake: [0, 'appName'], session: ['sessionId', sent_count, received_count] }
+   ```
+
+   and answer
+
+   ```javascript
+   { handshake: [0], ok: [sent_count, received_count] }
+   ```
+
+### Post-discussion additions:
+
+1. Even though packet IDs are incremented throughout the session, not the
+   connection, handshake packets are always 0 since we don't know which packet
+   IDs to use until a handshake has been performed. After that, the order
+   continues as it should have been if there hadn't been reconnection, with an
+   extra handshake being transparent.
+
+2. The standard `ERR_AUTH_FAILED` error will be used for any handshake
+   authentication strategy, regardless of it being `login`, `session` or
+   anything we may probably add later. What it means for session restoration
+   handshakes is that if session ID is invalid, the server responds with
+
+   ```javascript
+   { handshake: [0], error: [11] }
+   ```