5.1.2. Profile Names and Interoperability (プロファイル名と相互運用性)

5.1.2. Profile Names and Interoperability (プロファイル名と相互運用性)

メディア "m=" セクションについて, JSEP 実装は [RFC5764] で指定された "UDP/TLS/RTP/SAVPF" プロファイル, および [RFC7850] で指定された "TCP/DTLS/RTP/SAVPF" プロファイルをサポートしなければならず, オファーで生成する各メディア "m=" 行に対してこれらのプロファイルのいずれかを示さなければなりません。データ "m=" セクションについて, 実装は "UDP/DTLS/SCTP" プロファイルおよび "TCP/DTLS/SCTP" プロファイルをサポートしなければならず, オファーで生成する各データ "m=" 行に対してこれらのプロファイルのいずれかを示さなければなりません。使用する正確なプロファイルは, [RFC8839] のセクション 4.2.1.2 で説明されているように, 現在のデフォルトまたは選択された ICE 候補に関連付けられたプロトコルによって決定されます。

残念ながら, 互換性を試みる中で, これらのプロファイルのいずれかをサポートする意図があっても, 一部のエンドポイントは他のプロファイル文字列を生成します。たとえば, エンドポイントは "RTP/AVP" を生成する一方で "a=fingerprint" および "a=rtcp-fb" 属性を提供し, "UDP/TLS/RTP/SAVPF" または "TCP/DTLS/RTP/SAVPF" をサポートする意思を示す場合があります。このようなエンドポイントとの互換性を簡素化するため, JSEP 実装は受信したオファーのメディア "m=" セクションを処理する際に以下のルールに従わなければなりません:

• オファー内の以下のいずれかに一致するプロファイルは受け入れなければなりません:

  • "RTP/AVP" ([RFC4566] のセクション 8.2.2 で定義)
  • "RTP/AVPF" ([RFC4585] のセクション 9 で定義)
  • "RTP/SAVP" ([RFC3711] のセクション 12 で定義)
  • "RTP/SAVPF" ([RFC5124] のセクション 6 で定義)
  • "TCP/DTLS/RTP/SAVP" ([RFC7850] のセクション 3.4 で定義)
  • "TCP/DTLS/RTP/SAVPF" ([RFC7850] のセクション 3.5 で定義)
  • "UDP/TLS/RTP/SAVP" ([RFC5764] のセクション 9 で定義)
  • "UDP/TLS/RTP/SAVPF" ([RFC5764] のセクション 9 で定義)

• 生成されたアンサー内の任意の "m=" 行のプロファイルは, オファーで提供されたプロファイルと正確に一致しなければなりません。

• DTLS-SRTP が必須であるため, SAVP または AVP の選択は影響しません; DTLS-SRTP のサポートは, 1つ以上の "a=fingerprint" 属性の存在によって決定されます。"a=fingerprint" 属性がないと交渉の失敗につながることに注意してください。

• AVPF または AVP の使用は, RTCP フィードバックに使用されるタイミングルールを制御するだけです。AVPF が提供されているか, "a=rtcp-fb" 属性が存在する場合は, AVPF タイミングを想定します, つまりデフォルト値は "trr-int=0" です。それ以外の場合は, AVPF が AVP 互換モードで使用されていると想定し, 値 "trr-int=4000" を使用します。

• データ "m=" セクションについて, 実装は "UDP/DTLS/SCTP", "TCP/DTLS/SCTP", または "DTLS/SCTP" (後方互換性のため) プロファイルの受信をサポートしなければなりません。

JSEP 実装による再オファーは, 初期オファー/アンサー交換が (不正確な) 古いプロファイル文字列を使用した場合でも, 正しいプロファイル文字列を使用しなければならないことに注意してください。これにより JSEP の動作が簡素化され, 悪影響は最小限に抑えられます, なぜなら, そのような再オファーを処理できないリモートエンドポイントは, JSEP エンドポイントの初期オファーも処理できないためです。