doc: Add RFC documents

1 files changed, 787 insertions, 0 deletions

diff --git a/doc/rfc/rfc4298.txt b/doc/rfc/rfc4298.txt
new file mode 100644
index 0000000..17f23d9
--- /dev/null
+++ b/doc/rfc/rfc4298.txt
@@ -0,0 +1,787 @@
+
+
+
+
+
+
+Network Working Group                                         J.-H. Chen
+Request for Comments: 4298                                        W. Lee
+Category: Standards Track                                     J. Thyssen
+                                                    Broadcom Corporation
+                                                           December 2005
+
+
+            RTP Payload Format for BroadVoice Speech Codecs
+
+Status of This Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2005).
+
+Abstract
+
+   This document describes the RTP payload format for the BroadVoice(R)
+   narrowband and wideband speech codecs.  The narrowband codec, called
+   BroadVoice16, or BV16, has been selected by CableLabs as a mandatory
+   codec in PacketCable 1.5 and has a CableLabs specification.  The
+   document also provides specifications for the use of BroadVoice with
+   MIME and the Session Description Protocol (SDP).
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Chen, et al.                Standards Track                     [Page 1]
+
+RFC 4298           RTP Payload Format for BroadVoice       December 2005
+
+
+Table of Contents
+
+   1. Introduction ....................................................2
+   2. Background ......................................................2
+   3. RTP Payload Format for BroadVoice16 Narrowband Codec ............3
+      3.1. BroadVoice16 Bit Stream Definition .........................4
+      3.2. Multiple BroadVoice16 Frames in an RTP Packet ..............5
+   4. RTP Payload Format for BroadVoice32 Wideband Codec ..............6
+      4.1. BroadVoice32 Bit Stream Definition .........................6
+      4.2. Multiple BroadVoice32 Frames in an RTP Packet ..............8
+   5. IANA Considerations .............................................8
+      5.1. MIME Registration of BroadVoice16 for RTP ..................9
+      5.2. MIME Registration of BroadVoice32 for RTP ..................9
+   6. Mapping to SDP Parameters ......................................10
+      6.1. Offer-Answer Model Considerations .........................11
+   7. Security Considerations ........................................11
+   8. Congestion Control .............................................11
+   9. Acknowledgements ...............................................11
+   10. References ....................................................12
+      10.1. Normative References .....................................12
+      10.2. Informative References ...................................12
+
+1.  Introduction
+
+   This document specifies the payload format for sending BroadVoice
+   encoded speech or audio signals using the Real-time Transport
+   Protocol (RTP) [1].  The sender may send one or more BroadVoice codec
+   data frames per packet, depending on the application scenario, based
+   on network conditions, bandwidth availability, delay requirements,
+   and packet-loss tolerance.
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in RFC 2119 [2].
+
+2.  Background
+
+   BroadVoice is a speech codec family developed for VoIP (Voice over
+   Internet Protocol) applications, including Voice over Cable, Voice
+   over DSL, and IP phone applications.  BroadVoice achieves high speech
+   quality with a low coding delay and relatively low codec complexity.
+
+   The BroadVoice codec family contains two codec versions.  The
+   narrowband version of BroadVoice, called BroadVoice16 [3], or BV16
+   for short, encodes 8 kHz-sampled narrowband speech at a bit rate of
+   16 kilobits/second, or 16 kbit/s.  The wideband version of
+   BroadVoice, called BroadVoice32, or BV32, encodes 16 kHz-sampled
+   wideband speech at a bit rate of 32 kbit/s.  The BV16 and BV32 use
+
+
+
+Chen, et al.                Standards Track                     [Page 2]
+
+RFC 4298           RTP Payload Format for BroadVoice       December 2005
+
+
+   very similar (but not identical) coding algorithms; they share most
+   of their algorithm modules.
+
+   To minimize the delay in real-time two-way communications, both the
+   BV16 and BV32 encode speech with a very small frame size of 5 ms
+   without using any look ahead.  By using a packet size as small as 5
+   ms if necessary, this allows VoIP systems based on BroadVoice to have
+   a very low end-to-end system delay.
+
+   BroadVoice also has relatively low codec complexity when compared
+   with ITU-T standard speech codecs based on CELP (Coded Excited Linear
+   Prediction), such as G.728, G.729, G.723.1, and G.722.2.  Full-duplex
+   implementations of the BV16 and BV32 take around 12 and 17 MIPS,
+   respectively, on general-purpose 16-bit fixed-point digital signal
+   processors (DSPs).  The total memory footprints of the BV16 and BV32,
+   including program size, data tables, and data RAM, are around 12
+   kwords each, or 24 kbytes.
+
+   The PacketCable(TM) project of Cable Television Laboratories, Inc.
+   (CableLabs(R)) has chosen the BV16 codec for use in VoIP telephone
+   services provided by cable operators.  More specifically, the BV16
+   codec was selected as one of the mandatory audio codecs in the
+   PacketCable(TM) 1.5 Audio/Video Codecs Specification [8] and has been
+   implemented by multiple vendors.  The wideband version (BV32) has
+   been developed by Broadcom but has not yet appeared in a public
+   specification; since it is technically very similar to BV16, its
+   payload format is also defined in this document.
+
+3.  RTP Payload Format for BroadVoice16 Narrowband Codec
+
+   The BroadVoice16 uses 5 ms frames and a sampling frequency of 8 kHz,
+   so the RTP timestamp MUST be in units of 1/8000 of a second.  The RTP
+   timestamp indicates the sampling instant of the oldest audio sample
+   represented by the frame(s) present in the payload.  The RTP payload
+   for the BroadVoice16 has the format shown in the figure below.  No
+   additional header specific to this payload format is required.
+
+    0                   1                   2                   3
+    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
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                      RTP Header [1]                           |
+   +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
+   |                                                               |
+   |             one or more frames of BroadVoice16                |
+   |                                                               |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+
+
+
+Chen, et al.                Standards Track                     [Page 3]
+
+RFC 4298           RTP Payload Format for BroadVoice       December 2005
+
+
+   If BroadVoice16 is used for applications with silence compression,
+   the first BroadVoice16 packet after a silence period during which
+   packets have not been transmitted contiguously SHOULD have the marker
+   bit in the RTP data header set to one.  The marker bit in all other
+   packets is zero.  Applications without silence suppression MUST set
+   the marker bit to zero.
+
+   The assignment of an RTP payload type for this new packet format is
+   outside the scope of this document, and will not be specified here.
+   It is expected that the RTP profile for a particular class of
+   applications will assign a payload type for this encoding, or if that
+   is not done, then a payload type in the dynamic range shall be
+   chosen.
+
+3.1.  BroadVoice16 Bit Stream Definition
+
+   The BroadVoice16 encoder operates on speech frames of 5 ms
+   corresponding to 40 samples at a sampling rate of 8000 samples per
+   second.  For every 5 ms frame, the encoder encodes the 40 consecutive
+   audio samples into 80 bits, or 10 octets.  Thus, the 80-bit bit
+   stream produced by the BroadVoice16 for each 5 ms frame is octet-
+   aligned, and no padding bits are required.  The bit allocation for
+   the encoded parameters of the BroadVoice16 codec is listed in the
+   following table.
+
+      Encoded Parameter      Codeword     Number of bits per frame
+      ------------------------------------------------------------
+      Line Spectrum Pairs    L0,L1            7+7=14
+      Pitch Lag              PL                    7
+      Pitch Gain             PG                    5
+      Log-Gain               LG                    4
+      Excitation Vectors     V0,...,V9       5*10=50
+      ------------------------------------------------------------
+      Total:                                      80 bits
+
+   The mapping of the encoded parameters in an 80-bit BroadVoice16 data
+   frame is defined in the following figure.  This figure shows the bit
+   packing in "network byte order", also known as big-endian order.  The
+   bits of each 32-bit word are numbered 0 to 31, with the most
+   significant bit on the left and numbered 0.  The octets (bytes) of
+   each word are transmitted with the most significant octet first.  The
+   bits of the data field for each encoded parameter are numbered in the
+   same order, with the most significant bit on the left.
+
+
+
+
+
+
+
+
+Chen, et al.                Standards Track                     [Page 4]
+
+RFC 4298           RTP Payload Format for BroadVoice       December 2005
+
+
+    0                   1                   2                   3
+    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
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |     L0      |     L1      |      PL     |   PG    |  LG   | V0|
+   |             |             |             |         |       |   |
+   |0 1 2 3 4 5 6|0 1 2 3 4 5 6|0 1 2 3 4 5 6|0 1 2 3 4|0 1 2 3|0 1|
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   | V0  |    V1   |    V2   |    V3   |    V4   |    V5   |   V6  |
+   |     |         |         |         |         |         |       |
+   |2 3 4|0 1 2 3 4|0 1 2 3 4|0 1 2 3 4|0 1 2 3 4|0 1 2 3 4|0 1 2 3|
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |V|    V7   |    V8   |   V9    |
+   |6|         |         |         |
+   |4|0 1 2 3 4|0 1 2 3 4|0 1 2 3 4|
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+                      Figure 1: BroadVoice16 bit packing
+
+3.2.  Multiple BroadVoice16 Frames in an RTP Packet
+
+   More than one BroadVoice16 frame MAY be included in a single RTP
+   packet by a sender.  Senders have the following additional
+   restrictions:
+
+      o  SHOULD NOT include more BroadVoice16 frames in a single RTP
+         packet than will fit in the MTU of the RTP.
+
+      o  MUST NOT split a BroadVoice16 frame between RTP packets.
+
+      o  BroadVoice16 frames in an RTP packet MUST be consecutive.
+
+   Since multiple BroadVoice16 frames in an RTP packet MUST be
+   consecutive, and since BroadVoice16 has a fixed frame size of 5 ms,
+   recovering the timestamps of all frames within a packet is easy.  The
+   oldest frame within an RTP packet has the same timestamp as the RTP
+   packet, as mentioned above.  To obtain the timestamp of the frame
+   that is N frames later than the oldest frame in the packet, one
+   simply adds 5*N ms worth of time units to the timestamp of the RTP
+   packet.
+
+   It is RECOMMENDED that the number of frames contained within an RTP
+   packet be consistent with the application.  For example, in a
+   telephony application where delay is important, the fewer frames per
+   packet, the lower the delay; whereas, for a delay insensitive
+   streaming or messaging application, many frames per packet would be
+   acceptable.
+
+
+
+
+
+Chen, et al.                Standards Track                     [Page 5]
+
+RFC 4298           RTP Payload Format for BroadVoice       December 2005
+
+
+   Information describing the number of frames contained in an RTP
+   packet is not transmitted as part of the RTP payload.  The only way
+   to determine the number of BroadVoice16 frames is to count the total
+   number of octets within the RTP payload, and divide the octet count
+   by 10.
+
+4.  RTP Payload Format for BroadVoice32 Wideband Codec
+
+   The BroadVoice32 uses 5 ms frames and a sampling frequency of 16 kHz,
+   so the RTP timestamp MUST be in units of 1/16000 of a second.  The
+   RTP timestamp indicates the sampling instant of the oldest audio
+   sample represented by the frame(s) present in the payload.  The RTP
+   payload for the BroadVoice32 has the format shown in the figure
+   below.  No additional header specific to this payload format is
+   required.
+
+    0                   1                   2                   3
+    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
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                      RTP Header [1]                           |
+   +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
+   |                                                               |
+   |             one or more frames of BroadVoice32                |
+   |                                                               |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   If BroadVoice32 is used for applications with silence compression,
+   the first BroadVoice32 packet after a silence period during which
+   packets have not been transmitted contiguously SHOULD have the marker
+   bit in the RTP data header set to one.  The marker bit in all other
+   packets is zero.  Applications without silence suppression MUST set
+   the marker bit to zero.
+
+   The assignment of an RTP payload type for this new packet format is
+   outside the scope of this document, and will not be specified here.
+   It is expected that the RTP profile for a particular class of
+   applications will assign a payload type for this encoding, or if that
+   is not done, then a payload type in the dynamic range shall be
+   chosen.
+
+4.1.  BroadVoice32 Bit Stream Definition
+
+   The BroadVoice32 encoder operates on speech frames of 5 ms
+   corresponding to 80 samples at a sampling rate of 16000 samples per
+   second.  For every 5 ms frame, the encoder encodes the 80 consecutive
+   audio samples into 160 bits, or 20 octets.  Thus, the 160-bit bit
+   stream produced by the BroadVoice32 for each 5 ms frame is octet-
+   aligned, and no padding bits are required.  The bit allocation for
+
+
+
+Chen, et al.                Standards Track                     [Page 6]
+
+RFC 4298           RTP Payload Format for BroadVoice       December 2005
+
+
+   the encoded parameters of the BroadVoice32 codec is listed in the
+   following table.
+                                                        Number of bits
+      Encoded Parameter                  Codeword       per frame
+      ---------------------------------------------------------------
+      Line Spectrum Pairs                L0,L1,L2       7+5+5=17
+      Pitch Lag                          PL                    8
+      Pitch Gain                         PG                    5
+      Log-Gains (1st & 2nd subframes)    LG0,LG1          5+5=10
+      Excitation Vectors (1st subframe)  VA0,...,VA9     6*10=60
+      Excitation Vectors (2nd subframe)  VB0,...,VB9     6*10=60
+      ---------------------------------------------------------------
+      Total:                                                 160 bits
+
+   The mapping of the encoded parameters in a 160-bit BroadVoice32 data
+   frame is defined in the following figure.  This figure shows the bit
+   packing in "network byte order", also known as big-endian order.  The
+   bits of each 32-bit word are numbered 0 to 31, with the most
+   significant bit on the left and numbered 0.  The octets (bytes) of
+   each word are transmitted with the most significant octet first.  The
+   bits of the data field for each encoded parameter are numbered in the
+   same order, with the most significant bit on the left.
+
+    0                   1                   2                   3
+    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
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |     L0      |    L1   |    L2   |       PL      |    PG   |LG0|
+   |             |         |         |               |         |   |
+   |0 1 2 3 4 5 6|0 1 2 3 4|0 1 2 3 4|0 1 2 3 4 5 6 7|0 1 2 3 4|0 1|
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   | LG0 |   LG1   |    VA0    |    VA1    |    VA2    |    VA3    |
+   |     |         |           |           |           |           |
+   |2 3 4|0 1 2 3 4|0 1 2 3 4 5|0 1 2 3 4 5|0 1 2 3 4 5|0 1 2 3 4 5|
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |    VA4    |    VA5    |    VA6    |    VA7    |    VA8    |VA9|
+   |           |           |           |           |           |   |
+   |0 1 2 3 4 5|0 1 2 3 4 5|0 1 2 3 4 5|0 1 2 3 4 5|0 1 2 3 4 5|0 1|
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   | VA9   |    VB0    |    VB1    |    VB2    |    VB3    |  VB4  |
+   |       |           |           |           |           |       |
+   |2 3 4 5|0 1 2 3 4 5|0 1 2 3 4 5|0 1 2 3 4 5|0 1 2 3 4 5|0 1 2 3|
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |VB4|    VB5    |    VB6    |    VB7    |    VB8    |   VB9     |
+   |   |           |           |           |           |           |
+   |4 5|0 1 2 3 4 5|0 1 2 3 4 5|0 1 2 3 4 5|0 1 2 3 4 5|0 1 2 3 4 5|
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+                  Figure 2: BroadVoice32 bit packing
+
+
+
+Chen, et al.                Standards Track                     [Page 7]
+
+RFC 4298           RTP Payload Format for BroadVoice       December 2005
+
+
+4.2.  Multiple BroadVoice32 Frames in an RTP Packet
+
+   More than one BroadVoice32 frame MAY be included in a single RTP
+   packet by a sender.  Senders have the following additional
+   restrictions:
+
+      o  SHOULD NOT include more BroadVoice32 frames in a single RTP
+         packet than will fit in the MTU of the RTP.
+
+      o  MUST NOT split a BroadVoice32 frame between RTP packets.
+
+      o  BroadVoice32 frames in an RTP packet MUST be consecutive.
+
+   Since multiple BroadVoice32 frames in an RTP packet MUST be
+   consecutive, and since BroadVoice32 has a fixed frame size of 5 ms,
+   recovering the timestamps of all frames within a packet is easy.  The
+   oldest frame within an RTP packet has the same timestamp as the RTP
+   packet, as mentioned above.  To obtain the timestamp of the frame
+   that is N frames later than the oldest frame in the packet, one
+   simply adds 5*N ms worth of time units to the timestamp of the RTP
+   packet.
+
+   It is RECOMMENDED that the number of frames contained within an RTP
+   packet be consistent with the application.  For example, in a
+   telephony application where delay is important, the fewer frames per
+   packet, the lower the delay; whereas, for a delay insensitive
+   streaming or messaging application, many frames per packet would be
+   acceptable.
+
+   Information describing the number of frames contained in an RTP
+   packet is not transmitted as part of the RTP payload.  The only way
+   to determine the number of BroadVoice32 frames is to count the total
+   number of octets within the RTP payload, and divide the octet count
+   by 20.
+
+5.  IANA Considerations
+
+   Two new MIME sub-types, as described in this section, have been
+   registered.
+
+   The MIME names for the BV16 and BV32 codecs have been allocated from
+   the IETF tree since these two codecs are expected to be widely used
+   for Voice-over-IP applications, especially in Voice over Cable
+   applications.
+
+
+
+
+
+
+
+Chen, et al.                Standards Track                     [Page 8]
+
+RFC 4298           RTP Payload Format for BroadVoice       December 2005
+
+
+5.1.  MIME Registration of BroadVoice16 for RTP
+
+   MIME media type name: audio
+
+   MIME media subtype name: BV16
+
+   Required parameter: none
+
+   Optional parameters:
+      ptime:    Defined as usual for RTP audio (see RFC 2327 [4]).
+
+      maxptime: See RFC 3267 [7] for its definition.  The maxptime
+         SHOULD be a multiple of the duration of a single codec data
+         frame (5 ms).
+
+   Encoding considerations:
+      This type is defined for transferring BV16-encoded data via RTP
+      using the payload format specified in Section 3 of RFC 4298.
+      Audio data is binary data and must be encoded for non-binary
+      transport; the Base64 encoding is suitable for Email.
+
+   Security considerations:
+      See Section 7 "Security Considerations" of RFC 4298.
+
+   Public specification:
+      The BroadVoice16 codec has been specified in [3].
+
+   Intended usage:
+      COMMON.  It is expected that many VoIP applications, especially
+      Voice over Cable applications, will use this type.
+
+   Person & email address to contact for further information:
+      Juin-Hwey (Raymond) Chen
+      rchen@broadcom.com
+
+   Author/Change controller:
+      Author: Juin-Hwey (Raymond) Chen, rchen@broadcom.com
+      Change Controller: IETF Audio/Video Transport Working Group
+         delegated from the IESG
+
+5.2.  MIME Registration of BroadVoice32 for RTP
+
+   MIME media type name: audio
+
+   MIME media subtype name: BV32
+
+   Required parameter: none
+
+
+
+
+Chen, et al.                Standards Track                     [Page 9]
+
+RFC 4298           RTP Payload Format for BroadVoice       December 2005
+
+
+   Optional parameters:
+      ptime:    Defined as usual for RTP audio (see RFC 2327 [4]).
+
+      maxptime: See RFC 3267 [7] for its definition.  The maxptime
+         SHOULD be a multiple of the duration of a single codec data
+         frame (5 ms).
+
+   Encoding considerations:
+      This type is defined for transferring BV32-encoded data via RTP
+      using the payload format specified in Section 4 of RFC 4298.
+      Audio data is binary data and must be encoded for non-binary
+      transport; the Base64 encoding is suitable for Email.
+
+   Security considerations:
+      See Section 7 "Security Considerations" of RFC 4298.
+
+   Intended usage:
+      COMMON.  It is expected that many VoIP applications, especially
+      Voice over Cable applications, will use this type.
+
+   Person & email address to contact for further information:
+      Juin-Hwey (Raymond) Chen
+      rchen@broadcom.com
+
+   Author/Change controller:
+      Author: Juin-Hwey (Raymond) Chen, rchen@broadcom.com
+      Change Controller: IETF Audio/Video Transport Working Group
+         delegated from the IESG
+
+6.  Mapping to SDP Parameters
+
+   The information carried in the MIME media type specification has a
+   specific mapping to fields in the Session Description Protocol (SDP)
+   [4], which is commonly used to describe RTP sessions.  When SDP is
+   used to specify sessions employing the BroadVoice16 or BroadVoice32
+   codec, the mapping is as follows:
+
+      -  The MIME type ("audio") goes in SDP "m=" as the media name.
+
+      -  The MIME subtype (payload format name) goes in SDP "a=rtpmap"
+         as the encoding name.  The RTP clock rate in "a=rtpmap" MUST be
+         8000 for BV16 and 16000 for BV32.
+
+      -  The parameters "ptime" and "maxptime" go in the SDP "a=ptime"
+         and "a=maxptime" attributes, respectively.
+
+
+
+
+
+
+Chen, et al.                Standards Track                    [Page 10]
+
+RFC 4298           RTP Payload Format for BroadVoice       December 2005
+
+
+   An example of the media representation in SDP for describing BV16
+   might be:
+
+      m=audio 49120 RTP/AVP 97
+      a=rtpmap:97 BV16/8000
+
+   An example of the media representation in SDP for describing BV32
+   might be:
+
+      m=audio 49122 RTP/AVP 99
+      a=rtpmap:99 BV32/16000
+
+6.1.  Offer-Answer Model Considerations
+
+   No special considerations are needed for using the SDP Offer/Answer
+   model [5] with the BV16 and BV32 RTP payload formats.
+
+7.  Security Considerations
+
+   RTP packets using the payload format defined in this specification
+   are subject to the security considerations discussed in the RTP
+   specification [1] and any appropriate profile (for example, [6]).
+   This implies that confidentiality of the media streams is achieved by
+   encryption.
+
+   A potential denial-of-service threat exists for data encoding using
+   compression techniques that have non-uniform receiver-end
+   computational load.  The attacker can inject pathological datagrams
+   into the stream that are complex to decode and cause the receiver to
+   become overloaded.  However, the encodings covered in this document
+   do not exhibit any significant non-uniformity.
+
+8.  Congestion Control
+
+   The general congestion control considerations for transporting RTP
+   data apply to BV16 and BV32 audio over RTP as well (see RTP [1]) and
+   any applicable RTP profile like AVP [6].  BV16 and BV32 do not have
+   any built-in mechanism for reducing the bandwidth.  Packing more
+   frames in each RTP payload can reduce the number of packets sent, and
+   hence the overhead from IP/UDP/RTP headers, at the expense of
+   increased delay and reduced error robustness against packet losses.
+
+9.  Acknowledgements
+
+   The authors would like to thank Magnus Westerlund, Colin Perkins,
+   Allison Mankin, and Jean-Francois Mule for their review of this
+   document.
+
+
+
+
+Chen, et al.                Standards Track                    [Page 11]
+
+RFC 4298           RTP Payload Format for BroadVoice       December 2005
+
+
+10.  References
+
+10.1.  Normative References
+
+   [1] Schulzrinne, H.,  Casner, S., Frederick, R., and V. Jacobson,
+       "RTP: A Transport Protocol for Real-Time Applications", STD 64,
+       RFC 3550, July 2003.
+
+   [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
+       Levels", BCP 14, RFC 2119, March 1997.
+
+   [3] Cable Television Laboratories, Inc., BroadVoice(TM)16 Speech
+       Codec Specification, Revision 1.2, October 30, 2003.
+
+   [4] Handley, M. and V. Jacobson, "SDP: Session Description Protocol",
+       RFC 2327, April 1998.
+
+   [5] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with
+       Session Description Protocol (SDP)", RFC 3264, June 2002.
+
+   [6] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video
+       Conferences with Minimal Control", STD 65, RFC 3551, July 2003.
+
+   [7] Sjoberg, J., Westerlund, M., Lakaniemi, A., and Q. Xie, "Real-
+       Time Transport Protocol (RTP) Payload Format and File Storage
+       Format for the Adaptive Multi-Rate (AMR) and Adaptive Multi-Rate
+       Wideband (AMR-WB) Audio Codecs", RFC 3267, June 2002.
+
+10.2.  Informative References
+
+   [8] Cable Television Laboratories, Inc., PacketCable(TM) 1.5
+       Audio/Video Codecs Specification, PKT-SP-CODEC1.5-I01-050128,
+       January 28, 2005.
+       http://www.cablelabs.com/specifications/archives/
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Chen, et al.                Standards Track                    [Page 12]
+
+RFC 4298           RTP Payload Format for BroadVoice       December 2005
+
+
+Authors' Addresses
+
+   Juin-Hwey (Raymond) Chen
+   Broadcom Corporation
+   Room A3020
+   16215 Alton Parkway
+   Irvine, CA 92618
+   USA
+
+   Phone: +1 949 926 6288
+   EMail: rchen@broadcom.com
+
+
+   Winnie Lee
+   Broadcom Corporation
+   Room A2012E
+   200-13711 International Place
+   Richmond, British Columbia V6V 2Z8
+   Canada
+
+   Phone: +1 604 233 8605
+   EMail: wlee@broadcom.com
+
+
+   Jes Thyssen
+   Broadcom Corporation
+   Room A3018
+   16215 Alton Parkway
+   Irvine, CA 92618
+   USA
+
+   Phone: +1 949 926 5768
+   EMail: jthyssen@broadcom.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Chen, et al.                Standards Track                    [Page 13]
+
+RFC 4298           RTP Payload Format for BroadVoice       December 2005
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2005).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at ietf-
+   ipr@ietf.org.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+Chen, et al.                Standards Track                    [Page 14]
+