2026-06-02

ONVIF funziona ma l'URL RTSP non riesce: trovare il percorso del flusso della telecamera reale

Perché il rilevamento ONVIF può funzionare mentre il flusso RTSP non riesce e come eseguire il debug di profili di telecamere, URL multimediali, autenticazione, trasporto e prove SDP.

È normale che una telecamera IP venga visualizzata correttamente nel rilevamento ONVIF mentre l'URL RTSP continua a non funzionare. Il dispositivo è visibile in rete, vengono rilevati il nome e il modello della telecamera, forse vengono elencati anche i profili, ma il flusso video vero e proprio non si apre. Gli utenti cercano "ONVIF funziona ma RTSP non riesce", "telecamera rilevata ma nessun video RTSP" o "come trovare l'URL RTSP da ONVIF" perché il successo del rilevamento sembra garantire il successo dello streaming.

Non è così.

ONVIF e RTSP sono correlati in molti flussi di lavoro delle telecamere, ma non sono lo stesso protocollo e non dimostrano la stessa cosa. ONVIF può dirti che esiste una telecamera e può fornire un profilo multimediale. RTSP deve comunque autenticarsi, descrivere il flusso, negoziare il trasporto, impostare tracce RTP e consegnare pacchetti multimediali.

RTSP Inspector si concentra sulla seconda parte: cosa succede effettivamente quando viene utilizzato uno specifico URL RTSP.

Cosa dimostra ONVIF

La scoperta ONVIF può dimostrare che:

La fotocamera risponde a WS-Discovery.
La telecamera espone un endpoint del servizio ONVIF.
Il client può raggiungere l'interfaccia di gestione della telecamera.
La fotocamera può avere uno o più profili multimediali.
Il dispositivo può segnalare gli URI dello streaming tramite i servizi multimediali ONVIF.

Ciò è utile, ma non equivale a dimostrare che il flusso RTSP funziona. Il rilevamento ONVIF può utilizzare una porta diversa, un comportamento di autenticazione diverso e un percorso del servizio diverso rispetto a RTSP.

Una telecamera può superare il rilevamento ONVIF e comunque non riuscire a eseguire l'RTSP perché:

RTSP è disabilitato nelle impostazioni della fotocamera.
L'account ONVIF non dispone dell'autorizzazione RTSP.
L'URI del flusso restituito è incompleto o solo interno.
La porta RTSP è bloccata da un firewall.
La telecamera richiede il trasporto interleaved TCP ma il client tenta UDP.
Il profilo punta a H.265 ma il client si aspetta H.264.
Il percorso del canale NVR è sbagliato.
La fotocamera restituisce SDP ma non invia pacchetti RTP.

L'URI del flusso ONVIF potrebbe non essere direttamente utilizzabile

Alcune telecamere restituiscono un URI RTSP tramite ONVIF che sembra utilizzabile ma necessita ancora di modifiche. Per esempio:

rtsp://192.168.1.50/Streaming/Channels/101

The real usable URL may need:

ONVIF profile does not guarantee codec support

The symptom may be:

RTSP Inspector helps by separating the layers:

RTSP transport can fail after ONVIF succeeds

This is common when:

Authentication can differ between ONVIF and RTSP

You may see:

RTSP/1.0 401 Unauthorized
WWW-Authenticate: Digest realm="IP Camera", nonce="..."

anche se la scoperta ONVIF ha funzionato. Ciò significa che il servizio RTSP richiede credenziali. Se il client invia credenziali e la telecamera continua a restituire "401", controlla le autorizzazioni dell'account, l'autenticazione del digest, la codifica URL e i diritti del canale.

Gli NVR rendono tutto questo più confuso perché il dispositivo ONVIF potrebbe essere l'NVR, mentre il percorso del flusso RTSP fa riferimento a un canale della telecamera dietro l'NVR. All'account potrebbe essere consentito interrogare l'NVR ma non eseguire lo streaming del flusso principale del canale 1.

Confusione del flusso principale e del flusso secondario

Molte fotocamere espongono più profili:

Flusso principale: alta risoluzione, bitrate elevato, spesso H.265.
Sub-stream: risoluzione inferiore, bitrate inferiore, spesso H.264.
Streaming mobile: dimensioni del frame ridotte e frame rate inferiore.

ONVIF può restituire uno di questi profili per impostazione predefinita. L'URL RTSP copiato da un forum o da un PDF del fornitore potrebbe puntare a un altro. Se il flusso principale è H.265 ma il client supporta solo H.264, il flusso secondario potrebbe funzionare mentre il flusso principale non funziona.

