Merge branch 'master' into gh-pages

juberti · Oct 15, 2015 · 4bd6b30 · 4bd6b30
2 parents dcecdc8 + e9a6f48
commit 4bd6b30
Show file tree

Hide file tree

Showing 18 changed files with 5,997 additions and 2,548 deletions.
diff --git a/.travis.yml b/.travis.yml
@@ -0,0 +1,23 @@
+language: python
+python:
+  - "2.7"
+
+# command to install dependencies, e.g. pip install -r requirements.txt --use-mirrors
+before_install:
+  - sudo apt-get update -qq
+  - sudo apt-get install -y python-lxml python-pip
+install:
+  # here we don't use the travis virtualenv because that
+  # causes us to install lxml again below, doubling the build time
+  # when it compiles the native modules from source
+  - deactivate
+  - sudo pip install xml2rfc
+
+# command to run tests, e.g. python setup.py test
+script: make all #upload
+
+env:
+ global:
+ - GH_REF: github.com/juberti/draughts.git
+ - secure: "Dyu6BRI5Gyidgnshtz4qNvDtXfGLhsoOH9KIyGpk+3RgDYpE2t0uL2D1oWAr7oNbgzHuBpEkd4HaSigs0Yu5UgmQXvhwjBO/ChrleX9g4lVx7qjkOGEz94o6B/FI/ygqmQ819V4CyldZkSYyAJSaL0/OanwuKZ6CejKpCyJYJeo="
+
diff --git a/nombis/Makefile → Makefile b/nombis/Makefile → Makefile
@@ -9,8 +9,9 @@ DIF  := #$(patsubst %.xml,%.diff.html,$(SRC))
 PDF  := #$(patsubst %.xml,%.pdf,$(SRC))
 SVG  := #$(patsubst %.wsd,%.svg,$(WSRC))
 
-#all: $(HTML) $(TXT) $(DIF) $(PDF)
-all: $(HTML) $(TXT) $(DIF) $(SVG) $(PDF)
+all: $(HTML) $(TXT)
+# $(DIF) $(PDF)
+#all: $(HTML) $(TXT) $(DIF) $(SVG) $(PDF)
 
 clean:
 	rm -f *~ draft*.html draft*pdf draft-*txt $(SVG)

