2026-06-02

Las transmisiones de cámara RTCP BYE y RTSP finalizan inesperadamente: por qué el vídeo se detiene sin un error claro

Cómo depurar RTCP BYE, fin de transmisión RTP, desmontaje de cámara, tiempo de espera de sesión, pérdida de paquetes y detenciones inesperadas de transmisión RTSP con evidencia de protocolo.

Algunas transmisiones de cámara RTSP no fallan con un error de limpieza. Comienzan, reproducen durante un rato y luego el vídeo se detiene. El jugador puede congelarse en el último fotograma. La grabadora puede cerrar el archivo. El cliente puede volver a conectarse automáticamente. Los registros pueden decir "fin de la transmisión", "tiempo de espera de RTP", "RTCP BYE", "conexión cerrada del servidor" o nada útil.

Búsquedas como "Transmisión de cámara RTCP BYE", "La transmisión RTSP finaliza inesperadamente", "la cámara envía RTCP BYE", "La transmisión RTP se detiene sin error" y "El video RTSP se congela después de minutos" generalmente provienen de equipos que ya demostraron que la URL funciona. Necesitan saber por qué terminó la transmisión.

RTCP BYE es una posible respuesta. Es un mensaje de control que indica que un participante abandona la sesión RTP. En una transmisión de cámara, puede significar que la cámara finalizó intencionalmente una pista multimedia, reinició su codificador, expiró una sesión o cerró la entrega de medios mientras el canal de control RTSP se comportaba de manera diferente.

RTSP Inspector es útil porque un jugador puede ocultar este detalle. Una herramienta de diagnóstico de protocolo puede preservar eventos RTSP, RTP y RTCP juntos.

Qué significa RTCP BYE

RTCP es el protocolo de control emparejado con RTP. RTP transporta paquetes de medios. RTCP transporta informes e información de control. Un paquete RTCP BYE indica que una fuente está abandonando la sesión RTP.

En un caso sencillo:

RTP video packets arrive
RTCP Sender Reports arrive
RTCP BYE arrives
RTP video packets stop

RTCP BYE vs RTP timeout

Common reasons include:

RTSP TEARDOWN vs RTCP BYE

RTSP TEARDOWN and RTCP BYE are different.

TEARDOWN rtsp://camera/stream RTSP/1.0
Session: 12345678

RTCP BYE es un paquete de control de sesión de medios. Una transmisión puede terminar con uno, ambos o ninguno visible según el comportamiento de la cámara y el punto de captura.

Casos:

El cliente envía RTSP TEARDOWN: apagado esperado.
La cámara cierra la conexión TCP: final abrupto del lado del servidor.
La cámara envía RTCP BYE: la fuente multimedia finalizó.
RTP se detiene sin RTCP BYE: tiempo de espera agotado o ruta de medios perdida.
RTSP permanece abierto pero RTP finaliza: la capa de medios finalizó mientras el control permaneció activo.

Esta distinción ayuda a evitar culpar a la capa equivocada.

La transmisión finaliza después de un tiempo predecible

Si la transmisión finaliza a los 30, 60, 120 o 300 segundos, sospeche de keepalive o de tiempo de espera de sesión. Verifique el encabezado RTSP Session:

Session: abcdef;timeout=60

Stream ends during camera reconfiguration

Many cameras restart encoders when settings change:

NVR and channel behavior

Evidence to collect:

Packet loss before BYE

Checklist for RTCP BYE investigations

Use this process:

What a useful report includes

For a vendor or network team, include:

Final diagnosis

Evidencia reproducible para «Las transmisiones de cámara RTCP BYE y RTSP finalizan inesperadamente: por qué el vídeo se detiene sin un error claro»