Ricerche come "Il flusso principale RTSP non funziona, il flusso secondario funziona" spesso appartengono a questa categoria. Il problema non è la scoperta. Si tratta della selezione del profilo, della selezione del codec, del bitrate o del comportamento di trasporto.

Come eseguire il debug di ONVIF funziona ma RTSP fallisce

Utilizza una lista di controllo a più livelli:

Confermare che il servizio RTSP della fotocamera sia abilitato.
Confermare che la porta RTSP, in genere 554, sia raggiungibile dal client.
Ottieni il profilo multimediale ONVIF e l'URI dello streaming.
Normalizza l'URL RTSP per il percorso di rete che stai effettivamente utilizzando.
Aggiungi le credenziali con attenzione e codifica i caratteri speciali nell'URL.
Esegui RTSP "OPZIONI" e "DESCRIBE".
Esaminare le sfide e le risposte di autenticazione.
Ispeziona SDP per codec, tipo di payload, frequenza di clock e traccia gli URL di controllo.
Confronta il trasporto interleaved UDP e TCP.
Conferma che i pacchetti RTP arrivano dopo "PLAY".
Controlla la continuità della sequenza RTP, i timestamp e il tipo di payload.
Testare separatamente il flusso principale e il flusso secondario.

Questa lista di controllo previene un errore comune: considerare il successo del rilevamento ONVIF come una prova che lo streaming multimediale dovrebbe funzionare automaticamente.

Cosa dovrebbe mostrare la traccia RTSP

Un flusso RTSP sano solitamente si presenta così:

OPTIONS rtsp://camera/stream RTSP/1.0
RTSP/1.0 200 OK

DESCRIBE rtsp://camera/stream RTSP/1.0
RTSP/1.0 200 OK
Content-Type: application/sdp

SETUP rtsp://camera/stream/trackID=1 RTSP/1.0
RTSP/1.0 200 OK
Transport: RTP/AVP/TCP;unicast;interleaved=0-1

PLAY rtsp://camera/stream RTSP/1.0
RTSP/1.0 200 OK

Final diagnosis

Prova riproducibile per «ONVIF funziona ma l'URL RTSP non riesce: trovare il percorso del flusso della telecamera reale»

La risposta diretta è che una schermata nera o un solo codice non dimostra l’origine del guasto. Una diagnosi affidabile collega richiesta e risposta RTSP, trasporto negoziato, sessione valida e poi numeri di sequenza RTP, timestamp e segnali RTCP. Per «ONVIF funziona ma l'URL RTSP non riesce: trovare il percorso del flusso della telecamera reale» parti dal livello più vicino al sintomo visibile, ma conserva una cronologia comune per non confondere controllo, rete e decodifica.

Prima di cambiare camera, firewall o VMS, crea un test di base piccolo. Registra URL RTSP senza password, ora, percorso, trasporto richiesto, risposta del server e momento del primo pacchetto multimediale. Prova separatamente UDP e TCP interleaved quando disponibili. Non cambiare insieme percorso, credenziali e trasporto: se il secondo tentativo funziona, devi poter identificare la variabile decisiva.

Livello	Evidenza da conservare	Domanda
RTSP	metodo, stato, header, CSeq e Session	Il server ha accettato proprio questa operazione?
SDP	control, payload type, clock rate e codec	È descritta la traccia attesa?
Transport	client_port, server_port o interleaved	I due estremi usano lo stesso canale?
RTP	SSRC, sequenza, timestamp e marker	Le unità arrivano in ordine spiegabile?
RTCP	sender report, CNAME e BYE	Orologio, identità e fine sono tracciabili?
Decoder	SPS/PPS/VPS e packetization mode	Il payload ricevuto può inizializzare il decoder?

Separa «nessun media ricevuto» da «media ricevuto ma non decodificabile». Se RTP manca dopo SETUP e PLAY riusciti, verifica UDP, NAT, firewall e risposta Transport. Buchi nella sequenza provano perdita o riordinamento. Una sequenza continua senza immagine sposta l’indagine su payload type, clock rate, confini del frame e parametri H.264 o H.265. Questo confine è più utile del messaggio generico del player.

Come si scrive una risposta citabile?

Usa tre frasi: ultima operazione riuscita, prima evidenza fallita, prossimo test che separa due cause. Esempio: «DESCRIBE, SETUP e PLAY riescono; nessun RTP arriva alle porte annunciate; una prova TCP interleaved separerà blocco UDP e percorso media errato». Non attribuire il guasto a camera o rete senza una risposta o un pacchetto che dimostri il confine.

Quali dati rendono il caso riproducibile?

Conserva OPTIONS, DESCRIBE, SETUP e PLAY, SDP, risposta Transport e Session ripulita. Per RTP annota SSRC, prima e ultima sequenza, clock rate, buchi e durata. Indica se VLC o un altro VMS funziona, ma usalo come confronto controllato, non come prova che il client riuscito interpreti correttamente ogni regola.

Quando controllare server o client?

Controlla il server se rifiuta un metodo, fornisce un control URL assente, restituisce un trasporto incompatibile o cambia SSRC o clock senza transizione. Controlla il client se riusa un nonce scaduto, perde Session, richiede UDP senza aprire le porte o tratta ogni fine NAL come fine access unit. Se il difetto è intermedio, pacchetto e tempo devono accompagnare ogni conclusione.

Come verificare il rapporto?

Ripeti da una connessione nuova e confronta le cronologie fino alla prima differenza. Rimuovi password e valori Authorization completi. Collega ogni conclusione a CSeq, sequenza o timestamp. Segui la guida RTSP correlata e usa RTSP Inspector per testare uno stream RTSP e raccogliere prove localmente, senza caricare il video su un servizio pubblico.

Dall’osservazione al verdetto per livello

In «ONVIF funziona ma l'URL RTSP non riesce: trovare il percorso del flusso della telecamera reale» scrivi prima l’osservazione e poi l’interpretazione. Un’altra persona deve poter ritrovare l’osservazione nella cattura: stato RTSP legato a CSeq, valore SDP, risposta Transport, buco di sequenza, cambio SSRC o differenza tra RTP timestamp e RTCP sender report. “Il server è lento” o “il codec è incompatibile” resta un’ipotesi finché una prova precisa non la rende migliore delle alternative.

Dividi il percorso in confini. Prima si apre TCP, poi vengono accettati OPTIONS o DESCRIBE. SDP deve descrivere una traccia utilizzabile con control URL, payload type e clock rate. SETUP richiede una risposta Transport compatibile e PLAY una Session valida. Solo dopo vengono arrivo RTP, ordine, tempo e preparazione del decoder. Fermati al primo confine senza prova di successo.

Mantieni fonte e intervallo costanti nei confronti. UDP contro TCP interleaved usa lo stesso percorso e le stesse credenziali. Main stream contro sub stream conserva client e trasporto. Confrontando VLC e VMS, registra metodi, header e URL reali; differenze in control URL, Authorization, Session o keepalive possono spiegare il risultato più del nome del programma.

Matrice di esclusione

Parti da due ipotesi. Se non arriva media, UDP può essere bloccato oppure il server può inviare ad altre porte. TCP interleaved verifica la prima; confrontare offerta e risposta Transport, IP e porte verifica la seconda. Per immagine corrotta, la sequenza RTP separa perdita da inizializzazione incompleta, mentre SPS/PPS/VPS prima del primo frame verifica i parametri codec.

Per ogni ipotesi annota una prova favorevole e una che potrebbe smentirla. Un’affermazione che nessun pacchetto può negare è troppo ampia. “NAT elimina UDP” è smentita da RTP sulla porta client. “Mancano parametri H.264” è smentita da SPS e PPS validi prima di IDR. Il rapporto resta così prioritario.

Leggere il tempo senza conclusioni eccessive

RTSP CSeq ordina transazioni, RTP sequence ordina pacchetti, RTP timestamp esprime il tempo di campionamento e l’orologio di cattura l’arrivo al punto osservato. Non sono lo stesso orologio. Variazione di arrivo non prova drift; salto timestamp non prova perdita senza sequenza. RTCP sender report collega orologi RTP audio e video a un riferimento comune.

Pacchetto di accettazione

Chiudi il caso quando la correzione si ripete su una connessione nuova con una sola modifica documentata. Il rapporto indica input, ultimo confine riuscito, prima prova fallita, modifica, risultato e test aperti. Allega un breve transcript o statistiche mirate. Nascondi i segreti, ma conserva CSeq, Session ripulita, SSRC e intervallo.

Usa la risoluzione problemi RTSP per ricostruire il flusso e i report di RTSP Inspector per consegnare il confine al team camera, rete o VMS.