01
Connected Device Firmware
Firmware for connected products where the device, hardware interfaces, network behavior and lifecycle all have to agree.
REAZ ROMEN / INDEPENDENT SYSTEMS ENGINEER
I build systems that have to work together.
I’m Reaz Romen, an independent systems engineer working across embedded firmware, real-time voice, networking, Linux infrastructure, and the tooling around them.
Most of my work lives at the boundaries: device ↔ network, SIP ↔ RTP, service ↔ dependency, hardware ↔ firmware. That is usually where the interesting failures are too.
ESP32-S3SIP / RTPLinuxObservabilitySystems debugging
ABOUT ME
I’m Reaz. I like the seams between systems.
I’m a systems engineer who works across embedded devices, networks, real-time communications, backend services and infrastructure. I’m most useful when a product crosses several of those layers and the problem does not belong cleanly to one team or one tool.
The part I enjoy most is turning a messy cross-layer failure into a system somebody can reason about.
More about how I work ↗
WORKS ACROSS
firmwarevoicenetworkinginfrastructureoperations
01 / WHAT I HELP WITHServices & approach →
02
Voice & Real-Time Communications
SIP/RTP systems from endpoint behavior through PBX and media paths, including the failures that only appear during real calls.
03
Infrastructure & Operations
Linux and container infrastructure with clear ingress, health, observability, service state and recovery paths.
04
Cross-Layer Debugging
For problems that refuse to stay in one box: audio that is really timing, calls that connect without media, or healthy processes behind broken services.
02 / PORTFOLIOFull portfolio →
01
Embedded firmware / real-time audio / SIP-RTP
ESP32-S3 Connected Voice Device
Building and debugging a real-time voice device across firmware, codecs, audio timing, packet transport, PBX integration and hardware behavior.
ESP32-S3ESP-IDFESP-ADFFreeRTOSC/C++
Open case study ↗
02
Linux / Docker / secure ingress / operations
Infrastructure Operations Platform
An operations layer for a multi-service Linux environment where runtime state, health, dependencies, access and recovery need to be understood together.
Linux / UbuntuDockerDocker ComposesystemdCaddy
Open case study ↗
03
Prometheus / Grafana / failure simulation
Production Observability & Alert Validation
Testing whether monitoring detects real failure, including deliberately creating load and proving the complete alert path rather than trusting dashboards.
PrometheusPromQLGrafanaAlertmanagerBlackbox Exporter
Open case study ↗
04
SIP signaling / RTP media / distributed debugging
VoIP & Real-Time Communications Infrastructure
Building and debugging signaling, routing, media, endpoints and infrastructure around real-time communications rather than treating the PBX as the whole system.
SIPRTPSDPAsteriskFreeSWITCH
Open case study ↗
PROOF, NOT ADJECTIVES
I try to show the system, not just describe myself.
The useful evidence is usually ordinary engineering evidence: a packet trace, a serial log, an architecture map, a timing measurement, a failure test, a preserved build, a dashboard that actually caught the failure.
01Code & buildsknown-good versions, diffs, release artifacts
02Packets & timingSIP, RTP, sequence, jitter, media paths
03System statemetrics, logs, health, dependencies, ingress
04Hardware behaviorcodec paths, I/O, power, board integration
03 / HOW I WORKWorking style →
Frame the system
Map boundaries, clocks, dependencies, data paths and the exact failure before changing behavior.
Make it observable
Collect the evidence the system already has: logs, packets, timing, state, metrics and hardware behavior.
Isolate one boundary
Preserve a known-good control and change one part of the path at a time.
Build and retest
Turn the hypothesis into the smallest useful change, then repeat the same failure test.
Leave a trail
Document architecture, verification and recovery so the system is easier to operate after the fix.
04 / FIELD NOTESBrowse all notes →
I write from the workbench.
Debugging notes, architecture decisions and technical write-ups from systems I have actually been working through.
Voiceware Started With One Deployable Service, Not a “Platform”
Why I validated the delivery path with the web application before expanding to the rest of the stack.
Read note →How Voiceware Grew From a Web-App Chart Into a Multi-Service Deployment Repository
The transition from a single Helm chart to a repository containing ten independently represented workloads.
Read note →The Real Architecture Work Was Finding Voiceware’s Runtime Boundaries
How I treated process boundaries as deployment boundaries instead of forcing the application into one monolithic unit.
Read note →Why I Kept Audio, Workers, Redis, Nginx, and the Web App Separate
The operational reasons for not collapsing supporting services into one large deployment.
Read note →ONE WORKING PRINCIPLE
When a failure crosses layers, debugging has to cross layers too.
That is the thread running through the firmware, voice, infrastructure and operations work on this site.