Rewording of negotiation section

w3c · Aug 17, 2024 · d043fa3 · d043fa3
1 parent 03fea9e
commit d043fa3
Showing 1 changed file with 40 additions and 37 deletions.
diff --git a/index.html b/index.html
@@ -316,10 +316,10 @@ <h2>Negotiation issues</h2>
  means.
  </p>
  <p> 
- One way to handle this is for the SFM to indicate the codecs
- and scalability modes it can decode in the form of receiver
- capabilities. After exchanging capabilities, the application
- can compute the intersection of codecs and
+ One way to handle this is for the SFM to indicate the combination
+ of codecs and scalability modes it can forward in the form of receiver
+ capabilities. After receiving the SFM's capabilities, the application
+ can compute the intersection of codec and
  {{RTCRtpEncodingParameters/scalabilityMode}} values supported
  by the browser's {{RTCRtpSender}} and the
  <a title="Selective Forwarding Middlebox">SFM</a>'s receiver. This
@@ -328,42 +328,45 @@ <h2>Negotiation issues</h2>
  methods.
  </p>
  <p>
- There are situations where an <a title="Selective Forwarding Middlebox">SFM</a>
- may only support reception of a subset of codecs and scalability modes.
- For example, an <a title="Selective Forwarding Middlebox">SFM</a> that parses
- codec payloads may only support the H.264/AVC codec without scalability and
- the VP8 codec with temporal scalability. On the other hand, the browser
- may be able to encode VP8 with temporal scalability, VP9 with temporal
- and spatial scalability and or H.264/AVC with temporal scalability.
- In such a situation, an application desiring to use SVC would only
- be able to encode VP8 with temporal scalability.
+ Here are some examples:
+ <ol>
+ <li>
+ An <a title="Selective Forwarding Middlebox">SFM</a> that parses
+ codec payloads may only support the H.264/AVC codec without scalability and
+ the VP8 codec with temporal scalability. On the other hand, the browser
+ may be able to encode VP8 with temporal scalability, VP9 and AV1 with temporal
+ and spatial scalability and H.264/AVC with temporal scalability.
+ In this example, an application desiring to use SVC would only
+ be able to encode VP8 with temporal scalability.
+ </li>
+ <li>
+ An <a title="Selective Forwarding Middlebox">SFM</a> may only support 
+ single stream simulcast using the [="S2T1"=] and [="S2T1h"=] scalability
+ with the AV1 codec, while the browser may support encoding single
+ stream simulcast using the [="S2T1"=], [="S2T1h"=], [="S3T1"=] and
+ [="S3T1h"=] modes with both the VP9 and AV1 codecs. In this example,
+ an application would only be able to use single-stream simulcast with
+ a maximum of two layers with the AV1 codec. If the application prefers
+ to utilize three layers, then it may decide to forgo use of single
+ stream simulcast and negotiate multi-stream simulcast instead.
+ </li>
+ </ol>
  </p>
  <p>
- Since sending simulcast encodings on a single stream is not negotiated within
- Offer/Answer, an application using SDP signaling needs to determine whether
- single stream simulcast transport is supported prior to the Offer/Answer negotiation.
- This can be handled by having the <a title="Selective Forwarding Middlebox">SFM</a>
- send it's receiver capabilities to the application prior to Offer/Answer.
- This allows the application to determine whether single stream simulcast is
- supported, and if so, what scalability modes the
- <a title="Selective Forwarding Middlebox">SFM</a> can handle. For example,
- an <a title="Selective Forwarding Middlebox">SFM</a> that can only support
- reception of a maximum of two simulcast encodings on a single SSRC with the
- AV1 codec would only indicate support for the [="S2T1"=] and [="S2T1h"=] scalability
- modes in its receiver capabilities.
- </p>
- <p>
- For an <a title="Selective Forwarding Middlebox">SFM</a> the supported
- {{RTCRtpEncodingParameters/scalabilityMode}} values may depend on the negotiated RTP
- header extensions. For example, if the <a title="Selective Forwarding Middlebox">SFM</a>
+ There are situations in which computing the intersection of the browser and
+ SFM capabilities has implications for RTP header extension negotiation.
+ For example, if the <a title="Selective Forwarding Middlebox">SFM</a>
  cannot parse codec payloads (either because it is not designed to do so, or
  because the payloads are encrypted), then negotiation of an RTP header extension
  (such as the AV1 Dependency Descriptor defined in Appendix A of [[?AV1-RTP-SPEC]])
- could be a prerequisite for the <a title="Selective Forwarding Middlebox">SFM</a>
- to forward a {{RTCRtpEncodingParameters/scalabilityMode}} value. As a result,
- the {{RTCRtpEncodingParameters/scalabilityMode}} values supported by an
- <a title="Selective Forwarding Middlebox">SFM</a> may not be determined until
- completion of the Offer/Answer negotiation.
+ could be required for the <a title="Selective Forwarding Middlebox">SFM</a>
+ to forward a particular codec and {{RTCRtpEncodingParameters/scalabilityMode}} value.
+ To take this into account, the RTP header extensions required for forwarding of a 
+ codec could be added to the SFM's receiver capabilities. The application could
+ then compute the intersection of codec, header extension and
+ {{RTCRtpEncodingParameters/scalabilityMode}} values supported
+ by the browser's {{RTCRtpSender}} and the
+ <a title="Selective Forwarding Middlebox">SFM</a>'s receiver.
  </p>
  </section>
  </section>
@@ -1231,8 +1234,8 @@ <h3>S3T3 and S3T3h</h3>
  <h2>Acknowledgements</h2>
  <p>
  The editors wish to thank Robin Raymond, Michael Horowitz, Harald Alvestrand,
- Chris Cunningham, Danil Chapovalov, Florent Castelli and Henrik Boström for their
- contributions to this specification, which evolved from the ORTC API
+ Chris Cunningham, Danil Chapovalov, Florent Castelli, Erik Språng and Henrik Boström
+ for their contributions to this specification, which evolved from the ORTC API
  developed in the <a href="https://www.w3.org/community/ortc/">W3C ORTC CG</a>.
  </p>
  </section>