Skip to content
ARGUS User Manual

TACLINK debug tile

The TACLINK debug tile is a developer / support surface that exposes the raw state of your browser’s TACLINK session. Most operators will not need it — but when a support engineer asks for “the TACLINK stats” this is where to get them.

Add the tile from the op’s + Add tile → Diagnostics → TACLINK debug. It renders per-peer and per-track metrics and re-polls getStats() on a one-second cadence.

Per-peer stats

At the top of the tile, each connected peer lists:

  • Connection state — new → connecting → connected → failed. Stuck on connecting points at an ICE problem; failed means the transport gave up and the client is in reconnect backoff.
  • Signalling state — stable is healthy. A persistent have-remote-offer is a sign of a signalling-plane problem, usually the SFU being unreachable.
  • ICE state — checking → connected → completed. checking for more than 5 seconds means candidates are failing to form a pair.
  • Selected candidate pair — shows which local/remote candidates are carrying traffic. host/host is ideal, srflx/srflx is normal, relay/relay means TURN fallback and explains degraded quality.
  • RTT — smoothed round-trip time in milliseconds. SAR ops should be below 150 ms; above 400 ms the DRC will feel laggy.

A red peer-card indicator means at least one of these is unhealthy; hover for the specific metric that tripped.

Per-track stats

Each published and subscribed track has its own row:

  • Bitrate in / out — live kbps on this track. Compare against the publisher’s target from stream settings.
  • Packets lost / received / nacked — cumulative counters. A low steady-state loss (< 1%) is fine. A rising NACK rate with stable loss means retransmit recovery is working. Rising loss with rising NACK means the NACKs aren’t being filled — usually uplink congestion on the publisher side.
  • FIR / PLI / keyframe requests — how often the subscriber asked for a fresh keyframe. A spike usually means the bitrate bottomed out and the decoder lost sync.
  • Jitter buffer delay — ms currently buffered by the decoder. A climbing jitter buffer is about to become a freeze.
  • Frames dropped — decoder-side drops. Usually indicates CPU starvation rather than network.

Audio tracks have a subset of the same fields plus audio-specific counters (concealed samples, silent concealed).

Raw getStats JSON dump

At the bottom of the tile is a Raw stats expander. Clicking it renders the full, unfiltered getStats() dictionary for every peer connection on the page — the same thing you would get from running pc.getStats() in DevTools, but already collected into one object.

Fields in the raw dump that are not rendered above are still valuable for support — for example codec negotiation (codec, mimeType), simulcast layer selection (encodings[]) and candidate gathering history (iceCandidateEvents[]).

Copy-as-JSON for support tickets

The header has a Copy as JSON button. It snapshots:

  1. Peer-level summary.
  2. All track-level rows.
  3. The raw getStats dump.
  4. The TACLINK client build version and the op ID.

Paste this into a support ticket along with the UTC timestamp at which you clicked the button. It is the single most useful artefact to attach — more useful than screenshots, browser console logs or video recordings.

Safe to leave running

The debug tile is read-only. Polling getStats() once per second has negligible CPU cost. You can leave it open throughout an op without affecting performance, and a commander may want to do exactly that when support has asked for live observation.