7. Connection Management (接続管理)

接続の確立、ネゴシエーション、および切断の方法、メカニズム、および要件は、広範なトピックであり、相互運用性とイノベーションの自由の両方が必要な領域でもあります。

以下の原則が適用されます:

WebRTC メディアネゴシエーションは、SIP で使用されるものと同じ SDP offer/answer セマンティクス [RFC3264] を表現できるため、SIP と WebRTC メディアネゴシエーション間でシグナリングゲートウェイを構築できます。
ICE および適切な RTP/SDP メカニズム、コーデック、およびセキュリティメカニズムをサポートする従来の SIP デバイス間のゲートウェイは、メディアゲートウェイを使用せずに実現できます。Web 側のシグナリングと SIP シグナリング間の変換にはシグナリングゲートウェイが必要になる場合があります。
新しいコーデックの SDP を規定する際、その他の標準化を必要とせずに、そのコーデックを Web ブラウザで使用できるようにすべきです。新しい SDP パラメータを持つ可能性のある新しいコーデックを追加しても、ブラウザと JavaScript アプリケーション間の API を変更する必要はありません。ブラウザが新しいコーデックをサポートすると、コーデックが規定される前に書かれた古いアプリケーションは、JavaScript アプリケーションの変更なしで、適切な場合に新しいコーデックを自動的に使用できるはずです。

WebRTC に対して行われた特定の選択と、WebRTC を実装するブラウザに提供される API への影響は、[RFC8829] で説明されています。

WebRTC ブラウザは、[RFC8829] を実装しなければなりません (MUST)。

WebRTC エンドポイントは、[RFC8829] で説明されているネットワーク層に関連する機能（例えば、BUNDLE [RFC8843]、"rtcp-mux" [RFC5761]、および Trickle ICE [RFC8838]）を実装しなければなりません (MUST) が、これらのエンドポイントは [RFC8829] で説明されている API 機能をサポートする必要はありません。