draft-ietf-avt-rtp-bv-02.txt   draft-ietf-avt-rtp-bv-03.txt 
Internet Draft Juin-Hwey Chen Internet Draft Juin-Hwey Chen
draft-ietf-avt-rtp-bv-02.txt Winnie Lee draft-ietf-avt-rtp-bv-03.txt Winnie Lee
December 7, 2004 Jes Thyssen February 17, 2005 Jes Thyssen
Expires: June 7, 2005 Broadcom Corporation Expires: August 17, 2005 Broadcom Corporation
RTP Payload and Storage Format for BroadVoice Speech Codecs RTP Payload and Storage Format for BroadVoice Speech Codecs
Status of This Memo Status of This Memo
By submitting this Internet-Draft, we certify that any applicable By submitting this Internet-Draft, we certify that any applicable
patent or other IPR claims of which we are aware have been patent or other IPR claims of which we are aware have been
disclosed, or will be disclosed, and any of which we become aware disclosed, or will be disclosed, and any of which we become aware
will be disclosed, in accordance with RFC 3668. will be disclosed, in accordance with RFC 3668.
skipping to change at page 2, line 23 skipping to change at page 2, line 23
4.1 BroadVoice32 Bit Stream Definition..........................6 4.1 BroadVoice32 Bit Stream Definition..........................6
4.2 Multiple BroadVoice32 Frames in an RTP Packet...............8 4.2 Multiple BroadVoice32 Frames in an RTP Packet...............8
5. Storage Format..................................................8 5. Storage Format..................................................8
6. IANA Considerations.............................................9 6. IANA Considerations.............................................9
6.1 MIME Registration of BroadVoice16...........................9 6.1 MIME Registration of BroadVoice16...........................9
6.2 MIME Registration of BroadVoice32..........................10 6.2 MIME Registration of BroadVoice32..........................10
7. Mapping to SDP Parameters......................................11 7. Mapping to SDP Parameters......................................11
7.1 Offer-Answer Model Considerations..........................12 7.1 Offer-Answer Model Considerations..........................12
8. Security Considerations........................................12 8. Security Considerations........................................12
9. Congestion Control.............................................12 9. Congestion Control.............................................12
10. Normative References...........................................13 10. Acknowledgments................................................13
10.1 Informative References....................................13 11. References.....................................................13
11. Authors' Addresses.............................................13 11.1 Normative References......................................13
11.2 Informative References....................................13
12. Authors' Addresses.............................................14
13. RFC-Editor Consideration.......................................14
1. Introduction 1. Introduction
This document specifies the payload format for sending BroadVoice This document specifies the payload format for sending BroadVoice
encoded speech or audio signals using the Real-time Transport encoded speech or audio signals using the Real-time Transport
Protocol (RTP) [1]. The sender may send one or more BroadVoice Protocol (RTP) [1]. The sender may send one or more BroadVoice
codec data frames per packet, depending on the application scenario, codec data frames per packet, depending on the application scenario,
based on network conditions, bandwidth availability, delay based on network conditions, bandwidth availability, delay
requirements, and packet-loss tolerance. requirements, and packet-loss tolerance.
skipping to change at page 3, line 23 skipping to change at page 3, line 25
BroadVoice also has relatively low codec complexity when compared BroadVoice also has relatively low codec complexity when compared
with ITU-T standard speech codecs based on CELP (Coded Excited with ITU-T standard speech codecs based on CELP (Coded Excited
Linear Prediction), such as G.728, G.729, G.723.1, G.722.2, etc. Linear Prediction), such as G.728, G.729, G.723.1, G.722.2, etc.
Full-duplex implementations of the BV16 and BV32 take around 12 and Full-duplex implementations of the BV16 and BV32 take around 12 and
17 MIPS, respectively, on general-purpose 16-bit fixed-point DSPs. 17 MIPS, respectively, on general-purpose 16-bit fixed-point DSPs.
The total memory footprints of the BV16 and BV32, including program The total memory footprints of the BV16 and BV32, including program
size, data tables, and data RAM, are around 12 kwords each, or 24 size, data tables, and data RAM, are around 12 kwords each, or 24
kbytes. kbytes.
The BV16 codec was standardized by Cable Television Laboratories, The PacketCable(TM) project of Cable Television Laboratories, Inc.
Inc. (CableLabs) as a standard codec for use in VoIP (Voice over (CableLabs(r)) has chosen the BV16 codec for use in VoIP (Voice
Internet Protocol) telephone services provided by cable operators. over Internet Protocol) telephone services provided by cable
More specifically, the BV16 codec was selected as one of the operators. More specifically, the BV16 codec was selected as one
mandatory audio codecs in PacketCable (TM) 1.1 Audio/Video Codecs of the mandatory audio codecs in PacketCable (TM) 1.5 Audio/Video
Specification [4]. Codecs Specification [4].
3. RTP Payload Format for BroadVoice16 Narrowband Codec 3. RTP Payload Format for BroadVoice16 Narrowband Codec
The BroadVoice16 uses 5 ms frames and a sampling frequency of 8 kHz, 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 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 RTP timestamp indicates the sampling instant of the oldest audio
sample represented by the frame(s) present in the payload. The sample represented by the frame(s) present in the payload. The
RTP payload for the BroadVoice16 has the format shown in the figure RTP payload for the BroadVoice16 has the format shown in the figure
below. No additional header specific to this payload format is below. No additional header specific to this payload format is
required. required.
skipping to change at page 9, line 37 skipping to change at page 9, line 37
MIME media type name: audio MIME media type name: audio
MIME media subtype name: BV16 MIME media subtype name: BV16
Required parameter: none Required parameter: none
Optional parameters: Optional parameters:
The following parameters apply to RTP transfer only. The following parameters apply to RTP transfer only.
ptime: Defined as usual for RTP audio (see RFC YYYY [5]). ptime: Defined as usual for RTP audio (see RFC 2327 [5]).
maxptime: See RFC YYYY [5] for its definition. The maxptime maxptime: See RFC 2327 [5] for its definition. The maxptime
SHOULD be a multiple of the duration of a single codec data SHOULD be a multiple of the duration of a single codec data
frame (5 ms). ). frame (5 ms).
Encoding considerations: Encoding considerations:
This type is defined for transfer of BV16-encoded data via RTP This type is defined for transfer of BV16-encoded data via RTP
using the payload format specified in Sections 3 of RFC xxxx. using the payload format specified in Sections 3 of RFC XXXX.
It is also defined for other transfer methods using the storage It is also defined for other transfer methods using the storage
format specified in Section 5 of RFC xxxx. Audio data is binary format specified in Section 5 of RFC XXXX. Audio data is binary
data, and must be encoded for non-binary transport; the Base64 data, and must be encoded for non-binary transport; the Base64
encoding is suitable for Email. encoding is suitable for Email.
Security considerations: Security considerations:
See Section 8 "Security Considerations" of RFC xxxx. See Section 8 "Security Considerations" of RFC XXXX.
Public specification: Public specification:
The BroadVoice16 codec has been specified in [3]. The BroadVoice16 codec has been specified in [3].
Additional information: Additional information:
The following information applies to storage format only. The following information applies to storage format only.
Magic number: ASCII character string "#!BV16\n" (or "0x23 0x21 Magic number: ASCII character string "#!BV16\n" (or "0x23 0x21
0x42 0x56 0x31 0x36 0x0A" in hexadecimal) 0x42 0x56 0x31 0x36 0x0A" in hexadecimal)
skipping to change at page 10, line 44 skipping to change at page 10, line 44
MIME media type name: audio MIME media type name: audio
MIME media subtype name: BV32 MIME media subtype name: BV32
Required parameter: none Required parameter: none
Optional parameters: Optional parameters:
The following parameters apply to RTP transfer only. The following parameters apply to RTP transfer only.
ptime: Defined as usual for RTP audio (see RFC YYYY [5]). ptime: Defined as usual for RTP audio (see RFC 2327 [5]).
maxptime: See RFC YYYY [5] for its definition. The maxptime maxptime: See RFC 2327 [5] for its definition. The maxptime
SHOULD be a multiple of the duration of a single codec data SHOULD be a multiple of the duration of a single codec data
frame (5 ms). frame (5 ms).
Encoding considerations: Encoding considerations:
This type is defined for transfer of BV32-encoded data via RTP This type is defined for transfer of BV32-encoded data via RTP
using the payload format specified in Sections 4 of RFC xxxx. using the payload format specified in Sections 4 of RFC XXXX.
It is also defined for other transfer methods using the storage It is also defined for other transfer methods using the storage
format specified in Section 5 of RFC xxxx. Audio data is binary format specified in Section 5 of RFC XXXX. Audio data is binary
data, and must be encoded for non-binary transport; the Base64 data, and must be encoded for non-binary transport; the Base64
encoding is suitable for Email. encoding is suitable for Email.
Security considerations: Security considerations:
See Section 8 "Security Considerations" of RFC xxxx . See Section 8 "Security Considerations" of RFC XXXX.
Additional information: Additional information:
The following information applies to storage format only. The following information applies to storage format only.
Magic number: ASCII character string "#!BV32\n" (or "0x23 0x21 Magic number: ASCII character string "#!BV32\n" (or "0x23 0x21
0x42 0x56 0x33 0x32 0x0A" in hexadecimal) 0x42 0x56 0x33 0x32 0x0A" in hexadecimal)
File extensions: bvw, BVW (stands for "BroadVoice, Wideband") File extensions: bvw, BVW (stands for "BroadVoice, Wideband")
Macintosh file type code: none Macintosh file type code: none
skipping to change at page 13, line 5 skipping to change at page 13, line 5
The general congestion control considerations for transporting RTP The general congestion control considerations for transporting RTP
data apply to BV16 and BV32 audio over RTP as well, see RTP [1] data apply to BV16 and BV32 audio over RTP as well, see RTP [1]
and any applicable RTP profile like AVP [7]. BV16 and BV32 do not and any applicable RTP profile like AVP [7]. BV16 and BV32 do not
have any built-in mechanism for reducing the bandwidth. Packing have any built-in mechanism for reducing the bandwidth. Packing
more frames in each RTP payload can reduce the number of packets more frames in each RTP payload can reduce the number of packets
sent and hence the overhead from IP/UDP/RTP headers, at the sent and hence the overhead from IP/UDP/RTP headers, at the
expense of increased delay and reduced error robustness against expense of increased delay and reduced error robustness against
packet losses. packet losses.
10. Normative References 10. Acknowledgments
The authors would like to thank Magnus Westerlung, Colin Perkins,
Allison Mankin, and Jean-Francois Mule for their review of this
document.
11. References
11.1 Normative References
[1] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, "RTP: [1] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, "RTP:
A Transport Protocol for Real-Time Applications", STD 64, A Transport Protocol for Real-Time Applications", STD 64,
RFC 3550, Internet Engineering Task Force, July 2003. RFC 3550, Internet Engineering Task Force, July 2003.
[2] S. Bradner, "Key words for use in RFCs to Indicate requirement [2] S. Bradner, "Key words for use in RFCs to Indicate requirement
Levels", BCP 14, RFC 2119, Internet Engineering Task Force, Levels", BCP 14, RFC 2119, Internet Engineering Task Force,
March 1997. March 1997.
[3] Cable Television Laboratories, Inc., BroadVoice(TM)16 Speech [3] Cable Television Laboratories, Inc., BroadVoice(TM)16 Speech
Codec Specification, Revision 1.2, October 30, 2003. Codec Specification, Revision 1.2, October 30, 2003.
[5] M. Handley et al., "SDP: Session Description Protocol", [5] M. Handley and V. Jacobson, "SDP: Session Description
draft-ietf-mmusic-sdp-new-20.txt, September 2004. Protocol", RC 2327, April 1998.
[6] J. Rosenberg and H. Schulzrinne, "An Offer/Answer Model with [6] J. Rosenberg and H. Schulzrinne, "An Offer/Answer Model with
the Session Description Protocol (SDP)", RFC 3264, Internet the Session Description Protocol (SDP)", RFC 3264, Internet
Engineering Task Force, June 2002. Engineering Task Force, June 2002.
[7] H. Schulzrinne and S. Casner, "RTP Profile for Audio and Video [7] H. Schulzrinne and S. Casner, "RTP Profile for Audio and Video
Conferences with Minimal Control", STD 65, RFC 3551, Internet Conferences with Minimal Control", STD 65, RFC 3551, Internet
Engineering Task Force, July 2003. Engineering Task Force, July 2003.
10.1 Informative References 11.2 Informative References
[4] Cable Television Laboratories, Inc., PacketCable(TM) 1.1 [4] Cable Television Laboratories, Inc., PacketCable(TM) 1.5
Audio/Video Codecs Specification, PKT-SP-CODEC 1.1-I01-040621, Audio/Video Codecs Specification, PKT-SP-CODEC1.5-I01-050128,
June 21, 2004. January 28, 2005.
http://www.cablelabs.com/specifications/archives/
11. Authors' Addresses 12. Authors' Addresses
Juin-Hwey (Raymond) Chen Juin-Hwey (Raymond) Chen
Broadcom Corporation Broadcom Corporation
Room A3032 Room A3032
16215 Alton Parkway 16215 Alton Parkway
Irvine, CA 92618 Irvine, CA 92618
USA USA
Phone: +1 949 926 6288 Phone: +1 949 926 6288
Email: rchen@broadcom.com Email: rchen@broadcom.com
Winnie Lee Winnie Lee
Broadcom Corporation Broadcom Corporation
Room A2012E Room A2012E
200-13711 International Place 200-13711 International Place
Richmond, British Columbia V6V 2Z8 Richmond, British Columbia V6V 2Z8
Canada Canada
Phone: +1 604 233 8605 Phone: +1 604 233 8605
Email: wlee@broadcom.com Email: wlee@broadcom.com
Expires: June 7, 2005
Jes Thyssen Jes Thyssen
Broadcom Corporation Broadcom Corporation
Room A3053 Room A3053
16215 Alton Parkway 16215 Alton Parkway
Irvine, CA 92618 Irvine, CA 92618
USA USA
Phone: +1 949 926 5768 Phone: +1 949 926 5768
Email: jthyssen@broadcom.com Email: jthyssen@broadcom.com
Copyright (C) The Internet Society (2004). This document is subject 13. RFC-Editor Consideration
The RFC-editor is kindly requested to perform the following
modifications upon the publication of this specification:
- Replace all occurrences of RFC XXXX with the RFC number this
specification receives when being published.
- Remove this Section.
Expires: August 17, 2005
Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights. except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/