RFC 3550 - Appendix B. Changes from RFC 1889

Appendice B - Modifiche rispetto a RFC 1889 (Changes from RFC 1889)

La maggior parte di questo RFC è identica a RFC 1889. Non ci sono modifiche nei formati dei pacchetti "sul filo" (on the wire), solo modifiche alle regole e agli algoritmi che governano l'uso del protocollo. La modifica più importante è un miglioramento all'algoritmo di timer scalabile per calcolare quando inviare i pacchetti RTCP:

o L'algoritmo per calcolare l'intervallo di trasmissione RTCP specificato nelle Sezioni 6.2 e 6.3 e illustrato nell'Appendice A.7 è ampliato per includere la "riconsiderazione" (reconsideration) per minimizzare la trasmissione in eccesso rispetto alla velocità prevista quando molti partecipanti si uniscono a una sessione simultaneamente, e la "riconsiderazione inversa" (reverse reconsideration) per ridurre l'incidenza e la durata dei falsi timeout dei partecipanti quando il numero di partecipanti cala rapidamente. La riconsiderazione inversa è usata anche per accorciare possibilmente il ritardo prima dell'invio di un RTCP SR durante la transizione dalla modalità di ricevitore passivo a quella di mittente attivo.

o La Sezione 6.3.7 specifica nuove regole che controllano quando inviare un pacchetto RTCP BYE per evitare un'inondazione di pacchetti quando molti partecipanti lasciano una sessione simultaneamente.

o Il requisito di mantenere lo stato per i partecipanti inattivi per un periodo sufficientemente lungo da coprire tipiche partizioni di rete è stato rimosso dalla Sezione 6.2.1. In una sessione in cui molti partecipanti si uniscono per un breve tempo e omettono di inviare BYE, tale requisito causerebbe una significativa sovrastima del numero di partecipanti. L'algoritmo di riconconsiderazione aggiunto in questa revisione compensa il grande numero di nuovi partecipanti che si uniscono simultaneamente quando una partizione si risana.

Si deve notare che questi miglioramenti hanno un effetto significativo solo quando il numero di partecipanti alla sessione è grande (migliaia) e la maggior parte dei partecipanti si unisce o lascia nello stesso momento. Ciò rende difficile il test in una rete reale. Tuttavia, l'algoritmo è stato sottoposto a un'analisi e a una simulazione approfondite per verificarne le prestazioni. Inoltre, l'algoritmo migliorato è stato progettato per interoperare con l'algoritmo in RFC 1889 in modo che il grado di riduzione della banda di trasmissione in eccesso durante un ingresso a gradino sia proporzionale alla frazione di partecipanti che implementano l'algoritmo migliorato. L'interoperabilità dei due algoritmi è stata verificata sperimentalmente su reti reali.

Altre modifiche funzionali sono state:

o La Sezione 6.2.1 specifica che le implementazioni possono memorizzare solo un campionamento degli identificatori SSRC dei partecipanti per consentire la scalabilità a sessioni molto grandi. Gli algoritmi sono specificati in RFC 2762 [21].

o Nella Sezione 6.2 è specificato che le bande dei mittenti e dei non-mittenti RTCP possono essere impostate come parametri separati della sessione anziché come stretta percentuale della banda di sessione, e possono essere impostate a zero. Il requisito che RTCP fosse obbligatorio per le sessioni RTP usanti il multicast IP è stato allentato. Tuttavia, è stata aggiunta anche una precisazione che disattivare RTCP NON È RACCOMANDATO.

o Nelle Sezioni 6.2, 6.3.1 e Appendice A.7, è specificato che la frazione di partecipanti al di sotto della quale i mittenti ottengono banda RTCP dedicata cambia dal fisso 1/4 a un rapporto basato sui parametri di banda RTCP dei mittenti e dei non-mittenti quando questi sono forniti. La condizione che nessuna banda sia dedicata ai mittenti quando non ci sono mittenti è stata rimossa poiché ciò è atteso essere uno stato transitorio. Ciò impedisce anche ai non-mittenti di usare la banda RTCP dei mittenti quando non è inteso.

o Anche nella Sezione 6.2 è specificato che l'intervallo RTCP minimo può essere ridotto a valori minori per sessioni ad alta banda, e che il ritardo RTCP iniziale può essere impostato a zero per sessioni unicast.

o Il timeout di un partecipante deve basarsi sull'inattività per un numero di intervalli di rapporto RTCP calcolati usando la frazione di banda RTCP dei ricevitori anche per i mittenti attivi.

