diff options
Diffstat (limited to 'doc/rfc/rfc4298.txt')
| -rw-r--r-- | doc/rfc/rfc4298.txt | 787 |
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] + |