2026-06-03

Depuración de URL de control agregado RTSP: control SDP:*, URL de seguimiento, CONFIGURACIÓN 404 y error de reproducción

Cómo solucionar problemas de URL de control agregado RTSP, control SDP:* atributos, rutas de control a nivel de pista, errores de CONFIGURACIÓN 404, fallas de PLAY y errores de construcción de URL de cámara.

Las URL de las cámaras RTSP a menudo fallan porque el cliente crea una URL de control incorrecta desde SDP. Los usuarios buscan "RTSP SETUP 404", "estrella de control SDP", "URL de control agregado RTSP", "URL de seguimiento RTSP incorrecta", "DESCRIBIR funciona pero la CONFIGURACIÓN falla" y "REPRODUCCIÓN falla después de la CONFIGURACIÓN" cuando una cámara devuelve SDP correctamente pero el medio nunca se inicia.

RTSP Inspector es útil porque esta falla no tiene que ver con si el reproductor puede dibujar video. Se trata de si el cliente RTSP interpretó correctamente los atributos de "control" a nivel de sesión y a nivel de medios.

El síntoma común

Un rastro típico se ve así:

DESCRIBE rtsp://camera/live
200 OK
SDP contains a=control:*
SDP video media contains a=control:trackID=1
SETUP rtsp://camera/trackID=1
404 Not Found

The camera did not necessarily reject RTSP. The client may have constructed SETUP with the wrong base URL.

Session-level and media-level control

SDP can contain control attributes at different levels:

a=control:*
m=video 0 RTP/AVP 96
a=control:trackID=1
m=audio 0 RTP/AVP 97
a=control:trackID=2

El control a nivel de sesión puede identificar el recurso agregado utilizado para "REPRODUCIR" y "PAUSAR". El control de nivel de medios identifica cada pista RTP utilizada para "CONFIGURAR".

Si un cliente trata cada valor de "control" como una ruta absoluta, puede crear URL no válidas.

URL de control relativo versus absoluto

Los valores de control RTSP SDP pueden ser:

URL RTSP absolutas.
Caminos relativos.
Identificadores de seguimiento.
* control agregado.
Rutas específicas del proveedor.

Ejemplos:

a=control:rtsp://192.168.1.10/live/trackID=1
a=control:trackID=1
a=control:streamid=0
a=control:video
a=control:*

The client must combine relative track control values with the correct base URL. A tiny difference such as /live/trackID=1 vs /trackID=1 can turn a working camera into a 404 Not Found.

DESCRIBE succeeds but SETUP fails

This is one of the strongest search patterns for this article. DESCRIBE proves the camera accepted the main URL and returned SDP. SETUP failure points to transport negotiation, track URL construction, unsupported media track, or camera firmware behavior.

Evidence to collect:

Original DESCRIBE URL.
Content-Base header if present.
Content-Location header if present.
Session-level a=control.
Media-level a=control for each track.
Exact SETUP URL.
SETUP response status.
Transport header used by SETUP.

Without the SETUP URL, the diagnosis is incomplete.

Content-Base and Content-Location

Some cameras include Content-Base or Content-Location headers in the DESCRIBE response. These headers can affect how relative SDP control paths should be resolved.

Failure patterns:

Client ignores Content-Base.
Client uses the original DESCRIBE URL when camera intended a different base.
Camera returns a base URL with trailing slash differences.
Proxy rewrites the RTSP URL but not SDP.
Client normalizes away a path component needed by the camera.

These details are exactly why protocol evidence matters.

PLAY uses aggregate control

After SETUP succeeds for one or more tracks, PLAY may need to target the aggregate control URL instead of a single track URL. Some cameras accept either. Others are strict.

Search symptoms:

"RTSP SETUP works but PLAY fails"
"RTSP 460 Only Aggregate Operation Allowed"
"RTSP PLAY 404"
"RTSP track SETUP OK no video"

If PLAY targets the wrong URI, the RTP stream may never start even though SETUP returned 200 OK.

Multi-track audio and video

The bug is easier to see when both audio and video exist:

m=video ...
a=control:trackID=1
m=audio ...
a=control:trackID=2

El cliente debe CONFIGURAR ambas pistas con sus propias URL de control y luego REPRODUCIR la URL agregada correcta. Si el cliente solo configura video pero PLAY apunta al audio, o si combina ambas pistas en una URL de CONFIGURACIÓN, la cámara puede devolver un error que parece no estar relacionado.

URL del perfil ONVIF frente a URL de seguimiento RTSP

