9. Considerazioni su RTSP
Il Real Time Streaming Protocol (RTSP), RFC 2326 [7], è un protocollo a livello applicazione per il controllo della consegna di dati con proprietà in tempo reale. Questa sezione esamina le questioni coinvolte nel controllo di sessioni RTP che usano ritrasmissioni.
9.1. Controllo RTSP con SSRC-multiplexing
Nel caso di SSRC-multiplexing, la riga "m" include sia i tipi di payload originali sia quelli di ritrasmissione e ha un singolo attributo RTSP "control". Il ricevente usa la riga "m" per richiedere SETUP e TEARDOWN dell'intera sessione media. Il profilo RTP contenuto nell'intestazione Transport MUST essere il profilo AVPF o un altro profilo adatto che consenta feedback esteso. Se il valore SSRC è incluso nell'intestazione Transport della risposta SETUP, MUST essere quello del flusso originale.
Per controllare l'invio del flusso media originale della sessione, il ricevente invia come al solito richieste PLAY e PAUSE al mittente per la sessione. L'intestazione RTP-info usata per impostare i parametri specifici RTP nella risposta PLAY MUST essere impostata secondo le informazioni RTP del flusso originale.
Quando il ricevente inizia a ricevere il flusso originale, può quindi richiedere la ritrasmissione tramite NACK RTCP senza segnalazione RTSP aggiuntiva.
9.2. Controllo RTSP con session-multiplexing
Nel caso di session-multiplexing, ogni riga "m" SDP ha un attributo RTSP "control". Pertanto, quando si usa la ritrasmissione, sia la sessione originale sia quella di ritrasmissione hanno i propri attributi "control". Il ricevente può associare la sessione originale e la sessione di ritrasmissione tramite la semantica FID come specificato nella sezione 8.
I flussi originali e di ritrasmissione sono istituiti e chiusi separatamente tramite il rispettivo attributo media "control". Il profilo RTP contenuto nell'intestazione Transport MUST essere il profilo AVPF o un altro profilo adatto che consenta feedback esteso sia per la sessione originale sia per quella di ritrasmissione.
La presentazione RTSP SHOULD supportare il controllo aggregato e SHOULD contenere un URL RTSP a livello di sessione. Il ricevente SHOULD usare il controllo aggregato per una sessione originale e la sessione di ritrasmissione associata. Altrimenti, sarebbero necessari due valori distinti di 'session-id', cioè valori diversi per le sessioni originale e di ritrasmissione, e il mittente non saprebbe come associarli.
L'attributo "control" a livello di sessione è poi usato come al solito per controllare la riproduzione del flusso originale. Quando il ricevente inizia a ricevere il flusso originale, può quindi richiedere le ritrasmissioni tramite RTCP senza segnalazione RTSP aggiuntiva.
9.3. Controllo RTSP del flusso di ritrasmissione
A causa della natura delle ritrasmissioni, l'invio dei pacchetti di ritrasmissione SHOULD NOT essere controllato tramite richieste RTSP PLAY e PAUSE. Le richieste PLAY e PAUSE SHOULD NOT influenzare il flusso di ritrasmissione. I pacchetti di ritrasmissione sono inviati su richiesta del ricevente nel flusso RTCP originale, indipendentemente dallo stato.
9.4. Controllo della cache
I flussi di ritrasmissione SHOULD NOT essere messi in cache.
Nel caso di session-multiplexing, l'intestazione "Cache-Control" SHOULD essere impostata a "no-cache" per il flusso di ritrasmissione.
Nel caso di SSRC-multiplexing, RTSP non può specificare caching indipendente per il flusso di ritrasmissione, perché c'è una sola riga "m" in SDP. Pertanto, chi implementa deve tenere conto di questo fatto quando decide se mettere o meno in cache una sessione con SSRC-multiplexing.