[xiph-commits] r10736 - trunk/theora/doc

[lu_zero at svn.xiph.org]

Author: lu_zero
Date: 2006-01-17 11:12:07 -0800 (Tue, 17 Jan 2006)
New Revision: 10736

Modified:
   trunk/theora/doc/draft-barbato-avt-rtp-theora-00.xml
Log:
p2p IM section clarified a bit

Modified: trunk/theora/doc/draft-barbato-avt-rtp-theora-00.xml
===================================================================
--- trunk/theora/doc/draft-barbato-avt-rtp-theora-00.xml	2006-01-17 06:24:22 UTC (rev 10735)
+++ trunk/theora/doc/draft-barbato-avt-rtp-theora-00.xml	2006-01-17 19:12:07 UTC (rev 10736)
@@ -943,30 +943,28 @@
 
 </section>
 
-<!-- WIP, still doesn't look good and probably is quite silly
 <section anchor="Examples" title="Examples">
 
 <t>
 The following examples are common usage patterns that MAY be applied in such situations, the main scope of this section is to explain better usage of the transmission vectors.
 </t>
+<!--
 
 <section anchor="Peer to Peer Internet Messaging" title="Peer to Peer Internet Messaging">
 
-<t>This scenario implies two peers linked by a best effort network, the bandwidth isn't guaranteed, in order to keep the latency low enough is necessary to use dynamic adaptation tecniques [missing reference].</t>
+<t>This scenario implies two peers linked through a best effort network, the bandwidth isn't guaranteed and may have large variance, in order to keep the latency low enough dynamic adaptation tecniques [missing reference] are required.</t>
 
-<t>Due the strict latency requirement sending the Configuration in-band isn't possible and the choice for the proposed solution is to not send Configuration on demand or by any other out of band means, since it will affect latency,  but prepare a set of possible Configurations related to different bitrates in advance during the session initiation.</t>
+<t>Each peer will receive 2 streams (voice and video) from the other. To determine the quality of the stream and ensure the latency is bearable [put maximum latency here] a form of handshake is required. SIP or Jingle or TINS could be used in this phase.</t>
 
-<t>Different session initiation methods either depending on the IM protocol (Jingle[reference], TINS[reference]) or stand alone (SIP[reference]); all all based on the Offer-Answer[reference] paradigm and let the peers agree on the Configurations set. All the Configuration usable for the session are known after this initial handshake.</t>
+<t>Since changes in the bitrates will reflect on the setup header, the simplest way to get dynamic adaptation is to consider each stream as a completely different coded, have a payload number for each of them and use the dynamic coding change tecniques.</t>
 
-<t>Each bitrate will be described using a separated payload number</t>
+<t>Due the latency requirement even if sending the Configuration in-band MAY be possible, usually it SHOULD be avoided. Other out of band methods that send Configuration on demand, since they would affect latency as the in-band method, SHOULD be avoided as well. Agree on a set of Configurations related to different bitrates during the session initiation is the best method.</t>
 
-<t>To adapt to the network profile with minimal overhead and latency the simplest way is to change the payload number within the same rtp session and have the client ready to decode any possible bitrate agreed.</t>
-
-
 </section>
-</section>
 -->
 
+</section>
+
 <section anchor="Security Considerations" title="Security Considerations"> 
 <t>
 RTP packets using this payload format are subject to the security considerations discussed in the RTP specification