Bump version
[platform/upstream/libvorbis.git] / doc / draft-ietf-avt-rtp-vorbis-09.xml
1 <?xml version="1.0"?>
2 <!DOCTYPE rfc SYSTEM "rfc2629.dtd">
3 <?rfc toc="yes" ?>
4 <?rfc compact="yes" ?>
5 <?rfc rfcedstyle="yes" ?>
6
7 <rfc ipr="full3978" docName="draft-ietf-avt-rtp-vorbis-09">
8
9 <front>
10 <title abbrev="Vorbis RTP Payload Format">RTP Payload Format for Vorbis Encoded Audio</title>
11
12 <author initials="L" surname="Barbato" fullname="Luca Barbato">
13 <organization abbrev="Xiph">Xiph.Org Foundation</organization>
14 <address>
15 <email>lu_zero@gentoo.org</email>
16 <uri>http://xiph.org/</uri>
17 </address>
18 </author>
19
20 <date day="14" month="Jan" year="2008" />
21
22 <area>General</area>
23 <workgroup>AVT Working Group</workgroup>
24 <keyword>I-D</keyword>
25
26 <keyword>Internet-Draft</keyword>
27 <keyword>Vorbis</keyword>
28 <keyword>RTP</keyword>
29
30 <abstract>
31
32 <t>
33 This document describes an RTP payload format for transporting Vorbis encoded
34 audio. It details the RTP encapsulation mechanism for raw Vorbis data and 
35 details the delivery mechanisms for the decoder probability model, referred to
36 as a codebook and other setup information.
37 </t>
38
39 <t>
40 Also included within this memo are media type registrations, and the details
41 necessary for the use of Vorbis with the Session Description Protocol (SDP).
42 </t>
43
44 </abstract>
45
46 <note title="Editors Note">
47 <t>
48 All references to RFC XXXX are to be replaced by references to the RFC number
49 of this memo, when published.
50 </t>
51 </note>
52
53 </front>
54
55 <middle>
56
57 <section anchor="Introduction" title="Introduction">
58
59 <t>
60 Vorbis is a general purpose perceptual audio codec intended to allow 
61 maximum encoder flexibility, thus allowing it to scale competitively 
62 over an exceptionally wide range of bitrates. At the high 
63 quality/bitrate end of the scale (CD or DAT rate stereo, 16/24 bits), it 
64 is in the same league as MPEG-4 AAC.
65 Vorbis is also intended for lower and higher sample rates (from 
66 8kHz telephony to 192kHz digital masters) and a range of channel 
67 representations (monaural, polyphonic, stereo, quadraphonic, 5.1, 
68 ambisonic, or up to 255 discrete channels).
69 </t>
70
71 <t>
72 Vorbis encoded audio is generally encapsulated within an Ogg format bitstream
73 <xref target="rfc3533"></xref>, which provides framing and synchronization.
74 For the purposes of RTP transport, this layer is unnecessary, and so raw Vorbis
75 packets are used in the payload.
76 </t>
77
78 <section anchor="Terminology" title="Conformance and Document Conventions">
79
80 <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, <xref target="rfc2119"/> and indicate requirement levels for compliant implementations.  Requirements apply to all implementations unless otherwise stated.</t>
81 <t>An implementation is a software module that supports one of the media types defined in this document.  Software modules may support multiple media types, but conformance is considered individually for each type.</t>
82 <t>Implementations that fail to satisfy one or more "MUST" requirements are considered non-compliant.  Implementations that satisfy all "MUST" requirements, but fail to satisfy one or more "SHOULD" requirements, are said to be "conditionally compliant".  All other implementations are "unconditionally compliant".</t>
83
84 </section>
85 </section>
86
87 <section anchor="Payload Format" title="Payload Format">
88
89 <t>
90 For RTP based transport of Vorbis encoded audio the standard RTP header is
91 followed by a 4 octets payload header, then the payload data. The payload
92 headers are used to associate the Vorbis data with its associated decoding
93 codebooks as well as indicating if the following packet contains fragmented
94 Vorbis data and/or the number of whole Vorbis data frames. The payload data
95 contains the raw Vorbis bitstream information. There are 3 types of Vorbis
96 data, an RTP payload MUST contain just one of them at a time.
97 </t>
98
99 <section anchor="RTP Header" title="RTP Header">
100
101 <t>
102 The format of the RTP header is specified in <xref target="rfc3550"></xref>
103 and shown in Figure <xref target="RTP Header Figure"/>.  This payload format
104 uses the fields of the header in a manner consistent with that specification.
105 </t>
106
107 <t>
108 <figure anchor="RTP Header Figure" title="RTP Header">
109 <artwork><![CDATA[
110     0                   1                   2                   3
111     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
112    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
113    |V=2|P|X|  CC   |M|     PT      |       sequence number         |
114    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
115    |                           timestamp                           |
116    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
117    |           synchronization source (SSRC) identifier            |
118    +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
119    |            contributing source (CSRC) identifiers             |
120    |                              ...                              |
121    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
122 ]]></artwork>
123 </figure>
124 </t>
125
126 <t>
127 The RTP header begins with an octet of fields (V, P, X, and CC) to support
128 specialized RTP uses (see <xref target="rfc3550"></xref> and 
129 <xref target="rfc3551"></xref> for details). For Vorbis RTP, the following
130 values are used.
131 </t>
132
133 <t>
134 Version (V): 2 bits</t>
135 <t>
136 This field identifies the version of RTP. The version used by this
137 specification is two (2).
138 </t>
139
140 <t>
141 Padding (P): 1 bit</t>
142 <t>
143 Padding MAY be used with this payload format according to section 5.1 of
144 <xref target="rfc3550"></xref>.
145 </t>
146
147 <t>
148 Extension (X): 1 bit</t>
149 <t>
150 The Extension bit is used in accordance with <xref target="rfc3550"></xref>.
151 </t>
152
153 <t>
154 CSRC count (CC): 4 bits</t>
155 <t>
156 The CSRC count is used in accordance with <xref target="rfc3550"></xref>.
157 </t>
158
159 <t>
160 Marker (M): 1 bit</t>
161 <t>
162 Set to zero.  Audio silence suppression not used.  This conforms to section 4.1
163 of <xref target="vorbis-spec-ref"></xref>.
164 </t>
165
166 <t>
167 Payload Type (PT): 7 bits</t>
168 <t>
169 An RTP profile for a class of applications is expected to assign a payload type
170 for this format, or a dynamically allocated payload type SHOULD be chosen which
171 designates the payload as Vorbis.
172 </t>
173
174 <t>
175 Sequence number: 16 bits</t>
176 <t>
177 The sequence number increments by one for each RTP data packet sent, and may be
178 used by the receiver to detect packet loss and to restore packet sequence. This
179 field is detailed further in <xref target="rfc3550"></xref>.
180 </t>
181
182 <t>
183 Timestamp: 32 bits</t>
184 <t>
185 A timestamp representing the sampling time of the first sample of the first
186 Vorbis packet in the RTP payload. The clock frequency MUST be set to the sample
187 rate of the encoded audio data and is conveyed out-of-band (e.g. as an SDP parameter).
188 </t>
189
190 <t>
191 SSRC/CSRC identifiers: </t>
192 <t>
193 These two fields, 32 bits each with one SSRC field and a maximum of 16 CSRC
194 fields, are as defined in <xref target="rfc3550">
195 </xref>.  
196 </t>
197
198 </section>
199
200 <section anchor="Payload Header" title="Payload Header">
201
202 <t>
203 The 4 octets following the RTP Header section are the Payload Header. This
204 header is split into a number of bitfields detailing the format of the
205 following payload data packets.
206 </t>
207
208 <figure anchor="Payload Header Figure" title="Payload Header">
209 <artwork><![CDATA[
210     0                   1                   2                   3
211     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
212    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
213    |                     Ident                     | F |VDT|# pkts.|
214    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
215 ]]></artwork>
216 </figure>
217
218 <t>
219 Ident: 24 bits</t>
220 <t>
221 This 24 bit field is used to associate the Vorbis data to a decoding
222 Configuration. It is stored as network byte order integer.
223 </t>
224
225 <t>
226 Fragment type (F): 2 bits</t>
227 <t>
228 This field is set according to the following list
229 </t>
230 <vspace blankLines="1" />
231 <list style="empty">
232 <t>      0 = Not Fragmented</t>
233 <t>      1 = Start Fragment</t>
234 <t>      2 = Continuation Fragment</t>
235 <t>      3 = End Fragment</t>
236 </list>
237
238 <t>
239 Vorbis Data Type (VDT): 2 bits</t>
240 <t>
241 This field specifies the kind of Vorbis data stored in this RTP packet. There
242 are currently three different types of Vorbis payloads. Each packet MUST contain only a single type of Vorbis packet (e.g. you must not aggregate configuration and comment packets in the same RTP payload)
243 </t>
244
245 <vspace blankLines="1" />
246 <list style="empty">
247 <t>      0 = Raw Vorbis payload</t>
248 <t>      1 = Vorbis Packed Configuration payload</t>
249 <t>      2 = Legacy Vorbis Comment payload</t>
250 <t>      3 = Reserved</t>
251 </list>
252
253 <t> The packets with a VDT of value 3 MUST be ignored </t>
254
255 <t>
256 The last 4 bits represent the number of complete packets in this payload. This
257 provides for a maximum number of 15 Vorbis packets in the payload. If the
258 payload contains fragmented data the number of packets MUST be set to 0.
259 </t>
260
261 </section>
262
263 <section anchor="Payload Data" title="Payload Data">
264
265 <t>
266 Raw Vorbis packets are currently unbounded in length, application profiles will
267 likely define a practical limit. Typical Vorbis packet sizes range from very
268 small (2-3 bytes) to quite large (8-12 kilobytes). The reference implementation
269 <xref target="libvorbis"></xref> typically produces packets less than ~800
270 bytes, except for the setup header packets which are ~4-12 kilobytes. Within an
271 RTP context, to avoid fragmentation, the Vorbis data packet size SHOULD be kept
272 sufficiently small so that after adding the RTP and payload headers, the
273 complete RTP packet is smaller than the path MTU.
274 </t>
275
276 <figure anchor="Payload Data Figure" title="Payload Data Header">
277 <artwork><![CDATA[
278     0                   1                   2                   3
279     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
280    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
281    |            length             |       vorbis packet data     ..
282    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
283 ]]></artwork>
284 </figure>
285
286 <t>
287 Each Vorbis payload packet starts with a two octet length header, which is used
288 to represent the size in bytes of the following data payload, followed by the
289 raw Vorbis data padded to the nearest byte boundary, as explained by the <xref target="vorbis-spec-ref">vorbis specification</xref>. The length value is stored
290 as network byte order integer.
291 </t>
292
293 <t>
294 For payloads which consist of multiple Vorbis packets the payload data consists
295 of the packet length followed by the packet data for each of the Vorbis packets
296 in the payload.
297 </t>
298
299 <t>
300 The Vorbis packet length header is the length of the Vorbis data block only and
301 does not include the length field.
302 </t>
303
304 <t>
305 The payload packing of the Vorbis data packets MUST follow the guidelines
306 set-out in <xref target="rfc3551"></xref> where the oldest Vorbis packet occurs
307 immediately after the RTP packet header. Subsequent Vorbis packets, if any, MUST
308 follow in temporal order.
309 </t>
310
311 <t>
312 Channel mapping of the audio is in accordance with the
313 <xref target="vorbis-spec-ref">Vorbis I Specification</xref>.
314 </t>
315
316 </section>
317
318 <section anchor="Example RTP Packet" title="Example RTP Packet">
319
320 <t>
321 Here is an example RTP payload containing two Vorbis packets.
322 </t>
323
324 <figure anchor="Example Raw Vorbis Packet" title="Example Raw Vorbis Packet">
325 <artwork><![CDATA[
326     0                   1                   2                   3
327     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
328    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
329    | 2 |0|0|  0    |0|      PT     |       sequence number         |
330    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
331    |               timestamp (in sample rate units)                |
332    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
333    |           synchronisation source (SSRC) identifier            |
334    +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
335    |            contributing source (CSRC) identifiers             |
336    |                              ...                              |
337    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
338    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
339    |                     Ident                     | 0 | 0 | 2 pks |
340    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
341    |            length             |          vorbis data         ..
342    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
343    ..                        vorbis data                           |
344    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
345    |            length             |   next vorbis packet data    ..
346    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
347    ..                        vorbis data                          ..
348    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
349    ..               vorbis data                    |
350    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
351 ]]></artwork>
352 </figure>
353
354 <t>
355 The payload data section of the RTP packet begins with the 24 bit Ident field
356 followed by the one octet bitfield header, which has the number of Vorbis
357 frames set to 2.  Each of the Vorbis data frames is prefixed by the two octets
358 length field. The Packet Type and Fragment Type are set to 0. The Configuration
359 that will be used to decode the packets is the one indexed by the ident value.
360 </t>
361
362 </section>
363 </section>
364
365
366
367 <section anchor="Configuration Headers" title="Configuration Headers">
368
369 <t>
370 Unlike other mainstream audio codecs Vorbis has no statically 
371 configured probability model. Instead, it packs all entropy decoding 
372 configuration, Vector Quantization and Huffman models into a data block
373 that must be transmitted to the decoder along with the compressed data.
374 A decoder also requires information detailing the number of audio 
375 channels, bitrates and similar information to configure itself for a 
376 particular compressed data stream. These two blocks of information are 
377 often referred to collectively as the "codebooks" for a Vorbis stream,
378 and are nominally included as special "header" packets at the start 
379 of the compressed data. In addition,
380 the <xref target="vorbis-spec-ref">Vorbis I specification</xref>
381 requires the presence of a comment header packet which gives simple
382 metadata about the stream, but this information is not required for 
383 decoding the frame sequence.
384 </t>
385
386 <t>
387 Thus these two codebook header packets must be received by the decoder before
388 any audio data can be interpreted. These requirements pose problems in RTP,
389 which is often used over unreliable transports.
390 </t>
391
392 <t>
393 Since this information must be transmitted reliably and, as the RTP 
394 stream may change certain configuration data mid-session, there are 
395 different methods for delivering this configuration data to a 
396 client, both in-band and out-of-band which is detailed below. SDP 
397 delivery is typically used to set up an initial state for the client 
398 application. The changes may be due to different codebooks as well as 
399 different bitrates of the RTP stream.
400 </t>
401
402 <!--
403 <t>
404 The delivery vectors in use can be specified by an SDP attribute to indicate the
405 method and the optional URI where the Vorbis
406 <xref target="Packed Configuration">Packed Configuration</xref> Packets could
407 be fetched.
408 -->
409 <t>For non chained streams, the recommended Configuration delivery
410 method is inline the <xref target="Packed Configuration">Packed Configuration</xref> in the SDP as explained in the <xref target="Mapping Media Type Parameters into SDP"> IANA considerations</xref>.
411 </t>
412
413 <t>
414 The 24 bit Ident field is used to map which Configuration will be used to
415 decode a packet. When the Ident field changes, it indicates that a change in
416 the stream has taken place. The client application MUST have in advance the
417 correct configuration and if the client detects a change in the Ident value and
418 does not have this information it MUST NOT decode the raw Vorbis data
419 associated until it fetches the correct Configuration.
420 </t>
421
422 <section anchor="In-band Header Transmission" title="In-band Header Transmission">
423
424 <t>
425 The <xref target="Packed Configuration">Packed Configuration</xref> Payload is
426 sent in-band with the packet type bits set to match the Vorbis Data Type.
427 Clients MUST be capable of dealing with fragmentation and periodic
428 <xref target="rfc4588">re-transmission of</xref> the configuration headers.
429 The RTP timestamp value MUST reflect the transmission time of the first data packet for which this configuration applies.
430 </t>
431
432 <section anchor="Packed Configuration" title="Packed Configuration">
433
434 <t>
435 A Vorbis Packed Configuration is indicated with the Vorbis Data Type field set
436 to 1. Of the three headers defined in the
437 <xref target="vorbis-spec-ref">Vorbis I specification</xref>, the
438 Identification and the Setup MUST be packed as they are, while the comment
439 header MAY be replaced with a dummy one.</t>
440 <t>
441 The packed configuration follows a generic way to store Xiph codec
442 configurations: The first field stores the number of the following packets
443 minus one (count field), the next ones represent the size of the headers
444 (length fields), the headers immediately follow the list of length fields.
445 The size of the last header is implicit.</t>
446 <t>
447 The count and the length fields are encoded using the following logic: the data
448 is in network byte order, every byte has the most significant bit used as flag
449 and the following 7 used to store the value.
450 The first N bit are to be taken, where N is number of bits needed to represent
451 the value, taken modulo 7, and stored in the first byte.
452 If there are more bits, the flag bit is set to 1 and the subsequent 7bit are
453 stored in the following byte, if there are remaining bits set the flag to 1 and
454 the same procedure is repeated.
455 The ending byte has the flag bit set to 0. In order to decode it is enough to
456 iterate over the bytes until the flag bit set to 0, for every byte the data is
457 added to the accumulated value multiplied by 128.</t>
458 <t>
459 The headers are packed in the same order they are present in ogg:
460 Identification, Comment, Setup.</t>
461
462 <t>
463 The 2 byte length tag defines the length of the packed headers as the sum of
464 the Configuration, Comment and Setup lengths.</t>
465
466 <figure anchor="Packed Configuration Figure" title="Packed Configuration Figure">
467 <artwork><![CDATA[
468     0                   1                   2                   3
469     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
470    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
471    |V=2|P|X|  CC   |M|     PT      |             xxxx              |
472    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
473    |                             xxxxx                             |
474    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
475    |           synchronization source (SSRC) identifier            |
476    +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
477    |            contributing source (CSRC) identifiers             |
478    |                              ...                              |
479    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
480    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
481    |                      Ident                    | 1 | 0 |      0|
482    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
483    |           length              | n. of headers |    length1    |
484    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
485    |    length2    |                  Identification              ..
486    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
487    ..                        Identification                       ..
488    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
489    ..                        Identification                       ..
490    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
491    ..                        Identification                       ..
492    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
493    ..               Identification                 |    Comment   ..
494    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
495    ..                            Comment                          ..
496    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
497    ..                            Comment                          ..
498    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
499    ..                            Comment                          ..
500    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
501    ..           Comment            |             Setup            ..
502    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
503    ..                            Setup                            ..
504    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
505    ..                            Setup                            ..
506    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
507 ]]></artwork>
508 </figure>
509
510 <t>The Ident field is set with the value that will be used by the Raw Payload
511 Packets to address this Configuration. The Fragment type is set to 0 since the
512 packet bears the full Packed configuration, the number of packet is set to 1.</t>
513 </section>
514 </section>
515
516 <section anchor="Out of Band Transmission" title="Out of Band Transmission">
517
518 <t>
519 The following packet definition MUST be used when Configuration is inlined
520 in the SDP.
521 </t>
522
523 <section anchor="Packed Headers" title="Packed Headers"> 
524
525 <t>
526 As mentioned above the RECOMMENDED delivery vector for Vorbis configuration
527 data is via a retrieval method that can be performed using a reliable transport
528 protocol. As the RTP headers are not required for this method of delivery the
529 structure of the configuration data is slightly different. The packed header
530 starts with a 32 bit (network byte ordered) count field which details the number of packed headers that are contained in the bundle. Next is the Packed header
531 payload for each chained Vorbis stream.
532 </t>
533
534 <figure anchor="Packed Headers Overview Figure" title="Packed Headers Overview">
535 <artwork><![CDATA[
536    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
537    |                     Number of packed headers                  |
538    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
539    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
540    |                          Packed header                        |
541    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
542    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
543    |                          Packed header                        |
544    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
545 ]]></artwork>
546 </figure>
547
548 <figure anchor="Packed Headers Detail Figure" title="Packed Headers Detail">
549 <artwork><![CDATA[
550     0                   1                   2                   3
551     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
552    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
553    |                   Ident                       |    length    ..
554    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
555    ..              | n. of headers |    length1    |    length2   ..
556    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
557    ..              |             Identification Header            ..
558    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
559    .................................................................
560    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
561    ..              |         Comment Header                       ..
562    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
563    .................................................................
564    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
565    ..                        Comment Header                        |
566    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
567    |                          Setup Header                        ..
568    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
569    .................................................................
570    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
571    ..                         Setup Header                         |
572    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
573 ]]></artwork>
574 </figure>
575 <t>
576 The key difference between the in-band format and this one, is that there is no
577 need for the payload header octet. In this figure the comment has a size bigger
578 than 127 bytes.
579 </t>
580 </section>
581
582 </section>
583
584 <section anchor="Loss of Configuration Headers" title="Loss of Configuration Headers">
585
586 <t>
587 Unlike the loss of raw Vorbis payload data, loss of a configuration header
588 lead to a situation where it will not be possible to successfully decode the
589 stream. Implementations MAY try to recover from error by requesting again the
590 missing Configuration or, if the delivery method is in-band, by buffering the
591 payloads waiting for the Configuration needed to decode them.
592 The baseline reaction SHOULD be either reset or end the RTP session.
593 </t>
594
595 </section>
596
597 </section>
598
599 <section anchor="Comment Headers" title="Comment Headers">
600
601 <t>
602 With the Vorbis Data Type flag set to 2, this indicates that the packet contain
603 the comment metadata, such as artist name, track title and so on. These
604 metadata messages are not intended to be fully descriptive but to offer basic
605 track/song information. Clients MAY ignore it completely. The details on the
606 format of the comments can be found in the <xref target="vorbis-spec-ref">Vorbis documentation</xref>.
607 </t>
608 <figure anchor="Comment Packet Figure" title="Comment Packet">
609 <artwork><![CDATA[
610     0                   1                   2                   3
611     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
612    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
613    |V=2|P|X|  CC   |M|     PT      |             xxxx              |
614    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
615    |                             xxxxx                             |
616    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
617    |           synchronization source (SSRC) identifier            |
618    +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
619    |            contributing source (CSRC) identifiers             |
620    |                              ...                              |
621    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
622    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
623    |                      Ident                    | 0 | 2 |      1|
624    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
625    |            length             |            Comment           ..
626    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
627    ..                           Comment                           ..
628    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
629    ..                           Comment                            |
630    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
631 ]]></artwork>
632 </figure>
633
634 <t>
635 The 2 bytes length field is necessary since this packet could be fragmented.
636 </t>
637
638 </section>
639 <section anchor="Frame Packetization" title="Frame Packetization">
640
641 <t>
642 Each RTP payload contains either one Vorbis packet fragment, or an integer
643 number of complete Vorbis packets (up to a maximum of 15 packets, since the
644 number of packets is defined by a 4 bit value).
645 </t>
646
647 <t>
648 Any Vorbis data packet that is less than path MTU SHOULD be bundled in the RTP
649 payload with as many Vorbis packets as will fit, up to a maximum of 15, except
650 when such bundling would exceed an application's desired transmission latency.
651 Path MTU is detailed in <xref target="rfc1191"></xref> and <xref target="rfc1981"></xref>.
652 </t>
653
654 <t>
655 A fragmented packet has a zero in the last four bits of the payload header.
656 The first fragment will set the Fragment type to 1. Each fragment after the
657 first will set the Fragment type to 2 in the payload header. The consecutive
658 fragments MUST be sent without any other payloads being sent between the first
659 and the last fragment. The RTP payload containing the last fragment of the
660 Vorbis packet will have the Fragment type set to 3. To maintain the correct
661 sequence for fragmented packet reception the timestamp field of fragmented
662 packets MUST be the same as the first packet sent, with the sequence number
663 incremented as normal for the subsequent RTP payloads, this will affect the
664 RTCP jitter measurement. The length field shows the fragment length.
665 </t>
666
667 <section anchor="Example Fragmented Vorbis Packet" title="Example Fragmented Vorbis Packet">
668
669 <t>
670 Here is an example fragmented Vorbis packet split over three RTP payloads.
671 Each of them contains the standard RTP headers as well as the 4 octets Vorbis
672 headers.
673 </t>
674
675 <figure anchor="Example Fragmented Packet (Packet 1)" title="Example Fragmented Packet (Packet 1)">
676 <artwork><![CDATA[
677    Packet 1:
678
679     0                   1                   2                   3
680     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
681    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
682    |V=2|P|X|  CC   |M|     PT      |           1000                |
683    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
684    |                            12345                              |
685    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
686    |           synchronization source (SSRC) identifier            |
687    +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
688    |            contributing source (CSRC) identifiers             |
689    |                              ...                              |
690    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
691    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
692    |                       Ident                   | 1 | 0 |      0|
693    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
694    |             length            |            vorbis data       ..
695    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
696    ..                        vorbis data                           |
697    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
698 ]]></artwork>
699 </figure>
700
701 <t>
702 In this payload the initial sequence number is 1000 and the timestamp is 12345.  The Fragment type is set to 1, the number of packets field is set to 0, and as
703 the payload is raw Vorbis data the VDT field is set to 0.
704 </t>
705
706 <figure anchor="Example Fragmented Packet (Packet 2)" title="Example Fragmented Packet (Packet 2)">
707 <artwork><![CDATA[
708    Packet 2:
709
710     0                   1                   2                   3
711     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
712    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
713    |V=2|P|X|  CC   |M|     PT      |           1001                |
714    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
715    |                             12345                             |
716    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
717    |           synchronization source (SSRC) identifier            |
718    +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
719    |            contributing source (CSRC) identifiers             |
720    |                              ...                              |
721    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
722    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
723    |                       Ident                   | 2 | 0 |      0|
724    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
725    |             length            |          vorbis data         ..
726    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
727    ..                        vorbis data                           |
728    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
729 ]]></artwork>
730 </figure>
731
732 <t>
733 The Fragment type field is set to 2 and the number of packets field is set to 0.
734 For large Vorbis fragments there can be several of this type of payloads.
735 The maximum packet size SHOULD be no greater than the path MTU,
736 including all RTP and payload headers. The sequence number has been incremented
737 by one but the timestamp field remains the same as the initial payload.
738 </t>
739
740 <figure anchor="Example Fragmented Packet (Packet 3)" title="Example Fragmented Packet (Packet 3)">
741 <artwork><![CDATA[
742    Packet 3:
743
744     0                   1                   2                   3
745     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
746    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
747    |V=2|P|X|  CC   |M|     PT      |           1002                |
748    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
749    |                             12345                             |
750    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
751    |           synchronization source (SSRC) identifier            |
752    +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
753    |            contributing source (CSRC) identifiers             |
754    |                              ...                              |
755    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
756    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
757    |                      Ident                    | 3 | 0 |      0|
758    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
759    |             length            |          vorbis data         ..
760    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
761    ..                        vorbis data                           |
762    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
763 ]]></artwork>
764 </figure>
765
766 <t>
767 This is the last Vorbis fragment payload.  The Fragment type is set to 3 and the
768 packet count remains set to 0. As in the previous payloads the timestamp remains
769 set to the first payload timestamp in the sequence and the sequence number has
770 been incremented.
771 </t>
772 </section>
773
774 <section anchor="Packet Loss" title="Packet Loss">
775
776 <t>
777 As there is no error correction within the Vorbis stream, packet loss will
778 result in a loss of signal. Packet loss is more of an issue for fragmented
779 Vorbis packets as the client will have to cope with the handling of the
780 Fragment Type. In case of loss of fragments the client MUST discard all the
781 remaining Vorbis fragments and decode the incomplete packet. If we use the
782 fragmented Vorbis packet example above and the first RTP payload is lost the
783 client MUST detect that the next RTP payload has the packet count field set
784 to 0 and the Fragment type 2 and MUST drop it.
785 The next RTP payload, which is the final fragmented packet, MUST be dropped
786 in the same manner.
787 If the missing RTP payload is the last, the received two fragments will be
788 kept and the incomplete Vorbis packet decoded.
789 </t>
790
791 <t>
792 Loss of any of the Configuration fragment will result in the loss of the full
793 Configuration packet with the result detailed in the <xref target="Loss of Configuration Headers">Loss of Configuration Headers</xref> section.
794 </t>
795
796 </section>
797 </section>
798 <section anchor="IANA Considerations" title="IANA Considerations"> 
799
800 <vspace blankLines="1" />
801 <list style="hanging">
802 <t hangText="Type name:"> audio </t>
803 <vspace blankLines="1" />
804
805 <t hangText="Subtype name:"> vorbis </t>
806 <vspace blankLines="1" />
807
808 <t hangText="Required parameters:">
809
810 <vspace blankLines="1" />
811
812 <list style="hanging">
813 <t hangText="rate:"> indicates the RTP timestamp clock rate as described in <xref target="rfc3551">RTP Profile for Audio and Video Conferences with Minimal Control.</xref>
814 </t>
815 <vspace blankLines="1" />
816
817 <t hangText="channels:"> indicates the number of audio channels as described in <xref target="rfc3551">RTP Profile for Audio and Video Conferences with Minimal Control.</xref>
818 </t>
819
820 <vspace blankLines="1" />
821
822 <t hangText="configuration:"> the <xref target="rfc3548">base64</xref> representation of the <xref target="Packed Headers">Packed Headers</xref>.
823 </t>
824 </list>
825 </t>
826
827 <vspace blankLines="1" />
828
829 <t hangText="Encoding considerations:">
830 <vspace blankLines="1" />
831 This media type is framed and contains binary data.
832 </t>
833
834 <vspace blankLines="1" />
835
836 <t hangText="Security considerations:">
837 <vspace blankLines="1" />
838 See Section 10 of RFC XXXX.</t>
839
840 <vspace blankLines="1" />
841 <t hangText="Interoperability considerations:">
842 <vspace blankLines="1" />
843 None</t>
844
845 <vspace blankLines="1" />
846 <t hangText="Published specification:">
847
848 <vspace blankLines="1" />
849 RFC XXXX [RFC Editor: please replace by the RFC number of  this memo, when published]
850 <vspace blankLines="1" />
851 Ogg Vorbis I specification: Codec setup and packet decode.  Available from the Xiph website, http://xiph.org
852 </t>
853
854 <vspace blankLines="1" />
855
856 <t hangText="Applications which use this media type:">
857 <vspace blankLines="1"/>
858 Audio streaming and conferencing tools </t>
859
860 <vspace blankLines="1" />
861
862 <t hangText="Additional information:">
863 <vspace blankLines="1" />
864 None </t>
865
866 <vspace blankLines="1" />
867
868 <t hangText="Person &amp; email address to contact for further information:">
869
870 <vspace blankLines="1" />
871
872 Luca Barbato: &lt;lu_zero@gentoo.org&gt;<br/>
873 IETF Audio/Video Transport Working Group
874
875 </t>
876
877 <vspace blankLines="1" />
878
879 <t hangText="Intended usage:">
880 <vspace blankLines="1" />
881 COMMON</t>
882
883 <vspace blankLines="1" />
884
885 <t hangText="Restriction on usage:">
886 <vspace blankLines="1" />
887 This media type depends on RTP framing, and hence is only defined for transfer via <xref target="rfc3550">RTP</xref></t>
888
889 <vspace blankLines="1" />
890
891 <t hangText="Author:">
892 <vspace blankLines="1"/>Luca Barbato</t>
893
894 <vspace blankLines="1" />
895
896 <t hangText="Change controller:">
897 <vspace blankLines="1"/>IETF AVT Working Group delegated from the IESG</t>
898
899 <vspace blankLines="1" />
900 </list>
901
902 <section anchor="Packed Headers IANA Considerations" title="Packed Headers IANA Considerations"> 
903
904 <t>
905 The following IANA considerations refers to the split configuration <xref target="Packed Headers">Packed Headers</xref> used within RFC XXXX.
906 </t>
907
908 <vspace blankLines="1" />
909
910 <list style="hanging">
911 <t hangText="Type name:"> audio </t>
912
913 <vspace blankLines="1" />
914
915 <t hangText="Subtype name:"> vorbis-config </t>
916
917 <vspace blankLines="1" />
918
919 <t hangText="Required parameters:">
920 <vspace blankLines="1" />
921 None
922 </t>
923
924 <vspace blankLines="1" />
925
926 <t hangText="Optional parameters:">
927 <vspace blankLines="1" />
928 None
929 </t>
930
931 <vspace blankLines="1" />
932
933 <t hangText="Encoding considerations:">
934 <vspace blankLines="1" />
935 This media type contains binary data.
936 </t>
937
938 <vspace blankLines="1" />
939
940 <t hangText="Security considerations:">
941 <vspace blankLines="1" />
942 See Section 10 of RFC XXXX.
943 </t>
944
945 <vspace blankLines="1" />
946
947 <t hangText="Interoperability considerations:">
948 <vspace blankLines="1" />
949 None
950 </t>
951
952 <vspace blankLines="1" />
953
954 <t hangText="Published specification:">
955 <vspace blankLines="1" />
956 RFC XXXX [RFC Editor: please replace by the RFC number of  this memo,
957        when published]
958 </t>
959
960 <vspace blankLines="1" />
961
962 <t hangText="Applications which use this media type:">
963 <vspace blankLines="1" />
964 Vorbis encoded audio, configuration data.
965 </t>
966
967 <vspace blankLines="1" />
968
969 <t hangText="Additional information:"> 
970 <vspace blankLines="1" />
971 None
972 </t>
973
974 <vspace blankLines="1" />
975
976 <t hangText="Person &amp; email address to contact for further information:">
977 <vspace blankLines="1" />
978 Luca Barbato: &lt;lu_zero@gentoo.org&gt;
979 <vspace blankLines="0" />
980 IETF Audio/Video Transport Working Group
981 </t>
982
983 <vspace blankLines="1" />
984
985 <t hangText="Intended usage:">
986 COMMON
987 </t>
988
989 <vspace blankLines="1" />
990
991 <t hangText="Restriction on usage:">
992 <vspace blankLines="1" />
993 This media type doesn't depend on the transport.
994 </t>
995
996 <vspace blankLines="1" />
997
998 <t hangText="Author:">
999 <vspace blankLines="1" />
1000 Luca Barbato</t>
1001
1002 <vspace blankLines="1" />
1003
1004 <t hangText="Change controller:">
1005 <vspace blankLines="1" />
1006 IETF AVT Working Group delegated from the IESG</t>
1007 </list>
1008
1009 </section>
1010
1011 </section>
1012
1013 <section anchor="SDP related considerations" title="SDP related considerations">
1014 <t>
1015 The following paragraphs define the mapping of the parameters described in the IANA considerations section and their usage in the <xref target="rfc3264">Offer/Answer Model</xref>. In order to be forward compatible the implementation MUST ignore unknown parameters.
1016 </t>
1017
1018 <section anchor="Mapping Media Type Parameters into SDP" title="Mapping Media Type Parameters into SDP"> 
1019
1020 <t>
1021 The information carried in the Media Type specification has a
1022 specific mapping to fields in the <xref target="rfc4566">Session Description
1023 Protocol (SDP)</xref>, which is commonly used to describe RTP sessions.
1024 When SDP is used to specify sessions the mapping are as follows:
1025 </t>
1026
1027 <vspace blankLines="1" />
1028 <list style="symbols">
1029
1030 <t>The type name ("audio") goes in SDP "m=" as the media name.</t>
1031 <vspace blankLines="1" />
1032
1033 <t>The subtype name ("vorbis") goes in SDP "a=rtpmap" as the encoding name.</t>
1034 <vspace blankLines="1" />
1035
1036 <t>The parameter "rate" also goes in "a=rtpmap" as clock rate.</t>
1037 <vspace blankLines="1" />
1038
1039 <t>The parameter "channels" also goes in "a=rtpmap" as channel count.</t>
1040 <vspace blankLines="1" />
1041
1042 <t>The mandated parameters "configuration" MUST be included in the SDP
1043 "a=fmtp" attribute.</t>
1044 <vspace blankLines="1" />
1045
1046 </list>
1047
1048 <t>
1049 If the stream comprises chained Vorbis files and all of them are known in
1050 advance, the Configuration Packet for each file SHOULD be passed to the client
1051 using the configuration attribute.
1052 </t>
1053
1054 <t>
1055 The port value is specified by the server application bound to the address
1056 specified in the c= line. The sample rate and channel count value specified
1057 in the rtpmap attribute SHOULD match the current Vorbis stream or considered
1058 the maximum number of channels to be expected and the least common multiple
1059 sample rate for the session. The Configuration payload delivers the exact
1060 information, thus the SDP information SHOULD be considered as a hint.
1061 An example is found below.
1062 </t>
1063
1064 <section anchor="SDP Example" title="SDP Example">
1065 <t>The following example shows a basic SDP single stream. The first
1066 configuration packet is inlined in the SDP, other configurations could be
1067 fetched at any time from the URIs provided. The inline
1068 <xref target="rfc3548">base64</xref> configuration string is folded in this
1069 example due to RFC line length limitations.</t>
1070
1071 <list style="empty">
1072 <t>c=IN IP4 192.0.2.1</t>
1073 <t>m=audio  RTP/AVP 98</t>
1074 <t>a=rtpmap:98 vorbis/44100/2</t>
1075 <t>a=fmtp:98 configuration=AAAAAZ2f4g9NAh4aAXZvcmJpcwA...;</t>
1076 </list>
1077 </section>
1078
1079 <t>
1080 Note that the payload format (encoding) names are commonly shown in upper case.
1081 Media Type subtypes are commonly shown in lower case. These names are
1082 case-insensitive in both places.  Similarly, parameter names are
1083 case-insensitive both in Media Type types and in the default mapping to the SDP
1084 a=fmtp attribute. The a=fmtp line is a single line even if it is shown as multiple lines in this document for clarity.
1085 </t>
1086
1087 </section>
1088
1089 <section anchor="Usage with the SDP Offer/Answer Mode" title="Usage with the SDP Offer/Answer Model">
1090
1091 <t>
1092 The are no negotiable parameters. All the of them are declarative.
1093 </t>
1094
1095 </section>
1096
1097 </section>
1098 <section anchor="Congestion Control" title="Congestion Control">
1099 <t>
1100    Vorbis clients SHOULD send regular receiver reports detailing
1101    congestion. A way to handle bandwidth changes MAY be redirect
1102    the client to a lower bitrate stream if one is available.
1103 </t>
1104 </section>
1105 <section anchor="Example" title="Example">
1106
1107 <t>
1108 The following example shows a common usage pattern that MAY be applied in
1109 such situation, the main scope of this section is to explain better usage
1110 of the transmission vectors.
1111 </t>
1112
1113 <section anchor="Stream Radio" title="Stream Radio">
1114
1115 <t>This is one of the most common situation: one single server streaming
1116 content in multicast, the clients may start a session at random time. The
1117 content itself could be a mix of live stream, as the webjockey's voice,
1118 and stored streams as the music she plays.</t>
1119
1120 <t>In this situation we don't know in advance how many codebooks we will use.
1121 The clients can join anytime and users expect to start listening to the content
1122 in a short time.</t>
1123
1124 <t>On join the client will receive the current Configuration necessary to
1125 decode the current stream inlined in the SDP so that the decoding will start
1126 immediately after.</t>
1127
1128 <t>When the streamed content changes the new Configuration is sent in-band
1129 before the actual stream and the Configuration that has to be sent inline in
1130 the SDP updated. Since the in-band method is unreliable, an out of band
1131 fallback is provided.</t>
1132
1133 <t>The client may choose to fetch the Configuration from the alternate source
1134 as soon as it discovers a Configuration packet got lost in-band or use
1135 <xref target="RFC3611">selective retransmission</xref>, if the server supports
1136 the feature.</t>
1137
1138 <t>A serverside optimization would be to keep an hash list of the
1139 Configurations per session to avoid packing all of them and send the same
1140 Configuration with different Ident tags</t>
1141
1142 <t>A clientside optimization would be to keep a tag list of the Configurations
1143 per session and don't process configuration packets already known.</t>
1144
1145 </section>
1146 </section>
1147
1148 <section anchor="Security Considerations" title="Security Considerations"> 
1149 <t>
1150 RTP packets using this payload format are subject to the security 
1151 considerations discussed in the 
1152 <xref target="rfc3550">RTP specification</xref>, the
1153 <xref target="rfc3548">base64 specification</xref> and the
1154 <xref target="rfc3986">URI Generic syntax specification</xref>.
1155 Among other considerations, this implies that the confidentiality of the
1156 media stream is archieved by using encryption. Because the data compression used
1157 with this payload format is applied end-to-end, encryption may be performed on
1158 the compressed data.
1159 </t>
1160
1161 </section> 
1162 <section title="Copying Conditions">
1163   <t>The authors agree to grant third parties the irrevocable right to copy,
1164   use and distribute the work, with or without modification, in any medium,
1165   without royalty, provided that, unless separate permission is granted,
1166   redistributed modified works do not contain misleading author, version,
1167   name of work, or endorsement information.</t>
1168 </section>
1169 <section anchor="Acknowledgments" title="Acknowledgments"> 
1170
1171 <t>
1172 This document is a continuation of draft-moffitt-vorbis-rtp-00.txt and
1173 draft-kerr-avt-vorbis-rtp-04.txt.  The Media Type declaration is a
1174 continuation of draft-short-avt-rtp-vorbis-mime-00.txt.
1175 </t>
1176
1177 <t>
1178 Thanks to the AVT, Vorbis Communities / Xiph.Org Foundation including Steve Casner,
1179 Aaron Colwell, Ross Finlayson, Fluendo, Ramon Garcia, Pascal Hennequin, Ralph
1180 Giles, Tor-Einar Jarnbjo, Colin Law, John Lazzaro, Jack Moffitt, Christopher
1181 Montgomery, Colin Perkins, Barry Short, Mike Smith, Phil Kerr, Michael Sparks,
1182 Magnus Westerlund, David Barrett, Silvia Pfeiffer, Stefan Ehmann, Alessandro
1183 Salvatori. Politecnico di Torino (LS)³/IMG Group in particular Federico
1184 Ridolfo, Francesco Varano, Giampaolo Mancini, Dario Gallucci, Juan Carlos De Martin.
1185 </t>
1186
1187 </section> 
1188
1189 </middle>
1190
1191 <back>
1192
1193 <references title="Normative References">
1194
1195 <reference anchor="rfc2119">
1196 <front>
1197 <title>Key words for use in RFCs to Indicate Requirement Levels </title>
1198 <author initials="S." surname="Bradner" fullname="Scott Bradner"></author>
1199 </front>
1200 <seriesInfo name="RFC" value="2119" />
1201 </reference>
1202
1203 <reference anchor="rfc3550">
1204 <front>
1205 <title>RTP: A Transport Protocol for real-time applications</title>
1206 <author initials="H." surname="Schulzrinne" fullname=""></author>
1207 <author initials="S." surname="Casner" fullname=""></author>
1208 <author initials="R." surname="Frederick" fullname=""></author>
1209 <author initials="V." surname="Jacobson" fullname=""></author>
1210 </front>
1211 <seriesInfo name="STD" value="64"/>
1212 <seriesInfo name="RFC" value="3550" />
1213 </reference> 
1214
1215 <reference anchor="rfc3551">
1216 <front>
1217 <title>RTP Profile for Audio and Video Conferences with Minimal Control.</title>
1218 <author initials="H." surname="Schulzrinne" fullname=""></author>
1219 <author initials="S." surname="Casner" fullname=""></author>
1220 </front>
1221 <date month="July" year="2003" />
1222 <seriesInfo name="STD" value="65"/>
1223 <seriesInfo name="RFC" value="3551" />
1224 </reference> 
1225
1226 <reference anchor="rfc3986">
1227 <front>
1228 <title abbrev="URI Generic Syntax">Uniform Resource Identifier (URI): Generic Syntax</title>
1229 <author initials="T." surname="Berners-Lee" fullname="Tim Berners-Lee">
1230 </author>
1231 <author initials="R." surname="Fielding" fullname="Roy T. Fielding">
1232 </author>
1233 <author initials="L." surname="Masinter" fullname="Larry Masinter">
1234 </author>
1235 </front>
1236 <date year="2005" month="January" />
1237 <seriesInfo name="STD" value="66"/>
1238 <seriesInfo name="RFC" value="3986" />
1239 </reference>
1240
1241 <reference anchor="rfc4566">
1242 <front>
1243 <title>SDP: Session Description Protocol</title>
1244 <author initials="M." surname="Handley" fullname="M. Handley">
1245 <organization /></author>
1246 <author initials="V." surname="Jacobson" fullname="V. Jacobson">
1247 <organization /></author>
1248 <author initials="C." surname="Perkins" fullname="C. Perkins">
1249 <organization /></author>
1250 <date year="2006" month="July" />
1251 </front>
1252 <seriesInfo name="RFC" value="4566" />
1253 <format type="TXT" octets="108820" target="ftp://ftp.isi.edu/in-notes/rfc4566.txt" />
1254 </reference>
1255
1256 <reference anchor="rfc1191">
1257 <front>
1258 <title>Path MTU discovery</title>
1259 <author initials="J." surname="Mogul" fullname="Jeffrey Mogul">
1260 <organization>Digital Equipment Corporation (DEC) , Western Research Laboratory</organization>
1261 <address>
1262 <email>mogul@decwrl.dec.com</email></address></author>
1263 <author initials="S." surname="Deering" fullname="Steve Deering">
1264 <organization>Xerox Palo Alto Research Center</organization>
1265 <address>
1266 <email>deering@xerox.com</email></address></author>
1267 <date year="1990" day="1" month="November" />
1268 </front>
1269 <seriesInfo name="RFC" value="1191" />
1270 <format type="TXT" octets="47936" target="ftp://ftp.isi.edu/in-notes/rfc1191.txt" />
1271 </reference>
1272
1273 <reference anchor="rfc1981">
1274 <front>
1275 <title>Path MTU Discovery for IP version 6</title>
1276 <author initials="J." surname="McCann et al." fullname="J. McCann et al."></author>
1277 </front>
1278 <seriesInfo name="RFC" value="1981" />
1279 </reference>   
1280
1281 <reference anchor="rfc3264">
1282 <front>
1283 <title>An Offer/Answer Model with Session Description Protocol (SDP)</title>
1284 <author initials="J." surname="Rosenberg" fullname="Jonathan Rosenberg"></author>
1285 <author initials="H." surname="Schulzrinne" fullname="Henning Schulzrinne"></author>
1286 </front>
1287 <seriesInfo name="RFC" value="3264" />
1288 </reference>
1289
1290 <reference anchor="rfc3548">
1291 <front>
1292 <title>The Base16, Base32, and Base64 Data Encodings</title>
1293 <author initials="S." surname="Josefsson" fullname="Simon Josefsson"></author>
1294 </front>
1295 <seriesInfo name="RFC" value="3548" />
1296 </reference>
1297
1298 <reference anchor="vorbis-spec-ref">
1299 <front>
1300 <title>Ogg Vorbis I specification:  Codec setup and packet decode.  Available from the Xiph website, http://xiph.org/vorbis/doc/Vorbis_I_spec.html</title>
1301 </front>
1302 </reference>
1303
1304 </references>
1305
1306 <references title="Informative References">
1307
1308 <reference anchor="rfc3533">
1309 <front>
1310 <title>The Ogg Encapsulation Format Version 0</title>
1311 <author initials="S." surname="Pfeiffer" fullname="Silvia Pfeiffer"></author>
1312 </front>
1313 <seriesInfo name="RFC" value="3533" />
1314 </reference>
1315
1316 <reference anchor="libvorbis">
1317 <front>
1318 <title>libvorbis: Available from the dedicated website, http://vorbis.com</title>
1319 </front>
1320 </reference>
1321
1322 <reference anchor="RFC3611">
1323 <front>
1324 <title>RTP Control Protocol Extended Reports (RTCP XR)</title>
1325 <author initials="T." surname="Friedman" fullname="T. Friedman" />
1326 <author initials="R." surname="Caceres" fullname="R. Caceres" />
1327 <author initials="A." surname="Clark" fullname="A. Clark" />
1328 <date year="2003" month="November"/>
1329 </front>
1330 <seriesInfo name="RFC" value="3611"/>
1331 </reference>
1332 <reference anchor="rfc4588">
1333 <front>
1334 <title>RTP Retransmission Payload Format</title>
1335 <author initials="J." surname="Rey" fullname="J. Rey">
1336 <organization /></author>
1337 <author initials="D." surname="Leon" fullname="D. Leon">
1338 <organization /></author>
1339 <author initials="A." surname="Miyazaki" fullname="A. Miyazaki">
1340 <organization /></author>
1341 <author initials="V." surname="Varsa" fullname="V. Varsa">
1342 <organization /></author>
1343 <author initials="R." surname="Hakenberg" fullname="R. Hakenberg">
1344 <organization /></author>
1345 <date year="2006" month="July" />
1346 </front>
1347 <seriesInfo name="RFC" value="4588" />
1348 <format type="TXT" octets="76630" target="ftp://ftp.isi.edu/in-notes/rfc4588.txt" />
1349 </reference>
1350 </references>
1351 </back>
1352 </rfc>