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

[lu_zero at svn.xiph.org]

Author: lu_zero
Date: 2005-12-14 05:15:48 -0800 (Wed, 14 Dec 2005)
New Revision: 10588

Modified:
   trunk/vorbis/doc/draft-ietf-avt-vorbis-rtp-00.txt
Log:
text updated

Modified: trunk/vorbis/doc/draft-ietf-avt-vorbis-rtp-00.txt
===================================================================
--- trunk/vorbis/doc/draft-ietf-avt-vorbis-rtp-00.txt	2005-12-13 23:13:20 UTC (rev 10587)
+++ trunk/vorbis/doc/draft-ietf-avt-vorbis-rtp-00.txt	2005-12-14 13:15:48 UTC (rev 10588)
@@ -1152,7 +1152,7 @@
 
    That is one of the most common situation: one single server streaming
    content in multicast, the clients may start a session at random time.
-   The content itself could be a mix of live stream as the dj's speech
+   The content itself could be a mix of live stream, as the dj's voice,
    and stored streams as the music she plays.
 
    In this situation we don't know in advance how many codebooks we will
@@ -1161,24 +1161,28 @@
 
    On join the client will receive the current Configuration necessary
    to decode the current stream inlined in the SDP.  And can start
-   decoding the current stream.
+   decoding the current stream as soon it joins the session.
 
    When the streamed content changes the new Configuration is sent in-
    band before the actual stream, and the Configuration that has to be
-   sent inline in the SDP updated.
+   sent inline in the SDP updated.  Since the inline method is
+   unreliable, an out of band fallback is provided.  The client could
+   choose to fetch the Configuration from the alternate source as soon
+   it discovers a Configuration packet got lost inline or use selective
+   retransmission{FIXME}, if the server supports them
 
-   A serverside optimization would be keep an hash list of the
-   Configurations per session to avoid packing them and send the same
-   Configuration with different Ident tags
 
 
-
 Barbato                  Expires April 24, 2006                [Page 21]
 
 Internet-Draft        draft-kerr-avt-vorbis-rtp-05          October 2005
 
 
-   A clientside optimization would be keep a tag list of the
+   A serverside optimization would be to keep an hash list of the
+   Configurations per session to avoid packing all of them and send the
+   same Configuration with different Ident tags
+
+   A clientside optimization would be to keep a tag list of the
    Configurations per session and don't process configuration packets
    already known.
 
@@ -1223,17 +1227,17 @@
    [2]   Bradner, S., "Key words for use in RFCs to Indicate Requirement
          Levels", RFC 2119.
 
-   [3]   Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson,
-         "RTP: A Transport Protocol for real-time applications",
-         RFC 3550.
 
 
-
 Barbato                  Expires April 24, 2006                [Page 22]
 
 Internet-Draft        draft-kerr-avt-vorbis-rtp-05          October 2005
 
 
+   [3]   Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson,
+         "RTP: A Transport Protocol for real-time applications",
+         RFC 3550.
+
    [4]   Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video
          Conferences with Minimal Control.", RFC 3551.
 
@@ -1281,10 +1285,6 @@
 
 
 
-
-
-
-
 Barbato                  Expires April 24, 2006                [Page 23]
 
 Internet-Draft        draft-kerr-avt-vorbis-rtp-05          October 2005