o Le Sezioni 7.2 e 7.3 specificano che traduttori e mixer dovrebbero inviare pacchetti BYE per le sorgenti che non stanno più inoltrando.

o Le modifiche alle regole per le codifiche a livelli sono definite nelle Sezioni 2.4, 6.3.9, 8.3 e 11. Nell'ultima di queste, si nota che la regola di assegnazione di indirizzi e porte è in conflitto con la specifica SDP, RFC 2327 [15], ma è inteso che questa restrizione sarà allentata in una revisione di RFC 2327.

o La convenzione per l'uso di coppie di porte pari/dispari per RTP e RTCP nella Sezione 11 è stata chiarita per riferirsi alle porte di destinazione. Il requisito di usare una coppia di porte pari/dispari è stato rimosso se le due porte sono specificate esplicitamente. Per le sessioni RTP unicast, possono essere usate coppie di porte distinte per le due estremità (Sezioni 3, 7.1 e 11).

o È stata aggiunta una nuova Sezione 10 per spiegare il requisito del controllo della congestione nelle applicazioni che usano RTP.

o Nella Sezione 8.2, il requisito che un nuovo identificatore SSRC DEBBA essere scelto ogni volta che l'indirizzo di trasporto sorgente cambia è stato allentato per dire che un nuovo identificatore SSRC PUÒ essere scelto. Di conseguenza, è stato chiarito che un'implementazione PUÒ scegliere di mantenere i pacchetti dal nuovo indirizzo sorgente anziché dal già esistente indirizzo sorgente quando si verifica una collisione SSRC tra due altri partecipanti, e DOVREBBE farlo per applicazioni come la telefonia in cui alcune sorgenti come le entità mobili possono cambiare indirizzi nel corso di una sessione RTP.

o Un bug di indentazione nella stampa RFC 1889 dello pseudo-codice per l'algoritmo di rilevamento e risoluzione delle collisioni nella Sezione 8.2 è stato corretto traducendo la sintassi in un linguaggio pseudo-C, e l'algoritmo è stato modificato per rimuovere la restrizione che sia RTP che RTCP debbano essere inviati dallo stesso numero di porta sorgente.

o La descrizione del meccanismo di padding per i pacchetti RTCP è stata chiarita e si specifica che il padding DEVE essere applicato solo all'ultimo pacchetto di un pacchetto RTCP composto.

