3. RTCP CNAME の選択に関する以前のガイドラインの不備

[RFC3550] における推奨事項は、マルチユーザーシステムの場合は "user@host" の形式、ユーザー名が利用できない場合は "host" の形式で RTCP CNAME を生成することです。"host" 部分は、リアルタイムデータの送信元となるホストの完全修飾ドメイン名 (FQDN) であると指定されています。この手引きは [RFC3550] が作成された当時は適切でしたが、FQDN はもはや必ずしも一意ではなく、大規模なサービスプロバイダーネットワーク内の複数のエンドポイントで共通になることもあります。本文書は、代わりのメカニズムによって RTCP CNAME としての FQDN の使用を置き換えます。

IPv4 アドレスも [RFC3550] において RTCP CNAME での使用が提案されており、そこでは RTCP CNAME の "host" 部分は RTP データが送信されるインターフェースの IPv4 アドレスの数値表現となっています。[RFC3550] で指摘されているように、プライベートネットワークアドレス空間 [RFC1918] を使用すると、グローバルに一意ではないネットワークアドレスをホストが持つ可能性があります。さらに、パブリック IPv4 アドレスであっても、複数のホストに同じパブリック IPv4 アドレスが割り当てられ、ネットワークアドレス変換 (NAT) デバイス [RFC3022] に接続されている場合、この同じ IPv4 アドレスの共有利用が発生する可能性があります。プライベートかパブリックかを問わず、複数のホストが同じ IPv4 アドレスを共有している場合、IPv4 アドレスを RTCP CNAME として使用すると、必ずしも一意ではない RTCP CNAME が生成されてしまいます。

また、[RFC3550] では、プライベートアドレスを持ち、パブリックインターネットへの直接的な IP 接続を持たないホストが、RTP レベルのトランスレーターを介して RTP パケットをパブリックインターネットに転送する場合、一意ではない RTCP CNAME を持つことになる可能性があることも指摘されています。[RFC3550] の提案では、そのようなアプリケーションは、ユーザーが一意の RTCP CNAME を選択できるような設定オプションを提供すべきであるとされています。この手法は、プライベートアドレスの露出を防ぐために必要に応じてプライベートアドレスからパブリックアドレスへと RTCP CNAME を変換する負担をトランスレーターに課すことになります。経験上、これは実際にはうまく機能しません。