Callaba SRT Server

Cos’è un server SRT?

Un Server SRT è l’endpoint che accetta o gestisce connessioni SRT. Può ricevere uno stream SRT live da un encoder, inoltrarlo a un altro sistema o fungere da punto di consegna controllato tra una sorgente remota e una piattaforma di produzione.

In un workflow live tipico, il server SRT svolge quattro funzioni pratiche:

• Riceve il feed live: un encoder per telecamera, OBS, vMix, FFmpeg, Larix o un’altra sorgente invia il video al server.
• Protegge il percorso di contribution: SRT può recuperare i pacchetti persi e cifrare la sessione di trasporto.
• Espone statistiche live: gli operatori monitorano bitrate, RTT, perdita di pacchetti, ritrasmissioni e stato della connessione.
• Passa lo stream a valle: il server instrada il feed verso registrazione, transcodifica, restreaming, switching o riproduzione.

Il server SRT diventa così il confine tra sorgente e piattaforma. Quando una squadra remota dice di essere in trasmissione, qui verifichi che il segnale arrivi davvero, sia stabile e possa essere usato a valle.

Server SRT e protocollo SRT

Il protocollo SRT è il metodo di trasporto. Il Server SRT è il sistema o endpoint software che usa il protocollo per ricevere o inviare stream live.

Cos’è un server SRT live?

Un server SRT live è un server SRT usato per contribution video in tempo reale o quasi. Riceve lo stream durante l’evento e lo inoltra alla produzione live, alla registrazione o alla distribuzione.

I team usano server SRT live per eventi remoti, ingest cloud da telecamere ed encoder, trasporto studio-cloud, feed partner, percorsi di backup, produzione remota e restreaming verso più destinazioni.

La parola «live» conta perché la regolazione SRT è diversa dal trasferimento file. Il server deve bilanciare ritardo e recupero. Se la latenza è troppo bassa per la rete reale, lo stream può connettersi ma interrompersi con perdita o jitter.

Come funziona un server SRT

Un server SRT riceve audio e video già codificati tramite una connessione SRT. Nei workflow live, SRT trasporta spesso MPEG-TS multiplexato; il container dipende da mittente e workflow. Sono comuni video H.264 o H.265/HEVC, audio AAC e talvolta metadati.

1. Un encoder crea lo stream audio e video live.
2. L’encoder invia lo stream a un server SRT.
3. Il server SRT riceve lo stream e controlla lo stato della connessione.
4. Se si perdono pacchetti, SRT può richiederne la ritrasmissione finché sono ancora utili.
5. Il server passa lo stream allo step seguente: registratore, transcoder, restream, switcher, workflow API o sistema di riproduzione.

Modalità Caller, Listener e Rendezvous

SRT usa tre modalità di connessione. La modalità decide quale lato avvia la connessione e come la sessione attraversa firewall e NAT.

• Listener: attende una connessione SRT in entrata su una porta UDP nota. È la modalità tipica per un server di ingest cloud o un endpoint in data center.
• Caller: avvia la connessione a un Listener. È comune per encoder sul campo, OBS, vMix, FFmpeg, app mobili e sorgenti remote.
• Rendezvous: entrambi i lati avviano la connessione. Può aiutare in alcuni casi NAT, ma va testato attentamente prima della produzione.

Porte del server SRT e regole firewall

SRT usa UDP. La porta UDP corretta deve quindi essere aperta nel security group cloud, nel firewall host, nel router o nella policy di rete.

• il server ha un IP pubblico o un indirizzo di rete raggiungibile;
• la porta UDP corretta è aperta;
• l’encoder usa la modalità Caller/Listener corretta;
• lo stream ID corrisponde alla regola di routing, se usato;
• la passphrase coincide sui due lati, se la cifratura è attiva;
• il workflow ricevente è associato all’uscita a valle corretta.

Un errore comune è verificare solo che l’encoder dica «connesso». Non basta: devi confermare che i media arrivino, il bitrate sia stabile e il sistema a valle possa usare lo stream.

Esempio di configurazione del server SRT

Questa è una configurazione pratica per il primo test. Sostituisci host, porta, stream ID e passphrase con i tuoi valori.

Server side:
mode: listener
UDP port: 10080
latency: 200 ms
stream ID: event-main
passphrase: optional, same on both sides

Sender side:
srt://YOUR_CALLABA_IP:10080?mode=caller&latency=200&streamid=event-main

Dove si colloca il server SRT nei workflow live

SRT è particolarmente efficace sul lato contribution, dove il feed live viaggia dalla sorgente alla piattaforma.

telecamera o encoder → server SRT → transcoder / registratore / restream / workflow player

