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.

Risposta diretta e confine di accettazione

La risposta breve a «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. Tratta questa frase come un risultato da verificare, non come una promessa per ogni input, dispositivo, progetto o ambiente. Un risultato completo registra stato iniziale, azione esatta, output visibile e condizione che dimostra la conclusione dell’attività in RTSP Inspector.

Procedura basata sulle prove

Parti da un caso piccolo e ripetibile prima di modificare un progetto intero. Registra versione, sistema operativo, identità dell’input o dispositivo, impostazioni rilevanti e risultato atteso. Esegui un’azione deliberata, conserva la prima transizione inattesa e confrontala con un caso noto quando disponibile. Cambiare più controlli insieme nasconde quale condizione ha creato o corretto il problema.

Punto di controllo 1: ONVIF funziona ma l'URL RTSP non riesce: trovare il percorso del flusso della telecamera r

Chiudi «ONVIF funziona ma l'URL RTSP non riesce: trovare il percorso del flusso della telecamera reale» solo quando il risultato salvato, esportato o riaperto conserva lo stato osservato. Il feedback temporaneo dell’interfaccia è utile, ma la prova durevole è più forte. Registra ogni limite residuo per chi prosegue.

Punto di controllo 2: Perché il rilevamento ONVIF può funzionare mentre il flusso RTSP non riesce e come eseguir

Per «Perché il rilevamento ONVIF può funzionare mentre il flusso RTSP non riesce e come eseguire il debug di profili di telecamere, URL multimediali, auten», separa una decisione del prodotto da un limite del sistema, hardware, file sorgente, permesso o processo. Conferma quale livello ha prodotto la prova prima di assegnare una causa. Così un sintomo vicino non diventa una causa radice data per certa.

Punto di controllo 3: Cosa dimostra ONVIF

Chiudi «Cosa dimostra ONVIF» solo quando il risultato salvato, esportato o riaperto conserva lo stato osservato. Il feedback temporaneo dell’interfaccia è utile, ma la prova durevole è più forte. Registra ogni limite residuo per chi prosegue.

Punto di controllo 4: L'URI del flusso ONVIF potrebbe non essere direttamente utilizzabile

Per «L'URI del flusso ONVIF potrebbe non essere direttamente utilizzabile», separa una decisione del prodotto da un limite del sistema, hardware, file sorgente, permesso o processo. Conferma quale livello ha prodotto la prova prima di assegnare una causa. Così un sintomo vicino non diventa una causa radice data per certa.

Punto di controllo 5: ONVIF profile does not guarantee codec support

Chiudi «ONVIF profile does not guarantee codec support» solo quando il risultato salvato, esportato o riaperto conserva lo stato osservato. Il feedback temporaneo dell’interfaccia è utile, ma la prova durevole è più forte. Registra ogni limite residuo per chi prosegue.

Punto di controllo 6: RTSP transport can fail after ONVIF succeeds

Per «RTSP transport can fail after ONVIF succeeds», separa una decisione del prodotto da un limite del sistema, hardware, file sorgente, permesso o processo. Conferma quale livello ha prodotto la prova prima di assegnare una causa. Così un sintomo vicino non diventa una causa radice data per certa.

Punto di controllo 7: Authentication can differ between ONVIF and RTSP

Chiudi «Authentication can differ between ONVIF and RTSP» solo quando il risultato salvato, esportato o riaperto conserva lo stato osservato. Il feedback temporaneo dell’interfaccia è utile, ma la prova durevole è più forte. Registra ogni limite residuo per chi prosegue.

Punto di controllo 8: Confusione del flusso principale e del flusso secondario

Per «Confusione del flusso principale e del flusso secondario», separa una decisione del prodotto da un limite del sistema, hardware, file sorgente, permesso o processo. Conferma quale livello ha prodotto la prova prima di assegnare una causa. Così un sintomo vicino non diventa una causa radice data per certa.

Punto di controllo 9: Come eseguire il debug di ONVIF funziona ma RTSP fallisce

Chiudi «Come eseguire il debug di ONVIF funziona ma RTSP fallisce» solo quando il risultato salvato, esportato o riaperto conserva lo stato osservato. Il feedback temporaneo dell’interfaccia è utile, ma la prova durevole è più forte. Registra ogni limite residuo per chi prosegue.

Punto di controllo 10: Cosa dovrebbe mostrare la traccia RTSP

Per «Cosa dovrebbe mostrare la traccia RTSP», separa una decisione del prodotto da un limite del sistema, hardware, file sorgente, permesso o processo. Conferma quale livello ha prodotto la prova prima di assegnare una causa. Così un sintomo vicino non diventa una causa radice data per certa.

Matrice di accettazione

Punto	Prova da conservare	Criterio di superamento
ONVIF funziona ma l'URL RTSP non riesce: trovare il percorso del flusso della telecamera reale	Stato iniziale, un’azione e stato risultante	Una seconda persona riproduce il risultato
Perché il rilevamento ONVIF può funzionare mentre il flusso RTSP non riesce e come eseguire il debug di profili di telec	Stato iniziale, un’azione e stato risultante	Una seconda persona riproduce il risultato
Cosa dimostra ONVIF	Stato iniziale, un’azione e stato risultante	Una seconda persona riproduce il risultato
L'URI del flusso ONVIF potrebbe non essere direttamente utilizzabile	Stato iniziale, un’azione e stato risultante	Una seconda persona riproduce il risultato
ONVIF profile does not guarantee codec support	Stato iniziale, un’azione e stato risultante	Una seconda persona riproduce il risultato
RTSP transport can fail after ONVIF succeeds	Stato iniziale, un’azione e stato risultante	Una seconda persona riproduce il risultato

Isolamento, ripristino e consegna

Fermati al primo confine che fallisce. Conserva sorgente, progetto, sessione o cattura, crea una copia prima di modifiche distruttive e cambia una variabile per esperimento. Ripetere un flusso ampio dopo più cambiamenti può dare un esito diverso senza spiegarlo.

Separa assenza di prove da prova di assenza. Una vista vuota può indicare input, ambito, filtro, permesso, dispositivo, intervallo o stato errato. Verifica acquisizione o importazione prima di interpretare decoder, editor, report o esportazione.

Prima della consegna, riapri l’artefatto e controlla inizio, punto decisionale e fine. Registra versione, piattaforma, configurazione, attesa, osservazione e riproduzione minima. Rimuovi o oscura dati sensibili e verifica l’autorizzazione del destinatario.

Domande e risposte

Qual è il modo affidabile più rapido per iniziare?

Usa il più piccolo caso rappresentativo, scrivi il risultato atteso e cambia una variabile. Conferma il percorso base prima di aggiungere filtri, effetti, modifiche, automazione o una sorgente maggiore.

Quali prove vanno salvate?

Conserva identità dell’input, versione, piattaforma, impostazioni, azione esatta, prima transizione inattesa e output finale. Chiudi e riapri progetto, sessione, report o export prima di considerarli durevoli.

Quando va ripetuta la procedura?

Ripetila dopo cambiamenti rilevanti ad applicazione, sistema, driver, firmware, modello, sorgente o workflow. Conserva il caso accettato precedente come riferimento non modificato.

Quando il risultato è pronto per la consegna?

Quando un’altra persona autorizzata identifica l’input, ripete l’azione, vede lo stesso risultato, comprende i limiti e apre l’artefatto senza stato locale non documentato.

Guide correlate

Queste pagine nella stessa lingua coprono le fasi vicine senza cambiare il proprietario canonico dell’argomento: