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

[lu_zero at svn.xiph.org]

Author: lu_zero
Date: 2008-01-25 03:50:58 -0800 (Fri, 25 Jan 2008)
New Revision: 14431

Modified:
   trunk/vorbis/doc/draft-ietf-avt-rtp-vorbis-09.txt
   trunk/vorbis/doc/draft-ietf-avt-rtp-vorbis-09.xml
Log:
Colin suggestion to clarify the SDP reference is just an example

Modified: trunk/vorbis/doc/draft-ietf-avt-rtp-vorbis-09.txt
===================================================================
--- trunk/vorbis/doc/draft-ietf-avt-rtp-vorbis-09.txt	2008-01-24 03:31:25 UTC (rev 14430)
+++ trunk/vorbis/doc/draft-ietf-avt-rtp-vorbis-09.txt	2008-01-25 11:50:58 UTC (rev 14431)
@@ -427,20 +427,20 @@
    different methods for delivering this configuration data to a client,
    both in-band and out-of-band which is detailed below.  In order to
    set up an initial state for the client application the configuration
-   MUST be inlined in the session setup informations.  Changes to the
-   configuration MAY be communicated via a re-invite, conveying new SDP,
-   or sent in-band in the RTP channel.  Implementations MUST support in-
-   band delivery of updated codebooks, and SHOULD support out-of-band
-   codebook update using a new SDP file.  The changes may be due to
-   different codebooks as well as different bitrates of the RTP stream.
+   MUST be conveyed via the signalling channel used to setup the
+   session.  One example of such signalling is SDP [5] with the Offer/
+   Answer Model [8].  Changes to the configuration MAY be communicated
+   via a re-invite, conveying new SDP, or sent in-band in the RTP
+   channel.  Implementations MUST support in-band delivery of updated
+   codebooks, and SHOULD support out-of-band codebook update using a new
+   SDP file.  The changes may be due to different codebooks as well as
+   different bitrates of the RTP stream.
 
    For non chained streams, the recommended Configuration delivery
    method is inline the Packed Configuration (Section 3.1.1) in the SDP
    as explained in the IANA considerations (Section 7.1).
 
    The 24 bit Ident field is used to map which Configuration will be
-   used to decode a packet.  When the Ident field changes, it indicates
-   that a change in the stream has taken place.  The client application
 
 
 
@@ -449,6 +449,8 @@
 Internet-Draft          Vorbis RTP Payload Format               Jan 2008
 
 
+   used to decode a packet.  When the Ident field changes, it indicates
+   that a change in the stream has taken place.  The client application
    MUST have in advance the correct configuration and if the client
    detects a change in the Ident value and does not have this
    information it MUST NOT decode the raw Vorbis data associated until
@@ -498,8 +500,6 @@
 
 
 
-
-
 Barbato                   Expires July 17, 2008                 [Page 9]
 
 Internet-Draft          Vorbis RTP Payload Format               Jan 2008

Modified: trunk/vorbis/doc/draft-ietf-avt-rtp-vorbis-09.xml
===================================================================
--- trunk/vorbis/doc/draft-ietf-avt-rtp-vorbis-09.xml	2008-01-24 03:31:25 UTC (rev 14430)
+++ trunk/vorbis/doc/draft-ietf-avt-rtp-vorbis-09.xml	2008-01-25 11:50:58 UTC (rev 14431)
@@ -395,7 +395,10 @@
 different methods for delivering this configuration data to a 
 client, both in-band and out-of-band which is detailed below.
 In order to set up an initial state for the client application the
-configuration MUST be inlined in the session setup informations.
+configuration MUST be conveyed via the signalling channel used to setup
+the session. One example of such signalling is
+<xref target="rfc4566">SDP</xref> with the
+<xref target="rfc3264">Offer/Answer Model</xref>.
 Changes to the configuration MAY be communicated via a re-invite,
 conveying new SDP, or sent in-band in the RTP channel.
 Implementations MUST support in-band delivery of updated codebooks,