[xiph-commits] r14172 - trunk/vorbis/doc

[lu_zero at svn.xiph.org]

Author: lu_zero
Date: 2007-11-17 09:32:16 -0800 (Sat, 17 Nov 2007)
New Revision: 14172

Modified:
   trunk/vorbis/doc/draft-ietf-avt-rtp-vorbis-08.xml
Log:
address 73718 from David Ward

Modified: trunk/vorbis/doc/draft-ietf-avt-rtp-vorbis-08.xml
===================================================================
--- trunk/vorbis/doc/draft-ietf-avt-rtp-vorbis-08.xml	2007-11-17 17:14:57 UTC (rev 14171)
+++ trunk/vorbis/doc/draft-ietf-avt-rtp-vorbis-08.xml	2007-11-17 17:32:16 UTC (rev 14172)
@@ -567,18 +567,14 @@
 
 </section>
 
-<section anchor="Loss of Configuration Headers" title="Loss of Configuration Headers"> 
+<section anchor="Loss of Configuration Headers" title="Loss of Configuration Headers">
 
 <t>
-Unlike the loss of raw Vorbis payload data, loss of a configuration header can
+Unlike the loss of raw Vorbis payload data, loss of a configuration header
 lead to a situation where it will not be possible to successfully decode the
-stream.
+stream. Implementations MAY try to use recover from error requesting again the missing Configuration, the baseline reaction SHOULD be either reset or end the connection.
 </t>
 
-<t>
-Loss of Configuration Packets results in the halting of stream decoding.
-</t>
-
 </section>
 
 </section>
@@ -769,10 +765,10 @@
 fragmented Vorbis packet example above and the first RTP payload is lost the
 client MUST detect that the next RTP payload has the packet count field set
 to 0 and the Fragment type 2 and MUST drop it.
-The next RTP payload, which is the final fragmented packet, MUST be dropped in
-the same manner.
-If the missing RTP payload is the last, the received two fragments will be kept
-and the incomplete Vorbis packet decoded.
+The next RTP payload, which is the final fragmented packet, MUST be dropped
+in the same manner.
+If the missing RTP payload is the last, the received two fragments will be
+kept and the incomplete Vorbis packet decoded.
 </t>
 
 <t>