RTC capabillity negotiation

index.bs

@@ -1184,8 +1184,36 @@ spec: encrypted-media-draft; for: EME; urlPrefix: https://w3c.github.io/encrypte
       or APIs but is provides an easier access to some information that can be
       used to fingerprint users.
     </p>
-
-    <section>
+  <section>
+      <h3 id='capabilities-model'>
+        Capabilities Model
+      </h3>
+      <p>
+        This specification supports {{MediaDecodingType}} values of {{file}},
+        {{media-source}} or {{webrtc}} as well as {{MediaEncodingType}}
+        values of {{record}} and {{webrtc}}. 
+      </p>
+      <p>
+        In realtime communications as supported in [[webrtc]], media is
+        transported between peers. Although web sites are responsible for
+        relaying of signaling between user agents, they are typically not
+        involved in media transport, encoding or decoding. For 1-1 calls,
+        user agents negotiate media to be sent and received.
+     </p>
+     <p>
+        In a conferencing scenario, a user agent can send media for
+        reception by dozens or even hundreds of receivers.  To improve
+        scalability, applications make use of external servers, such as
+        selective forwarding units or conferencing bridges. These servers
+        negotiate media parameters with participants, ensuring consistency
+        across senders and receivers. This is more scalable than negotiation 
+        between user agents, which would require N (N -1) negotiations.
+        Since typically senders encode with a single codec, and conferencing
+        servers do not support transcoding, a user agent cannot simply
+        "pick the one they like best".
+     </p>
+  </section>
+  <section>
       <h3 id='decoding-encoding-fingerprinting'>
         Decoding/Encoding and Fingerprinting
       </h3>