diff --git a/README.md b/README.md
@@ -1,3 +1,5 @@
+[![Build Status](https://travis-ci.org/juberti/draughts.svg)](https://travis-ci.org/juberti/draughts)
+
 draughts
 ========
 

diff --git a/fec/draft-uberti-rtcweb-fec.xml → draft-ietf-rtcweb-fec.xml b/fec/draft-uberti-rtcweb-fec.xml → draft-ietf-rtcweb-fec.xml
@@ -5,7 +5,7 @@
 <!ENTITY rfc5109 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5109.xml">
 <!ENTITY rfc5956 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5956.xml">
 <!ENTITY rfc6716 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6716.xml">
-<!ENTITY fecpayload SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.singh-payload-rtp-1d2d-parity-scheme.xml">
+<!ENTITY fecpayload SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-payload-flexible-fec-scheme.xml">
 <!ENTITY opuspayload SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-payload-rtp-opus.xml">
 ]>
 <?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
@@ -19,7 +19,7 @@
 <?rfc rfcedstyle="no" ?>
 <?rfc tocdepth="4"?>
 
-<rfc category="std" docName="draft-uberti-rtcweb-fec-00" ipr="trust200902">
+<rfc category="std" docName="draft-ietf-rtcweb-fec-01" ipr="trust200902">
   <front>
     <title abbrev="WebRTC FEC">WebRTC Forward Error Correction Requirements</title>
 
@@ -43,22 +43,22 @@
       </address>
     </author>
 
-    <date day="27" month="October" year="2014" />
+    <date day="5" month="March" year="2015" />
 
     <area>RAI</area>
 
     <abstract>
-      <t>This document makes recommendations for how Forward Error Correction
-      (FEC) should be used by WebRTC applications.</t>
+      <t>This document provides information and requirements for how
+      Forward Error Correction (FEC) should be used by WebRTC applications.</t>
     </abstract>
   </front>
 
   <middle>
     <section title="Introduction">
-      <t>In situations where packet loss is high, or media quality must be perfect,
+      <t>In situations where packet loss is high, or perfect media quality is essential,
       Forward Error Correction (FEC) can be used to proactively recover from packet losses.
-      This document describes what FEC mechanisms should be used by WebRTC
-      client implementations.</t>
+      This specification provides guidance on which FEC mechanisms to use, and
+      how to use them, for WebRTC client implementations.</t>
     </section>
 
     <section title="Terminology">
@@ -75,22 +75,25 @@
          can be accomplished; this section enumerates the various mechanisms
          and describes their tradeoffs.</t>
       <section title="Separate FEC Stream">
-          <t>This approach, as described in <xref target="RFC5956"/>, Section 4.3, sends FEC packets as an 
+          <t>This approach, as described in <xref target="RFC5956"/>, Section 4.3,
+            sends FEC packets as an
             independent SSRC-multiplexed stream, with its own SSRC and payload type.
             While by far the most flexible, each FEC packet will have its own
             IP+UDP+RTP+FEC header, leading to additional overhead of the FEC stream.
           </t>
       </section>
       <section title="Redundant Encoding">
           <t>This approach, as descibed in <xref target="RFC2198"/>, allows for redundant data
-            to be piggybacked on an existing primary encoding in a single packet.
+            to be piggybacked on an existing primary encoding, all in a single packet.
             This redundant data may be an exact copy of a previous packet, or
             for codecs that support variable-bitrate encodings, possibly a smaller,
-            lower-quality representation. Since there is only a single set of
-            packet headers, this allows for a very efficient representation of
+            lower-quality representation. In certain cases, the redundant data
+            could include multiple prior packets.</t>
+          <t>Since there is only a single set of
+            packet headers, this approach allows for a very efficient representation of
             primary + redundant data. However, this savings is only realized when
-            the two encodings both fit into a single packet (i.e. less than a MTU).
-            This approach is also only applicable to audio content.
+            the data all fits into a single packet (i.e. the size is less than a MTU).
+            As a result, this approach is generally not useful for video content.
           </t>
       </section>
        <section title="Codec-Specific In-band FEC">
@@ -104,42 +107,37 @@
     </section>
 
     <section title="FEC for Audio Content">
-      <t>The following section provides guidance on how to best use FEC for transmitting 
+      <t>The following section provides guidance on how to best use FEC for transmitting
       audio data. As indicated in <xref target="adaptive-fec"/> below, FEC should only
       be activated if network conditions warrant it, or upon explicit application request.
       </t>
       <section title="Recommended Mechanism">
         <t>When using the Opus codec in its default (hybrid) mode, use of
-          the built-in Opus FEC mechanism is RECOMMENDED.
-          This provides reasonable protection of the
-          audio stream against typical losses, with moderate overhead. [TODO: add stats]
-          Note though that this mechanism only protects the SILK layer of the Opus codec;
-          the CELT portion is not protected. This is not an issue when Opus is running in 
-          hybrid mode, as the lower frequencies will still be able to be recovered,
-          with minimal quality impact.
+          the built-in Opus FEC mechanism is RECOMMENDED. This provides reasonable
+          protection of the audio stream against typical losses, with minimal
+          overhead. [TODO: add stats]
         </t>
-        <t>When using Opus in CELT mode, or other variable-bitrate codecs,
-        use of <xref target="RFC2198"/> redundant encoding with a lower-fidelity version of the
-        previous packet is RECOMMENDED. When using Opus specifically, the lower-fidelity
-        version can simply be a truncated version of the previous Opus packet.
-        [TODO: decide exact truncated size]
-        This provides reasonable protection of the payload with minimal overhead.
+        <t>When using variable-bitrate codecs without an internal FEC, use of
+        <xref target="RFC2198"/> redundant encoding with a lower-fidelity version
+        of previous packet(s) is RECOMMENDED.
+        This provides reasonable protection of the payload with moderate overhead.
         </t>
-        <t>When using constant-bitrate codecs, e.g. PCMU, use of <xref target="RFC2198"/> redundant encoding
-        is NOT RECOMMENDED, as this will result in a potentially significant bitrate increase.
-        Furthermore, suddenly increasing the bitrate to deal with packet losses may
+        <t>When using constant-bitrate codecs, e.g. PCMU, use of
+        <xref target="RFC2198"/> redundant encoding MAY be used, but note that
+        this will result in a potentially significant bitrate increase, and
+        that suddenly increasing bitrate to deal with losses from congestion may
         actually make things worse.
         </t>
-        <t>Because of the lower packet rate of audio encodings, usually a single packet per
-        frame, use of a separate FEC stream comes with a higher overhead than other
-        mechanisms, and therefore is NOT RECOMMENDED.
+        <t>Because of the lower packet rate of audio encodings, usually a single
+        packet per frame, use of a separate FEC stream comes with a higher overhead
+        than other mechanisms, and therefore is NOT RECOMMENDED.
         </t>
       </section>
 
       <section title="Negotiating Support">
         <t>Support for redundant encoding can be indicated by offering "red" as a
         supported payload type in the offer. Answerers can reject the use of
-        redundant encoding by not including "red" as a supported payload type in 
+        redundant encoding by not including "red" as a supported payload type in
         the answer.</t>
         <t>Support for codec-specific FEC mechanisms are typically indicated via
         "a=fmtp" parameters. For Opus specifically, this is controlled by the
@@ -150,13 +148,13 @@
     </section>
 
     <section title="FEC for Video Content">
-      <t>The following section provides guidance on how to best use FEC for transmitting 
+      <t>The following section provides guidance on how to best use FEC for transmitting
       video data. As indicated in <xref target="adaptive-fec"/> below, FEC should only
       be activated if network conditions warrant it, or upon explicit application request.
       </t>
       <section title="Recommended Mechanism">
         <t>For video content, use of a separate FEC stream with the RTP payload format
-        described in <xref target="I-D.singh-payload-rtp-1d2d-parity-scheme"/> is RECOMMENDED.
+        described in <xref target="I-D.ietf-payload-flexible-fec-scheme"/> is RECOMMENDED.
         The receiver can demultiplex the incoming FEC stream by SSRC and correlate it
         with the primary stream via the ssrc-group mechanism.
         </t>
@@ -166,22 +164,36 @@
       </section>
       <section title="Negotiating Support">
         <t>To offer support for a separate FEC stream, the offerer MUST offer one of
-        the formats described in <xref target="I-D.singh-payload-rtp-1d2d-parity-scheme"/>, Section 5.1, as well as a
+        the formats described in <xref target="I-D.ietf-payload-flexible-fec-scheme"/>,
+        Section 5.1, as well as a
         ssrc-group with "FEC-FR" semantics as described in <xref target="RFC5956"/>, Section 4.3.</t>
         <t>Answerers can reject the use of FEC by not including FEC payloads in the answer.</t>
-      </section>   
+      </section>
+    </section>
+
+    <section title="FEC for Application Content">
+      <t>WebRTC also supports the ability to send generic application data, and
+      provides transport-level retransmission mechanisms that the application
+      can use to ensure that its data is delivered reliably. </t>
+      <t>
+      Because the application can control exactly what data to send, it has the
+      ability to monitor packet statistics and perform its own application-level
+      FEC, if necessary.</t>
+      <t>As a result, this document makes no recommendations regarding FEC for
+      the underlying data transport.</t>
     </section>
 
     <section title="Implementation Requirements">
         <t>To support the functionality recommended above, implementations MUST support
-        the redundant encoding mechanism described in <xref target="RFC2198"/> and the FEC 
-        mechanism described in <xref target="RFC5956"/> and <xref target="I-D.singh-payload-rtp-1d2d-parity-scheme"/>.</t>
-        <t>Implementations MAY support additional FEC mechanisms if desired, 
+        the redundant encoding mechanism described in <xref target="RFC2198"/> and the FEC
+        mechanism described in <xref target="RFC5956"/> and
+        <xref target="I-D.ietf-payload-flexible-fec-scheme"/>.</t>
+        <t>Implementations MAY support additional FEC mechanisms if desired,
         e.g. <xref target="RFC5109"/>.</t>
     </section>
-    
+
     <section anchor="adaptive-fec" title="Adaptive Use of FEC">
-      <t>Since use of FEC causes redundant data to be transmitted, this will 
+      <t>Since use of FEC causes redundant data to be transmitted, this will
         lead to less bandwidth available for the primary encoding, when in a
         bandwidth-constrained environment. Given this, WebRTC implementations
         SHOULD only transmit FEC data when network conditions indicate that
@@ -192,15 +204,26 @@
     </section>
 
     <section title="Security Considerations">
-      <t>TODO</t>
+      <t>This document makes recommendations regarding the use of FEC.
+      Generally, it should be noted that although applying redundancy is often useful
+      in protecting a stream against packet loss, if the loss is caused by network
+      congestion, the additional bandwidth used by the redundant data may actually
+      make the situation worse, and can lead to significant degradation of the
+      network.
+      </t>
+      <t>Additional security considerations for each individual FEC mechanism
+      are enumerated in their respective documents.
+      </t>
+
     </section>
 
     <section title="IANA Considerations">
       <t>This document requires no actions from IANA.</t>
     </section>
 
     <section title="Acknowledgements">
-      <t>Several people provided significant input into this document, including Jonathan Lennox, Giri Mandyam, Varun Singh, Tim Terriberry, and Mo Zanaty.</t>
+      <t>Several people provided significant input into this document, including
+      Jonathan Lennox, Giri Mandyam, Varun Singh, Tim Terriberry, and Mo Zanaty.</t>
     </section>
   </middle>
 
@@ -219,6 +242,15 @@
     </references>
 
     <section title="Change log">
+      <t>Changes in draft -01: <list style="symbols">
+        <t>Tweaked abstract/intro text that was ambiguously normative.</t>
+        <t>Removed text on FEC for Opus in CELT mode.</t>
+        <t>Changed RFC 2198 recommendation for PCMU to be MAY instead of
+           NOT RECOMMENDED, based on list feedback.</t>
+        <t>Explicitly called out application data as something not addressed
+           in this document.</t>
+        <t>Updated flexible-fec reference.</t>
+      </list></t>
       <t>Changes in draft -00: <list style="symbols">
         <t>Initial version, from sidebar conversation at IETF 90.</t>
       </list></t>