← All work

Mission-Critical Push-to-Talk Command Platform

Led the development of a command platform combining push-to-talk audio, live video, dispatcher workflows, SOS, location, and device monitoring.

Field
Systems engineering
Role
Technical lead and primary implementer
Editorial visualization of a dispatcher coordinating field teams through push-to-talk, video, location, and radio-side controls.
The command system connected field endpoints, dispatch, live communications, operational signals, and a radio-side control path.

The problem

A communications organization was evaluating whether an owned push-to-talk platform was technically worth further investment. The first step was a focused proof of concept: could browser endpoints and a dispatcher coordinate push-to-talk audio, live video, SOS, status, and location in one system?

The work had to be designed around mission-critical standards from the beginning. Push-to-talk needs explicit floor ownership. Dispatchers need a reliable view of who is online, who is speaking, and what is happening in the field. Failures need to be visible rather than hidden behind a polished interface.

My role

I led the technical implementation and testing, working with business and technical reviewers to turn the original requirements into repeatable test scenarios. I designed and built the browser endpoints, dispatcher console, realtime control service, live media paths, and diagnostic tooling. I also developed the technical architecture and roadmap for a potential next development phase.

The PoC included:

  • push-to-talk audio with server-authoritative room, presence, floor-control, and signaling state;
  • live audio and video through WebRTC;
  • dispatcher-visible presence, floor, and connection state;
  • SOS, status, location, and device events;
  • repeatable automated tests for control behavior, browser workflows, media state, reconnect handling, privacy, protocol options, and simulated-client load under a defined test profile;
  • physical-device and field-network observations;
  • a hosted environment for controlled testing.

Key decisions

One shared operational state

Endpoints and dispatch needed to agree on room membership, presence, floor ownership, signaling, and operational events. Keeping the core control state server-authoritative made contention predictable and gave dispatch a coherent view of the system.

Separate control from media

Room state, signaling, and floor ownership belonged to the control path. Live audio and video belonged to the media path. This made failures easier to locate and kept the first working transport from becoming an accidental architecture decision.

Make the system measurable

The PoC recorded state transitions, connection behavior, media statistics, resource observations, and test conditions. This made interactions repeatable and comparable across devices and networks.

Radio feasibility

Alongside the browser platform, I evaluated an Astro radio built around an EC600M module as a future control and status participant. Preliminary work covered safe PTT and key input mapping, speaker output, temporary microphone-file creation, LTE reachability, and repeatable JSON control acknowledgements over a constrained module path. The microphone content was not audibly validated.

The acknowledgements were repeatable but slow, which made the path useful for non-realtime status and control rather than live floor control. The work established a practical radio-side direction separate from the browser media architecture. Live radio audio and a full radio gateway remained separate engineering problems for a later phase.

Outcome

The PoC established that the browser-based workflow was technically feasible within the tested scope. It also identified the reliability and media-quality work required for product development.