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