-
Notifications
You must be signed in to change notification settings - Fork 2
A Quick Overview of AFV
As far as the client is concerned, AFV consists of two services:
-
The API Server
-
The Voice Server
The API Server is a http/https endpoint with a well published name. Authentication, state management and network related queries are performed against the API server.
The Voice server is a UDP endpoint which the API server directs the client to use. The Voice server provides and receives the UDP streams of voice data.
The API Server uses a number of REST-like calls to perform the main operations required by an AFV client:
- User Authentication and endpoint discovery
- Transmitter/Receiver State Synchronization
- HF Aliasing Directory fetch
AFV-Native only sends a state update to the API server every 20 seconds, or whenever a radio is tuned.
The Voice Server uses CryptoDTO - a packet layout devised by Mark Barnes that uses the chacha20-poly1305 cipher to authenticate the packet header, and encrypt the payload.
As UDP is sessionless, the client must maintain a regular stream of heartbeat packets to the server both to ensure that any NAT remains open, but also so the server remains aware that the client is still present, and continues to send voice data as needed.
The server will respond to every heartbeat. AFV-Native sends a heart-beat every 3 seconds, and times-out the session if a response is not received within 10 seconds. Bear in mind that packetloss may result in the loss of heartbeats, so as long as any heartbeat response is received within the 10s window, AFV-Native considers that sufficient to keep the session alive.
The server will automatically stream voice data to a client with a recent heart-beat, according to the transceiver data sent in the last position update. This data contians per-client voice packets, with each voice packet containing 20ms of opus encoded audio. The client must mix incoming streams, apply any effects, and generally must handle all of the concerns.