メインコンテンツまでスキップ

4. RTCP CNAME の選択

ホストが、自身と RTP ピアの間に NAT があるかどうかを判断することは困難であり、場合によっては不可能です。さらに、一部のパブリック IPv4 アドレスであっても、インターネット上の複数のホストで共有される可能性があります。RTCP CNAME の "host" 部分として IPv4 アドレスの数値表現を使用することは「推奨されません（NOT RECOMMENDED）」。

4.1. 永続的な RTCP CNAME とセッションごとの RTCP CNAME​

RTCP CNAME は、RTP エンドポイントの異なる RTP セッション間で永続的であることも、セッションごとに一意であることも可能です。後者の場合、RTP エンドポイントは RTP セッションごとに異なる RTCP CNAME を選択します。

他のエンドポイントで同期を必要とする複数の関連する RTP ストリームを送信している RTP エンドポイントは、同期されるすべてのストリームに対して同じ RTCP CNAME を使用「しなければなりません（MUST）」。これには、複数の RTP ストリーム間、および場合によっては複数の関連する RTP セッション間で共通の、短期間の永続的な RTCP CNAME が必要です。このような使用の一般的な例は、マルチメディアセッションでオーディオストリームとビデオストリームを同期させる場合に発生します。この場合、1人の参加者はそのオーディオ RTP セッションとビデオ RTP セッションに対して同じ RTCP CNAME を使用する必要があります。別の例としては、レイヤードオーディオコーデックのレイヤーを同期させる場合が挙げられ、各レイヤーに対して同じ RTCP CNAME を使用する必要があります。

1つの RTP セッション内の複数の RTP ストリームが関連しておらず、したがって同期を必要としない場合、RTP エンドポイントはそれらのストリームに対して異なる RTCP CNAME を使用できます。

[RFC3550] と同様に、第三者による監視を容易にするために、長期間の永続的な RTCP CNAME が役立つことがあります。そのような用途の1つとして、ネットワーク管理ツールが故障診断のために複数の RTP セッションにわたる参加者の継続的なサービス品質を関連付けたり、長期的なネットワークパフォーマンス統計を把握したりできるようにすることが考えられます。この種の第三者による監視を阻止したいアプリケーション開発者は、アプリケーションが参加する各 RTP セッション、または関連する RTP セッションのグループに対して、一意の RTCP CNAME を生成することを選択できます。このようなセッションごとの RTCP CNAME はトラフィック分析に使用できないため、ある程度の限定的なプライバシー保護を提供します。ただし、第三者が RTP セッションを関連付けるために使用できる非 RTP 手段が存在するため、セッションごとの RTCP CNAME を使用しても、意志の固いトラフィック分析者による監視を完全に防ぐことはできないことに注意してください。

本メモでは、実装が RTCP CNAME を選択するためのいくつかの異なる方法を定義しています。同じホスト上で実行される場合に、独立した実装が RTCP CNAME に対して異なる選択をすることは可能であり、正当なことです。これは、それらの実装に対して永続的な RTCP CNAME の選択を構成するための何らかの外部手段が提供されない限り、第三者による監視を妨げる可能性があります。

本メモで導入された内容によって、（[RFC3550] と互換性のある実装との）後方互換性の問題は発生しません。なぜなら、RTCP CNAME はリモートピアに対して不透明（opaque）な文字列だからです。

4.2. 要件​

RTP エンドポイントは、永続的またはセッションごとの RTCP CNAME を生成することを選択します。永続的な RTCP CNAME を生成することを希望する RTP エンドポイントは、以下の2つの方法のいずれかを使用「しなければなりません（MUST）」：

  • 長期間の永続的な RTCP CNAME を生成するために、RTP エンドポイントは、RTCP CNAME の "host" 部分として使用するための Universally Unique IDentifier (UUID) [RFC4122] を生成し、保存「しなければなりません（MUST）」。UUID は [RFC4122] で説明されているバージョン1、2、または4であり、「urn:uuid:」を削除した36オクテットの印刷可能な文字列表現でなければなりません。

  • 短期間の永続的な RTCP CNAME を生成するために、RTP エンドポイントはセクション5で説明されている手順に従って識別子を生成し、使用「しなければなりません（MUST）」。この手順は、ソフトウェアの初期化ごとに少なくとも1回実行されます。識別子を取得した後、少なくとも下位96ビットを Base64 エンコーディング [RFC4648] を使用して ASCII に変換「すべきです（SHOULD）」（パケットサイズと一意性の間の妥協点として。セクション 6.1 を参照）。96ビットが使用される場合、結果の文字列は16オクテットになります。Base64 エンコードされた値は、RTCP CNAME の最大長である255オクテット [RFC3550] を超えることはできないことに注意してください。

上記の2つのケースにおいて、プライバシーを保護するために、シングルユーザーシステムでは RTCP CNAME の "user@" 部分を省略「してもよく（MAY）」、マルチユーザーシステムでは不透明なトークンに置き換え「てもよい（MAY）」です。

セッションごとの RTCP CNAME を生成することを希望する RTP エンドポイントは、以下の方法を使用「しなければなりません（MUST）」：

  • 新しい RTP セッションごとに、セクション5で説明されている手順に従って新しい RTCP CNAME が生成されます。その手順を実行した後、少なくとも下位96ビットを Base64 エンコーディング [RFC4648] を使用して ASCII に変換「すべきです（SHOULD）」。RTCP CNAME は RTP セッションの期間中に変更することはできません [RFC3550]。セッションごとの RTCP CNAME を生成する場合、RTCP CNAME の "user@" 部分は省略されます。

一意性を得ることは（高い確率で）、方法の慎重な評価を必要とする重要な特性であると考えられます。本文書はいくつかの方法を提供しており、そのうちの少なくとも1つは、どのような導入シナリオにも適しています。したがって、本文書は、実装者が代替方法を定義し選択することを認めていません。

提案された方法が適切な一意性を持ち、相関させる必要のある複数の RTP セッション間で一貫性がある限り、将来の仕様で RTCP CNAME 生成のための代替方法が定義される可能性があります。ただし、そのような仕様は導入前にレビューされ承認される必要があります。

本文書で説明されているメカニズムは RTCP CNAME を生成するために使用されるものであり、汎用的な一意の識別子を生成するために使用されるものではありません。

5. 一意の識別子を生成する手順

一意の識別子をローカルで生成するには、[RFC4086] で説明されているように、暗号学的に疑似乱数値を生成するだけです。この値は少なくとも96ビットでなければ「なりません（MUST）」。

このアルゴリズムの実装における最大のボトルネックは、適切な暗号学的に安全な疑似乱数ジェネレーター (CSPRNG) が利用可能かどうかです。すでに安全な PRNG を備えている環境であれば、ここで説明するアルゴリズムは [RFC6222] のセクション5で説明されているアルゴリズムよりもはるかに単純です。SIP スタック [RFC3261] は、To および From タグを生成するために暗号学的な乱数を使用することが要求されています（セクション 19.3）。Web 上のリアルタイム通信 (RTCWEB) の実装 [ARCH] は、ICE [RFC5245] および DTLS-SRTP [RFC5764] を実装するために安全な PRNG を持つ必要があります。そしてもちろん、実質的にすべての Web ブラウザはすでに TLS をサポートしており、TLS には安全な PRNG が必要です。

に最終更新