1. Introduction
Dans la section 6.5.1 de la [RFC3550], il existe un certain nombre de recommandations pour choisir un CNAME RTCP unique pour un point d'extrémité RTP. Cependant, en pratique, certaines de ces méthodes ne garantissent pas la production d'un CNAME RTCP unique. La [RFC6222] a mis à jour les lignes directrices pour le choix des CNAME RTCP, remplaçant celles présentées dans la section 6.5.1 de la [RFC3550]. Malheureusement, certaines parties des nouveaux algorithmes sont assez compliquées et produisent également des CNAME RTCP qui, dans certains cas, sont potentiellement liables sur plusieurs sessions RTCP même si un nouveau CNAME RTCP est généré pour chaque session. Ce document spécifie un remplacement pour l'algorithme de la section 5 de la [RFC6222], qui ne présente pas cette limitation et est également plus simple à mettre en œuvre.
Pour une discussion sur la liabilité des CNAME RTCP produits par la [RFC6222], se référer à [RESCORLA].
2. Notation des exigences
Les termes "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", et "OPTIONAL" dans ce document doivent être interprétés comme décrit dans la [RFC2119].
3. Déficiences des lignes directrices précédentes pour le choix d'un CNAME RTCP
La recommandation dans la [RFC3550] est de générer un CNAME RTCP de la forme "user@host" pour les systèmes multi-utilisateurs, ou "host" si le nom d'utilisateur n'est pas disponible. La partie "host" est spécifiée comme étant le nom de domaine pleinement qualifié (FQDN) de l'hôte d'où proviennent les données en temps réel. Bien que ce conseil fût approprié au moment où la [RFC3550] a été écrite, les FQDN ne sont plus nécessairement uniques et peuvent parfois être communs à plusieurs points d'extrémité dans les grands réseaux de fournisseurs de services. Ce document remplace l'utilisation du FQDN comme CNAME RTCP par des mécanismes alternatifs.
Les adresses IPv4 sont également suggérées pour une utilisation dans les CNAME RTCP dans la [RFC3550], où la partie "host" du CNAME RTCP est la représentation numérique de l'adresse IPv4 de l'interface d'où proviennent les données RTP. Comme noté dans la [RFC3550], l'utilisation de l'espace d'adressage réseau privé [RFC1918] peut avoir pour résultat que des hôtes aient des adresses réseau qui ne sont pas globalement uniques. De plus, ce partage d'une même adresse IPv4 peut se produire avec des adresses IPv4 publiques si plusieurs hôtes se voient assigner la même adresse IPv4 publique et sont connectés à un dispositif de traduction d'adresse réseau (NAT) [RFC3022]. Lorsque plusieurs hôtes partagent la même adresse IPv4, qu'elle soit privée ou publique, l'utilisation de l'adresse IPv4 comme CNAME RTCP conduit à des CNAME RTCP qui ne sont pas nécessairement uniques.
Il est également noté dans la [RFC3550] que si des hôtes avec des adresses privées et sans connectivité IP directe à l'Internet public ont leurs paquets RTP acheminés vers l'Internet public via un traducteur de niveau RTP, ils pourraient se retrouver avec des CNAME RTCP non uniques. La suggestion dans la [RFC3550] est que de telles applications fournissent une option de configuration pour permettre à l'utilisateur de choisir un CNAME RTCP unique ; cette technique fait peser sur le traducteur la responsabilité de traduire les CNAME RTCP des adresses privées vers les adresses publiques si nécessaire pour éviter que les adresses privées ne soient exposées. L'expérience a montré que cela ne fonctionne pas bien en pratique.