Tiempo de espera RTSP: cuándo probar TCP intercalado, UDP unidifusión o corregir la ruta de red

Cómo diagnosticar el tiempo de espera de RTSP, el tiempo de espera de RTP, la conexión rechazada y las paradas de transmisión de cámara comparando evidencia de transporte entrelazado UDP y TCP.

RTSP, tiempo de espera, UDP, TCP intercalado, RTP

"Tiempo de espera RTSP" es una de las frases más amplias para solucionar problemas de cámaras. Puede significar que se agotó el tiempo de espera de la conexión TCP con el servidor RTSP. Puede significar que "DESCRIBIR" regresó lentamente. Puede significar que "PLAY" se realizó correctamente pero los paquetes RTP nunca llegaron. Puede significar que los puertos UDP fueron bloqueados, que NAT reescribió algo incorrectamente o que un firewall permitió controlar el tráfico pero no el tráfico de medios.

La frase es vaga. La evidencia no tiene por qué serlo.

Separe el tiempo de espera de control del tiempo de espera de medios

El control RTSP generalmente ocurre a través de TCP. Los medios RTP pueden fluir a través de UDP o pueden entrelazarse a través de la conexión TCP RTSP. La primera división diagnóstica es:

  • ¿Se abrió la conexión RTSP TCP?
  • ¿El servidor respondió OPCIONES?
  • ¿DESCRIBE devolvió SDP?
  • ¿Tuvo éxito SETUP?
  • ¿Tuvo éxito PLAY?
  • ¿Llegó el RTP después de "PLAY"?

Si la conexión TCP falla, inspeccione el host, el puerto, el enrutamiento, el firewall, la VPN y si el servicio RTSP está habilitado. Si el control RTSP tiene éxito pero el RTP no llega, inspeccione la negociación de transporte y la ruta de los medios.

Por qué UDP falla a menudo mientras TCP funciona

UDP RTP puede fallar incluso cuando el control RTSP funciona. El cliente y la cámara negocian puertos durante la "CONFIGURACIÓN". Los firewalls, los dispositivos NAT, la política VLAN y el enrutamiento en la nube pueden bloquear la ruta de los medios. Una cámara puede enviar RTP a un puerto que el cliente no puede recibir. Una puerta de enlace de seguridad puede permitir TCP 554 pero descartar UDP.

Síntomas:

  • DESCRIBIR tiene éxito
  • SETUP tiene éxito
  • PLAY tiene éxito
  • no llegan paquetes RTP
  • El jugador finalmente informa tiempo de espera o pantalla negra.

En este caso, cambiar a TCP entrelazado es una prueba útil. Envía RTP dentro de la conexión TCP RTSP. Si TCP intercalado funciona y UDP no, el códec probablemente no sea el primer sospechoso. La ruta de los medios de red es.

TCP intercalado es una prueba, no siempre la respuesta final

RTSP sobre TCP entrelazado puede ser más fácil entre firewalls y NAT porque mantiene el control y los medios en la misma conexión. También puede aumentar la latencia y cambiar el comportamiento del rendimiento. Para el diagnóstico de campo, es mejor tratarlo como un punto de comparación.

Comparar:

  • UDP unidifusión RTP: ¿llegan los medios?
  • TCP RTP intercalado: ¿llegan los medios?
  • RTCP: ¿son visibles los informes del remitente?
  • Pérdida de paquetes: ¿UDP muestra espacios en la secuencia?
  • Latencia: ¿TCP crea bloqueos bajo presión de ancho de banda?

Si la implementación espera UDP, el éxito de TCP no valida completamente el sitio. Identifica el límite de la red que necesita trabajo.

La conexión rechazada es diferente del tiempo de espera

"Conexión rechazada" generalmente significa que el host rechazó activamente la conexión TCP. Causas comunes:

  • Servicio RTSP deshabilitado
  • puerto equivocado
  • el firmware de la cámara no expone RTSP
  • El puerto NVR difiere del puerto de la cámara
  • el firewall rechaza en lugar de descartar

Tiempo de espera significa que no llegó respuesta antes de que el cliente se diera por vencido. Causas comunes:

  • problema de enrutamiento
  • caída del cortafuegos
  • red inalcanzable
  • mapeo de puerto público incorrecto
  • cámara fuera de línea
  • Problema de ruta VPN

No los colapses en la misma nota de soporte. Rechazado y agotado el tiempo de espera apunta a diferentes propietarios.

Qué capturar en un informe de tiempo de espera

Un informe de tiempo de espera RTSP útil debe incluir:

  • host y puerto de destino
  • si TCP está conectado
  • último método RTSP enviado
  • estado de respuesta si lo hubiera
  • SDP devuelto o no
  • encabezado de transporte seleccionado
  • puertos cliente/servidor negociados
  • si llegó RTP
  • si llegó RTCP
  • Comparación TCP entrelazada
  • Comparación UDP

Ésta es la evidencia que necesita un ingeniero de redes. "Se acaba el tiempo" no es suficiente.

Dónde encaja el inspector RTSP

RTSP Inspector ayuda a mantener el control RTSP, la negociación de transporte, la entrega RTP, la evidencia RTCP y la preparación del códec en un solo flujo de diagnóstico. No es intentar ser el jugador el que oculta la distinción.

Para las búsquedas de tiempo de espera RTSP, el resultado más sólido es un breve veredicto:

  • control de tiempo de espera antes de SDP
  • tiempo de espera de medios después de un PLAY exitoso
  • UDP bloqueado pero TCP intercalado funciona
  • TCP rechazado en el puerto RTSP
  • RTP entregado pero el códec no está listo para decodificar

Cada veredicto tiene una solución diferente. La palabra clave de búsqueda puede ser "tiempo de espera RTSP", pero la verdadera respuesta se encuentra en el límite entre el control y los medios.