o Nell'Appendice A.1, l'inizializzazione di base_seq è stata corretta per essere seq anziché seq - 1, e il testo è stato corretto per dire che il numero di sequenza errato più 1 è memorizzato. L'inizializzazione di max_seq e di altre variabili per l'algoritmo è stata separata dal testo per chiarire che questa inizializzazione deve essere fatta in aggiunta alla chiamata della funzione init_seq() (e alcune parole perse in RFC 1889 durante l'elaborazione del documento dalla forma sorgente a quella di output sono state ripristinate).

o Il limitamento del numero di pacchetti persi nell'Appendice A.3 è stato corretto per usare entrambi i limiti positivo e negativo.

o La specifica del timestamp NTP "relativo" nella sezione RTCP SR ora definisce questi timestamp come basati sull'orologio più comune specifico del sistema, come il tempo di attività del sistema (system uptime), anziché sul tempo trascorso della sessione che non sarebbe uguale per applicazioni multiple avviate sulla stessa macchina in momenti diversi.

Modifiche non funzionali:

o È specificato che un ricevitore DEVE ignorare i pacchetti con tipi di payload che non comprende.

o Nella Fig. 2, il valore del timestamp NTP a virgola mobile è stato corretto, alcuni zeri iniziali mancanti sono stati aggiunti in un numero esadecimale, ed è stato specificato il fuso orario UTC.

o È spiegata l'irrilevanza del rollover dei timestamp NTP nell'anno 2036.

o La politica per la registrazione dei tipi di pacchetto RTCP e dei tipi SDES è stata chiarita in una nuova Sezione 15, Considerazioni IANA. Il suggerimento che gli sperimentatori registrassero i numeri di cui avevano bisogno e poi li cancellassero se risultavano non necessari è stato rimosso a favore dell'uso di APP e PRIV. È stata specificata anche la registrazione dei nomi di profilo.

o Il riferimento per il set di caratteri UTF-8 è stato cambiato da una X/Open Preliminary Specification a RFC 2279.

o Il riferimento per RFC 1597 è stato aggiornato a RFC 1918 e il riferimento per RFC 2543 è stato aggiornato a RFC 3261.

o L'ultimo paragrafo dell'introduzione in RFC 1889, che avvertiva gli implementatori di limitare l'implementazione su Internet, è stato rimosso poiché ritenuto non più rilevante.

o Una nota non normativa riguardante l'uso di RTP con il Source-Specific Multicast (SSM) è stata aggiunta nella Sezione 6.

o La definizione di "sessione RTP" nella Sezione 3 è stata ampliata per riconoscere che una singola sessione può usare multipli indirizzi di trasporto di destinazione (come era sempre il caso per un traduttore o mixer) e per spiegare che la caratteristica distintiva di una sessione RTP è che ciascuna corrisponde a uno spazio di identificatori SSRC separato. È stata aggiunta una nuova definizione di "sessione multimediale" per ridurre la confusione sulla parola "sessione".

o Il significato di "istante di campionamento" (sampling instant) è stato spiegato in maggior dettaglio come parte della definizione del campo timestamp dell'header RTP nella Sezione 5.1.

o Piccoli chiarimenti del testo sono stati fatti in diversi punti, alcuni in risposta a domande dei lettori. In particolare:

  -  In RFC 1889, le prime cinque parole della seconda frase della
     Sezione 2.2 sono state perse durante l'elaborazione del documento
     dalla forma sorgente a quella di output, ma ora sono ripristinate.

  -  Una definizione per "RTP media type" è stata aggiunta nella Sezione
     3 per rendere più chiara la spiegazione del multiplexing delle
     sessioni RTP nella Sezione 5.2 riguardo al multiplexing di multipli
     medium.  Quella sezione spiega ora anche che il multiplexing di
     multiple sorgenti dello stesso medium basato sugli identificatori
     SSRC può essere appropriato ed è la norma per le sessioni multicast.

  -  La definizione di "non-RTP means" è stata ampliata per includere
     esempi di altri protocolli che costituiscono non-RTP means.

  -  La descrizione del parametro di banda di sessione è ampliata nella
     Sezione 6.2, inclusa la precisazione che la banda del traffico di
     controllo è in aggiunta alla banda di sessione per il traffico dati.

  -  L'effetto della durata variabile dei pacchetti sul calcolo del
     jitter è stato spiegato nella Sezione 6.4.4.

  -  Il metodo per terminare e paddare una sequenza di elementi SDES è
     stato chiarito nella Sezione 6.5.

  -  Esempi di indirizzi IPv6 sono stati aggiunti nella descrizione di
     SDES CNAME nella Sezione 6.5.1, e "example.com" è stato usato al
     posto di altri nomi di dominio di esempio.

  -  La sezione Sicurezza ha aggiunto un riferimento formale a IPSEC ora
     che è disponibile, e dice che il metodo di riservatezza definito in
     questa specifica è principalmente per codificare la pratica esistente.
     È RACCOMANDATO che algoritmi di cifratura più forti come Triple-DES
     siano usati al posto dell'algoritmo predefinito, e si nota che il
     profilo SRTP basato su AES sarà la scelta corretta in futuro.  È
     stata aggiunta una cautela sulla debolezza dell'header RTP come
     vettore di inizializzazione.  È stato anche notato che la cifratura
     solo del payload è necessaria per consentire la compressione degli
     header.

  -  Il metodo per la cifratura parziale di RTCP è stato chiarito; in
     particolare, SDES CNAME è trasportato in una sola parte quando il
     pacchetto RTCP composto è suddiviso.

  -  È chiarito che solo un pacchetto RTCP composto dovrebbe essere
     inviato per intervallo di rapporto e che se ci sono troppe sorgenti
     attive perché i rapporti entrino nell'MTU, allora un sottoinsieme
     delle sorgenti dovrebbe essere selezionato a turno (round-robin) su
     multipli intervalli.

  -  Una nota è stata aggiunta nell'Appendice A.1 che i pacchetti possono
     essere salvati durante la validazione dell'header RTP e consegnati in
     caso di successo.

  -  La Sezione 7.3 spiega ora che un mixer che aggrega pacchetti SDES
     usa più banda RTCP a causa di pacchetti più lunghi, e un mixer che
     fa passare RTCP naturalmente invia pacchetti a una velocità superiore
     a quella della singola sorgente, ma entrambi i comportamenti sono
     validi.

  -  La Sezione 13 chiarisce che un'applicazione RTP può usare multipli
     profili ma tipicamente solo uno in una data sessione.

  -  I termini MUST, SHOULD, MAY, ecc. sono usati come definiti in RFC
     2119.

  -  La bibliografia è stata divisa in riferimenti normativi e
     informativi.