Version -01 of the RTP draft
[opus.git] / doc / ietf / draft-valin-celt-rtp-profile-01.txt
1
2
3
4 AVT Working Group                                             J-M. Valin
5 Internet-Draft                                     Octasic Semiconductor
6 Expires: November 12, 2009                                    G. Maxwell
7                                                         Juniper Networks
8                                                             May 11, 2009
9
10
11                     draft-valin-celt-rtp-profile-01
12                  RTP Payload Format for the CELT Codec
13
14 Status of this Memo
15
16    This Internet-Draft is submitted to IETF in full conformance with the
17    provisions of BCP 78 and BCP 79.
18
19    Internet-Drafts are working documents of the Internet Engineering
20    Task Force (IETF), its areas, and its working groups.  Note that
21    other groups may also distribute working documents as Internet-
22    Drafts.
23
24    Internet-Drafts are draft documents valid for a maximum of six months
25    and may be updated, replaced, or obsoleted by other documents at any
26    time.  It is inappropriate to use Internet-Drafts as reference
27    material or to cite them other than as "work in progress."
28
29    The list of current Internet-Drafts can be accessed at
30    http://www.ietf.org/ietf/1id-abstracts.txt.
31
32    The list of Internet-Draft Shadow Directories can be accessed at
33    http://www.ietf.org/shadow.html.
34
35    This Internet-Draft will expire on November 12, 2009.
36
37 Copyright Notice
38
39    Copyright (c) 2009 IETF Trust and the persons identified as the
40    document authors.  All rights reserved.
41
42    This document is subject to BCP 78 and the IETF Trust's Legal
43    Provisions Relating to IETF Documents in effect on the date of
44    publication of this document (http://trustee.ietf.org/license-info).
45    Please review these documents carefully, as they describe your rights
46    and restrictions with respect to this document.
47
48
49
50
51
52
53
54
55 Valin & Maxwell         Expires November 12, 2009               [Page 1]
56 \f
57 Internet-Draft       draft-valin-celt-rtp-profile-01            May 2009
58
59
60 Abstract
61
62    CELT is an open-source voice codec suitable for use in very low delay
63    audio communication applications, including Voice over IP (VoIP).
64    This document describes the payload format for CELT generated bit
65    streams within an RTP packet.  Also included here are the necessary
66    details for the use of CELT with the Session Description Protocol
67    (SDP).  At the time of this writing, the CELT bit-stream has NOT been
68    finalized yet, and compatibility is usually broken with every new
69    release of the codec.
70
71
72 Table of Contents
73
74    1.  Conventions used in this document  . . . . . . . . . . . . . .  3
75    2.  Overview of the CELT Codec . . . . . . . . . . . . . . . . . .  4
76    3.  RTP payload format for CELT  . . . . . . . . . . . . . . . . .  5
77      3.1.  RTP Header . . . . . . . . . . . . . . . . . . . . . . . .  5
78      3.2.  CELT payload . . . . . . . . . . . . . . . . . . . . . . .  6
79      3.3.  Multiple CELT frames in a RTP packet . . . . . . . . . . .  7
80      3.4.  Multiple channels  . . . . . . . . . . . . . . . . . . . .  8
81    4.  MIME registration of CELT  . . . . . . . . . . . . . . . . . . 10
82    5.  SDP usage of CELT  . . . . . . . . . . . . . . . . . . . . . . 12
83      5.1.  Multichannel Mapping . . . . . . . . . . . . . . . . . . . 13
84      5.2.  Low-Overhead Mode  . . . . . . . . . . . . . . . . . . . . 15
85    6.  Congestion Control . . . . . . . . . . . . . . . . . . . . . . 16
86    7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 17
87    8.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 18
88    9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
89      9.1.  Normative References . . . . . . . . . . . . . . . . . . . 19
90      9.2.  Informative References . . . . . . . . . . . . . . . . . . 19
91    Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111 Valin & Maxwell         Expires November 12, 2009               [Page 2]
112 \f
113 Internet-Draft       draft-valin-celt-rtp-profile-01            May 2009
114
115
116 1.  Conventions used in this document
117
118    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
119    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
120    document are to be interpreted as described in RFC 2119 [rfc2119].
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167 Valin & Maxwell         Expires November 12, 2009               [Page 3]
168 \f
169 Internet-Draft       draft-valin-celt-rtp-profile-01            May 2009
170
171
172 2.  Overview of the CELT Codec
173
174    CELT stands for "Constrained Energy Lapped Transform".  It applies
175    some of the CELP principles, but does everything in the frequency
176    domain, which removes some of the limitations of CELP.  CELT is
177    suitable for both speech and music and currently features:
178
179    o  Ultra-low algorithmic delay (as low as 2 ms)
180
181    o  Full audio bandwidth (up to 20 kHz audio bandwidth)
182
183    o  Support for both voice and music
184
185    o  Stereo support
186
187    o  Packet loss concealment
188
189    o  Constant bitrates from under 32 kbps to 128 kbps and above
190
191    o  Free software/open-source
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223 Valin & Maxwell         Expires November 12, 2009               [Page 4]
224 \f
225 Internet-Draft       draft-valin-celt-rtp-profile-01            May 2009
226
227
228 3.  RTP payload format for CELT
229
230    For RTP based transportation of CELT encoded audio the standard RTP
231    header [rfc3550] is followed by one or more payload data blocks.  An
232    optional padding terminator may also be used.
233
234
235         0                   1                   2                   3
236         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
237        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
238        |                         RTP Header                            |
239        +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
240        |                   one or more frames of CELT ....             |
241        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
242        |                              ....                             |
243        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
244
245 3.1.  RTP Header
246
247
248         0                   1                   2                   3
249         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
250        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
251        |V=2|P|X|  CC   |M|     PT      |       sequence number         |
252        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
253        |                           timestamp                           |
254        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
255        |           synchronization source (SSRC) identifier            |
256        +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
257        |            contributing source (CSRC) identifiers             |
258        |                              ...                              |
259        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
260
261    The RTP header is defined in the RTP specification [rfc3550].  This
262    section defines how fields in the RTP header are used.
263
264    Padding (P): 1 bit
265
266    If the padding bit is set, the packet contains one or more additional
267    padding octets at the end which are not part of the payload.  The
268    last octet of the padding contains a count of how many padding octets
269    should be ignored, including itself.  Padding may be needed by some
270    encryption algorithms with fixed block sizes or for carrying several
271    RTP packets in a lower-layer protocol data unit.
272
273    Extension (X): 1 bit
274
275    If the extension, X, bit is set, the fixed header MUST be followed by
276
277
278
279 Valin & Maxwell         Expires November 12, 2009               [Page 5]
280 \f
281 Internet-Draft       draft-valin-celt-rtp-profile-01            May 2009
282
283
284    exactly one header extension, with a format defined in Section 5.3.1.
285    of [rfc3550].
286
287    Marker (M): 1 bit
288
289    The M bit MUST be set to zero in all packets.  The receiver MUST
290    ignore the M bit.
291
292    Payload Type (PT): 7 bits
293
294    Payload Type (PT): The assignment of an RTP payload type for this
295    packet format is outside the scope of this document; it is specified
296    by the RTP profile under which this payload format is used, or
297    signaled dynamically out-of-band (e.g., using SDP).
298
299    Timestamp: 32 bits
300
301    A timestamp representing the sampling time of the first sample of the
302    first CELT frame in the RTP payload.  The clock frequency MUST be set
303    to the sample rate of the encoded audio data and is conveyed out-of-
304    band (e.g., as an SDP parameter).
305
306 3.2.  CELT payload
307
308    For the purposes of packetizing the bit stream in RTP, it is only
309    necessary to consider the sequence of bits as output by the CELT
310    encoder [celt-website], and present the same sequence to the decoder.
311    The payload format described here maintains this sequence.
312
313    A typical CELT frame, encoded at a high bitrate, is approx. 128
314    octets and the total size of the CELT frames SHOULD be kept below the
315    path MTU to prevent fragmentation.  CELT frames MUST NOT be split
316    across multiple RTP packets,
317
318    An RTP packet MAY contain CELT frames of the same bit rate or of
319    varying bit rates, since the bitrate for the frames is explicitly
320    conveyed in band with the signal.  The encoding and decoding
321    algorithm can change the bit rate at any frame boundary, with the bit
322    rate change notification provided in-band.  No out-of-band
323    notification is required for the decoder to process changes in the
324    bit rate sent by the encoder.
325
326    It is RECOMMENDED that sampling rates 32000, 44100, or 48000 Hz be
327    used for most applications, unless a specific reason exists -- such
328    as requirements for a very specific packetization time.  For example,
329    51200 Hz sampling may be useful to obtain a 5 ms packetization time
330    with 256-sample frames.  For compatibility reasons, the sender and
331    receiver MUST support 48000 Hz sampling rate.
332
333
334
335 Valin & Maxwell         Expires November 12, 2009               [Page 6]
336 \f
337 Internet-Draft       draft-valin-celt-rtp-profile-01            May 2009
338
339
340    The CELT codec always produces an integer number of bytes and can
341    produce any integer number of bytes, so no padding is ever required.
342    Bitrate adjustment SHOULD be used instead of padding.
343
344 3.3.  Multiple CELT frames in a RTP packet
345
346    The bitrate used by CELT is implicitly determined by the size of the
347    compressed data.  When more than one frame is encoded in the same
348    packet, it is not possible to determine the size of each encoded
349    frame, so the information MUST be explicitly encoded.  If N frames
350    are present in a packet, N compressed frame sizes need to be encoded
351    at the beginning of the packet.  Each size that is less than 255
352    bytes is encoded in one byte (unsigned 8-bit integer).  For sizes
353    greater or equal to 255, a 0xff byte is encoded, followed by the
354    size-255.  Multiple 0xff bytes are allowed if there are more than 510
355    bytes transmitted.  The length is always the size of the CELT frame
356    excluding the length byte itself.  The payload MUST NOT be padded,
357    except in accordance with the padding bit definition in the RTP
358    header.
359
360    Below is an example of two CELT frames contained within one RTP
361    packet.
362
363
364        0                   1                   2                   3
365        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
366       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
367       |V=2|P|X|  CC   |M|     PT      |       sequence number         |
368       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
369       |                           timestamp                           |
370       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
371       |         synchronization source (SSRC) identifier              |
372       +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
373       |         contributing source (CSRC) identifiers                |
374       |                              ...                              |
375       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
376       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
377       | length frame 1| length frame 2|          CELT frame 1...      |
378       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
379       |         (frame 1)             |        CELT frame 2...        |
380       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
381       |                          (frame 2)                            |
382       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
383
384    The following is an example of C code that interprets the length
385    bytes:
386
387
388
389
390
391 Valin & Maxwell         Expires November 12, 2009               [Page 7]
392 \f
393 Internet-Draft       draft-valin-celt-rtp-profile-01            May 2009
394
395
396       int i, N, pos;
397       int sizes[MAX_FRAMES][channels];
398       unsigned int total_size;
399       total_size=0;
400       N = 0;
401       pos = 0;
402       while (total_size < payload_size) {
403          for (i=0;i<channels;i++) {
404             int s;
405             int sum;
406             sum = 0;
407             do {
408                s = payload[pos++];
409                sum += s;
410                total_size += s+1;
411             } while (s == 255);
412             sizes[N][i] = sum;
413          }
414          N++;
415       }
416
417 3.4.  Multiple channels
418
419    CELT supports both mono streams and stereo streams.  If more than two
420    channels are desired, it is possible to use transmit multiple streams
421    in the same packet.  In this case, the number of streams S and the
422    pairing must be agreed with out-of-band negotiation such as SDP.
423    Each stream can be either mono or stereo, depending on whether the
424    channels are assumed to be correlated.  For example, a 5.1 surround
425    could have the front-left and front-right channels in a stereo
426    stream, the rear-left and rear-right channels in a separate stereo
427    stream, while the center and low-frequency channels would be in
428    separate mono streams.  In that example, the RTP packet would be:
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447 Valin & Maxwell         Expires November 12, 2009               [Page 8]
448 \f
449 Internet-Draft       draft-valin-celt-rtp-profile-01            May 2009
450
451
452        0                   1                   2                   3
453        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
454       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
455       |V=2|P|X|  CC   |M|     PT      |       sequence number         |
456       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
457       |                           timestamp                           |
458       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
459       |         synchronization source (SSRC) identifier              |
460       +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
461       |         contributing source (CSRC) identifiers                |
462       |                              ...                              |
463       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
464       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
465       |  Front length |  rear length  | center length |  LFE length   |
466       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
467       |                        Front stereo                           |
468       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
469       |                             ...                               |
470       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
471       |      ...      |        Rear stereo data...                    |
472       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
473       |                             ...                               |
474       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
475       |                       Center mono data...                     |
476       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
477       |                             ...                               |
478       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
479       |                               |      LFE mono data...         |
480       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
481       |                             ...                               |
482       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
483
484    In the case where streams for multiple channels are used with
485    multiple frames of the same streams per packet, then all streams for
486    a certain timestamp are encoded before all streams for the following
487    timestamp.  In the case of the 5.1 example above with two frames per
488    packet, the number of compressed length fields would be S*N = 8.
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503 Valin & Maxwell         Expires November 12, 2009               [Page 9]
504 \f
505 Internet-Draft       draft-valin-celt-rtp-profile-01            May 2009
506
507
508 4.  MIME registration of CELT
509
510    Full definition of the MIME [rfc2045] type for CELT will be part of
511    the Ogg Vorbis MIME type definition application [rfc3534].
512
513    MIME media type name: audio
514
515    MIME subtype: celt
516
517    Optional parameters:
518
519    Required parameters: to be included in the Ogg MIME specification.
520
521    Encoding considerations:
522
523    Security Considerations:
524
525    See Section 6 of RFC 3047.
526
527    Interoperability considerations: none
528
529    Published specification:
530
531    Applications which use this media type:
532
533    Additional information: none
534
535    Person & email address to contact for further information:
536
537
538       Jean-Marc Valin <jean-marc.valin@octasic.com>
539
540    Intended usage: COMMON
541
542    Author/Change controller:
543
544       Author: Jean-Marc Valin <jean-marc.valin@octasic.com>
545
546       Change controller: Jean-Marc Valin <jean-marc.valin@octasic.com>
547
548       Change controller: IETF AVT Working Group
549
550    This transport type signifies that the content is to be interpreted
551    according to this document if the contents are transmitted over RTP.
552    Should this transport type appear over a lossless streaming protocol
553    such as TCP, the content encapsulation should be interpreted as an
554    Ogg Stream in accordance with [rfc3534], with the exception that the
555    content of the Ogg Stream may be assumed to be CELT audio and CELT
556
557
558
559 Valin & Maxwell         Expires November 12, 2009              [Page 10]
560 \f
561 Internet-Draft       draft-valin-celt-rtp-profile-01            May 2009
562
563
564    audio only.
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615 Valin & Maxwell         Expires November 12, 2009              [Page 11]
616 \f
617 Internet-Draft       draft-valin-celt-rtp-profile-01            May 2009
618
619
620 5.  SDP usage of CELT
621
622    When conveying information by SDP [rfc4566], the encoding name MUST
623    be set to "CELT".  The sampling frequency is typically between 32000
624    and 48000 Hz.  Implementations MUST support 48000 Hz and SHOULD also
625    support 44100 Hz.
626
627    The SDP parameters have the following interpretation with respect to
628    CELT:
629
630       ptime: The desired packetization time.  The sender SHOULD choose a
631       number of frames per packet that corresponds to the smallest
632       packetization time greater or equal to the specified ptime for the
633       selected frame size.  The default is 20 ms as specified in
634       [rfc3551]
635
636       maxptime: The maximum packetization time desired.  As specified in
637       [rfc4566], if the maximum is lower than the smallest packetization
638       time determined from the chosen frame size (as described above),
639       then that packtization time SHOULD be used despite the maxptime
640       value.  The default is "no maximum".
641
642    CELT-specific parameters can be given via the "a=fmtp:" directive.
643    Several parameters can be given in a single a=fmtp line provided that
644    they are separated by a semi-colon.  The following parameters are
645    defined for use in this way:
646
647       bitrate: The desired bit-rate in kbit/s for the codec only
648       (excluding headers and the length bytes).  The value MUST be
649       rounded to an integer number of bytes per frame.  The round-to-
650       nearest method is RECOMMENDED.  The default bit-rate value is 64
651       kbit/s per channel.
652
653       frame-size: The frame size is the duration of each frame in
654       samples and has to be even.  The default is 480.
655
656       mapping: Optional string describing the multi-channel mapping.
657
658    The selected frame-size values MUST be even.  For quality and
659    complexity reasons, they SHOULD also be divisible by 8 and have a
660    prime factorization which consists only of 2, 3, or 5 factors.  For
661    example, powers-of-two and values such as 160, 320, 240, and 480 are
662    recommended.  Implementations MUST support receiving and sending the
663    default value of 480.  Implementations SHOULD also support frame
664    sizes of 256 and 512 since these are the ones that lead to the lowest
665    complexity.  When frame sizes that are powers-of-two are supported,
666    they SHOULD be listed first in the offer and chosen over non-powers-
667    of-two in the answer.
668
669
670
671 Valin & Maxwell         Expires November 12, 2009              [Page 12]
672 \f
673 Internet-Draft       draft-valin-celt-rtp-profile-01            May 2009
674
675
676    Care must be taken when setting the value of ptime: and bitrate: so
677    that the RTP packet size does not exceed the path MTU.
678
679    An example of the media representation in SDP for offering a single
680    channel of CELT at 48000 samples per second might be:
681
682
683       m=audio 8088 RTP/AVP 97
684
685       a=rtpmap:97 CELT/48000/1
686
687    Note that the RTP payload type code of 97 is defined in this media
688    definition to be 'mapped' to the CELT codec at a 48 kHz sampling
689    frequency using the 'a=rtpmap' line.  Any number from 96 to 127 could
690    have been chosen (the allowed range for dynamic types).  If there is
691    more than one channel being encoded the rtpmap MUST specify the
692    channel count.  When no channel count is included, the default is one
693    channel.
694
695    The following example demonstrates the use of the a=fmtp: parameters:
696
697
698       m=audio 8008 RTP/AVP 97
699
700       a=ptime: 25
701
702       a=rtpmap:97 CELT/44100
703
704       a=fmtp:97 frame-size=512;bitrate=48
705
706    This examples illustrate an offerer that wishes to receive a CELT
707    stream at 44100 Hz, by packing two 512-sample frames in each packet
708    (less than 25 ms) at around 48 kbps (70 bytes per frame).
709
710 5.1.  Multichannel Mapping
711
712    When more than two channels are used, a mapping parameter MUST be
713    provided.  The mapping parameter is defined as comma separated list
714    of integers which specify the number of channels contained in each
715    CELT stream, OPTIONALLY followed by a '/' and a comma separated list
716    of channel identifiers, then OPTIONALLY another '/' and a string
717    which provides an application specific elaboration on any speaker-
718    feed definitions.  The channels per stream entries MUST be either 1
719    or 2.  The total number of channels is indicated by the sum of the
720    channels per stream entries.  The sum of the channel counts MUST be
721    equal to the total number of channels.
722
723    Channel identifiers are short alphanumeric strings.  Each identifier
724
725
726
727 Valin & Maxwell         Expires November 12, 2009              [Page 13]
728 \f
729 Internet-Draft       draft-valin-celt-rtp-profile-01            May 2009
730
731
732    MUST begin with a letter indicating the type of channel.  'A' MUST be
733    used to indicate an ambisonic channel, 'S' to indicate a speaker-feed
734    channel, or 'O' indicating other usage.
735
736    A channel identifier MAY be repeated, but the meaning of such
737    repetition is application specific.  Applications SHOULD attempt to
738    utilize channel identifiers such that mixing all identical
739    identifiers would produce a reasonable result.
740
741    Non-surround usage such as individual performer tracks, effect send,
742    "order wire", or other administrative channels may be given
743    application specific identifiers which MUST not conflict with the
744    identifiers defined in this draft.  These identifiers SHOULD begin
745    with S if it would be sensible to include them in a mono-downmix, or
746    O if it would be most sensible to exclude them from a mono-downmix.
747    An example usage might be mapping=2,1,2,1,1/
748    SLguitar,SRguitar,OheadsetG,SLkeyboard,SRkeyboard,OheadsetK,SMbass,Oh
749    eadsetB"
750
751    Ambisonic channels MUST follow the Furse-Malham naming and weighing
752    conventions for up to third order spherical[Ambisonic].  Higher order
753    ambisonic support is application defined but MUST NOT reuse any of
754    WXYZRSTUVKLMNOPQ for higher order components.  For example, second
755    order spherical ambisonics SHOULD use the mapping
756    "mapping=1,1,1,1,1,1,1,1,1/AW,AX,AY,AZ,AR,AS,AT,AU,AV".  Any set of
757    Ambisonic channels MUST contain at least one "AW" channel.
758
759    Speaker-feed identifiers are named based on the intended speaker
760    locations.  "L", "R" for the left and right speakers, respectively,
761    in conventional stereo or the front left and right in 4, 5, 5.1, or
762    7.1 channel surround.  "LR", "RR" for the left and right rear
763    speakers in 4,5 or 5.1 channel surround.  C" is used for a center
764    channel, "MLFE" for a low frequency extension channel.  "LS", "RS"
765    for the side channels in 7.1 channel surround.  Additional speaker-
766    feeds are application specific but should not reuse the prior
767    identifiers.  For 5.1 surround in non-ambisonic form the mapping
768    SHOULD be "mapping=2,2,1,1/L,R,LR,RR,C,MLFE/ITU-RBS.775-1".  When
769    only one or two channels are used, the mapping parameter MAY be
770    omitted, in which case the default mapping is used.  For one channel,
771    the default is "mapping=1/C", while for two channels, the default is
772    "mapping=2/L,R".
773
774    For example a stereo configuration might signal:
775
776
777       m=audio 8008 RTP/AVP 97
778
779
780
781
782
783 Valin & Maxwell         Expires November 12, 2009              [Page 14]
784 \f
785 Internet-Draft       draft-valin-celt-rtp-profile-01            May 2009
786
787
788       a=ptime: 5
789
790       a=rtpmap:97 CELT/44100/2
791
792       a=fmtp:97 frame-size=256
793
794    Which specifies a single two-channel CELT stream according to the
795    default mapping.
796
797 5.2.  Low-Overhead Mode
798
799    A low-overhead mode is defined to make more efficient use of
800    bandwidth when transmitting CELT frames.  In that mode none of the
801    length values need to be transmitted.  One the a=fmtp: parameter low-
802    overhead: is defined and contains a single frame size, followed by a
803    '/', followed by a comma-separated list of the number of bytes per
804    frame for each stream defined in the channel mapping.  The number of
805    frames per channel can thus be computed as the payload size divided
806    by the sum of the bytes-per-frame values.  The frame-size: parameter
807    MUST not be specified and SHOULD be ignored if encountered in an SDP
808    offer or answer.  The bitrate: parameter MUST also be ignored since
809    the low-overhead: parameter makes it redundant.  When the low-
810    overhead: parameter is specified, the length of each frame MUST NOT
811    be encoded in the payload and the bit-rate MUST NOT be changed during
812    the session.
813
814    For example a low-overhead surround configuration could be signaled
815    as:
816
817       m=audio 8008 RTP/AVP 97
818
819       a=ptime: 5
820
821       a=rtpmap:97 CELT/48000/6
822
823       a=fmtp:97 low-overhead=256/1/86,86,43,30;mapping=2,2,1,1/
824       L,R,LR,RR,C,MLFE/ITU-RBS.775-1
825
826    In this example, 4 bytes per packet would be saved.  This corresponds
827    to a 6 kbit/s reduction in the overhead, although the 60 kbit/s
828    overhead of the IP, UDP and RTP headers is still present.
829
830
831
832
833
834
835
836
837
838
839 Valin & Maxwell         Expires November 12, 2009              [Page 15]
840 \f
841 Internet-Draft       draft-valin-celt-rtp-profile-01            May 2009
842
843
844 6.  Congestion Control
845
846    CELT allows any bitrate, with a one byte per frame resolution,
847    without any signaling requirement or overhead.  Applications SHOULD
848    utilize congestion control to regulate the transmitted bitrate.  In
849    some applications it may make sense to increase the packetization
850    interval rather than decreasing the codec bitrate.  Congestion
851    control implementations should consider the users differential
852    tolerance for high latency and low quality.
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895 Valin & Maxwell         Expires November 12, 2009              [Page 16]
896 \f
897 Internet-Draft       draft-valin-celt-rtp-profile-01            May 2009
898
899
900 7.  Security Considerations
901
902    RTP packets using the payload format defined in this specification
903    are subject to the security considerations discussed in the RTP
904    specification [rfc3550], and in any applicable RTP profile.  The main
905    security considerations for the RTP packet carrying the RTP payload
906    format defined within this memo are confidentiality, integrity and
907    source authenticity.  Confidentiality is achieved by encryption of
908    the RTP payload.  Integrity of the RTP packets through suitable
909    cryptographic integrity protection mechanism.  Cryptographic system
910    may also allow the authentication of the source of the payload.  A
911    suitable security mechanism for this RTP payload format should
912    provide confidentiality, integrity protection and at least source
913    authentication capable of determining if an RTP packet is from a
914    member of the RTP session or not.
915
916    Note that the appropriate mechanism to provide security to RTP and
917    payloads following this memo may vary.  It is dependent on the
918    application, the transport, and the signalling protocol employed.
919    Therefore a single mechanism is not sufficient, although if suitable
920    the usage of SRTP [rfc3711] is recommended.  Other mechanism that may
921    be used are IPsec [rfc4301] and TLS [rfc5246] (RTP over TCP), but
922    also other alternatives may exist.
923
924    This RTP payload format and its media decoder do not exhibit any
925    significant non-uniformity in the receiver-side computational
926    complexity for packet processing, and thus are unlikely to pose a
927    denial-of-service threat due to the receipt of pathological data.
928    Nor does the RTP payload format contain any active content.
929
930    Because this format supports VBR operation small amounts of
931    information about the transmitted audio may be leaked by a length
932    preserving cryptographic transport.  Accordingly, when CELT is used
933    inside a secure transport the sender SHOULD restrict the use of VBR
934    to congestion control purposes.
935
936    CELT implementations will typically exhibit tiny content-sensitive
937    encoding time variances.  Since transmission is usually triggered by
938    an accurate hardware clock and the encoded data is typically
939    transmitted as soon as encoding is complete this variance may result
940    in a small amount of additional frame to frame jitter which could be
941    measured by a third-party.  Encrypted implementations SHOULD transmit
942    packets at fixed intervals to avoid the possible information leak.
943
944
945
946
947
948
949
950
951 Valin & Maxwell         Expires November 12, 2009              [Page 17]
952 \f
953 Internet-Draft       draft-valin-celt-rtp-profile-01            May 2009
954
955
956 8.  Acknowledgments
957
958    The authors would also like to thank the following people for their
959    input: Timothy B. Terriberry, Ben Schwartz, Alexander Carot, Thorvald
960    Natvig, Brian West, Steve Underwood, and Anthony Minessale.
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
1001
1002
1003
1004
1005
1006
1007 Valin & Maxwell         Expires November 12, 2009              [Page 18]
1008 \f
1009 Internet-Draft       draft-valin-celt-rtp-profile-01            May 2009
1010
1011
1012 9.  References
1013
1014 9.1.  Normative References
1015
1016    [rfc2119]  Bradner, S., "Key words for use in RFCs to Indicate
1017               Requirement Levels", RFC 2119.
1018
1019    [rfc3550]  Schulzrinne, H., Casner, S., Frederick, R., and V.
1020               Jacobson, "RTP: A Transport Protocol for real-time
1021               applications", RFC 3550.
1022
1023    [rfc2045]  "Multipurpose Internet Mail Extensions (MIME) Part One:
1024               Format of Internet Message Bodies", RFC 2045,
1025               November 1998.
1026
1027    [rfc4566]  Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
1028               Description Protocol", RFC 4566, July 2006.
1029
1030    [rfc3551]  Schulzrinne, H. and S. Casner, "RTP Profile for Audio and
1031               Video Conferences with Minimal Control.", RFC 3551,
1032               July 2003.
1033
1034    [rfc3534]  Walleij, L., "The application/ogg Media Type", RFC 3534,
1035               May 2003.
1036
1037    [rfc3711]  Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
1038               Norrman, "The Secure Real-time Transport Protocol (SRTP)",
1039               RFC 3711, March 2004.
1040
1041    [rfc4301]  Kent, S. and K. Seo, "Security Architecture for the
1042               Internet Protocol", RFC 4301, December 2005.
1043
1044    [rfc5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security
1045               (TLS) Protocol Version 1.2", RFC 5246, August 2008.
1046
1047 9.2.  Informative References
1048
1049    [celt-website]
1050               Xiph.Org Foundation, "The CELT ultra-low delay audio
1051               codec", CELT website http://www.celt-codec.org/.
1052
1053    [Ambisonic]
1054               Malham, D., "Higher order Ambisonic systems", Paper http:/
1055               /www.york.ac.uk/inst/mustech/3d_audio/
1056               higher_order_ambisonics.pdf, December 2003.
1057
1058
1059
1060
1061
1062
1063 Valin & Maxwell         Expires November 12, 2009              [Page 19]
1064 \f
1065 Internet-Draft       draft-valin-celt-rtp-profile-01            May 2009
1066
1067
1068 Authors' Addresses
1069
1070    Jean-Marc Valin
1071    Octasic Semiconductor
1072    4101, Molson Street, suite 300
1073    Montreal, Quebec  H1Y 3L1
1074    Canada
1075
1076    Email: jean-marc.valin@octasic.com
1077
1078
1079    Gregory Maxwell
1080    Juniper Networks
1081    2251 Corporate Park Drive, Suite 100
1082    Herndon, VA  20171-1817
1083    USA
1084
1085    Email: gmaxwell@juniper.net
1086
1087
1088
1089
1090
1091
1092
1093
1094
1095
1096
1097
1098
1099
1100
1101
1102
1103
1104
1105
1106
1107
1108
1109
1110
1111
1112
1113
1114
1115
1116
1117
1118
1119 Valin & Maxwell         Expires November 12, 2009              [Page 20]
1120 \f