Some details on the MDCT, fixed a bunch of warnings
[opus.git] / doc / ietf / draft-valin-celt-rtp-profile.xml
1 <?xml version='1.0'?>
2 <!DOCTYPE rfc SYSTEM 'rfc2629.dtd'>
3 <?rfc toc="yes" ?>
4
5 <rfc ipr="full3667" docName="RTP Payload Format for the CELT Codec">
6
7 <front>
8 <title>draft-valin-celt-rtp-profile-01</title>
9
10
11
12 <author initials="J-M" surname="Valin" fullname="Jean-Marc Valin">
13 <organization>Octasic Semiconductor</organization>
14 <address>
15 <email>jean-marc.valin@octasic.com</email>
16 <postal>
17 <street>4101, Molson Street, suite 300</street>
18 <city>Montreal</city>
19 <region>Quebec</region>
20 <code>H1Y 3L1</code>
21 <country>Canada</country>
22 </postal>
23 </address>
24 </author>
25
26 <author initials="et" surname="al." fullname="et al.">
27 <organization></organization>
28 </author>
29
30 <date day="20" month="November" year="2008" />
31
32 <area>General</area>
33 <workgroup>AVT Working Group</workgroup>
34 <keyword>I-D</keyword>
35
36 <keyword>Internet-Draft</keyword>
37 <keyword>CELT</keyword>
38 <keyword>RTP</keyword>
39 <abstract>
40 <t>
41 CELT is an open-source voice codec suitable for use in very low delay 
42 Voice over IP (VoIP) type applications.  This document describes the payload
43 format for CELT generated bit streams within an RTP packet.  Also
44 included here are the necessary details for the use of CELT with
45 the Session Description Protocol (SDP). At the time of this writing, the CELT
46 bit-stream has NOT been finalized yet, and compatibility is usually broken with
47 every new release of the codec.
48 </t>
49 </abstract>
50 </front>
51
52 <middle>
53
54 <section anchor="Conventions used in this document" title="Conventions used in this document">
55 <t>
56 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
57 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
58 document are to be interpreted as described in RFC 2119 <xref target="rfc2119"></xref>.
59 </t>
60 </section>
61
62 <section anchor="Overview of the CELT Codec" title="Overview of the CELT Codec">
63
64 <t>
65 CELT stands for "Constrained Energy Lapped Transform". It applies some of the CELP principles, but does everything in the frequency domain, which removes some of the limitations of CELP. CELT is suitable for both speech and music and currently features:
66 </t>
67
68 <t>
69 <list style="symbols">
70 <t>Ultra-low latency (typically from 3 to 9 ms)</t>
71 <t>Full audio bandwidth (44.1 kHz and 48 kHz)</t>
72 <t>Support for both voice and music</t>
73 <t>Stereo support</t>
74 <t>Packet loss concealment</t>
75 <t>Constant bit-rates from 32 kbps to 128 kbps and above</t>
76 <t>Free software/open-source</t>
77 </list>
78 </t>
79
80 </section>
81
82 <section anchor="RTP payload format for CELT" title="RTP payload format for CELT">
83
84 <t>
85 For RTP based transportation of CELT encoded audio the standard 
86 RTP header [2] is followed by one or more payload data blocks. 
87 An optional padding terminator may also be used. 
88 </t>
89 <artwork><![CDATA[
90       0                   1                   2                   3
91       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
92      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
93      |                         RTP Header                            |
94      +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
95      |                 one or more frames of CELT ....              |
96      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
97      |        one or more frames of CELT ....                       |
98      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
99 ]]></artwork>
100
101 </section>
102
103 <section anchor="RTP Header" title="RTP Header">
104
105 <artwork><![CDATA[
106       0                   1                   2                   3
107       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
108      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
109      |V=2|P|X|  CC   |M|     PT      |       sequence number         |
110      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
111      |                           timestamp                           |
112      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
113      |           synchronization source (SSRC) identifier            |
114      +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
115      |            contributing source (CSRC) identifiers             |
116      |                              ...                              |
117      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
118 ]]></artwork>
119
120 <t>
121 The RTP header begins with an octet of fields (V, P, X, and CC) to   
122 support specialized RTP uses (see <xref target="rfc3550"></xref> and <xref target="rfc3551"></xref> for details). For 
123 CELT the following values are used.
124 </t>
125
126 <t>Version (V): 2 bits</t><t>
127    This field identifies the version of RTP. The version
128    used by this specification is two <xref target="rfc3550"></xref>.
129 </t>
130
131 <t>Padding (P): 1 bit</t><t>
132       If the padding bit is set, the packet contains one or more
133       additional padding octets at the end which are not part of the
134       payload.  The last octet of the padding contains a count of how
135       many padding octets should be ignored, including itself.  Padding
136       may be needed by some encryption algorithms with fixed block sizes
137       or for carrying several RTP packets in a lower-layer protocol data
138       unit.
139 </t>
140
141 <t>Extension (X): 1 bit</t><t>
142       If the extension, X, bit is set, the fixed header MUST be 
143       followed by exactly one header extension, with a format defined 
144       in Section 5.3.1. of <xref target="rfc3550"></xref>. 
145 </t>
146
147 <t>CSRC count (CC): 4 bits</t><t>
148       The CSRC count contains the number of CSRC identifiers.
149 </t>
150
151 <t>Marker (M): 1 bit</t><t>
152       The M bit MUST be set to zero in all packets. The receiver MUST
153           ignore the M bit.
154 </t>
155
156 <t>Payload Type (PT): 7 bits</t><t>
157       An RTP profile for a class of applications is expected to assign 
158       a payload type for this format, or a dynamically allocated 
159       payload type SHOULD be chosen which designates the payload as 
160       CELT.
161 </t>
162
163 <t>Sequence number: 16 bits</t><t>
164       The sequence number increments by one for each RTP data packet
165       sent, and may be used by the receiver to detect packet loss and
166       to restore packet sequence.  This field is detailed further in
167       <xref target="rfc3550"></xref>.
168 </t>
169
170 <t>Timestamp: 32 bits</t><t>
171       A timestamp representing the sampling time of the first sample of
172       the first CELT frame in the RTP packet.  The clock frequency
173       MUST be set to the sample rate of the encoded audio data.
174
175       CELT can use different frame sizes and a variable sampling rate clock.
176       The RTP timestamp MUST be in units of 1/X of a second where X 
177       is the sample rate used.
178 </t>
179
180 <t>SSRC/CSRC identifiers:</t><t>
181       These two fields, 32 bits each with one SSRC field and a maximum 
182       of 16 CSRC fields, are as defined in <xref target="rfc3550"></xref>.  
183 </t>
184
185 </section>
186
187 <section anchor="CELT payload" title="CELT payload">
188
189 <t>
190 For the purposes of packetizing the bit stream in RTP, it is only
191 necessary to consider the sequence of bits as output by the CELT
192 encoder <xref target="celt-website"></xref>, and present the same sequence to the decoder.  The 
193 payload format described here maintains this sequence.
194 </t>
195
196 <t>
197 A typical CELT frame, encoded at a high bitrate, is approx.
198 128 octets and the total number of CELT frames SHOULD be kept 
199 less than the path MTU to prevent fragmentation.  CELT frames MUST
200 NOT be fragmented across multiple RTP packets,
201 </t>
202
203 <t>
204 An RTP packet MAY contain CELT frames of the same bit rate or of
205 varying bit rates, since the bit-rate for a frame is implicitly 
206 conveyed in band with the signal.
207 </t>
208
209 <t>
210 The encoding and decoding algorithm can change the bit rate at any
211 frame boundary, with the bit rate change notification provided
212 implicitly from the compressed frame size. No out-of-band 
213 notification is required for the decoder to process changes in the 
214 bit rate sent by the encoder.
215 </t>
216
217 <t>
218 It is RECOMMENDED that values of 32000, 44100 and 48000 be used 
219 for most applications, unless a specific reason exists -- such as
220 requirements for a very specific packetization time. For example,
221 51200 Hz sampling may be useful to obtain a 5ms packetization time
222 with 256-sample frames.
223 </t>
224
225 <t>
226 The CELT codec always produces an integer number of bytes, so
227 no padding is ever required.
228 </t>
229
230 </section>
231
232 <section anchor="Example CELT packet" title="Example CELT packet">
233
234 <t>
235 In the example below we have a single CELT frame in the RTP packet.
236 </t>
237
238 <artwork><![CDATA[
239     0                   1                   2                   3
240     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
241    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
242    |V=2|P|X|  CC   |M|     PT      |       sequence number         |
243    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
244    |                           timestamp                           |
245    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
246    |         synchronization source (SSRC) identifier              |
247    +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
248
249     0                   1                   2                   3
250     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
251    +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
252    |         contributing source (CSRC) identifiers                |
253    |                              ...                              |
254    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
255    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
256    |                         ..celt data..                         |
257    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
258    |                         ..celt data..                         |
259    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
260 ]]></artwork>
261
262 </section>
263
264 <section anchor="Multiple CELT frames in a RTP packet" title="Multiple CELT frames in a RTP packet">
265
266 <t>
267 The bit-rate used by CELT is implicitly determined by the size of the
268 compressed data. When more than one frame is encoded in the same packet,
269 it is not possible to determine the size of each encoded frame, so the
270 information must be explicitly encoded. If N frames are present in a
271 packet, N-1 values compressed frame sizes need to be encoded at the 
272 beginning of the packet. Each size that is less than 255 bytes is encoded
273 in one byte. For sizes greater or equal to 255, a 0xff byte is encoded, 
274 followed by the size-255. Multiple 0xff bytes are allowed if there are
275 more than 510 bytes transmitted. A size of zero indicates silence for the
276 current frame.
277 </t>
278 <t>
279 Below is an example of two CELT frames contained within one RTP 
280 packet.
281 </t>
282
283
284 <artwork><![CDATA[
285     0                   1                   2                   3
286     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
287    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
288    |V=2|P|X|  CC   |M|     PT      |       sequence number         |
289    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
290    |                           timestamp                           |
291    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
292    |         synchronization source (SSRC) identifier              |
293    +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
294    |         contributing source (CSRC) identifiers                |
295    |                              ...                              |
296    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
297    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
298    |    length     |        ..celt data..                          |
299    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
300    |         ..celt data..         |         ..celt data..         |
301    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
302    |                        ..celt data..                          |
303    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
304 ]]></artwork>
305
306 </section>
307
308 <section anchor="MIME registration of CELT" title="MIME registration of CELT">
309
310 <t>
311 Full definition of the MIME <xref target="rfc2045"></xref> type for CELT will be part of the Ogg
312 Vorbis MIME type definition application <xref target="rfc3534"></xref>.
313 </t>
314
315 <t>MIME media type name: audio</t>
316
317 <t>MIME subtype: celt</t>
318
319 <t>Optional parameters:</t>
320
321 <t>Required parameters: to be included in the Ogg MIME specification.</t>
322
323 <t>Encoding considerations:</t>
324
325 <t>Security Considerations:</t>
326 <t>See Section 6 of RFC 3047.</t>
327
328 <t>Interoperability considerations: none</t>
329
330 <t>Published specification:  </t>
331
332 <t>Applications which use this media type:</t>
333
334 <t>Additional information: none</t>
335
336 <t>Person &amp; email address to contact for further information:<vspace blankLines="1" />
337 <list style="empty">
338 <t>Jean-Marc Valin &lt;jean-marc.valin@octasic.com&gt;</t>
339 </list>
340 </t>
341
342 <t>Intended usage: COMMON</t>
343
344 <t>Author/Change controller:</t>
345
346 <t>
347 <list style="empty">
348 <t>Author:  Jean-Marc Valin &lt;jean-marc.valin@octasic.com&gt;</t>
349 <t>Change controller: Jean-Marc Valin &lt;jean-marc.valin@octasic.com&gt;</t>          
350 <t>Change controller: IETF AVT Working Group</t>
351 </list>
352 </t>
353
354 <t>
355 This transport type signifies that the content is to be interpreted
356 according to this document if the contents are transmitted over RTP. 
357 Should this transport type appear over a lossless streaming protocol
358 such as TCP, the content encapsulation should be interpreted as an 
359 Ogg Stream in accordance with <xref target="rfc3534"></xref>, with the exception that the
360 content of the Ogg Stream may be assumed to be CELT audio and 
361 CELT audio only.
362 </t>
363
364 </section>
365
366 <section anchor="SDP usage of CELT" title="SDP usage of CELT">
367
368 <t>
369 When conveying information by SDP <xref target="rfc2327"></xref>, the encoding name MUST be
370 set to "CELT".  An example of the media representation in SDP for
371 offering a single channel of CELT at 48000 samples per second might
372 be:
373 </t>
374
375 <vspace blankLines="1" />
376 <list style="empty">
377 <t>m=audio 8088 RTP/AVP 97</t>
378 <t>a=rtpmap:97 CELT/48000</t>
379 </list> 
380
381 <t>
382 Note that the RTP payload type code of 97 is defined in this media
383 definition to be 'mapped' to the CELT codec at a 48kHz sampling
384 frequency using the 'a=rtpmap' line.  Any number from 96 to 127
385 could have been chosen (the allowed range for dynamic types).  
386 </t>
387
388 <t>
389 The value of the sampling frequency is typically between 32000 and 48000 Hz.
390 </t>
391
392 <t>
393 If for some reason the offerer has bandwidth limitations, the client 
394 may use the "b=" header, as explained in SDP <xref target="rfc2327"></xref>. The following example
395 illustrates the case where the offerer cannot receive more than
396 10 kbit/s.
397 </t>
398
399 <vspace blankLines="1" />
400 <list style="empty">
401 <t>m=audio 8088 RTP/AVP 97</t>
402 <t>b=AS:64</t>
403 <t>a=rtmap:97 CELT/48000</t>
404 </list> 
405
406 <t>
407 In this case, if the remote part agrees, it should configure its
408 CELT encoder so that it does not use modes that produce more than
409 64 kbit/s. Note that the "b=" constraint also applies on all
410 payload types that may be proposed in the media line ("m=").
411 </t>
412
413 <t>
414 An other way to make recommendations to the remote CELT encoder
415 is to use its specific parameters via the a=fmtp: directive.  The
416 following parameters are defined for use in this way:
417 </t>
418
419 <vspace blankLines="1" />
420 <list style="empty">
421 <t>frame-size: duration of each frame in samples (default is 256).<vspace blankLines="1" /></t>
422
423 <t>nb-frames: number of frames per packet (default is 1).<vspace blankLines="1" /></t>
424
425 <t>vbr:   variable bit rate  - either 'on' 'off' or 'vad'
426                 (defaults to off).  If on, variable bit rate is
427                 enabled.  If off, disabled.<vspace blankLines="1" /></t>
428 </list> 
429
430 <t>Examples:</t>
431
432 <vspace blankLines="1" />
433 <list style="empty">
434         <t>m=audio 8008 RTP/AVP 97</t>
435         <t>a=rtpmap:97 CELT/44100</t>
436         <t>a=fmtp:97 frame-size=512;nb-frames=2</t>
437 </list> 
438
439 <t>
440 This examples illustrate an offerer that wishes to receive
441 a CELT stream at 44100 Hz, by packing two 512-sample frames in each packet.
442 </t>
443
444 <t>
445 Several CELT specific parameters can be given in a single
446 a=fmtp line provided that they are separated by a semi-colon.
447 </t>
448
449 <t>
450 Care must be taken when setting the value of fsize and nframes so that the 
451 RTP packet size does not exceed the path MTU. 
452 </t>
453
454 </section>
455
456 <section anchor="Issues that need to be addressed" title="Issues that need to be addressed">
457
458 <t>
459 Do we allow "custom modes" where the entire mode data could be transmitted in
460 an initialization packet?
461 </t>
462
463 <t>
464 How do we minimize the possibility of encoder-decoder mode mismatch
465 </t>
466
467 <t>
468 Do we support more than 2 channels (and how)?
469 </t>
470
471 <t>
472 Support for redundant data (how)?
473 </t>
474
475 <t>
476 Should we force all frames in a packet to have the same bit-rate? That would remove the need to signal it.
477 </t>
478
479 </section>
480
481 <section anchor="RTP Payload Types" title="RTP Payload Types">
482
483 <t>
484 Dynamic payload type codes MUST be negotiated 'out-of-band'
485 for the assignment of a dynamic payload type from the
486 range of 96-127.
487 </t>
488
489 </section>
490
491 <section anchor="Security Considerations" title="Security Considerations">
492
493 <t>
494 RTP packets using the payload format defined in this specification
495 are subject to the security considerations discussed in the RTP
496 specification <xref target="rfc3550"></xref>, and any appropriate RTP profile.  This implies
497 that confidentiality of the media streams is achieved by encryption.
498 Because the data compression used with this payload format is applied
499 end-to-end, encryption may be performed after compression so there is
500 no conflict between the two operations.
501 </t>
502
503 <t>
504 A potential denial-of-service threat exists for data encodings using
505 compression techniques that have non-uniform receiver-end
506 computational load.  The attacker can inject pathological datagrams
507 into the stream which are complex to decode and cause the receiver to
508 be overloaded.  However, this encoding does not exhibit any
509 significant non-uniformity.
510 </t>
511
512 <t>
513 As with any IP-based protocol, in some circumstances a receiver may
514 be overloaded simply by the receipt of too many packets, either
515 desired or undesired.  Network-layer authentication may be used to
516 discard packets from undesired sources, but the processing cost of
517 the authentication itself may be too high.
518 </t>
519
520 </section> 
521
522 <section anchor="Acknowledgments" title="Acknowledgments">
523
524 <t>
525 The authors would also like to thank the following members of the 
526 CELT and AVT communities for their input:
527 </t>
528 </section> 
529
530 </middle>
531
532 <back>
533
534 <references title="Normative References">
535
536 <reference anchor="rfc2119">
537 <front>
538 <title>Key words for use in RFCs to Indicate Requirement Levels </title>
539 <author initials="S." surname="Bradner" fullname="Scott Bradner"></author>
540 </front>
541 <seriesInfo name="RFC" value="2119" />
542 </reference> 
543
544 <reference anchor="rfc3550">
545 <front>
546 <title>RTP: A Transport Protocol for real-time applications</title>
547 <author initials="H." surname="Schulzrinne" fullname=""></author>
548 <author initials="S." surname="Casner" fullname=""></author>
549 <author initials="R." surname="Frederick" fullname=""></author>
550 <author initials="V." surname="Jacobson" fullname=""></author>
551 </front>
552 <seriesInfo name="RFC" value="3550" />
553 </reference> 
554
555 <reference anchor="rfc2045">
556 <front>
557 <title>Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies</title>
558 <author initials="" surname="" fullname=""></author>
559 </front>
560 <date month="November" year="1998" />
561 <seriesInfo name="RFC" value="2045" />
562 </reference> 
563
564 <reference anchor="rfc2327">
565 <front>
566 <title>SDP: Session Description Protocol</title>
567 <author initials="V." surname="Jacobson" fullname=""></author>
568 <author initials="M." surname="Handley" fullname=""></author>
569 </front>
570 <date month="April" year="1998" />
571 <seriesInfo name="RFC" value="2327" />
572 </reference> 
573
574 <reference anchor="H323">
575 <front>
576 <title>Packet-based Multimedia Communications Systems</title>
577 <author initials="" surname="" fullname=""></author>
578 </front>
579 <date month="" year="1998" />
580 <seriesInfo name="ITU-T Recommendation" value="H.323" />
581 </reference> 
582
583 <reference anchor="H245">
584 <front>
585 <title>Control of communications between Visual Telephone Systems and Terminal Equipment</title>
586 <author initials="" surname="" fullname=""></author>
587 </front>
588 <date month="" year="1998" />
589 <seriesInfo name="ITU-T Recommendation" value="H.245" />
590 </reference> 
591
592 <reference anchor="rfc3551">
593 <front>
594 <title>RTP Profile for Audio and Video Conferences with Minimal Control.</title>
595 <author initials="H." surname="Schulzrinne" fullname=""></author>
596 <author initials="S." surname="Casner" fullname=""></author>
597 </front>
598 <date month="July" year="2003" />
599 <seriesInfo name="RFC" value="3551" />
600 </reference> 
601
602 <reference anchor="rfc3534">
603 <front>
604 <title>The application/ogg Media Type</title>
605 <author initials="L." surname="Walleij" fullname=""></author>
606 </front>
607 <date month="May" year="2003" />
608 <seriesInfo name="RFC" value="3534" />
609 </reference> 
610
611 </references> 
612
613 <references title="Informative References">
614
615 <reference anchor="celt-website">
616 <front>
617 <title>The CELT ultra-low delay audio codec</title>
618 </front>
619 <seriesInfo name="CELT website" value="http://www.celt-codec.org/" />
620 </reference> 
621
622
623 </references> 
624
625 </back>
626 </rfc>