6.3. Richieste di ritrasmissione
Il formato del messaggio di feedback NACK definito nel profilo AVPF SHOULD essere usato dai riceventi per inviare richieste di ritrasmissione. Se un ricevente scelga o meno di richiedere un pacchetto è una questione di implementazione. Un'implementazione reale del ricevente dovrebbe tenere conto di fattori quali il ritardo tollerabile dall'applicazione, l'ambiente di rete e il tipo di media.
Il ricevente dovrebbe in genere valutare se il pacchetto ritrasmesso sarebbe ancora utile al momento della ricezione. Il timestamp del pacchetto mancante può essere stimato dai timestamp dei pacchetti che precedono e/o seguono il salto di numero di sequenza causato dal pacchetto mancante nel flusso originale. Nella maggior parte dei casi, una qualche forma di stima lineare del timestamp è sufficiente.
Inoltre, un ricevente dovrebbe calcolare una stima del round-trip time (RTT) verso il mittente. Ciò può essere fatto, ad esempio, misurando il ritardo di ritrasmissione per ricevere un pacchetto di ritrasmissione dopo che è stato inviato un NACK per quel pacchetto. Questa stima può essere ottenuta anche da osservazioni passate, dal round-trip time dei report RTCP se disponibile, o con altri mezzi. Un meccanismo standard per il ricevente per stimare l'RTT è specificato in "RTP Control Protocol Extended Reports (RTCP XR)" [11].
Il ricevente non dovrebbe inviare una richiesta di ritrasmissione non appena rileva un numero di sequenza mancante, ma dovrebbe aggiungere un ritardo extra per compensare il riordino dei pacchetti. Questo ritardo extra può, ad esempio, basarsi su osservazioni passate del riordino di pacchetti riscontrato. Va notato che in ambienti in cui il riordino dei pacchetti è raro o non avviene, ad esempio se il livello datalink sottostante garantisce consegna ordinata, il ritardo può essere estremamente basso o addirittura zero. In tali casi, un algoritmo appropriato di "ritardo per riordino" potrebbe non essere effettivamente basato su timer, ma su pacchetti. Ad esempio, se dopo aver rilevato un salto vengono ricevuti n pacchetti, si può assumere che il pacchetto sia stato veramente perso piuttosto che fuori ordine. Ciò può risultare molto più semplice da codificare su alcune piattaforme come un buffer FIFO di pacchetti a lunghezza fissa molto breve rispetto al meccanismo basato su timer.
Per aumentare la robustezza alla perdita di un NACK o di un pacchetto di ritrasmissione, un ricevente può inviare un nuovo NACK per lo stesso pacchetto. Ciò è indicato come ritrasmissioni multiple. Prima di inviare un nuovo NACK per un pacchetto mancante, il ricevente dovrebbe basarsi su un timer per essere ragionevolmente sicuro che il tentativo di ritrasmissione precedente sia fallito e così evitare ritrasmissioni non necessarie. Il valore del timer deve basarsi sull'RTT osservato. MAY essere usato un valore statico o adattivo. Ad esempio, un timer adattivo potrebbe essere uno che cambia il suo valore ad ogni nuova richiesta per lo stesso pacchetto. Questo documento non fornisce linee guida su come calcolare questo valore adattivo perché non sono stati condotti esperimenti per determinarlo.
I NACK MUST essere inviati solo per il flusso RTP originale. Altrimenti, se un ricevente volesse eseguire ritrasmissioni multiple inviando un NACK nel flusso di ritrasmissione, non potrebbe conoscere il numero di sequenza originale e una stima del timestamp del pacchetto richiesto.
L'appendice A fornisce alcune linee guida su come controllare il numero di ritrasmissioni.