La respuesta directa es que una avería de vídeo no se demuestra con una ventana negra ni con un solo código de estado. Un diagnóstico fiable conecta la petición y la respuesta RTSP, el transporte negociado, una sesión válida y después los números de secuencia RTP, las marcas de tiempo y las señales RTCP. Para «Las transmisiones de cámara RTCP BYE y RTSP finalizan inesperadamente: por qué el vídeo se detiene sin un error claro», empieza por la capa más cercana al síntoma visible, pero conserva una cronología común para no mezclar un fallo de control con uno de red o decodificación.

Antes de cambiar la cámara, el firewall o el VMS, crea una prueba base pequeña. Anota la URL RTSP sin contraseña, la hora, la ruta, el transporte solicitado, la respuesta del servidor y el instante del primer paquete multimedia. Prueba UDP y TCP interleaved por separado cuando el equipo ofrezca ambos. No cambies ruta, credenciales y transporte a la vez; si el segundo intento funciona, necesitas saber qué variable produjo la diferencia.

Capa	Evidencia que se debe guardar	Pregunta de decisión
RTSP	método, estado, cabeceras, CSeq y Session	¿El servidor aceptó exactamente la operación?
SDP	control, payload type, clock rate y codec	¿El servidor describió la pista esperada?
Transport	client_port, server_port o interleaved	¿Ambos extremos usan el mismo canal?
RTP	SSRC, secuencia, timestamp y marker	¿Las unidades llegan en un orden explicable?
RTCP	sender report, CNAME y BYE	¿Se pueden relacionar reloj, identidad y final?
Decoder	SPS/PPS/VPS y packetization mode	¿El payload recibido permite iniciar el decoder?

Separa «no llega multimedia» de «llega multimedia que no se puede decodificar». Si no aparece RTP después de SETUP y PLAY correctos, revisa UDP, NAT, firewall y una respuesta Transport distinta de la oferta. RTP con huecos de secuencia prueba pérdida o reordenación. Una secuencia continua sin imagen desplaza la investigación hacia payload type, clock rate, límites de cuadro y parámetros H.264 o H.265. Esta frontera es más útil que el mensaje general del reproductor.

¿Cómo se redacta una respuesta que pueda citarse?

Usa tres frases: última operación correcta, primera evidencia que falla y siguiente prueba que separa dos causas. Ejemplo: «DESCRIBE, SETUP y PLAY terminan correctamente; no llega RTP a los puertos anunciados por el cliente; repetir por TCP interleaved separará el bloqueo UDP de una ruta multimedia incorrecta». No atribuyas el fallo a la cámara o a la red sin una respuesta o un paquete que marque ese límite.

¿Qué hace reproducible el caso?

Guarda OPTIONS, DESCRIBE, SETUP y PLAY, el SDP, la respuesta Transport y el identificador Session saneado. Para RTP registra SSRC, primer y último número de secuencia, clock rate, huecos y duración. Indica si VLC u otro VMS funciona, pero úsalo como comparación controlada, no como prueba de que el cliente exitoso interpreta todas las reglas de forma correcta.

¿Cuándo se investiga el servidor y cuándo el cliente?

Mira el servidor si rechaza un método, entrega un control URL inexistente, responde con un transporte incompatible o cambia SSRC o reloj sin transición. Mira el cliente si reutiliza un nonce caducado, pierde Session, solicita UDP sin abrir los puertos o interpreta cada final NAL como final de access unit. Si el límite está entre ambos, conserva paquete y hora en cada afirmación.

¿Cómo se revisa el informe?

Repite desde una conexión nueva y compara las dos cronologías solo hasta la primera diferencia. Elimina contraseñas y valores Authorization completos. Relaciona cada conclusión con CSeq, secuencia o timestamp. Continúa con la guía RTSP relacionada y usa RTSP Inspector para probar un stream RTSP y recoger evidencia de forma local, sin subir el vídeo de la cámara a un servicio público.

Respuesta directa y límite de aceptación