Dopo la ricezione, la piattaforma prepara lo stream per restreaming, registrazione, transcodifica, riproduzione, routing, failover, workflow API o monitoraggio.

Server SRT rispetto a RTMP, HLS, WebRTC e NDI

SRT non sostituisce ogni tecnologia video: risolve una parte specifica del workflow.

Per un confronto a livello di protocollo, leggi SRT vs RTMP.

Come distribuire un server SRT

La configurazione precisa dipende da software, provider cloud e workflow, ma la logica di distribuzione è generalmente la stessa.

1. Crea un server o un’istanza cloud con CPU, rete e storage sufficienti per il workflow.
2. Apri la porta UDP necessaria nel security group cloud e nel firewall host.
3. Crea un Listener SRT che riceverà lo stream in ingresso.
4. Imposta regole per stream ID e passphrase se servono routing e cifratura.
5. Collega l’encoder come Caller SRT e invia lo stream all’endpoint Listener.
6. Controlla le statistiche live come bitrate, RTT, perdita di pacchetti, ritrasmissioni e stato.
7. Instrada lo stream a valle verso registrazione, restreaming, transcodifica o riproduzione.

Come usare un server SRT in Callaba

In Callaba, un server SRT è normalmente un punto di ingest controllato. Una sorgente remota invia lo stream a Callaba, che lo rende disponibile allo step successivo.

Workflow Callaba comuni:

• encoder SRT verso Callaba, poi restream su Twitch o YouTube;
• OBS verso Callaba su SRT, poi registrazione dello stream;
• vMix verso Callaba su SRT, poi routing verso un’altra destinazione;
• app mobile verso Callaba su SRT, poi restream sui social;
• sede remota verso Callaba, poi packaging per la riproduzione web;
• ingresso SRT verso multiview web, registratore, routing API e player controllato.

Cosa monitorare su un server SRT

Una sessione SRT connessa non è sempre sana. Monitora salute del trasporto e dei media.

Segnali di trasporto

• Stato della connessione: connessa, disconnessa, in riconnessione o fallita.
• Bitrate in ingresso: indica se i media continuano a fluire al ritmo previsto.
• RTT: tempo di andata e ritorno tra mittente e ricevitore.
• Perdita di pacchetti: quantità di dati persa sul percorso.
• Ritrasmissioni: frequenza con cui SRT recupera pacchetti mancanti.
• Jitter: variazione nella temporizzazione dei pacchetti.
• Pressione del buffer di ricezione: indica se la connessione è vicina al limite di recupero.

Segnali multimediali

• video nero o bloccato, audio assente o muto;
• codec, frame rate, risoluzione o formato audio errati;
• timestamp errati, keyframe mancanti o mapping incompatibile.

Problemi comuni di un server SRT

La connessione SRT non parte

Controlla modalità, porta UDP, IP pubblico, firewall, stream ID e passphrase. La maggior parte degli handshake fallisce per modalità errata, UDP bloccato, porta sbagliata o impostazioni di sicurezza non corrispondenti.

Lo stream si connette ma il video è instabile

Controlla RTT, jitter, perdita, ritrasmissioni e latenza. Se la latenza è troppo aggressiva per la rete, SRT non riesce a recuperare i pacchetti in tempo.

Lo stream si connette ma non c’è audio

Controlla prima l’encoder: sorgente audio attiva, dispositivo corretto, codec compatibile con lo step successivo e traccia leggibile dall’applicazione ricevente.

Prima di diagnosticare SRT, conferma che l’audio esista alla sorgente. Usa il monitoraggio locale in OBS, vMix, nell’encoder hardware, in cuffia o nella preview del dispositivo.

Le statistiche SRT sono buone ma gli spettatori hanno problemi

Se il collegamento SRT è sano ma il pubblico vede blocchi o artefatti, il problema può essere a valle. Controlla transcodifica, packaging, origin, CDN, player e formato di uscita prima di accusare il server.

Server SRT self-hosted o gestito

Puoi gestire direttamente un server SRT o usare una piattaforma gestita. La scelta dipende dal controllo operativo che il team vuole mantenere.

Callaba può essere una piattaforma SRT cloud o self-hosted. Avviala su AWS o installala sul tuo server, crea punti di ingest SRT e collega gli stream a restreaming, registrazione, routing, preview web, multiview, player e workflow API.

Checklist del giorno dell’evento per un server SRT

