Saltearse al contenido
ARGUS User Manual

Tesela de depuración TACLINK

La tesela de depuración TACLINK es una superficie de desarrollador / soporte que expone el estado bruto de la sesión TACLINK de tu navegador. La mayoría de los operadores no la necesitarán — pero cuando un ingeniero de soporte te pida “las estadísticas de TACLINK” este es el lugar para obtenerlas.

Añade la tesela desde + Añadir tesela → Diagnósticos → Depuración TACLINK de la operación. Renderiza métricas por par y por pista y vuelve a consultar getStats() con una cadencia de un segundo.

Estadísticas por par

En la parte superior de la tesela, cada par conectado lista:

  • Estado de conexión: new → connecting → connected → failed. Quedarse en connecting apunta a un problema ICE; failed significa que el transporte se rindió y el cliente está en backoff de reconexión.
  • Estado de señalización: stable es saludable. Un have-remote-offer persistente es señal de un problema del plano de señalización, normalmente que el SFU es inalcanzable.
  • Estado ICE: checking → connected → completed. checking durante más de 5 segundos significa que los candidatos están fallando al formar un par.
  • Par de candidatos seleccionado: muestra qué candidatos locales/remotos están llevando el tráfico. host/host es ideal, srflx/srflx es normal, relay/relay significa fallback TURN y explica la calidad degradada.
  • RTT: tiempo de ida y vuelta suavizado en milisegundos. Las operaciones SAR deberían estar por debajo de 150 ms; por encima de 400 ms el DRC se sentirá con retardo.

Un indicador rojo en la tarjeta del par significa que al menos uno de estos no está saludable; pasa el cursor para ver la métrica específica que disparó.

Estadísticas por pista

Cada pista publicada y suscrita tiene su propia fila:

  • Bitrate entrante / saliente: kbps en vivo en esta pista. Compáralo con el objetivo del publicador desde configuración de stream.
  • Paquetes perdidos / recibidos / con NACK: contadores acumulativos. Una pérdida baja en estado estacionario (< 1%) está bien. Una tasa de NACK creciente con pérdida estable significa que la recuperación por retransmisión está funcionando. Pérdida creciente con NACK creciente significa que los NACKs no se están llenando — normalmente congestión del uplink en el lado del publicador.
  • Peticiones FIR / PLI / keyframe: con qué frecuencia el suscriptor pidió un keyframe fresco. Un pico suele significar que el bitrate tocó fondo y el decodificador perdió la sincronización.
  • Retardo del jitter buffer: ms actualmente almacenados por el decodificador. Un jitter buffer que sube está a punto de convertirse en una congelación.
  • Frames descartados: caídas del lado del decodificador. Suele indicar inanición de CPU en lugar de red.

Las pistas de audio tienen un subconjunto de los mismos campos más contadores específicos de audio (muestras ocultas, ocultas silenciosas).

Volcado JSON bruto de getStats

En la parte inferior de la tesela hay un expansor Estadísticas brutas. Al hacer clic, renderiza el diccionario getStats() completo y sin filtrar para cada peer connection en la página — lo mismo que obtendrías al ejecutar pc.getStats() en DevTools, pero ya recopilado en un solo objeto.

Los campos en el volcado bruto que no se renderizan arriba siguen siendo valiosos para soporte — por ejemplo, negociación de códecs (codec, mimeType), selección de capa simulcast (encodings[]) e historial de recolección de candidatos (iceCandidateEvents[]).

Copiar como JSON para tickets de soporte

El encabezado tiene un botón Copiar como JSON. Toma una instantánea de:

  1. Resumen a nivel de par.
  2. Todas las filas a nivel de pista.
  3. El volcado bruto de getStats.
  4. La versión de build del cliente TACLINK y el ID de la operación.

Pega esto en un ticket de soporte junto con la marca de tiempo UTC en la que hiciste clic en el botón. Es el artefacto más útil a adjuntar — más útil que capturas de pantalla, logs de consola del navegador o grabaciones de video.

Seguro dejarla ejecutándose

La tesela de depuración es de solo lectura. Consultar getStats() una vez por segundo tiene un coste de CPU insignificante. Puedes dejarla abierta durante toda una operación sin afectar al rendimiento, y un comandante podría querer hacer exactamente eso cuando soporte haya pedido observación en vivo.

Relacionado