Multi-Surface
Different interfaces for different roles
Field users, dispatchers, administrators, and lighter mobile users are supported through role-appropriate surfaces.
Technical Overview
Built as operational communications infrastructure, not a chat app with a push-to-talk button.
Clear comms. Live control. One operation.
This overview is for IT, operations, and technical buyers who need to understand the architectural posture: how Secure Radio separates control, media, identity, policy, telemetry, and administration without exposing proprietary implementation details.
Design Principles
The platform is designed around role separation, tenant governance, and measurable runtime behaviour.
Tenant Scoped
Identity and policy stay inside the operating boundary
Devices, operators, talkgroups, feature availability, and permissions are governed per customer environment.
Media Aware
Voice and video are treated as live operational paths
The communication path is designed for session control, routing decisions, and operational observability.
Observable
Runtime quality is visible, not guessed
Admin and support workflows can inspect service health, client state, stream behaviour, and operational telemetry.
Interop Ready
RF gateways can be governed as part of the same tenant model
Controlled DMR bridging is attached to named talkgroups and follows the same authorization and floor-control posture as IP clients.
Architecture
A clear split between control decisions, media transport, client experience, and administration.
The public architecture model is deliberately simple: the control plane decides who may do what, the media layer carries real-time communication, and every client surface consumes the same policy truth.
Control Plane
Identity, policy, signalling, and coordination
Handles device and operator authentication, tenant policy, talkgroup state, dispatch requests, session lifecycle, and administrative payloads.
Media Layer
Voice, selective calls, talkgroups, and optional video
Uses LiveKit media sessions for current real-time voice and video workflows, with controlled room membership, publish permissions, and operational visibility.
Client Surfaces
Android field app, dispatch console, admin, and web access
Each surface follows the same runtime model so behaviour stays consistent across field, browser, dispatch, and administration workflows.
RF Gateway
Controlled DMR talkgroup interop
A configured gateway can decode RF traffic into Secure Radio and transmit authorized Secure Radio talkgroup audio back to DMR.
Detailed diagrams, endpoint-level contracts, deployment runbooks, and implementation internals can be reviewed in the right commercial and technical context. This page intentionally stays public-safe.
Trial Provisioning Architecture
The self-service trial flow separates public lead capture from operational provisioning.
The marketing layer handles lead capture, email verification, CRM updates, and onboarding email delivery. The product backend remains authoritative for tenants, devices, operators, activation tokens, expiry, and revocation.
Marketing Edge
Lead capture, verification, CRM, and email
Trial requests are recorded, verified by email, reflected into HubSpot, and then handed to the product provisioning endpoint.
Product Authority
Tenant, device, operator, and activation truth
The product service creates the trial tenant, dispatch identity, Android radio identity, operator records, policy, and short-lived setup tokens.
Client Activation
QR setup with PIN chosen at onboarding
Dispatch and Android scan separate setup QR codes, apply the right credentials, and require the operator to choose a PIN before login.
The trial defaults are deliberately narrow: one dispatch console, one Android radio, mandatory operator authentication, one OPS channel, one OPS talkgroup, and time-limited access.
Security & Governance
Security starts with identity, then continues through session binding, permission scope, and operational auditability.
Authentication
Device and operator identity
The platform supports device-level authentication and named operator authentication so access can be tied to both device and person.
Authorization
Role and talkgroup scope
Channel, talkgroup, transmit, private-call, and feature permissions can be governed by tenant and operator policy rather than left to client behaviour.
Session Control
Short-lived, session-bound media access
Media access is designed to follow authenticated session state, with refresh and revocation patterns that reduce stale access risk.
Tenant Isolation
Operational boundaries by customer
Tenants, devices, operators, talkgroups, feature flags, and runtime state are treated as scoped operational data.
Privacy
Location handling can be policy-led
Where location features are used, the system can support different precision modes so customer policy can shape operational visibility.
Auditability
Structured operational events
Authentication decisions, signalling events, client state, and runtime telemetry are designed to support support review and operational accountability.
Activation
Short-lived setup tokens
Trial setup links and QR codes expire. Operator PINs are chosen during onboarding, transmitted over HTTPS, hashed server-side, and not sent in email.
Scalability & Reliability
The system is designed so live operations can be scaled, observed, and supported without blending every responsibility together.
Separation
Control and media can evolve independently
Policy, identity, telemetry, and administration are separated from the real-time media path so each layer can be improved deliberately.
Runtime State
Presence and session state are explicit
The runtime model tracks active sessions, room membership, media access, and client state so support teams can reason about live behaviour.
Media Posture
Current media sessions are explicit and observable
The current launch path uses LiveKit media sessions so access, publish state, and troubleshooting signals are tied to authenticated runtime behaviour.
Telemetry
Quality signals are part of operations
Runtime dashboards and exports help teams see stream quality, connected clients, activity, and support-relevant health indicators.
Documentation
Technical and product truth are maintained as the platform changes
Product flow, authentication, provisioning, and deployment notes are kept in canonical documentation so technical evaluation stays grounded in current behavior.
Technical Evaluation
Start with a contained workflow, then review architecture fit with the people who will support it.
A good technical review covers identity, device readiness, connectivity, support ownership, telemetry expectations, security posture, and the rollout boundary for the first live operation.