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