9 Connections (Connessioni)

Le richieste RTSP possono essere trasmesse in diversi modi:

connessioni di trasporto persistenti usate per più transazioni richiesta-risposta;
una connessione per transazione richiesta/risposta;
modalità senza connessione.

Il tipo di connessione di trasporto è definito dall'URI RTSP (sezione 3.2). Per lo scheme «rtsp» si assume una connessione persistente, mentre lo scheme «rtspu» richiede l'invio delle richieste RTSP senza stabilire una connessione.

A differenza di HTTP, RTSP consente al server media di inviare richieste al client media. Ciò è supportato solo per connessioni persistenti, poiché altrimenti il server media non ha un modo affidabile di raggiungere il client. Inoltre, è l'unico modo per cui le richieste dal server al client hanno probabilità di attraversare i firewall.

9.1 Pipelining (Pipeline)

Un client che supporta connessioni persistenti o modalità senza connessione PUÒ «mettere in pipeline» le richieste (cioè inviare più richieste senza attendere ogni risposta). Un server DEVE inviare le risposte a tali richieste nello stesso ordine in cui le richieste sono state ricevute.

9.2 Reliability and Acknowledgements (Affidabilità e conferme)

Le richieste sono confermate dal ricevente salvo che non siano inviate a un gruppo multicast. Se non c'è conferma, il mittente può reinviare lo stesso messaggio dopo un timeout di un round-trip time (RTT). Il round-trip time è stimato come in TCP (RFC 1123) [18], con valore iniziale di 500 ms. Un'implementazione PUÒ memorizzare l'ultima misura RTT come valore iniziale per connessioni future.

Se si usa un protocollo di trasporto affidabile per trasportare RTSP, le richieste NON DEVONO essere ritrasmesse; l'applicazione RTSP DEVE invece affidarsi al trasporto sottostante per l'affidabilità.

Se sia il trasporto affidabile sottostante come TCP sia l'applicazione RTSP ritrasmettono le richieste, ogni perdita di pacchetto può produrre due ritrasmissioni. Il ricevente in genere non può trarre vantaggio dalla ritrasmissione a livello applicazione perché lo stack di trasporto non consegnerà la ritrasmissione applicativa prima che il primo tentaggio raggiunga il ricevente. Se la perdita è dovuta a congestione, ritrasmissioni multiple a livelli diversi peggioreranno la congestione.

Se RTSP è usato su una LAN a RTT basso, procedure standard per ottimizzare le stime iniziali del round trip TCP, come in T/TCP (RFC 1644) [22], possono essere utili.

L'intestazione Timestamp (sezione 12.38) evita il problema dell'ambiguità delle ritrasmissioni [23, p. 301] e rende superfluo l'algoritmo di Karn.

Ogni richiesta porta un numero di sequenza nell'intestazione CSeq (sezione 12.17), incrementato di uno per ogni richiesta distinta trasmessa. Se una richiesta è ripetuta per mancanza di conferma, la richiesta DEVE portare il numero di sequenza originale (cioè il numero non è incrementato).

I sistemi che implementano RTSP DEVONO supportare RTSP su TCP e POSSONO supportare UDP. La porta predefinita del server RTSP è 554 sia per UDP sia per TCP.

Più pacchetti RTSP destinati allo stesso endpoint di controllo possono essere impacchettati in una singola PDU del livello inferiore o incapsulati in un flusso TCP. I dati RTSP POSSONO essere intercalati con pacchetti RTP e RTCP. A differenza di HTTP, un messaggio RTSP DEVE contenere un'intestazione Content-Length ogni volta che il messaggio include un payload. Altrimenti un pacchetto RTSP termina con una riga vuota immediatamente dopo l'ultima intestazione del messaggio.