La respuesta breve a «Las transmisiones de cámara RTCP BYE y RTSP finalizan inesperadamente: por qué el vídeo se detiene sin un error claro» es: Cómo depurar RTCP BYE, fin de transmisión RTP, desmontaje de cámara, tiempo de espera de sesión, pérdida de paquetes y detenciones inesperadas de transmisión RTSP con evidencia de protocolo. Trate esa frase como un resultado que debe comprobarse, no como una promesa para cualquier entrada, dispositivo, proyecto o entorno. Un resultado completo registra estado inicial, acción exacta, salida visible y condición que demuestra que la tarea terminó en RTSP Inspector.

Procedimiento basado en evidencia

Empiece con un caso pequeño y repetible antes de cambiar un proyecto completo. Anote versión de la aplicación, sistema operativo, identidad de entrada o dispositivo, ajustes relevantes y resultado esperado. Ejecute una acción deliberada, conserve la primera transición inesperada y compárela con un caso conocido cuando exista. Cambiar varios controles a la vez oculta qué condición creó o corrigió el problema.

Punto de control 1: Las transmisiones de cámara RTCP BYE y RTSP finalizan inesperadamente: por qué el vídeo se

Compruebe «Las transmisiones de cámara RTCP BYE y RTSP finalizan inesperadamente: por qué el vídeo se detiene sin un error claro» con la entrada representativa más pequeña. Mantenga iguales los ajustes no relacionados, repita la misma acción y revise el resultado después de reabrir o reconectar. Una captura aislada es más débil que un registro con entrada, ajuste, acción, salida y hora.

Punto de control 2: Cómo depurar RTCP BYE, fin de transmisión RTP, desmontaje de cámara, tiempo de espera de s

Si «Cómo depurar RTCP BYE, fin de transmisión RTP, desmontaje de cámara, tiempo de espera de sesión, pérdida de paquetes y detenciones inesperadas de tran» es ambiguo, compare un caso bueno y otro fallido bajo condiciones equivalentes. Marque la primera diferencia significativa en vez de enumerar todos los síntomas posteriores. Ese límite suele producir una consulta más clara y un experimento más seguro.

Punto de control 3: Qué significa RTCP BYE

Compruebe «Qué significa RTCP BYE» con la entrada representativa más pequeña. Mantenga iguales los ajustes no relacionados, repita la misma acción y revise el resultado después de reabrir o reconectar. Una captura aislada es más débil que un registro con entrada, ajuste, acción, salida y hora.

Punto de control 4: RTCP BYE vs RTP timeout

Si «RTCP BYE vs RTP timeout» es ambiguo, compare un caso bueno y otro fallido bajo condiciones equivalentes. Marque la primera diferencia significativa en vez de enumerar todos los síntomas posteriores. Ese límite suele producir una consulta más clara y un experimento más seguro.

Punto de control 5: RTSP TEARDOWN vs RTCP BYE

Compruebe «RTSP TEARDOWN vs RTCP BYE» con la entrada representativa más pequeña. Mantenga iguales los ajustes no relacionados, repita la misma acción y revise el resultado después de reabrir o reconectar. Una captura aislada es más débil que un registro con entrada, ajuste, acción, salida y hora.

Punto de control 6: La transmisión finaliza después de un tiempo predecible

Si «La transmisión finaliza después de un tiempo predecible» es ambiguo, compare un caso bueno y otro fallido bajo condiciones equivalentes. Marque la primera diferencia significativa en vez de enumerar todos los síntomas posteriores. Ese límite suele producir una consulta más clara y un experimento más seguro.

Punto de control 7: Stream ends during camera reconfiguration

Compruebe «Stream ends during camera reconfiguration» con la entrada representativa más pequeña. Mantenga iguales los ajustes no relacionados, repita la misma acción y revise el resultado después de reabrir o reconectar. Una captura aislada es más débil que un registro con entrada, ajuste, acción, salida y hora.

Punto de control 8: NVR and channel behavior