ONVIF puede informar URI de transmisión que difieren de las URL de seguimiento SDP finales. Un URI de transmisión de ONVIF puede ser válido para DESCRIBE pero no directamente válido para cada solicitud de CONFIGURACIÓN.

Eso crea la frase de soporte común: "ONVIF funciona pero la URL RTSP falla". El siguiente paso de diagnóstico es inspeccionar el SDP y las URL de CONFIGURACIÓN derivadas, no seguir generando nuevas URL ONVIF.

Lista de verificación de depuración

Utilice este flujo de trabajo:

Capturar DESCRIBIR respuesta.
Guarde Content-Base y Content-Location.
Extraiga el nivel de sesión a=control.
Extraiga cada nivel de medio a=control.
Cree la URL de CONFIGURACIÓN esperada manualmente.
Compárelo con la URL de CONFIGURACIÓN del cliente.
Compruebe si la CONFIGURACIÓN falla con 404, 461 o 500.
Confirme si PLAY apunta a una URL agregada o de seguimiento.
Verifique el comportamiento de audio/vídeo multipista.
Conserve las líneas de solicitud RTSP exactas para la asistencia del proveedor.

Diagnóstico final

Los errores de control agregado de RTSP se esconden dentro de la interpretación de SDP. Una cámara puede aceptar DESCRIBE y aun así rechazar SETUP o PLAY si el cliente crea la pista incorrecta o la URL de control agregada.

RTSP Inspector ayuda a exponer los atributos de control de SDP, los encabezados de la base de contenido, las URL de CONFIGURACIÓN y el destino de PLAY para que los ingenieros puedan demostrar si el problema es la construcción de la URL, el rigor de la cámara, la reescritura del proxy o el manejo de SDP del lado del cliente.

Evidencia reproducible para «Depuración de URL de control agregado RTSP: control SDP:*, URL de seguimiento, CONFIGURACIÓN 404 y error de reproducción»

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 «Depuración de URL de control agregado RTSP: control SDP:*, URL de seguimiento, CONFIGURACIÓN 404 y error de reproducción», 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 «Depuración de URL de control agregado RTSP: control SDP:, URL de seguimiento, CONFIGURACIÓN 404 y error de reproducción» es: Cómo solucionar problemas de URL de control agregado RTSP, control SDP: atributos, rutas de control a nivel de pista, errores de CONFIGURACIÓN 404, fallas de PLAY y errores de construcción de URL de cámara. 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: Depuración de URL de control agregado RTSP: control SDP:, URL de seguimiento, CONFIGURACIÓ

Si «Depuración de URL de control agregado RTSP: control SDP:*, URL de seguimiento, CONFIGURACIÓN 404 y error de reproducción» 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 2: Cómo solucionar problemas de URL de control agregado RTSP, control SDP: atributos, rutas d

Compruebe «Cómo solucionar problemas de URL de control agregado RTSP, control SDP:* atributos, rutas de control a nivel de pista, errores de CONFIGURACIÓN 404, f» 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 3: El síntoma común

Si «El síntoma común» 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 4: Session-level and media-level control

Compruebe «Session-level and media-level control» 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 5: URL de control relativo versus absoluto

Si «URL de control relativo versus absoluto» 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 6: DESCRIBE succeeds but SETUP fails

Compruebe «DESCRIBE succeeds but SETUP fails» 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 7: Content-Base and Content-Location

Si «Content-Base and Content-Location» 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 8: PLAY uses aggregate control

Compruebe «PLAY uses aggregate control» 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 9: Multi-track audio and video

Si «Multi-track audio and video» 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 10: URL del perfil ONVIF frente a URL de seguimiento RTSP

Compruebe «URL del perfil ONVIF frente a URL de seguimiento RTSP» 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.

Matriz de aceptación

Punto	Evidencia que conservar	Condición de aprobado
Depuración de URL de control agregado RTSP: control SDP:, URL de seguimiento, CONFIGURACIÓN 404 y error de reproducción	Estado inicial, una acción y estado resultante	Otra persona reproduce el resultado declarado
Cómo solucionar problemas de URL de control agregado RTSP, control SDP: atributos, rutas de control a nivel de pista, er	Estado inicial, una acción y estado resultante	Otra persona reproduce el resultado declarado
El síntoma común	Estado inicial, una acción y estado resultante	Otra persona reproduce el resultado declarado
Session-level and media-level control	Estado inicial, una acción y estado resultante	Otra persona reproduce el resultado declarado
URL de control relativo versus absoluto	Estado inicial, una acción y estado resultante	Otra persona reproduce el resultado declarado
DESCRIBE succeeds but SETUP fails	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: