1. Introduzione

Nella Sezione 6.5.1 della [RFC3550], sono presenti diverse raccomandazioni per la scelta di un CNAME RTCP univoco per un endpoint RTP. Tuttavia, in pratica, alcuni di questi metodi non garantiscono la produzione di un CNAME RTCP univoco. La [RFC6222] ha aggiornato le linee guida per la scelta dei CNAME RTCP, sostituendo quelle presentate nella Sezione 6.5.1 della [RFC3550]. Sfortunatamente, alcune parti dei nuovi algoritmi sono piuttosto complicate e producono anche CNAME RTCP che, in alcuni casi, sono potenzialmente collegabili su più sessioni RTCP anche se viene generato un nuovo CNAME RTCP per ogni sessione. Questo documento specifica una sostituzione per l'algoritmo nella Sezione 5 della [RFC6222], che non presenta questa limitazione ed è anche più semplice da implementare.

Per una discussione sulla collegabilità dei CNAME RTCP prodotti dalla [RFC6222], fare riferimento a [RESCORLA].

2. Notazione dei Requisiti

Le parole chiave "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", e "OPTIONAL" in questo documento devono essere interpretate come descritto nella [RFC2119].

3. Carenze delle Linee Guida Precedenti per la Scelta di un CNAME RTCP

La raccomandazione nella [RFC3550] è di generare un CNAME RTCP nella forma "utente@host" per i sistemi multiutente, o "host" se il nome utente non è disponibile. La parte "host" è specificata per essere il nome di dominio completo (FQDN) dell'host da cui provengono i dati in tempo reale. Sebbene questa guida fosse appropriata al momento in cui la [RFC3550] è stata scritta, gli FQDN non sono più necessariamente univoci e a volte possono essere comuni a diversi endpoint in grandi reti di fornitori di servizi. Questo documento sostituisce l'uso dell'FQDN come CNAME RTCP con meccanismi alternativi.

Gli indirizzi IPv4 sono anche suggeriti per l'uso nei CNAME RTCP nella [RFC3550], dove la parte "host" del CNAME RTCP è la rappresentazione numerica dell'indirizzo IPv4 dell'interfaccia da cui provengono i dati RTP. Come notato nella [RFC3550], l'uso dello spazio di indirizzamento di rete privato [RFC1918] può far sì che gli host abbiano indirizzi di rete che non sono univoci a livello globale. Inoltre, questo uso condiviso dello stesso indirizzo IPv4 può verificarsi con indirizzi IPv4 pubblici se a più host viene assegnato lo stesso indirizzo IPv4 pubblico e sono collegati a un dispositivo di traduzione degli indirizzi di rete (NAT) [RFC3022]. Quando più host condividono lo stesso indirizzo IPv4, sia esso privato o pubblico, l'uso dell'indirizzo IPv4 come CNAME RTCP porta a CNAME RTCP che non sono necessariamente univoci.

È anche notato nella [RFC3550] che se gli host con indirizzi privati e nessuna connettività IP diretta alla rete Internet pubblica hanno i loro pacchetti RTP inoltrati alla rete Internet pubblica attraverso un traduttore a livello RTP, potrebbero finire per avere CNAME RTCP non univoci. Il suggerimento nella [RFC3550] è che tali applicazioni forniscano un'opzione di configurazione per consentire all'utente di scegliere un CNAME RTCP univoco; questa tecnica pone l'onere sul traduttore di tradurre i CNAME RTCP da indirizzi privati a indirizzi pubblici, se necessario per evitare che gli indirizzi privati vengano esposti. L'esperienza ha dimostrato che questo non funziona bene nella pratica.