24789aef6647308c7c6cfc2f8ade56ed041e6b64
[opus.git] / doc / ietf / draft-valin-celt-rtp-profile-00.txt
1
2
3
4 AVT Working Group                                             J-M. Valin
5 Internet-Draft                                     Octasic Semiconductor
6 Expires: November 9, 2009                                     G. Maxwell
7                                                         Juniper Networks
8                                                              May 8, 2009
9
10
11                     draft-valin-celt-rtp-profile-00
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 9, 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 9, 2009                [Page 1]
56 \f
57 Internet-Draft       draft-valin-celt-rtp-profile-00            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 . . . . . . . . . . . . . . . . . . . 14
84      5.2.  Low-Overhead Mode  . . . . . . . . . . . . . . . . . . . . 15
85    6.  Congestion Control . . . . . . . . . . . . . . . . . . . . . . 17
86    7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 18
87    8.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 19
88    9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
89      9.1.  Normative References . . . . . . . . . . . . . . . . . . . 20
90      9.2.  Informative References . . . . . . . . . . . . . . . . . . 20
91    Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111 Valin & Maxwell         Expires November 9, 2009                [Page 2]
112 \f
113 Internet-Draft       draft-valin-celt-rtp-profile-00            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 9, 2009                [Page 3]
168 \f
169 Internet-Draft       draft-valin-celt-rtp-profile-00            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 9, 2009                [Page 4]
224 \f
225 Internet-Draft       draft-valin-celt-rtp-profile-00            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 9, 2009                [Page 5]
280 \f
281 Internet-Draft       draft-valin-celt-rtp-profile-00            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 9, 2009                [Page 6]
336 \f
337 Internet-Draft       draft-valin-celt-rtp-profile-00            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 9, 2009                [Page 7]
392 \f
393 Internet-Draft       draft-valin-celt-rtp-profile-00            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 9, 2009                [Page 8]
448 \f
449 Internet-Draft       draft-valin-celt-rtp-profile-00            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 9, 2009                [Page 9]
504 \f
505 Internet-Draft       draft-valin-celt-rtp-profile-00            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 9, 2009               [Page 10]
560 \f
561 Internet-Draft       draft-valin-celt-rtp-profile-00            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 9, 2009               [Page 11]
616 \f
617 Internet-Draft       draft-valin-celt-rtp-profile-00            May 2009
618
619
620 5.  SDP usage of CELT
621
622    When conveying information by SDP [rfc2327], the encoding name MUST
623    be set to "CELT".  The sampling frequency is typically between 32000
624    and 48000 Hz.  Implementations SHOULD support both 44100 Hz and 48000
625    Hz.  The maximum bandwidth permitted for the CELT audio is encoded
626    using the "b=AS:" header, as explained in SDP [rfc2327].
627
628    The SDP parameters have the following interpretation with respect to
629    CELT:
630
631       b=AS: The maximum bandwidth (in kbit/s) allowed for CELT,
632       excluding the header overhead.  The default is 64 kbit/s.
633
634       ptime: The desired packetization time.  The sender SHOULD choose a
635       number of frames per packet that corresponds to the smallest
636       packetization time greater or equal to the specified ptime for the
637       selected frame size.  The default is 20 ms as specified in
638       [rfc3551]
639
640       maxptime: The maximum packetization time desired.  If the maximum
641       is lower than the smallest packetization time determined from the
642       chosen frame size (as described above), then that packtization
643       time SHOULD be used despite the maxptime value.  The default is
644       "no maximum".
645
646    CELT-specific parameters can be given via the "a=fmtp:" directive.
647    Several parameters can be given in a single a=fmtp line provided that
648    they are separated by a semi-colon.  The following parameters are
649    defined for use in this way:
650
651       frame-size: The frame size is the duration of each frame in
652       samples.  If more than one frame size is supported, a comma-
653       separated list can be used.  It is possible to use "any" to denote
654       that all even frame sizes are supported.  The default is 480.
655
656       mapping: Optional string describing the multi-channel mapping.
657
658    Because the frame-size is not transmitted in-band, an SDP answer MUST
659    contain only one frame-size, even if multiple frame sizes were
660    offered.
661
662    The selected frame-size values MUST be even.  They SHOULD be
663    divisible by 8 and have a prime factorization which consists only of
664    2, 3, or 5 factors.  For example, powers-of-two and values such as
665    160, 320, 240, and 480 are recommended.  Implementations MUST support
666    receiving and sending the default value of 480, and if the size 480
667    is supported it MUST be offered.  Implementations SHOULD also support
668
669
670
671 Valin & Maxwell         Expires November 9, 2009               [Page 12]
672 \f
673 Internet-Draft       draft-valin-celt-rtp-profile-00            May 2009
674
675
676    frame sizes of 256 and 512 since these are the ones that lead to the
677    lowest complexity.  When frame sizes that are powers of two are
678    supported, they SHOULD be listed first in the offer and chosen over
679    non powers of two in the answer.
680
681    Care must be taken when setting the value of ptime: and b=AS: so that
682    the RTP packet size does not exceed the path MTU.
683
684    An example of the media representation in SDP for offering a single
685    channel of CELT at 48000 samples per second might be:
686
687
688       m=audio 8088 RTP/AVP 97
689
690       a=rtpmap:97 CELT/48000
691
692    Note that the RTP payload type code of 97 is defined in this media
693    definition to be 'mapped' to the CELT codec at a 48kHz sampling
694    frequency using the 'a=rtpmap' line.  Any number from 96 to 127 could
695    have been chosen (the allowed range for dynamic types).  If there is
696    more than one channel being encoded the rtpmap MUST specify the
697    channel count.
698
699    The following example illustrates the case where the offerer cannot
700    receive more than 64 kbit/s.
701
702
703       m=audio 8088 RTP/AVP 97
704
705       b=AS:64
706
707       a=rtmap:97 CELT/48000
708
709    In this case, if the remote party agrees, it should configure its
710    CELT encoder so that it does not use modes that produce more than 64
711    kbit/s.  Note that the "b=" constraint also applies on all payload
712    types that may be proposed in the media line ("m=").
713
714    The following example demonstrates the use of the a=fmtp: parameters:
715
716
717       m=audio 8008 RTP/AVP 97
718
719       a=ptime: 21
720
721       a=rtpmap:97 CELT/44100
722
723
724
725
726
727 Valin & Maxwell         Expires November 9, 2009               [Page 13]
728 \f
729 Internet-Draft       draft-valin-celt-rtp-profile-00            May 2009
730
731
732       a=fmtp:97 frame-size=512;
733
734    This examples illustrate an offerer that wishes to receive a CELT
735    stream at 44100 Hz, by packing two 512-sample frames in each packet.
736
737 5.1.  Multichannel Mapping
738
739    When more than two channels are used, a mapping parameter MUST be
740    provided.  The mapping parameter is defined as comma separated list
741    of integers which specify the number of channels contained in each
742    CELT stream, OPTIONALLY followed by a '/' and a comma separated list
743    of channel identifiers, then OPTIONALLY another '/' and a string
744    which provides an application specific elaboration on any speaker-
745    feed definitions.  The channels per stream entries MUST be either 1
746    or 2.  The total number of channels is indicated by the sum of the
747    channels per stream entries.  The sum of the channel counts MUST be
748    equal to the total number of channels.
749
750    Channel identifiers are short alphanumeric strings.  Each identifier
751    MUST begin with a letter indicating the type of channel.  'A' MUST be
752    used to indicate an ambisonic channel, 'S' to indicate a speaker-feed
753    channel, or 'O' indicating other usage.
754
755    A channel identifier MAY be repeated, but the meaning of such
756    repetition is application specific.  Applications SHOULD attempt to
757    utilize channel identifiers such that mixing all identical
758    identifiers would produce a reasonable result.
759
760    Non-surround usage such as individual performer tracks, effect send,
761    "order wire", or other administrative channels may be given
762    application specific identifiers which MUST not conflict with the
763    identifiers defined in this draft.  These identifiers SHOULD begin
764    with S if it would be sensible to include them in a mono-downmix, or
765    O if it would be most sensible to exclude them from a mono-downmix.
766    An example usage might be mapping=2,1,2,1,1/
767    SLguitar,SRguitar,OheadsetG,SLkeyboard,SRkeyboard,OheadsetK,SMbass,Oh
768    eadsetB"
769
770    Ambisonic channels MUST follow the Furse-Malham naming and weighing
771    conventions for up to third order spherical[Ambisonic].  Higher order
772    ambisonic support is application defined but MUST NOT reuse any of
773    WXYZRSTUVKLMNOPQ for higher order components.  For example, second
774    order spherical ambisonics SHOULD use the mapping
775    "mapping=1,1,1,1,1,1,1,1,1/AW,AX,AY,AZ,AR,AS,AT,AU,AV".  Any set of
776    Ambisonic channels MUST contain at least one "AW" channel.
777
778    Speaker-feed identifiers are named based on the intended speaker
779    locations.  "L", "R" for the left and right speakers, respectively,
780
781
782
783 Valin & Maxwell         Expires November 9, 2009               [Page 14]
784 \f
785 Internet-Draft       draft-valin-celt-rtp-profile-00            May 2009
786
787
788    in conventional stereo or the front left and right in 4, 5, 5.1, or
789    7.1 channel surround.  "LR", "RR" for the left and right rear
790    speakers in 4,5 or 5.1 channel surround.  C" is used for a center
791    channel, "MLFE" for a low frequency extension channel.  "LS", "RS"
792    for the side channels in 7.1 channel surround.  Additional speaker-
793    feeds are application specific but should not reuse the prior
794    identifiers.  For 5.1 surround in non-ambisonic form the mapping
795    SHOULD be "mapping=2,2,1,1/L,R,LR,RR,C,MLFE/ITU-RBS.775-1".  When
796    only one or two channels are used, the mapping parameter MAY be
797    omitted, in which case the default mapping is used.  For one channel,
798    the default is "mapping=1/C", while for two channels, the default is
799    "mapping=2/L,R".
800
801    For example a stereo configuration might signal:
802
803
804       m=audio 8008 RTP/AVP 97
805
806       a=ptime: 5
807
808       a=rtpmap:97 CELT/44100/2
809
810       a=fmtp:97 frame-size=256;
811
812    Which specifies a single two-channel CELT stream according to the
813    default mapping.
814
815 5.2.  Low-Overhead Mode
816
817    A low-overhead mode is defined to make more efficient use of
818    bandwidth when transmitting CELT frames.  In that mode none of the
819    length values need to be transmitted.  One the a=fmtp: parameter low-
820    overhead: is defined and contains a single frame size, followed by a
821    '/', followed by the number of frames (per channel) per packet,
822    followed by a '/', followed by a comma-separated list of the number
823    of bytes per frame for each stream defined in the channel mapping.
824    The frame-size: parameter MUST not be specified and SHOULD be ignored
825    if encountered in an SDP offer or answer.  The ptime:, maxptime: and
826    b=AS: parameters SHOULD also be ignored since the low-overhead:
827    parameter makes them redundant.  When the low-overhead: parameter is
828    specified, the length of each frame MUST NOT be encoded in the
829    payload and the bit-rate MUST NOT be changed during the session.
830
831    For example a low-overhead surround configuration could be signaled
832    as:
833
834       m=audio 8008 RTP/AVP 97
835
836
837
838
839 Valin & Maxwell         Expires November 9, 2009               [Page 15]
840 \f
841 Internet-Draft       draft-valin-celt-rtp-profile-00            May 2009
842
843
844       a=ptime: 5
845
846       a=rtpmap:97 CELT/48000/6
847
848       a=fmtp:97 low-overhead=256/1/86,86,43,30;mapping=2,2,1,1/
849       L,R,LR,RR,C,MLFE/ITU-RBS.775-1
850
851    In this example, 4 bytes per packet would be saved.  This corresponds
852    to a 6 kbit/s reduction in the overhead, although the 60 kbit/s
853    overhead of the IP, UDP and RTP headers is still present.
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 9, 2009               [Page 16]
896 \f
897 Internet-Draft       draft-valin-celt-rtp-profile-00            May 2009
898
899
900 6.  Congestion Control
901
902    CELT allows for bitrate adjustment in one byte per frame increments
903    without any signaling requirement or overhead.  Applications SHOULD
904    utilize congestion control to regulate the transmitted bitrate.  In
905    some applications it may make sense to increase the packetization
906    interval rather than decreasing the codec bitrate.  Congestion
907    control implementations should consider the users differential
908    tolerance for high latency and low quality.
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951 Valin & Maxwell         Expires November 9, 2009               [Page 17]
952 \f
953 Internet-Draft       draft-valin-celt-rtp-profile-00            May 2009
954
955
956 7.  Security Considerations
957
958    RTP packets using the payload format defined in this specification
959    are subject to the security considerations discussed in the RTP
960    specification [rfc3550], and in any applicable RTP profile.  The main
961    security considerations for the RTP packet carrying the RTP payload
962    format defined within this memo are confidentiality, integrity and
963    source authenticity.  Confidentiality is achieved by encryption of
964    the RTP payload.  Integrity of the RTP packets through suitable
965    cryptographic integrity protection mechanism.  Cryptographic system
966    may also allow the authentication of the source of the payload.  A
967    suitable security mechanism for this RTP payload format should
968    provide confidentiality, integrity protection and at least source
969    authentication capable of determining if an RTP packet is from a
970    member of the RTP session or not.
971
972    Note that the appropriate mechanism to provide security to RTP and
973    payloads following this memo may vary.  It is dependent on the
974    application, the transport, and the signalling protocol employed.
975    Therefore a single mechanism is not sufficient, although if suitable
976    the usage of SRTP [rfc3711] is recommended.  Other mechanism that may
977    be used are IPsec [rfc4301] and TLS [rfc5246] (RTP over TCP), but
978    also other alternatives may exist.
979
980    This RTP payload format and its media decoder do not exhibit any
981    significant non-uniformity in the receiver-side computational
982    complexity for packet processing, and thus are unlikely to pose a
983    denial-of-service threat due to the receipt of pathological data.
984    Nor does the RTP payload format contain any active content.
985
986    Because this format supports VBR operation small amounts of
987    information about the transmitted audio may be leaked by a length
988    preserving cryptographic transport.  Accordingly, when CELT is used
989    inside a secure transport the sender SHOULD restrict the use of VBR
990    to congestion control purposes.
991
992    CELT implementations will typically exhibit tiny content-sensitive
993    encoding time variances.  Since transmission is usually triggered by
994    an accurate hardware clock and the encoded data is typically
995    transmitted as soon as encoding is complete this variance may result
996    in a small amount of additional frame to frame jitter which could be
997    measured by a third-party.  Encrypted implementations SHOULD transmit
998    packets at fixed intervals to avoid the possible information leak.
999
1000
1001
1002
1003
1004
1005
1006
1007 Valin & Maxwell         Expires November 9, 2009               [Page 18]
1008 \f
1009 Internet-Draft       draft-valin-celt-rtp-profile-00            May 2009
1010
1011
1012 8.  Acknowledgments
1013
1014    The authors would also like to thank the following people for their
1015    input: Timothy B. Terriberry, Ben Schwartz, Alexander Carot, Thorvald
1016    Natvig, Brian West, Steve Underwood, and Anthony Minessale.
1017
1018
1019
1020
1021
1022
1023
1024
1025
1026
1027
1028
1029
1030
1031
1032
1033
1034
1035
1036
1037
1038
1039
1040
1041
1042
1043
1044
1045
1046
1047
1048
1049
1050
1051
1052
1053
1054
1055
1056
1057
1058
1059
1060
1061
1062
1063 Valin & Maxwell         Expires November 9, 2009               [Page 19]
1064 \f
1065 Internet-Draft       draft-valin-celt-rtp-profile-00            May 2009
1066
1067
1068 9.  References
1069
1070 9.1.  Normative References
1071
1072    [rfc2119]  Bradner, S., "Key words for use in RFCs to Indicate
1073               Requirement Levels", RFC 2119.
1074
1075    [rfc3550]  Schulzrinne, H., Casner, S., Frederick, R., and V.
1076               Jacobson, "RTP: A Transport Protocol for real-time
1077               applications", RFC 3550.
1078
1079    [rfc2045]  "Multipurpose Internet Mail Extensions (MIME) Part One:
1080               Format of Internet Message Bodies", RFC 2045,
1081               November 1998.
1082
1083    [rfc2327]  Jacobson, V. and M. Handley, "SDP: Session Description
1084               Protocol", RFC 2327, April 1998.
1085
1086    [rfc3551]  Schulzrinne, H. and S. Casner, "RTP Profile for Audio and
1087               Video Conferences with Minimal Control.", RFC 3551,
1088               July 2003.
1089
1090    [rfc3534]  Walleij, L., "The application/ogg Media Type", RFC 3534,
1091               May 2003.
1092
1093    [rfc3711]  Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
1094               Norrman, "The Secure Real-time Transport Protocol (SRTP)",
1095               RFC 3711, March 2004.
1096
1097    [rfc4301]  Kent, S. and K. Seo, "Security Architecture for the
1098               Internet Protocol", RFC 4301, December 2005.
1099
1100    [rfc5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security
1101               (TLS) Protocol Version 1.2", RFC 5246, August 2008.
1102
1103 9.2.  Informative References
1104
1105    [celt-website]
1106               Xiph.Org Foundation, "The CELT ultra-low delay audio
1107               codec", CELT website http://www.celt-codec.org/.
1108
1109    [Ambisonic]
1110               Malham, D., "Higher order Ambisonic systems", Paper http:/
1111               /www.york.ac.uk/inst/mustech/3d_audio/
1112               higher_order_ambisonics.pdf, December 2003.
1113
1114
1115
1116
1117
1118
1119 Valin & Maxwell         Expires November 9, 2009               [Page 20]
1120 \f
1121 Internet-Draft       draft-valin-celt-rtp-profile-00            May 2009
1122
1123
1124 Authors' Addresses
1125
1126    Jean-Marc Valin
1127    Octasic Semiconductor
1128    4101, Molson Street, suite 300
1129    Montreal, Quebec  H1Y 3L1
1130    Canada
1131
1132    Email: jean-marc.valin@octasic.com
1133
1134
1135    Gregory Maxwell
1136    Juniper Networks
1137    2251 Corporate Park Drive, Suite 100
1138    Herndon, VA  20171-1817
1139    USA
1140
1141    Email: gmaxwell@juniper.net
1142
1143
1144
1145
1146
1147
1148
1149
1150
1151
1152
1153
1154
1155
1156
1157
1158
1159
1160
1161
1162
1163
1164
1165
1166
1167
1168
1169
1170
1171
1172
1173
1174
1175 Valin & Maxwell         Expires November 9, 2009               [Page 21]
1176 \f