1. はじめに

[RFC3550] のセクション 6.5.1 には、RTP エンドポイントに対して一意の RTCP CNAME を選択するためのいくつかの推奨事項があります。しかし、実際には、これらの方法の一部は一意の RTCP CNAME を生成することを保証するものではありません。[RFC6222] は RTCP CNAME を選択するためのガイドラインを更新し、[RFC3550] のセクション 6.5.1 で提示されたものを置き換えました。残念ながら、新しいアルゴリズムの一部はかなり複雑であり、セッションごとに新しい RTCP CNAME が生成されたとしても、場合によっては複数の RTCP セッションにわたってリンクされる可能性のある RTCP CNAME を生成します。本文書は、この制限がなく、実装もより簡単な [RFC6222] のセクション 5 のアルゴリズムの代替を指定します。

[RFC6222] によって生成された RTCP CNAME のリンク可能性に関する議論については、[RESCORLA] を参照してください。

2. 要件の表記

本文書におけるキーワード「MUST（しなければならない）」、「MUST NOT（してはならない）」、「REQUIRED（必須）」、「SHALL（するものとする）」、「SHALL NOT（しないものとする）」、「SHOULD（すべきである）」、「SHOULD NOT（すべきではない）」、「RECOMMENDED（推奨される）」、「NOT RECOMMENDED（推奨されない）」、「MAY（してもよい）」、および「OPTIONAL（任意）」は、[RFC2119] に記述されているように解釈されるべきものです。

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 を変換する負担をトランスレーターに課すことになります。経験上、これは実際にはうまく機能しません。