3. Requisiti e motivazioni di progetto per uno schema di ritrasmissione

L'uso delle ritrasmissioni in RTP come metodo di riparazione per lo streaming multimediale è appropriato in quegli scenari con vincoli di ritardo rilassati in cui non è richiesta piena affidabilità. Più in dettaglio, la ritrasmissione RTP consente di scambiare affidabilità rispetto al ritardo; cioè, gli endpoint possono rinunciare a ritrasmettere un pacchetto perso dopo che è trascorso un dato tempo di buffering. A differenza di TCP, non si ha quindi blocco head-of-line causato dalle ritrasmissioni RTP. Chi implementa deve essere consapevole che nei casi in cui è richiesta piena affidabilità o si possono tollerare ritardo e jitter maggiori, vanno considerati TCP o altre opzioni di trasporto.

Lo schema di ritrasmissione RTP definito in questo documento è progettato per soddisfare il seguente insieme di requisiti:

1. Non deve violare i meccanismi generali di RTP e RTCP.

2. Deve essere adatto all'unicast e a piccoli gruppi multicast.

3. Deve funzionare con mixer e translator.

4. Deve funzionare con tutti i tipi di payload noti.

5. Non deve impedire l'uso di più tipi di payload in una sessione.

6. Per supportare la più ampia varietà di formati di payload, il ricevente RTP deve poter dedurre quanti e quali pacchetti RTP sono stati persi a causa di un salto nei numeri di sequenza RTP ricevuti. Questo requisito è indicato come preservazione del numero di sequenza. Senza tale requisito, sarebbe impossibile usare la ritrasmissione con formati di payload, come il testo conversazionale [9] o la maggior parte delle applicazioni audio/video in streaming, che usano il numero di sequenza RTP per rilevare i pacchetti persi.

Progettando una soluzione per la ritrasmissione RTP, si possono considerare diversi approcci per il multiplexing dei pacchetti RTP originali e di quelli ritrasmessi.

Un approccio può essere ritrasmettere il pacchetto RTP con il suo numero di sequenza originale e inviare pacchetti originali e di ritrasmissione nello stesso flusso RTP. Il pacchetto di ritrasmissione sarebbe allora identico al pacchetto RTP originale, cioè stessa intestazione (e quindi stesso numero di sequenza) e stesso payload. Tale approccio però non è accettabile perché corromperebbe le statistiche RTCP. Di conseguenza, il requisito 1 non sarebbe soddisfatto. Statistiche RTCP corrette richiedono che, per ogni pacchetto RTP nel flusso RTP, il numero di sequenza sia incrementato di uno.

Un altro approccio può essere multiplexare pacchetti RTP originali e di ritrasmissione nello stesso flusso RTP usando valori diversi del tipo di payload. Con tale approccio, i pacchetti originali e quelli di ritrasmissione condividerebbero lo stesso spazio dei numeri di sequenza. Di conseguenza, il ricevente RTP non potrebbe dedurre quanti e quali pacchetti originali (quali numeri di sequenza) sono stati persi.

In altre parole, questo approccio non soddisfa il requisito di preservazione del numero di sequenza (requisito 6). Ciò implica a sua volta che il requisito 4 non sarebbe soddisfatto. L'interoperabilità con mixer e translator sarebbe anche più difficile se non comprendessero questo nuovo tipo di payload di ritrasmissione in un flusso RTP del mittente. Per questi motivi, si esclude una soluzione basata sul multiplexing per tipo di payload di pacchetti originali e di ritrasmissione nello stesso flusso RTP.

Infine, i pacchetti originali e quelli di ritrasmissione possono essere inviati in due flussi separati. Questi due flussi possono essere multiplexati inviandoli in due sessioni distinte, cioè session-multiplexing, oppure nella stessa sessione usando valori SSRC diversi, cioè SSRC-multiplexing. Poiché i pacchetti originali e di ritrasmissione trasportano media dello stesso tipo, le obiezioni nella sezione 5.2 di RTP [3] al multiplexing RTP non si applicano in questo caso.

Mixer e translator possono elaborare il flusso originale e scartare semplicemente il flusso di ritrasmissione se non sono in grado di utilizzarlo.

D'altra parte, inviare i pacchetti originali e di ritrasmissione in due flussi separati non basta da solo a soddisfare i requisiti 1 e 6. A questo scopo, questo documento include il numero di sequenza originale nei pacchetti ritrasmessi.

In questo modo, l'uso di due flussi separati soddisfa tutti i requisiti elencati in questa sezione.