Informes del remitente RTCP, fluctuaciones y pérdida de paquetes: lectura del estado de la transmisión sin mirar el vídeo

Cómo los informes del remitente RTCP y la evidencia de sincronización RTP ayudan a diagnosticar el estado de la transmisión de la cámara RTSP sin depender de la reproducción de video.

RTCP, RTP, RTSP, fluctuación, pérdida de paquetes

Cuando los ingenieros buscan "jitter RTSP", "pérdida de paquetes RTP" o "informe del remitente RTCP", generalmente intentan responder una pregunta práctica: "¿la transmisión no está en buen estado o simplemente el reproductor tiene problemas? La reproducción de vídeo es un síntoma tardío. Las pruebas RTP y RTCP aparecen antes y son más fáciles de defender en un caso de soporte." RTCP es el compañero de control de RTP. Puede transportar informes del remitente, informes del receptor, recuentos de paquetes, información de sincronización y comentarios de calidad. No todas las cámaras exponen un comportamiento RTCP enriquecido y no todas las implementaciones lo reenvían correctamente, pero cuando RTCP está presente proporciona un contexto importante que la reproducción sin formato no ofrece.

Por qué es importante RTCP en el diagnóstico de cámaras

RTP transporta paquetes de medios. RTCP ayuda a describir el estado de la sesión multimedia. Para una transmisión de cámara RTSP, la evidencia RTCP puede ayudar a responder:

  • ¿Está vivo el remitente después de "PLAY"?
  • ¿Cuántos paquetes RTP informó el remitente?
  • ¿Las marcas de tiempo RTP están alineadas con la sincronización del reloj de pared?
  • ¿La entrega de paquetes es constante o en ráfagas?
  • ¿Hay inquietud visible?
  • ¿Continuó el RTP mientras fallaba la decodificación del video?
  • ¿La ruta de los medios incluyó RTCP?

Si el control RTSP tiene éxito y llega RTP, pero el vídeo se congela, RTCP puede ayudar a separar la sincronización de la red de la preparación del códec.

Los informes de los remitentes son evidencia del momento oportuno

Un informe de remitente RTCP puede relacionar una marca de tiempo RTP con un valor de tiempo absoluto de estilo NTP. Esa relación ayuda a los receptores a sincronizar las transmisiones y a razonar sobre el comportamiento del reloj. En el diagnóstico, las matemáticas exactas pueden ser menos importantes que la existencia y coherencia de los informes.

Observaciones útiles:

  • El informe del remitente aparece después de que se inician los medios.
  • Los recuentos de paquetes y octetos aumentan.
  • El mapeo de marca de tiempo RTP es consistente
  • el intervalo del informe es plausible
  • los informes se detienen cuando se detiene el RTP
  • Los informes continúan incluso cuando falla el decodificador.

Si RTCP se detiene junto con RTP, es posible que se interrumpa la ruta del remitente o del medio. Si RTCP continúa pero falla la decodificación de video, inspeccione la carga útil y la evidencia del códec.

Jitter no es lo mismo que pérdida de paquetes

Jitter significa que los paquetes llegan con un tiempo variable. La pérdida de paquetes significa que faltan paquetes. Ambos pueden causar tartamudeo visible, pero conducen a soluciones diferentes.

Los números de secuencia RTP muestran paquetes faltantes. Las marcas de tiempo RTP y los tiempos de llegada muestran variaciones en el tiempo. Los informes RTCP pueden agregar comentarios a nivel de sesión. Un informe adecuado no debería decir sólo "red mala". Debería indicar si el problema es pérdida, fluctuación, entrega en ráfaga, RTCP bloqueado o límite de decodificación del códec.

Para las cámaras, la fluctuación puede provenir de:

  • Variación del enlace ascendente Wi-Fi
  • codificador de cámara sobrecargado
  • Retraso en el reenvío del NVR
  • ruta de conmutación congestionada
  • Ruta VPN o WAN
  • comportamiento de almacenamiento en búfer del lado del cliente

La pérdida de paquetes puede deberse a:

  • UDP cae
  • comportamiento del cortafuegos/NAT
  • red sobrecargada
  • presión del buffer de envío de la cámara
  • limitaciones del punto de captura

Las soluciones son diferentes.

La falta de RTCP también es evidencia

Algunas implementaciones bloquean RTCP incluso cuando fluye RTP. Algunas cámaras no envían RTCP útil. Algunos clientes nunca lo solicitan ni lo reciben con claridad. La falta de RTCP no significa automáticamente que la transmisión se interrumpa, pero debe grabarse.

Si se negocia RTP sobre UDP, inspeccione ambos medios y controle el tráfico complementario. Si se utiliza RTSP sobre TCP entrelazado, inspeccione los metadatos del canal entrelazado. Un informe que dice "RTP visible, RTCP ausente" es más útil que un campo en blanco.

Dónde encaja el inspector RTSP

RTSP Inspector está diseñado para evidencia de protocolo, no para visualización pasiva. RTCP pertenece a la misma historia que los métodos RTSP, SDP, continuidad de secuencia RTP, tipo de carga útil, metadatos de códec y exportación de informes.

Para búsquedas intensas de RTCP, RTSP Inspector debería ayudar a responder:

  • ¿Llegó el RTP después de "PLAY"?
  • ¿Aparecieron los informes del remitente RTCP?
  • ¿Aumentó el número de paquetes?
  • ¿La fluctuación o las brechas en la secuencia se alinearon con fallas visibles?
  • ¿Falló la preparación del códec a pesar de la entrega del medio?
  • ¿El modo de transporte cambió el perfil de salud?

Esto le da al proveedor de cámaras, al ingeniero de redes o al desarrollador de VMS un punto de partida concreto. "El arroyo tartamudea" es un síntoma. "Los espacios en la secuencia RTP y la fluctuación aumentaron después de PLAY mientras el control RTSP se mantuvo vivo" es una evidencia.