@end float
But why? SIP-based solutions are pretty complicated to setup, because
-they are not for simple tasks like sudden voice chats between a few
-people. WebRTC-based solutions are insane bloated incredible monsters
-by complexity and size, hardly possible to debug and having frequent
-compatibility problems. They work mainly only if you use the same kind
-of software and codecs, for example Chromium, that requires dozens of
-gigabytes of disk space and much RAM, CPU time to build it. Is not it
-pure insanity for that relatively simple task?
+they are not made for simple tasks like sudden voice chats between a
+few people. WebRTC-based solutions are insane bloated incredible
+monsters by complexity and size, hardly possible to debug and having
+frequent compatibility problems. They work mainly only if you use the
+same kind of software and codecs, for example Chromium, that requires
+dozens of gigabytes of disk space and much RAM, CPU time to build it.
+Is not it pure insanity for such relatively simple task?
Mumble has wonderful simplicity and workability, but even its server
-side is still written on Qt, that requires hundreds of megabytes of
+side is still written on Qt, which requires hundreds of megabytes of
additional libraries to build it up. And users tend to complain about
its newer client versions quality and convenience.
So let's write as simple VoIP talking client as it is possible, without
-compromising convenience and simplicity for user! I just want a simple
-command, which I can specify server's address and just immediately talk
-with someone.
+compromising convenience and simplicity for the user! I just want a
+simple command, which only requires to specify the server's address to
+just immediately talk with someone.
@itemize
-@item No GUI requirement. Why would someone need it for voice
-application? But fancy real-time refreshing TUI would be desirable.
+@item No GUI requirement. Why would someone need a GUI for voice
+application? But a fancy real-time refreshing TUI would be desirable.
Mumble tends to output no information, sometimes hiding the fact of a
problem and that everything stopped working.
-@item No NAT-traversal possibility. It is 2024 year already, stop trying
-to use and revive legacy obsolete IPv4. Or use some overlay network on
-top of it, VPN, whatever.
+@item No NAT-traversal possibility. It is the year 2024 year already,
+stop trying to use and revive legacy obsolete IPv4. Or use some overlay
+network on top of it, Or VPN, whatever.
-@item Mono-cypher, mono-codec protocol. @url{https://opus-codec.org/, Opus}
+@item Mono-cypher, mono-codec protocol. The @url{https://opus-codec.org/, Opus}
audio codec is perfect for VoIP tasks. ChaCha20-Poly1305 is more than
-appropriate and satisfiable as fast and secure encryption solution.
+appropriate and satisfies as fast and secure encryption solution.
@end itemize
@node Protocol
@unnumbered Protocol
-VoRS uses Opus codec with 20ms frames with 48kHz 1ch 16-bit S-LE sound.
-It uses native @code{libopus}'es Packet Loss Concealment (PLC) feature
-if number of lost frame does not exceed 32 count. DTX (discontinuous
-transmission) is also on.
+VoRS uses the Opus codec with 20ms frames with 48kHz 1ch 16-bit S-LE
+sound. It uses native @code{libopus}'es Packet Loss Concealment (PLC)
+feature when the number of lost frame does not exceed 32 count. DTX
+(discontinuous transmission) is also on.
-Each frame has single byte stream identifier (unique identifier of the
+Each frame has a single byte stream identifier (unique identifier of the
participant) and 24-bit big-endian packet counter. Reordered packets are
dropped. 24-bit counter is long enough for very long talk sessions.
-Each packet is encrypted with ChaCha20-Poly1305. Key is generated during
-handshake procedure with the server and is shared among other participants.
-Stream identifier with packet counter are used as a nonce. Only 64-bits
-of Poly1305 are used.
+Each packet is encrypted with ChaCha20-Poly1305. The key is generated
+during the handshake procedure with the server and is shared among the
+other participants. The stream identifier together with the packet
+counter is used as a nonce. Only 64-bits of Poly1305 are used.
It is tuned for 24Kbps bandwidth. But remember that it has additional 8B
of MAC tag, 4B VoRS, 8B UDP and 40B IPv6 headers.
-Each client handshakes with the server over TCP connection using
+Each client handshakes with the server over TCP connection using the
@url{http://noiseprotocol.org/, Noise}-NK protocol pattern with
curve25519, ChaCha20-Poly1305 and BLAKE2s algorithms.
@item Client sends initial Noise handshake message with his username as
a payload.
-@item Server answers with final Noise handshake message with the payload
-of @code{OK HEX(COOKIE)}, or any other failure message. It may reject
+@item Server answers with final noise handshake message with the payload
+of @code{OK HEX(COOKIE)}, or any other failure message. It may reject a
client if there are too many peers or its name is already taken.
-@item That 128-bit cookie is sent by client over UDP to the server every
+@item The 128-bit cookie is sent by client over UDP to the server every
second. If UDP packets are lost, then no connection is possible and
-after timeout server drop TCP connection.
+after a timeout the server drops the TCP connection.
@item Otherwise it replies with @code{SID XXX}, where XXX is ASCII
decimal stream number client must use.
S -> C : ...
@end example
-Every second client sends UDP packet with his single-byte stream
-identifier, even if it is muted. That may help punching holes in
-stateful firewalls.
+Every second the client sends UDP packet with his single-byte stream
+identifier, even if it's muted. That may help punching holes in stateful
+firewalls.
Clients are notified about new peers appearance with @code{ADD}
commands, telling their SIDs, usernames and keys. @code{DEL} notifies
@node VAD
@unnumbered VAD
-Voice Activity Detection is off by default. You can use
+Voice Activity Detection is off by default. You can use the
@command{vors-vad THRES} command with feeding audio record in its stdin.
It will print calculated sound RMS value if it exceeds the
@option{THRES} threshold. So you can manually try various @option{THRES}
-values to see when it is comfortable to detect your voice. Pass that
+values to see when it is comfortable to detect your voice. Pass the
desired @option{THRES} value to @option{-vad} option of
@command{vors-client}.