Skip to content

Voice store-and-forward

Voice is modeled as codec frames carried in fragment clusters (same messageId as file transfer).

VOICE_META (0x41)

FieldSizeDescription
codecType2See registry below
sampleRateHz2e.g. 8000
durationMs4Total reconstructed audio
frameSizeBytes2Per codec frame
titleLen1Optional UTF-8 title
titleUtf8variable

Codec registry (examples)

These codecType values are inside the VOICE_META body (typically uint16, big-endian in dumps). They are not the mesh payloadType byte.

codecTypeCodecTypical bitrate
0x0001PCM s16le monoN/A
0x0101CODEC2 12001200 bps
0x0102CODEC2 700700 bps
0x0201Opus8–64 kbps

0x0101 is the canonical ultra-narrowband mesh voice profile for long-range links.

VOICE_FRAME (0x42)

FieldSize
frameSeq2
frameBytesremainder

frameSeq MUST be monotonic for the message. Missing frames trigger fragment recovery.

Store-and-forward behavior

Repeaters and gateways MAY cache complete voice messages for replay to late joiners (policy). Clients SHOULD NOT cache long audio to protect flash.

Bandwidth note

Voice competes with flood traffic. Implementations SHOULD prefer unicast / tighter TTL toward known recipients when possible and lower voice bitrate on busy default community (channelHash == 0x0000) channels.

Example flow

  1. Originator sends VOICE_META + N × VOICE_FRAME fragments with messageId = M.
  2. Receiver plays incrementally if codecType supports streaming; else buffers until complete.
  3. If frame 7 missing, receiver issues FRAG_NACK listing index 7.

LowMeshOS — always open-source mesh protocol documentation