doc/proto.texi

   1 @node Protocol
   2 @unnumbered Protocol
   3
   4 VoRS uses the Opus codec with 20ms frames with 48kHz 1ch 16-bit S-LE
   5 sound. It uses native @code{libopus}'es Packet Loss Concealment (PLC)
   6 feature when the number of lost frame does not exceed 32 count. DTX
   7 (discontinuous transmission) is also on.
   8
   9 Each frame has a single byte stream identifier (unique identifier of the
  10 participant) and 24-bit big-endian packet counter. Reordered packets are
  11 dropped. 24-bit counter is long enough for very long talk sessions.
  12
  13 Each packet is encrypted with ChaCha20 and authenticated with SipHash24.
  14 Their keys are generated from BLAKE2s-XOF, which is fed with completed
  15 handshake's binding value. Then they are shared among the other
  16 participants. The stream identifier together with the packet counter is
  17 used as a nonce.
  18
  19 It is tuned for 24Kbps bandwidth. But remember that it has additional 8B
  20 of MAC tag, 4B VoRS, 8B UDP and 40B IPv6 headers.
  21
  22 Each client handshakes with the server over TCP connection using the
  23 @url{http://noiseprotocol.org/, Noise}-NK protocol pattern with
  24 curve25519, ChaCha20-Poly1305 and BLAKE2s algorithms.
  25
  26 @itemize
  27
  28 @item Client sends @code{VoRS v2} to the socket. Just a magic number.
  29
  30 @item All next messages are prepended with 16-bit big-endian length.
  31
  32 @item Client sends initial Noise handshake message with his username as
  33 a payload.
  34
  35 @item Server answers with final noise handshake message with the payload
  36 of @code{OK HEX(COOKIE)}, or any other failure message. It may reject a
  37 client if there are too many peers or its name is already taken.
  38
  39 @item The 128-bit cookie is sent by client over UDP to the server every
  40 second. If UDP packets are lost, then no connection is possible and
  41 after a timeout the server drops the TCP connection. That cookie means:
  42
  43     @itemize
  44     @item confirmation of successful handshake on client side;
  45     @item UDP hole punching of stateful firewall or NAT;
  46     @item fact of client's UDP traffic ability to reach the server;
  47     @item client's UDP address knowledge (after passing NAT, its port
  48         may differ from known to client one)
  49     @end itemize
  50
  51 @item Server replies with @code{SID XXX}, where XXX is ASCII decimal
  52 stream number client must use.
  53
  54 @item @code{PING} and @code{PONG} messages are then sent every ten
  55 seconds as a heartbeat.
  56
  57 @end itemize
  58
  59 @example
  60 S <- C : e, es, "username"
  61 S -> C : e, ee, "OK COOKIE"
  62 S <- C : UDP(COOKIE)
  63 S -> C : "SID XXX"
  64
  65 S <- C : "PING"
  66 S -> C : "PONG"
  67 S <> C : ...
  68
  69 S -> C : "ADD SID USERNAME HEX(KEY)"
  70 S -> C : ...
  71
  72 S -> C : "DEL SID"
  73 S -> C : ...
  74 @end example
  75
  76 Every second the client sends UDP packet with his single-byte stream
  77 identifier, even if it's muted. That may help punching holes in stateful
  78 firewalls.
  79
  80 Clients are notified about new peers appearance with @code{ADD}
  81 commands, telling their SIDs, usernames and keys. @code{DEL} notifies
  82 about leaving peers.