draft-ietf-avt-rtp-bv-03.txt   draft-ietf-avt-rtp-bv-04.txt 
Internet Draft Juin-Hwey Chen Internet Draft Juin-Hwey Chen
draft-ietf-avt-rtp-bv-03.txt Winnie Lee draft-ietf-avt-rtp-bv-04.txt Winnie Lee
February 17, 2005 Jes Thyssen April 4, 2005 Jes Thyssen
Expires: August 17, 2005 Broadcom Corporation Expires: October 4, 2005 Broadcom Corporation
RTP Payload and Storage Format for BroadVoice Speech Codecs RTP Payload 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, each author represents that any
patent or other IPR claims of which we are aware have been applicable patent or other IPR claims of which he or she is aware
disclosed, or will be disclosed, and any of which we become aware have been or will be disclosed, and any of which he or she becomes
will be disclosed, in accordance with RFC 3668. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as other groups may also distribute working documents as
Internet-Drafts. Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress." reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Abstract Abstract
This document describes the RTP payload format and the storage This document describes the RTP payload format for the
format for the BroadVoice(TM) narrowband and wideband speech codecs BroadVoice(TM) narrowband and wideband speech codecs developed by
developed by Broadcom Corporation. The document also provides Broadcom Corporation. The document also provides specifications
specifications for the use of BroadVoice with MIME and SDP. for the use of BroadVoice with MIME and SDP.
Table of Contents Table of Contents
1. Introduction....................................................2 1. Introduction....................................................2
2. Background......................................................2 2. Background......................................................2
3. RTP Payload Format for BroadVoice16 Narrowband Codec............3 3. RTP Payload Format for BroadVoice16 Narrowband Codec............3
3.1 BroadVoice16 Bit Stream Definition..........................4 3.1 BroadVoice16 Bit Stream Definition..........................4
3.2 Multiple BroadVoice16 Frames in an RTP Packet...............5 3.2 Multiple BroadVoice16 Frames in an RTP Packet...............5
4. RTP Payload Format for BroadVoice32 Wideband Codec..............6 4. RTP Payload Format for BroadVoice32 Wideband Codec..............6
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. IANA Considerations.............................................8
6. IANA Considerations.............................................9 5.1 MIME Registration of BroadVoice16...........................9
6.1 MIME Registration of BroadVoice16...........................9 5.2 MIME Registration of BroadVoice32...........................9
6.2 MIME Registration of BroadVoice32..........................10 6. Mapping to SDP Parameters......................................10
7. Mapping to SDP Parameters......................................11 6.1 Offer-Answer Model Considerations..........................11
7.1 Offer-Answer Model Considerations..........................12 7. Security Considerations........................................11
8. Security Considerations........................................12 8. Congestion Control.............................................11
9. Congestion Control.............................................12 9. Acknowledgments................................................12
10. Acknowledgments................................................13 10. References.....................................................12
11. References.....................................................13 10.1 Normative References......................................12
11.1 Normative References......................................13 10.2 Informative References....................................12
11.2 Informative References....................................13 11. Authors' Addresses.............................................13
12. Authors' Addresses.............................................14 12. RFC-Editor Consideration.......................................13
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.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in RFC 2119 [2]. this document are to be interpreted as described in RFC 2119 [2].
2. Background 2. Background
BroadVoice is a speech codec family developed by Broadcom for VoIP BroadVoice is a speech codec family developed by Broadcom for VoIP
applications, including Voice over Cable, Voice over DSL, and IP (Voice over Internet Protocol) applications, including Voice over
phone applications. BroadVoice achieves high speech quality with Cable, Voice over DSL, and IP phone applications. BroadVoice
a low coding delay and relatively low codec complexity. achieves high speech quality with a low coding delay and relatively
low codec complexity.
The BroadVoice codec family contains two codec versions. The The BroadVoice codec family contains two codec versions. The
narrowband version of BroadVoice, called BroadVoice16 [3], or BV16 narrowband version of BroadVoice, called BroadVoice16 [3], or BV16
for short, encodes 8 kHz-sampled narrowband speech at a bit rate of for short, encodes 8 kHz-sampled narrowband speech at a bit rate of
16 kilobits/second, or 16 kbit/s. The wideband version of 16 kilobits/second, or 16 kbit/s. The wideband version of
BroadVoice, called BroadVoice32, or BV32, encodes 16 kHz-sampled BroadVoice, called BroadVoice32, or BV32, encodes 16 kHz-sampled
wideband speech at a bit rate of 32 kbit/s. The BV16 and BV32 use wideband speech at a bit rate of 32 kbit/s. The BV16 and BV32 use
very similar (but not identical) coding algorithms; they share most very similar (but not identical) coding algorithms; they share most
of their algorithm modules. of their algorithm modules.
skipping to change at page 3, line 26 skipping to change at page 3, line 26
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 PacketCable(TM) project of Cable Television Laboratories, Inc. The PacketCable(TM) project of Cable Television Laboratories, Inc.
(CableLabs(r)) has chosen the BV16 codec for use in VoIP (Voice (CableLabs(r)) has chosen the BV16 codec for use in VoIP telephone
over Internet Protocol) telephone services provided by cable services provided by cable operators. More specifically, the BV16
operators. More specifically, the BV16 codec was selected as one codec was selected as one of the mandatory audio codecs in
of the mandatory audio codecs in PacketCable (TM) 1.5 Audio/Video PacketCable (TM) 1.5 Audio/Video Codecs 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 8, line 19 skipping to change at page 8, line 19
restrictions: restrictions:
o SHOULD NOT include more BroadVoice32 frames in a single RTP o SHOULD NOT include more BroadVoice32 frames in a single RTP
packet than will fit in the MTU of the RTP transport protocol. packet than will fit in the MTU of the RTP transport protocol.
o MUST NOT split a BroadVoice32 frame between RTP packets. o MUST NOT split a BroadVoice32 frame between RTP packets.
o BroadVoice32 frames in an RTP packet MUST be consecutive. o BroadVoice32 frames in an RTP packet MUST be consecutive.
Since multiple BroadVoice32 frames in an RTP packet MUST be Since multiple BroadVoice32 frames in an RTP packet MUST be
consecutive, and since BroadVoice16 has a fixed frame size of 5 ms, consecutive, and since BroadVoice32 has a fixed frame size of 5 ms,
recovering the timestamps of all frames within a packet is easy. recovering the timestamps of all frames within a packet is easy.
The oldest frame within an RTP packet has the same timestamp as the The oldest frame within an RTP packet has the same timestamp as the
RTP packet, as mentioned above. To obtain the timestamp of 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, 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 one simply adds 5*N ms worth of time units to the timestamp of the
RTP packet. RTP packet.
It is RECOMMENDED that the number of frames contained within an RTP It is RECOMMENDED that the number of frames contained within an RTP
packet is consistent with the application. For example, in a packet is consistent with the application. For example, in a
telephony application where delay is important, the fewer frames per telephony application where delay is important, the fewer frames per
packet the lower the delay, whereas for a delay insensitive packet the lower the delay, whereas for a delay insensitive
streaming or messaging application, many frames per packet would be streaming or messaging application, many frames per packet would be
acceptable. acceptable.
Information describing the number of frames contained in an RTP Information describing the number of frames contained in an RTP
packet is not transmitted as part of the RTP payload. The only way 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 to determine the number of BroadVoice32 frames is to count the total
number of octets within the RTP payload, and divide the octet count number of octets within the RTP payload, and divide the octet count
by 20. by 20.
5. Storage Format 5. IANA Considerations
The storage format is used for storing speech frames, e.g., as a
file or e-mail attachment.
The file begins with a header that includes only a magic number to
identify the codec that is used. The magic number for the
BroadVoice16 narrowband codec MUST correspond to the ASCII character
string "#!BV16\n", or "0x23 0x21 0x42 0x56 0x31 0x36 0x0A" in
hexadecimal format. The magic number for the BroadVoice32 wideband
codec MUST correspond to the ASCII character string "#!BV32\n", or
"0x23 0x21 0x42 0x56 0x33 0x32 0x0A". A file contains the encoded
bit stream of either BroadVoice16 or BroadVoice32, but not both. In
other words, BroadVoice16 frames and BroadVoice32 frames MUST NOT be
mixed in the same file.
After the header that contains the magic number identifying the
codec used, the encoded codec data frames are stored in a sequential
order, as shown below. All encoded codec data frames must be
present, otherwise synchronization problems will arise.
+--------+---------------+---------------+-----+---------------+
| Header | Codec frame 1 | Codec frame 2 | ... | Codec frame N |
+--------+---------------+---------------+-----+---------------+
6. IANA Considerations
Two new MIME sub-types as described in this section are to be Two new MIME sub-types as described in this section are to be
registered. registered.
The MIME names for the BV16 and BV32 codecs are to be allocated from The MIME names for the BV16 and BV32 codecs are to be allocated from
the IETF tree since these two codecs are expected to be widely used the IETF tree since these two codecs are expected to be widely used
for Voice-over-IP applications, especially in Voice over Cable for Voice-over-IP applications, especially in Voice over Cable
applications. applications.
6.1 MIME Registration of BroadVoice16 for RTP 5.1 MIME Registration of BroadVoice16 for RTP
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.
ptime: Defined as usual for RTP audio (see RFC 2327 [5]). ptime: Defined as usual for RTP audio (see RFC 2327 [5]).
maxptime: See RFC 2327 [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 Audio data is binary data and must be encoded for non-binary
format specified in Section 5 of RFC XXXX. Audio data is binary transport; the Base64 encoding is suitable for Email.
data, and must be encoded for non-binary transport; the Base64
encoding is suitable for Email.
Security considerations: Security considerations:
See Section 8 "Security Considerations" of RFC XXXX. See Section 7 "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:
The following information applies to storage format only.
Magic number: ASCII character string "#!BV16\n" (or "0x23 0x21
0x42 0x56 0x31 0x36 0x0A" in hexadecimal)
File extensions: bvn, BVN (stands for "BroadVoice, Narrowband")
Macintosh file type code: none
Object identifier or OID: none
Intended usage: Intended usage:
COMMON. It is expected that many VoIP applications, especially COMMON. It is expected that many VoIP applications, especially
Voice over Cable applications, will use this type. Voice over Cable applications, will use this type.
Person & email address to contact for further information: Person & email address to contact for further information:
Juin-Hwey (Raymond) Chen Juin-Hwey (Raymond) Chen
rchen@broadcom.com rchen@broadcom.com
Author/Change controller: Author/Change controller:
Author: Juin-Hwey (Raymond) Chen, rchen@broadcom.com Author: Juin-Hwey (Raymond) Chen, rchen@broadcom.com
Change Controller: IETF Audio/Video Transport Working Group Change Controller: IETF Audio/Video Transport Working Group
delegated from the IESG delegated from the IESG
6.2 MIME Registration of BroadVoice32 for RTP 5.2 MIME Registration of BroadVoice32 for RTP
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.
ptime: Defined as usual for RTP audio (see RFC 2327 [5]). ptime: Defined as usual for RTP audio (see RFC 2327 [5]).
maxptime: See RFC 2327 [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 Audio data is binary data and must be encoded for non-binary
format specified in Section 5 of RFC XXXX. Audio data is binary transport; the Base64 encoding is suitable for Email.
data, and must be encoded for non-binary transport; the Base64
encoding is suitable for Email.
Security considerations: Security considerations:
See Section 8 "Security Considerations" of RFC XXXX. See Section 7 "Security Considerations" of RFC XXXX.
Additional information:
The following information applies to storage format only.
Magic number: ASCII character string "#!BV32\n" (or "0x23 0x21
0x42 0x56 0x33 0x32 0x0A" in hexadecimal)
File extensions: bvw, BVW (stands for "BroadVoice, Wideband")
Macintosh file type code: none
Object identifier or OID: none
Intended usage: Intended usage:
COMMON. It is expected that many VoIP applications, especially COMMON. It is expected that many VoIP applications, especially
Voice over Cable applications, will use this type. Voice over Cable applications, will use this type.
Person & email address to contact for further information: Person & email address to contact for further information:
Juin-Hwey (Raymond) Chen Juin-Hwey (Raymond) Chen
rchen@broadcom.com rchen@broadcom.com
Author/Change controller: Author/Change controller:
Author: Juin-Hwey (Raymond) Chen, rchen@broadcom.com Author: Juin-Hwey (Raymond) Chen, rchen@broadcom.com
Change Controller: IETF Audio/Video Transport Working Group Change Controller: IETF Audio/Video Transport Working Group
delegated from the IESG delegated from the IESG
7. Mapping to SDP Parameters 6. Mapping to SDP Parameters
The information carried in the MIME media type specification has a The information carried in the MIME media type specification has a
specific mapping to fields in the Session Description Protocol (SDP) specific mapping to fields in the Session Description Protocol (SDP)
[5], which is commonly used to describe RTP sessions. When SDP is [5], which is commonly used to describe RTP sessions. When SDP is
used to specify sessions employing the BroadVoice16 or BroadVoice32 used to specify sessions employing the BroadVoice16 or BroadVoice32
codec, the mapping is as follows: codec, the mapping is as follows:
- The MIME type ("audio") goes in SDP "m=" as the media name. - The MIME type ("audio") goes in SDP "m=" as the media name.
- The MIME subtype (payload format name) goes in SDP "a=rtpmap" - The MIME subtype (payload format name) goes in SDP "a=rtpmap"
skipping to change at page 12, line 17 skipping to change at page 11, line 17
m=audio 49120 RTP/AVP 97 m=audio 49120 RTP/AVP 97
a=rtpmap:97 BV16/8000 a=rtpmap:97 BV16/8000
An example of the media representation in SDP for describing BV32 An example of the media representation in SDP for describing BV32
might be: might be:
m=audio 49122 RTP/AVP 99 m=audio 49122 RTP/AVP 99
a=rtpmap:99 BV32/16000 a=rtpmap:99 BV32/16000
7.1 Offer-Answer Model Considerations 6.1 Offer-Answer Model Considerations
No special considerations are need for using the SDP Offer/Answer No special considerations are need for using the SDP Offer/Answer
model [6] with the BV16 and BV32 RTP payload formats. model [6] with the BV16 and BV32 RTP payload formats.
8. Security Considerations 7. Security Considerations
RTP packets using the payload format defined in this specification RTP packets using the payload format defined in this specification
are subject to the security considerations discussed in the RTP are subject to the security considerations discussed in the RTP
specification [1] and any appropriate profile (for example, [7]). specification [1] and any appropriate profile (for example, [7]).
This implies that confidentiality of the media streams is achieved This implies that confidentiality of the media streams is achieved
by encryption. Because the data compression used with this payload by encryption. Because the data compression used with this payload
format is applied end-to-end, encryption may be performed after format is applied end-to-end, encryption may be performed after
compression so there is no conflict between the two operations. compression so there is no conflict between the two operations.
A potential denial-of-service threat exists for data encoding using A potential denial-of-service threat exists for data encoding using
compression techniques that have non-uniform receiver-end compression techniques that have non-uniform receiver-end
computational load. The attacker can inject pathological datagrams computational load. The attacker can inject pathological datagrams
into the stream which are complex to decode and cause the receiver into the stream which are complex to decode and cause the receiver
to become overloaded. However, the encodings covered in this to become overloaded. However, the encodings covered in this
document do not exhibit any significant non-uniformity. document do not exhibit any significant non-uniformity.
9. Congestion Control 8. Congestion Control
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. Acknowledgments 9. Acknowledgments
The authors would like to thank Magnus Westerlung, Colin Perkins, The authors would like to thank Magnus Westerlung, Colin Perkins,
Allison Mankin, and Jean-Francois Mule for their review of this Allison Mankin, and Jean-Francois Mule for their review of this
document. document.
11. References 10. References
11.1 Normative References 10.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
skipping to change at page 13, line 37 skipping to change at page 12, line 37
Protocol", RC 2327, April 1998. 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.
11.2 Informative References 10.2 Informative References
[4] Cable Television Laboratories, Inc., PacketCable(TM) 1.5 [4] Cable Television Laboratories, Inc., PacketCable(TM) 1.5
Audio/Video Codecs Specification, PKT-SP-CODEC1.5-I01-050128, Audio/Video Codecs Specification, PKT-SP-CODEC1.5-I01-050128,
January 28, 2005. January 28, 2005.
http://www.cablelabs.com/specifications/archives/ http://www.cablelabs.com/specifications/archives/
12. Authors' Addresses 11. Authors' Addresses
Juin-Hwey (Raymond) Chen Juin-Hwey (Raymond) Chen
Broadcom Corporation Broadcom Corporation
Room A3032 Room A3020
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
Jes Thyssen Jes Thyssen
Broadcom Corporation Broadcom Corporation
Room A3053 Room A3018
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
13. RFC-Editor Consideration 12. RFC-Editor Consideration
The RFC-editor is kindly requested to perform the following The RFC-editor is kindly requested to perform the following
modifications upon the publication of this specification: modifications upon the publication of this specification:
- Replace all occurrences of RFC XXXX with the RFC number this - Replace all occurrences of RFC XXXX with the RFC number this
specification receives when being published. specification receives when being published.
- Remove this Section. - Remove this Section.
Expires: August 17, 2005 Expires: October 4, 2005
Copyright (C) The Internet Society (2005). This document is subject 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
 End of changes. 

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