Si «NVR and channel behavior» es ambiguo, compare un caso bueno y otro fallido bajo condiciones equivalentes. Marque la primera diferencia significativa en vez de enumerar todos los síntomas posteriores. Ese límite suele producir una consulta más clara y un experimento más seguro.

Punto de control 9: Packet loss before BYE

Compruebe «Packet loss before BYE» con la entrada representativa más pequeña. Mantenga iguales los ajustes no relacionados, repita la misma acción y revise el resultado después de reabrir o reconectar. Una captura aislada es más débil que un registro con entrada, ajuste, acción, salida y hora.

Punto de control 10: Checklist for RTCP BYE investigations

Si «Checklist for RTCP BYE investigations» es ambiguo, compare un caso bueno y otro fallido bajo condiciones equivalentes. Marque la primera diferencia significativa en vez de enumerar todos los síntomas posteriores. Ese límite suele producir una consulta más clara y un experimento más seguro.

Matriz de aceptación

Punto	Evidencia que conservar	Condición de aprobado
Las transmisiones de cámara RTCP BYE y RTSP finalizan inesperadamente: por qué el vídeo se detiene sin un error claro	Estado inicial, una acción y estado resultante	Otra persona reproduce el resultado declarado
Cómo depurar RTCP BYE, fin de transmisión RTP, desmontaje de cámara, tiempo de espera de sesión, pérdida de paquetes y d	Estado inicial, una acción y estado resultante	Otra persona reproduce el resultado declarado
Qué significa RTCP BYE	Estado inicial, una acción y estado resultante	Otra persona reproduce el resultado declarado
RTCP BYE vs RTP timeout	Estado inicial, una acción y estado resultante	Otra persona reproduce el resultado declarado
RTSP TEARDOWN vs RTCP BYE	Estado inicial, una acción y estado resultante	Otra persona reproduce el resultado declarado
La transmisión finaliza después de un tiempo predecible	Estado inicial, una acción y estado resultante	Otra persona reproduce el resultado declarado

Aislamiento, recuperación y entrega

Deténgase en el primer límite que falla. Conserve fuente, proyecto, sesión o captura, duplíquelo antes de una edición destructiva y cambie una variable por experimento. Repetir un flujo amplio después de varios cambios puede dar otro resultado sin explicar la causa.

Separe ausencia de evidencia de evidencia de ausencia. Una vista vacía puede indicar entrada, alcance, filtro, permiso, dispositivo, intervalo o estado equivocado. Verifique adquisición o importación antes de interpretar el decoder, editor, informe o exportación.

Antes de entregar, reabra el artefacto y revise inicio, punto de decisión y final. Registre versión, plataforma, configuración, expectativa, observación y reproducción mínima. Elimine o redacte datos sensibles y confirme que el destinatario está autorizado.

Preguntas y respuestas

¿Cuál es la forma fiable más rápida de empezar?

Use el caso representativo más pequeño, escriba el resultado esperado y cambie una variable. Confirme el recorrido básico antes de añadir filtros, efectos, ediciones, automatización o una fuente mayor.

¿Qué evidencia debe guardarse?

Conserve identidad de entrada, versión, plataforma, ajustes, acción exacta, primera transición inesperada y salida final. Cierre y reabra cualquier proyecto, sesión, informe o exportación antes de considerarlo duradero.

¿Cuándo debe repetirse el procedimiento?

Repítalo después de cambios relevantes en aplicación, sistema, driver, firmware, modelo, fuente o flujo. Preserve el caso aceptado anterior como referencia sin modificar.

¿Cuándo está listo para entregar?

Cuando otra persona autorizada identifica la entrada, repite la acción, obtiene el mismo resultado, entiende los límites restantes y abre el artefacto sin depender de estado local no documentado.

Guías relacionadas

Estas páginas en el mismo idioma cubren etapas contiguas sin cambiar el propietario canónico del tema: