3.2.3. Mapping SRTP Packets to Cryptographic Contexts (SRTP パケットの暗号コンテキストへのマッピング)

3.2.3. Mapping SRTP Packets to Cryptographic Contexts (SRTP パケットの暗号コンテキストへのマッピング)

各参加者の RTP セッション (RTP session) は, 一対の宛先トランスポートアドレス (destination transport addresses) [RFC3550] (1つのネットワークアドレスと RTP および RTCP のポートペア) によって定義され, マルチメディアセッション (multimedia session) は RTP セッションの集合として定義されることを思い出してください。例えば, 特定のマルチメディアセッションには, オーディオ RTP セッション, ビデオ RTP セッション, テキスト RTP セッションが含まれる可能性があります。

暗号コンテキスト (cryptographic context) は, 三つ組のコンテキスト識別子 (triplet context identifier) によって一意に識別されなければなりません (SHALL):

context id = <SSRC, destination network address, destination transport port number>

ここで, 宛先ネットワークアドレスと宛先トランスポートポートは, SRTP パケット内のものです。この情報が提示されたとき, 鍵管理 (key management) は Section 3.2 で説明されている情報を持つコンテキストを返すと想定されます。

上述のように, SRTP と SRTCP はデフォルトで暗号コンテキスト内のパラメータの大部分を共有します。したがって, 実際には SRTCP ストリームの暗号コンテキストパラメータを取得することは, 対応する SRTP 暗号コンテキストへのバインディングを意味する場合があります。RTCP ポートは RTP ポートのみから直接推測できない可能性があるため, このようなバインディングを保証するのは実装の責任です。あるいは, 鍵管理は, 共通パラメータ (マスター鍵 master key(s) など) を複製して, 個別の SRTP と SRTCP のコンテキストを提供することを選択できます。後者のアプローチにより, 必要に応じて SRTP と SRTCP が異なる変換 (transforms) を使用することも可能になります。単一の RTP セッションの一部を形成する複数の SRTP ストリームが鍵やその他のパラメータを共有する場合にも, 同様の考慮事項が生じます。

特定のコンテキスト識別子に対応するパケットに対して有効なコンテキストが見つからない場合, そのパケットは破棄されなければなりません (MUST)。