4. Scelta di un CNAME RTCP

È difficile, e in alcuni casi impossibile, per un host determinare se esiste un NAT tra se stesso e il suo peer RTP. Inoltre, anche alcuni indirizzi IPv4 pubblici possono essere condivisi da più host in Internet. L'uso della rappresentazione numerica dell'indirizzo IPv4 come parte "host" del CNAME RTCP NON È RACCOMANDATO.

4.1. CNAME RTCP Persistenti rispetto a CNAME RTCP per Sessione

Il CNAME RTCP può essere persistente attraverso diverse sessioni RTP per un endpoint RTP o univoco per sessione, il che significa che un endpoint RTP sceglie un CNAME RTCP diverso per ogni sessione RTP.

Un endpoint RTP che emette più flussi RTP correlati che richiedono la sincronizzazione presso l'altro endpoint (o gli altri endpoint) DEVE utilizzare lo stesso CNAME RTCP per tutti i flussi che devono essere sincronizzati. Ciò richiede un CNAME RTCP persistente a breve termine che sia comune a diversi flussi RTP e, potenzialmente, a diverse sessioni RTP correlate. Un esempio comune di tale utilizzo si verifica quando si sincronizzano flussi audio e video in una sessione multimediale, dove un singolo partecipante deve utilizzare lo stesso CNAME RTCP per la sua sessione RTP audio e per la sua sessione RTP video. Un altro esempio potrebbe essere la sincronizzazione dei livelli di un codec audio stratificato, dove lo stesso CNAME RTCP deve essere utilizzato per ogni livello.

Se i molteplici flussi RTP in una sessione RTP non sono correlati, e quindi non richiedono la sincronizzazione, un endpoint RTP può utilizzare CNAME RTCP diversi per questi flussi.

Un CNAME RTCP persistente a lungo termine è talvolta utile per facilitare il monitoraggio da parte di terzi, in linea con la [RFC3550]. Uno di questi utilizzi potrebbe essere quello di consentire agli strumenti di gestione della rete di correlare la qualità del servizio in corso per un partecipante attraverso molteplici sessioni RTP per la diagnosi dei guasti e per comprendere le statistiche sulle prestazioni della rete a lungo termine. Uno sviluppatore di applicazioni che desideri scoraggiare questo tipo di monitoraggio da parte di terzi può scegliere di generare un CNAME RTCP univoco per ogni sessione RTP, o gruppo di sessioni RTP correlate, a cui l'applicazione parteciperà. Tale CNAME RTCP per sessione non può essere utilizzato per l'analisi del traffico, e quindi fornisce una forma limitata di privacy. Si noti che esistono mezzi non-RTP che possono essere utilizzati da terzi per correlare le sessioni RTP, quindi l'uso di CNAME RTCP per sessione non impedirà a un analista del traffico determinato di monitorare tali sessioni.

Questo promemoria definisce diversi modi diversi in cui un'implementazione può scegliere un CNAME RTCP. È possibile, e legittimo, che implementazioni indipendenti facciano scelte diverse di CNAME RTCP quando eseguite sullo stesso host. Ciò può ostacolare il monitoraggio da parte di terzi, a meno che non venga fornito qualche mezzo esterno per configurare una scelta persistente di CNAME RTCP per tali implementazioni.

Si noti che non vi è alcun problema di compatibilità all'indietro (con le implementazioni compatibili con la [RFC3550]) introdotto in questo promemoria, poiché i CNAME RTCP sono stringhe opache per i peer remoti.

4.2. Requisiti

Gli endpoint RTP sceglieranno di generare CNAME RTCP persistenti o per sessione. Un endpoint RTP che desideri generare un CNAME RTCP persistente DEVE utilizzare uno dei seguenti due metodi:

• Per produrre un CNAME RTCP persistente a lungo termine, un endpoint RTP DEVE generare e memorizzare un Universally Unique IDentifier (UUID) [RFC4122] da utilizzare come parte "host" del suo CNAME RTCP. L'UUID DEVE essere di versione 1, 2 o 4, come descritto nella [RFC4122], con il prefisso "urn:uuid:" rimosso, risultando in una rappresentazione in stringa stampabile di 36 ottetti.

• Per produrre un CNAME RTCP persistente a breve termine, un endpoint RTP DEVE generare e utilizzare un identificatore seguendo la procedura descritta nella Sezione 5. Tale procedura viene eseguita almeno una volta per inizializzazione del software. Dopo aver ottenuto un identificatore, come minimo i 96 bit meno significativi DOVREBBERO essere convertiti in ASCII utilizzando la codifica Base64 [RFC4648] (per trovare un compromesso tra dimensione del pacchetto e univocità - fare riferimento alla Sezione 6.1). Se vengono utilizzati 96 bit, la stringa risultante sarà di 16 ottetti. Si noti che il valore codificato in Base64 non può superare la lunghezza massima del CNAME RTCP di 255 ottetti [RFC3550].

Nei due casi sopra citati, la parte "utente@" del CNAME RTCP PUÒ essere omessa sui sistemi monoutente e PUÒ essere sostituita da un token opaco sui sistemi multiutente, per preservare la privacy.

Un endpoint RTP che desideri generare un CNAME RTCP per sessione DEVE utilizzare il seguente metodo:

• Per ogni nuova sessione RTP, viene generato un nuovo CNAME RTCP seguendo la procedura descritta nella Sezione 5. Dopo aver eseguito tale procedura, come minimo i 96 bit meno significativi DOVREBBERO essere convertiti in ASCII utilizzando la codifica Base64 [RFC4648]. Il CNAME RTCP non può cambiare durante la vita di una sessione RTP [RFC3550]. La parte "utente@" del CNAME RTCP viene omessa quando si generano CNAME RTCP per sessione.

Si ritiene che ottenere l'univocità (con un'alta probabilità) sia una proprietà importante che richiede un'attenta valutazione del metodo. Questo documento fornisce una serie di metodi, almeno uno dei quali sarebbe adatto a qualsiasi scenario di implementazione dato. Questo documento non prevede quindi che l'implementatore definisca e selezioni un metodo alternativo.

Una specifica futura potrebbe definire un metodo alternativo per generare i CNAME RTCP, a condizione che il metodo proposto abbia un'univocità appropriata e vi sia coerenza tra i metodi utilizzati per più sessioni RTP che devono essere correlate. Tuttavia, tale specifica deve essere revisionata e approvata prima dell'implementazione.

I meccanismi descritti in questo documento devono essere utilizzati per generare CNAME RTCP e non devono essere utilizzati per generare identificatori univoci di uso generale.

5. Procedura per Generare un Identificatore Univoco

Per produrre localmente un identificatore univoco, si genera semplicemente un valore pseudocasuale crittograficamente sicuro come descritto nella [RFC4086]. Questo valore DEVE essere di almeno 96 bit.

Il più grande ostacolo all'implementazione di questo algoritmo è la disponibilità di un appropriato generatore di numeri pseudocasuali crittograficamente sicuro (CSPRNG). In qualsiasi contesto che disponga già di un PRNG sicuro, questo algoritmo descritto è molto più semplice dell'algoritmo descritto nella Sezione 5 della [RFC6222]. Gli stack SIP [RFC3261] sono tenuti a utilizzare numeri crittograficamente casuali per generare i tag To e From (Sezione 19.3). Le implementazioni di Real-Time Communications on the Web (RTCWEB) [ARCH] avranno bisogno di avere CSPRNG per implementare ICE [RFC5245] e DTLS-SRTP [RFC5764]. E, naturalmente, essenzialmente ogni browser web supporta già TLS, che richiede un PRNG sicuro.