TECHNICAL INVESTIGATIONS

What problem has everyone else1 failed to solve?

A technical investigation practice for the failures that survive vendor escalations, firmware swaps, and forum threads. Bring the evidence. Leave with the cause.

fig. 0 — a healthy stream, until it isn't.

1 typically: two vendors, three engineers, and one very long forum thread.

This is not consulting.

No retainers. No roadmaps. No transformation initiatives.

One unsolved problem at a time, worked until the mechanism of failure is proven — and shown to you in the capture, not asserted in a slide.

THE DOCKET

representative cases — details altered to protect the guilty hardware

CASE 014 CLOSED

Multicast

Streams dropped at the top of every hour. Every switch reported healthy.

ROOT CAUSE — IGMP querier election flapping between a redundant pair.

CASE 019 CLOSED

PTP / Timing

Lip-sync drift measured in frames. Offsets wandered only under load.

ROOT CAUSE — transparent-clock corrections discarded by one intermediate switch.

CASE 023 CLOSED

AV-over-IP

Dante flows died on one VLAN. Only on Tuesdays.

ROOT CAUSE — a backup job saturating an uplink shared with the clock domain.

CASE 027 CLOSED

Broadcast

One camera chain lost genlock during live segments. Never in rehearsal.

ROOT CAUSE — a reference distribution amp failing under show-day thermal load.

CASE 031 CLOSED

Packet analysis

The graphs said fine. The room said otherwise.

ROOT CAUSE — microbursts invisible at 30-second polling, convicted at packet timestamps.

CASE 036 CLOSED

Control systems

Touch panels dropped during events. Never in testing.

ROOT CAUSE — multicast flooding when spanning tree reconverged on the show-day topology.

HOW AN INVESTIGATION RUNS

Evidence in. Cause out.

01 / SUBMIT EVIDENCE

Captures, configs, topology, timeline — and the list of everything already tried. The failed fixes are evidence too.

02 / ANALYSIS

Reproduce, instrument, correlate. Every claim is tested against the capture, not the data sheet.

03 / ROOT CAUSE

A proven mechanism, not a plausible story. You see the packet, the config line, the timing diagram that convicts it.

04 / RESOLUTION

The fix, applied and verified against the original failure — documented so it stays fixed after the case closes.

You've already tried everything.
Good.

The firmware is current. The hardware was swapped. The vendor blamed the network, and the network team blamed the vendor. The problem is still there.

Everything you've ruled out narrows the search. That's not the end of the road — that's where a case begins.

THE PRACTICE

One engineer. One open case at a time.

Twenty years across data centers, broadcast plants, stadium multicast, and casino IPTV — the rooms where failure is public and "intermittent" is not an acceptable answer. Cases are accepted only when they can be solved.

FIELD

  • multicast routing & IGMP forensics
  • PTP & media clocking
  • Dante / AES67 / SMPTE 2110
  • packet-level analysis
  • broadcast plants & control rooms
  • converged AV / IT infrastructure

CASE INTAKE

Submit a case.

Describe the failure the way you'd describe it to another engineer. If it isn't a fit, you'll hear that quickly — with a pointer toward who might help instead.

SANITIZE BEFORE YOU SEND. No credentials, keys, or SNMP communities. A secure destination for captures and configs follows after contact.

Evidence files — captures, configs, diagrams — are requested after intake. Case files remain confidential.