Colin suggestion to clarify the SDP reference is just an example

svn path=/trunk/vorbis/; revision=14431

diff --git a/doc/draft-ietf-avt-rtp-vorbis-09.txt b/doc/draft-ietf-avt-rtp-vorbis-09.txt
index 0e3d039e2f7ae5d0f777f2df4e9ec0603f03f347..89de4ea19e7bcb5516d81fff640e9571e96bc112 100644 (file)
--- a/doc/draft-ietf-avt-rtp-vorbis-09.txt
+++ b/doc/draft-ietf-avt-rtp-vorbis-09.txt
@@ -427,20 +427,20 @@ Internet-Draft          Vorbis RTP Payload Format               Jan 2008
    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 @@ Barbato                   Expires July 17, 2008                 [Page 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 @@ Internet-Draft          Vorbis RTP Payload Format               Jan 2008
 
 
 
-
-
 Barbato                   Expires July 17, 2008                 [Page 9]
 \f
 Internet-Draft          Vorbis RTP Payload Format               Jan 2008

diff --git a/doc/draft-ietf-avt-rtp-vorbis-09.xml b/doc/draft-ietf-avt-rtp-vorbis-09.xml
index 619138f1fadd9be9180812e55cb9c1108d760173..697fea73e811d436a48c48ba9e2d96af96ffd150 100644 (file)
--- a/doc/draft-ietf-avt-rtp-vorbis-09.xml
+++ b/doc/draft-ietf-avt-rtp-vorbis-09.xml
@@ -395,7 +395,10 @@ stream may change certain configuration data mid-session, there are
 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,