One-way audio RCA

React SIP / WebRTC Diagnostic Lab for One-Way Audio

An audio-only React + SIP.js softphone with a live getStats() panel — built to isolate one-way audio across the browser, WSS/SIP signaling, FreeSWITCH media and the far-end device. Same PBX as production; none of the dashboard noise.

For frontend, SIP, QA and device engineers who hear “I cannot hear them” and need packet proof before changing NAT or dialplan.

Productized case-study delivery Scope-based estimator BYOC · Twilio · Telnyx · Sinch
Configure & request quote View case study Talk to architecture

Problems we solve

One-way audio reports that skip classification typically look like:

  • Calls connect but audio is missing in one direction
  • Production app has Redux, noise worklets and multi-call UI that mute playback
  • Teams change NAT or codecs before classifying the failure
  • Endpoint registration, forked contacts and silent RTP all look the same to users
  • No shared evidence vocabulary between frontend and PBX
  • NORMAL_CLEARING after bridge is treated as proof of audible playback
  • STUN options differ on invite vs answer paths
  • Remote track never attaches when event.streams[0] is empty

One platform: Trust certs → register browser → single device contact → outbound call → 5s silence · 10s shout · 5s silence → packets vs energy → repeat in production on same network

Known-good softphone

  • React 19 + SIP.js register, dial, answer, reject
  • Single active call / busy on second INVITE
  • Mic and speaker mute
  • Remote track fallback when streams[0] is empty
  • Shared ICE/STUN options on invite and answer
  • No AudioWorklet noise graph on remote audio (A/B vs production)

Live diagnostics & RCA

  • ICE / connection state and selected candidate pair
  • Inbound/outbound packets, bytes, jitter, loss
  • audioLevel and totalAudioEnergy
  • Remote element srcObject / play state
  • FreeSWITCH log correlation playbook
  • Vitest coverage for stream resolution and busy policy

Why WebRTC stats beat guesswork

Rising inbound PCMU packets with near-zero decoded energy points to far-end capture or payload — not a missing srcObject. The lab makes that visible in five seconds.

  • Stop speculative NAT/dialplan changes
  • Give FE, PBX, QA and device teams one evidence panel
  • A/B the production dashboard on the same network
  • Prove WSS digest registration independently of product chrome

Registers to your existing FusionPBX/FreeSWITCH or Asterisk WSS. Does not replace the PBX.

Platform architecture

flowchart LR
  Browser[React lab SIP.js getStats] -->|SIP WSS| PBX[FusionPBX FreeSWITCH]
  PBX --> Device[Embedded SIP device]
  Browser -->|DTLS SRTP| PBX
  PBX -->|RTP PCMU| Device
  Browser --> Ev1[Browser evidence]
  PBX --> Ev2[Channel logs]

Deployment: Cloud · VPS · On-premises · BYOC · Twilio · Telnyx · Sinch

Proven case study

This product is a productized delivery of the documented engineering case study — evidence stays on this page so you do not have to guess what was shipped.

  • Sanitized capture: ~200 inbound packets, zero loss, near-zero energy — far-end ownership
  • SIP digest registration and outbound sequence over WSS
  • FreeSWITCH log reconstructions for bridged vs USER_NOT_REGISTERED
  • 11 passing unit tests (stream resolution, busy policy, shared media options)
React SIP lab UI with softphone controls and diagnostics panel
One call, one remote audio element, one evidence panel.
WebRTC inbound RTP stats with packets and near-zero audio energy
Packets without energy — not a React attachment bug.
Sanitized SIP digest registration and outbound call over WSS
Signaling proof before blaming ICE.
Sanitized FreeSWITCH logs for bridged and failed outcomes
NORMAL_CLEARING is not audible playback.

Full case study with video and FAQ →

Configure this scope & send RFQ →

Built for

Frontend engineers

Prove srcObject / play() before rewriting the product UI.

SIP / PBX teams

Correlate browser stats with channel logs.

QA

Repeatable shout-test protocol on a known-good client.

Device vendors

Separate firmware/mic from browser playout.

Integrated vs fragmented stack

Traditional setupThis product direction
Change NAT firstClassify: registered? bridged? packets? energy? playing?
Production dashboard onlyLab without Redux/worklets/multi-call
“Bridge succeeded”Packets + energy + audio element state
Blame ReactNear-zero energy with rising RTP → far-end capture

Outcomes

Proves WSS registration and a known-good remote-track path; separates silent RTP from frontend playout defects; reduces pressure to change dialplan without packet proof. Rescue or internal-tool delivery — scoped in RFQ.

Deployment & carriers

  • Managed VPS — operate on your cloud account with runbooks.
  • Your cloud — AWS/GCP/Azure; you own the account.
  • On-premises — regulated or air-gapped cores (quote adjusted).
  • BYOC / own SIP — your carrier contract or trunks on the PBX we deploy.
  • Twilio / Telnyx / Sinch — CPaaS pass-through shown in the estimator (planning only).

Estimates are scope-based planning figures — not binding quotes. Taxes, carrier deposits, DIDs and third-party AI usage are scoped in discovery.

Frequently asked questions

Does this replace FusionPBX or FreeSWITCH?

No. It registers to your PBX and correlates browser stats with server logs.

When should we use this instead of production?

When Redux, noise worklets or multi-call UI obscure media. The lab is the A/B baseline.

What proves silent RTP vs a frontend bug?

Rising inbound packets with near-zero audioLevel / totalAudioEnergy.

Can you build this against our PBX?

Yes — FusionPBX, Asterisk or embedded SIP devices.

Does it include a full product UI?

Deliberately not. That is the point.

BYOC?

Uses your existing WSS/SIP. Estimator is BYOC / own SIP.

Tests?

Vitest coverage for media paths is an optional requirement.

Merge into production?

Optional “integrate into dashboard” requirement in the quote builder.

Requirements

Request formal quote