• Conferma l’IP o hostname del server.
• Conferma che la porta UDP sia aperta.
• Conferma la modalità Caller/Listener/Rendezvous su entrambi i lati.
• Conferma lo stream ID, se usato.
• Conferma la passphrase di cifratura, se usata.
• Conferma bitrate, codec, frame rate, risoluzione e audio previsti.
• Avvia lo stream e verifica il bitrate in ingresso.
• Controlla RTT, perdita, ritrasmissioni e jitter.
• Controlla video e audio reali, non solo lo stato.
• Conferma la route a valle: registrazione, restreaming, transcodifica o riproduzione.
• Conferma la sincronizzazione temporale: server ed encoder devono usare NTP o una sorgente coerente per correlare log e registrazioni durante la diagnosi.
• Testa il percorso di backup prima dell’evento.

Riferimenti ufficiali e letture correlate

Usali per dettagli SRT a livello di protocollo, configurazione Callaba o guide correlate.

• Bozza del protocollo SRT
• Documentazione Haivision SRT Live Transmit
• Cos’è il protocollo SRT?
• Come avviare uno streaming SRT in OBS Studio
• Come ricevere uno stream SRT in OBS Studio
• Inviare e ricevere SRT con vMix
• Trovare la latenza ideale per la configurazione SRT
• Documentazione API dei server SRT

FAQ

Cos’è un server SRT?

Un server SRT è un endpoint di ingest o relay live che riceve, invia o instrada stream SRT. Sposta un feed da encoder, telecamera, sede remota, studio, dispositivo mobile o partner verso un workflow controllato.

Cos’è un server SRT live?

Un server SRT live serve alla contribution video in tempo reale. Riceve il video durante l’evento e lo passa a registrazione, restreaming, transcodifica, switching, routing o riproduzione.

Un server SRT è uguale a un server di streaming?

Non sempre. Un server SRT gestisce soprattutto ingest live o trasporto tra endpoint controllati. Una piattaforma completa può gestire anche transcodifica, registrazione, riproduzione, analytics, controllo accessi, API e CDN.

Un server SRT usa UDP?

Sì. SRT funziona su UDP. La porta UDP corretta deve essere aperta nel firewall server, nel security group cloud, nel router o nella policy di rete.

Quale porta usa un server SRT?

SRT non richiede una porta fissa universale. La porta è definita dalla configurazione. In produzione si riserva una porta o un intervallo UDP e si documentano feed, tenant o eventi associati.

Il server SRT deve essere Listener o Caller?

Per la maggior parte degli ingest cloud, il server è Listener e l’encoder Caller. Funziona bene con IP pubblico o DNS, porta UDP nota e regole firewall chiare.

OBS può inviare a un server SRT?

Sì. Con un URL di uscita SRT, OBS invia il video al server, che può instradarlo a registrazione, restreaming, transcodifica o riproduzione.

vMix può inviare a un server SRT?

Sì. vMix supporta SRT e può inviare o ricevere stream. Una configurazione comune invia SRT da vMix a Callaba, che gestisce monitoraggio, routing, registrazione o restreaming.

SRT è migliore di RTMP?

SRT è in genere migliore per contribution su reti instabili, con perdita o lunghe distanze. RTMP resta comune per pubblicazione semplice e ingest di piattaforma. Molti workflow usano SRT per contribution e RTMP/RTMPS per l’uscita finale sui social.

I browser possono riprodurre SRT direttamente?

Nei normali workflow web, no. Il server riceve prima SRT, poi la piattaforma converte o impacchetta il flusso in HLS o WebRTC.

Perché lo stream SRT si connette ma non mostra video?

La connessione di trasporto può funzionare mentre il payload è errato. Controlla codec, container, timestamp, keyframe, tracce audio, mapping, compatibilità a valle e arrivo effettivo del bitrate.

Come rendo più affidabile un server SRT?

Usa un server stabile, apri le porte UDP corrette, scegli latenza realistica, monitora RTT e ritrasmissioni, mantieni margine di banda, valida il payload e prova un endpoint di backup prima dell’evento.

SRT trasporta normalmente MPEG-TS?

Nei workflow live, SRT trasporta spesso MPEG-TS con audio e video multiplexati. Il container esatto dipende da mittente e workflow. Il server deve verificare il payload, non solo la connessione.

Quali metriche SRT devo controllare per prime?

Inizia da bitrate in ingresso, RTT, perdita, ritrasmissioni e stato. In buone condizioni l’RTT è spesso 20–60 ms. Sopra 150 ms o 1–2% di perdita, aumenta latenza, riduci bitrate o migliora la rete.

Passi successivi

• Cos’è il protocollo SRT?
• SRT vs RTMP
• Come avviare uno streaming SRT in OBS Studio
• Come ricevere uno stream SRT in OBS Studio
• Inviare e ricevere SRT con vMix
• Trovare la latenza ideale per la configurazione SRT
• Documentazione API dei server SRT

Ultimo aggiornamento: 22 luglio 2026