IPSC3-POC is the cellular push-to-talk gateway for IPSC3. It is designed
as a separate daemon, not as code inside the main IPSC3 DMR router. This keeps
app clients, cellular jitter handling, codec conversion, and AMBE work
outside the live DMR voice path.
| Component |
Responsibility |
| IPSC3 core |
DMR routing, repeaters, hotspots, trunks, roaming, scan groups, private calls, SMS, GPS, and dashboard state. |
| IPSC3-POC daemon |
Cellular POC clients, control sessions, PTT arbitration, UDP/RTP audio, POC fanout, and bounded PCMU/AMBE bridge workers. |
| IPSC3 vocoder service |
Stateful 20 ms PCM/AMBE conversion behind a backend-neutral loopback protocol. OpenDMR is the first software backend; AMBE-3003 can be added later without changing POC media packets. |
| POC clients |
Android and other application clients using a persistent JSON control channel and RTP/UDP audio. |
The server remains intentionally separated into readable, bounded components:
- Rust daemon named
ipsc-poc.
- Line-delimited JSON control messages over a persistent TCP connection.
- Mandatory client-family authentication on production servers using a one-use 15-second HMAC-SHA256 login challenge. Radio, presence, PTT, SMS, GPS, and media state are not created until the proof is verified.
- One 32-byte key may cover a controlled family of similar client binaries, while each permitted release version remains explicitly allowlisted. The key registry hot-reloads outside all media paths and is securely shared by participating IPSC3 servers.
- Separate UDP/RTP audio plane using G.711 μ-law / PCMU, 8 kHz mono, RTP payload type 0.
- Backward-compatible RTP recovery negotiated per client: compact bidirectional NACKs, bounded two-second caches, one retransmission per packet, adaptive 350/700 ms jitter handling, and final-sequence recovery for a lost call tail.
- The POC dashboard status changes from
OK to amber LOSS while a recovery-capable client is in the 700 ms degraded packet-loss mode. The hover detail distinguishes legacy, normal, and degraded recovery state.
- In-memory users and a selectable talkgroup catalogue announced in full at login. Each server operator marks exactly one static talkgroup as POC Call/Default; the protocol announces that server-specific call channel instead of clients assuming TG505.
- Optional per-instance login options use the familiar semicolon format:
ScanInclude and ScanExclude constrain scan mode, while POC-only TGInclude and TGExclude provide complete talkgroup allowlist and denylist controls. Exclusions win. Filters are parsed once at login and enforced from in-memory session state across catalogue, selection, signalling, late-entry, and RTP fanout.
- Persistent per-installation client instance IDs allow up to eight POC radios to share one DMR Radio ID while retaining independent control, talkgroup, scan, NAT, and RTP state.
- A master-backed IPSC3 server directory announced in full at login, allowing clients to select VK, ZL, or future published POC servers.
- IPSC3 database-backed voice talkgroups, with JSON runtime entries retained for POC-specific additions and policy overrides.
- Read-only RadioID directory lookup for client identity.
- One active speaker per talkgroup.
- Server fanout from the current speaker to registered clients affiliated with the same talkgroup.
- Bidirectional private voice calls between POC and POC, Motorola/IPSC, or MMDVM users. The destination is resolved through the normal IPSC3 roaming table, and private RTP fans out to every available POC instance of the requested Radio ID.
- Bidirectional SMS between POC and DMR users through the existing IPSC3 durable store-and-forward service. Deliveries fan out to all destination instances and the first acknowledgement wins. POC submissions, acknowledgements, retry status, and expiry notices run on bounded workers outside both audio paths.
- POC access to the Radio ID 9998 AI SMS assistant, including shared conversation history and network context, targeted replies, and explicit failure status without introducing HTTP or database work into either voice path.
- Roaming-dashboard SMS plus operator call-alert, disable, and re-enable controls for live POC clients, transported over bounded queues and the authenticated control channel.
- Incoming-call control signalling carries the authoritative Radio ID, resolved callsign/name, talkgroup, timeslot, and stream ID for both POC and DMR audio.
- DMR caller identity is resolved by a bounded background worker with a six-hour in-memory cache, keeping RadioID database reads and client control writes outside audio decoding and RTP fanout.
- Per-instance UDP receive mappings and server-assigned transmit SSRCs learned from marker/silence RTP probes, allowing same-ID clients with different translated source ports to coexist behind one NAT address.
- Session-bound control-channel GPS, Android network, and privacy-preserving indoor WiFi-cache reports feed the existing IPSC3 map/history database and APRS-IS worker through a bounded background event gateway. WiFi identifiers never leave the client; indoor estimates retain only coordinates, accuracy, fix age, and an explicit lower-confidence source marker.
- Versioned loopback media protocol carrying DMR call requests, grants, starts, 27-byte AMBE bursts, and call ends.
- Standalone
ipsc-vocoder process with stateful encoder and decoder contexts per stream.
- Three 20 ms PCMU frames are encoded into the three 9-byte AMBE frames carried by one 60 ms DMR media burst.
- POC microphone audio has a configurable -20 to 0 dB attenuation stage and -12 to 0 dBFS safety-limiter threshold immediately before AMBE encoding. Both are managed from the Configuration > POC dashboard tab and default to -3 dB/-3 dBFS on new installations.
- DMR audio heading to POC radios has an independent configurable -20 to +20 dB decoder gain/pad after AMBE decoding and before PCMU RTP output. It is managed from the same POC tab and defaults to -3 dB.
- Inbound 27-byte AMBE bursts are decoded into a bounded one-burst, 60 ms playout buffer, then sent as independent PCMU RTP packets at 20 ms intervals.
- DMR calls without an RTP-qualified POC listener selected to the talkgroup are denied at the media edge rather than consuming decoder and playout capacity.
- The IPSC3 scan trigger is announced dynamically to POC. Scan state is isolated per client instance, eligible DMR or POC calls retain their real caller/talkgroup metadata, and PTT on the scan talkgroup is translated back to the followed route during a 30-second talkback window.
- DMR receive sequence gaps use bounded fade-to-silence concealment; duplicate and late bursts are not replayed.
- The IPSC3-configured parrot talkgroup is announced dynamically to POC clients and performs a complete PCMU-to-AMBE-to-PCMU replay targeted to the caller, followed by the RadioID-resolved callsign using the NATO phonetic alphabet, or the full radio ID digit-by-digit, using the configured signal-language assets.
- Per-call summaries in both directions measure peak/RMS, clipping, limiter activity, sequence gaps, concealment, underruns, and queue pressure as applicable, without database work in the audio path.
- The vocoder self-test performs a deterministic PCMU-to-AMBE-to-PCM round trip and rejects clipping or excessive level drift before a codec build is deployed.
- POC UDP-qualified presence and call activity appear in roaming, last heard, live talkgroups, radio-type statistics, maps, IPSC3view, and IPSC3qt. Operational views use the red
POC identity while GPS maps use the normal position marker.
- A dedicated POC dashboard lists clients with a current UDP lease. Optional app, Android, device model, manufacturer, package, screen, and battery percentage metadata is captured on login and available in the row details; client passwords are never stored or displayed.
- Logging for login, talkgroup join, PTT grant/deny/release, RTP packet counts, RTP sequence gaps, and disconnects.
¶ Reference Client and Supported Radios
The current reference radio client is a Qt 6/C++ Android application. The
production profiles cover the Retevis L71, UDO/Abbree 8900, and UNIWA F400;
the 0.6.1 Build 65 Beta adds the ANYSECU 4G-W2Pro. The application is designed
as a radio appliance with a small fixed display, physical PTT and keys,
microphone, speaker, GPS, and status LEDs rather than as a touch-first phone
application.
- Persistent JSON control connection with automatic reconnect and keepalive.
- Authenticated binary-family login using
client_type, exact client version, and the ipsc3-poc-auth/1 challenge-response protocol.
- A persistent random
client_instance_id and per-session server-assigned RTP SSRC allow multiple radios configured with the same Radio ID.
- POC-origin group fanout is session-aware: it excludes only the transmitting instance while allowing another same-ID instance on the talkgroup or scan route to receive the call.
- NAT-safe PCMU RTP registration, transmit, and receive using one persistent UDP socket.
- Master-backed IPSC3 server selection and complete talkgroup catalogue selection from the radio menu.
- Backward-compatible per-radio setup options for scan inclusion/exclusion and POC talkgroup allowlist/denylist filtering.
- Server-resolved Radio ID, callsign, and operator name for login and received caller display.
- Physical PTT request/grant/release handling, hardware volume/channel controls, and a configurable function key.
- Protocol support for targeted private PTT and acknowledged SMS using Radio IDs resolved through IPSC3 roaming.
- GPS, Android network, and local-only WiFi-cache indoor location reporting.
- Windows/ADB provisioning that selects the server and Radio ID, verifies the APK checksum, installs the app, grants permissions, and configures it as HOME.
See IPSC3 POC Client for supported-radio
operation and provisioning details.
Radio ID is the canonical identity throughout the client protocol. A client
does not provide a trusted callsign or operator name. At login, the POC
daemon performs one read-only lookup in the same RadioID directory used by
IPSC3 DMR services, then keeps the resolved callsign and name in the in-memory
session. Login responses and call signalling publish that trusted identity.
Unknown Radio IDs remain usable and are displayed by number.
Client-binary authentication and Radio ID identity are deliberately separate.
The HMAC challenge verifies that the connection knows the key provisioned for
its claimed client type and authorized release version. It does not prove who
owns the Radio ID, and it is not hardware-backed attestation. Future per-user
credentials can be added without changing the media path.
The lookup is outside the RTP and PTT paths. Keepalives, PTT signalling, and
every audio packet use only in-memory session state and perform no database
access.
Presence, roaming, endpoint selection, and private-call routing remain
authoritative server state. POC clients do not communicate directly and do
not receive a POC-only user digest. A partial list would not describe users
currently reachable through MMDVM hotspots, repeaters, or trunks and would
therefore be unsuitable for routing decisions.
The server no longer emits the former presence_list message at
login or after keepalive, talkgroup, GPS, disconnect, or configuration
events. Older clients may continue sending a periodic
presence message; IPSC3 accepts it as a liveness refresh without
returning a roster. Group calls, private calls, and SMS continue to address
IPSC3 by Radio ID, allowing the server to select any supported destination
transport.
A successful control login does not by itself establish roaming presence.
Valid RTP marker probes or voice packets refresh a bounded background
presence lease. The client repeats its silent RTP marker probe every 20
seconds, and IPSC3 removes POC from current roaming and statistics after 90
seconds without valid UDP traffic. Last Heard remains historical.
For DMR-linked talkgroups the intended chain is:
Android microphone
-> 8 kHz mono PCM
-> G.711 μ-law / PCMU over RTP/UDP
-> server decodes PCMU to linear PCM
-> server later encodes PCM to AMBE
-> OpenBridge/IPSC3
PCMU is used first because it is simple, low-latency, predictable, and avoids
stacking an independent low-bitrate speech codec in front of AMBE. Opus may be
added later for app-only talkgroups where no AMBE conversion is required.
The POC-side gateway and intermediate codec are implemented behind an
enabled: false configuration gate. The live RTP thread only makes
a non-blocking bounded queue submission. PCMU conversion, vocoder requests,
AMBE burst aggregation, media grants, reverse decoding, and bridge metrics all
run in a dedicated worker.
The initial software backend dynamically loads OpenDMR in a separate
ipsc-vocoder process. OpenDMR remains an external GPL-2.0
component and is built from a pinned upstream commit. IPSC3 does not statically
link it into ipsc-poc or ipsc-server. A later
AMBE-3003 hardware backend will implement the same vocoder service protocol.
The IPSC3 core adapter consumes the local AMBE media stream and reuses the
existing IPSC3 template, LC, timeslot, routing, and Motorola-safe packet
generation. The POC process does not construct raw Motorola or MMDVM packets.
Existing DMR packets are mirrored into a bounded non-blocking worker queue;
codec work and POC database telemetry do not run in the shared DMR packet loop.
Private calls use the same PCMU/AMBE conversion and Motorola-safe DMR packet
construction as group calls, but retain private-call LC and are offered only
to the roaming destination. POC SMS uses separate bounded ingress and egress
queues. Database insertion, retry scheduling, and acknowledgement updates are
performed by the established SMS store-and-forward worker, never by the POC
RTP or IPSC3 DMR packet loops.
Parrot is handled as a special endpoint service rather than a PCMU shortcut.
The core announces the enabled parrot rule to POC, captures the caller's
encoded AMBE bursts, waits for the configured delay, then returns them through
the same AMBE decoder and paced RTP path used by DMR calls. The recording is
bounded, targeted only to its caller, and is never sent to DMR fanout. The
replay then appends the same RadioID-resolved callsign prompt used by the DMR
parrot. Callsigns use the NATO phonetic alphabet, while unresolved IDs are
spoken digit-by-digit in full.
Version 0.6.0 includes negotiated bidirectional RTP recovery, packet-loss
indication, adaptive jitter handling, enhanced DMR receive audio, link
diagnostics, and support-log collection. Older authorized clients remain
protocol-compatible and continue without features they do not negotiate.
- Continue tuning resilient RTP thresholds from measured high-latency and lossy mobile-link call summaries.
- Field-test the DMR receive summaries before changing the production 0 dB decode gain.
- Native TLS or WebSocket transport for the control channel.
- Per-user authentication for Radio ID login in addition to current client-binary authentication.
- AMBE-3003 hardware vocoder backend.
- Opus profile for app-only talkgroups.
- Richer presence and user state.
- Server-side recording.
- OTA app/config update messages.
- MDM deployment support.
Client implementers should use the
IPSC3-POC Control and Audio Protocol
page as the current client wire-protocol reference. Server-side bridge
implementers should also use the
IPSC3-POC Media Gateway Protocol.
Operators and client testers should use the
IPSC3 POC Client page.