draft-ietf-avt-rtp-bv-01.txt   draft-ietf-avt-rtp-bv-02.txt 
Internet Draft Juin-Hwey Chen Internet Draft Juin-Hwey Chen
draft-ietf-avt-rtp-bv-01.txt Winnie Lee draft-ietf-avt-rtp-bv-02.txt Winnie Lee
August 25, 2004 Jes Thyssen December 7, 2004 Jes Thyssen
Expires: February 25, 2005 Broadcom Corporation Expires: June 7, 2005 Broadcom Corporation
RTP Payload 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.
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 Internet- other groups may also distribute working documents as
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 for the This document describes the RTP payload format and the storage
BroadVoice(TM) narrowband and wideband speech codecs developed by format for the BroadVoice(TM) narrowband and wideband speech codecs
Broadcom Corporation. The document also provides specifications for developed by Broadcom Corporation. The document also provides
the use of BroadVoice with MIME and SDP. specifications 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 Packets..............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. 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. Normative References...........................................13
10.1 Informative References....................................13 10.1 Informative References....................................13
11. Authors' Addresses.............................................13 11. Authors' Addresses.............................................13
1. Introduction 1. Introduction
skipping to change at page 3, line 34 skipping to change at page 3, line 34
Inc. (CableLabs) as a standard codec for use in VoIP (Voice over Inc. (CableLabs) as a standard codec for use in VoIP (Voice over
Internet Protocol) telephone services provided by cable operators. Internet Protocol) telephone services provided by cable operators.
More specifically, the BV16 codec was selected as one of the More specifically, the BV16 codec was selected as one of the
mandatory audio codecs in PacketCable (TM) 1.1 Audio/Video Codecs mandatory audio codecs in PacketCable (TM) 1.1 Audio/Video Codecs
Specification [4]. 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
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.
0 1 2 3 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 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] | | RTP Header [1] |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| | | |
| one or more frames of BroadVoice16 | | one or more frames of BroadVoice16 |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
When more than one codec data frame is present in a single RTP
packet, the timestamp is, as always, that of the oldest data frame
represented in the RTP packet.
If BroadVoice16 is used for applications with silence compression, If BroadVoice16 is used for applications with silence compression,
the first BroadVoice16 packet after a silence period during which the first BroadVoice16 packet after a silence period during which
packets have not been transmitted contiguously, SHOULD have the packets have not been transmitted contiguously, SHOULD have the
marker bit in the RTP data header set to one. The marker bit marker bit in the RTP data header set to one. The marker bit
in all other packets is zero. Applications without silence in all other packets is zero. Applications without silence
suppression MUST set the marker bit to zero. suppression MUST set the marker bit to zero.
The assignment of an RTP payload type for this new packet format is 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. outside the scope of this document, and will not be specified here.
It is expected that the RTP profile for a particular class of It is expected that the RTP profile for a particular class of
skipping to change at page 5, line 24 skipping to change at page 5, line 24
| | | | | | | | | | | | | | | |
|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| |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 | |V| V7 | V8 | V9 |
|6| | | | |6| | | |
|4|0 1 2 3 4|0 1 2 3 4|0 1 2 3 4| |4|0 1 2 3 4|0 1 2 3 4|0 1 2 3 4|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: BroadVoice16 bit packing Figure 1: BroadVoice16 bit packing
3.2 Multiple BroadVoice16 Frames in An RTP Packet 3.2 Multiple BroadVoice16 Frames in an RTP Packet
More than one BroadVoice16 frame MAY be included in a single RTP More than one BroadVoice16 frame MAY be included in a single RTP
packet by a sender. Senders have the following additional packet by a sender. Senders have the following additional
restrictions: restrictions:
o SHOULD NOT include more BroadVoice16 frames in a single RTP o SHOULD NOT include more BroadVoice16 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 BroadVoice16 frame between RTP packets. o MUST NOT split a BroadVoice16 frame between RTP packets.
skipping to change at page 6, line 15 skipping to change at page 6, line 15
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 BroadVoice16 frames is to count the total to determine the number of BroadVoice16 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 10. by 10.
4. RTP Payload Format for BroadVoice32 Wideband Codec 4. RTP Payload Format for BroadVoice32 Wideband Codec
The BroadVoice32 uses 5 ms frames and a sampling frequency of 16 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. 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 The RTP payload for the BroadVoice32 has the format shown in the
figure below. No additional header specific to this payload format figure below. No additional header specific to this payload format
is required. is required.
0 1 2 3 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 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] | | RTP Header [1] |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| | | |
| one or more frames of BroadVoice32 | | one or more frames of BroadVoice32 |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
When more than one codec data frame is present in a single RTP
packet, the timestamp is, as always, that of the oldest data frame
represented in the RTP packet.
If BroadVoice32 is used for applications with silence compression, If BroadVoice32 is used for applications with silence compression,
the first BroadVoice32 packet after a silence period during which the first BroadVoice32 packet after a silence period during which
packets have not been transmitted contiguously, SHOULD have the packets have not been transmitted contiguously, SHOULD have the
marker bit in the RTP data header set to one. The marker bit marker bit in the RTP data header set to one. The marker bit
in all other packets is zero. Applications without silence in all other packets is zero. Applications without silence
suppression MUST set the marker bit to zero. suppression MUST set the marker bit to zero.
The assignment of an RTP payload type for this new packet format is 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. outside the scope of this document, and will not be specified here.
It is expected that the RTP profile for a particular class of It is expected that the RTP profile for a particular class of
skipping to change at page 8, line 5 skipping to change at page 8, line 5
| | | | | | | | | | | | | |
|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| |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 | |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| |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 Figure 2: BroadVoice32 bit packing
4.2 Multiple BroadVoice32 Frames in An RTP Packet 4.2 Multiple BroadVoice32 Frames in an RTP Packet
More than one BroadVoice32 frame MAY be included in a single RTP More than one BroadVoice32 frame MAY be included in a single RTP
packet by a sender. Senders have the following additional packet by a sender. Senders have the following additional
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.
skipping to change at page 9, line 26 skipping to change at page 9, line 26
6. IANA Considerations 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 6.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. The following parameters apply to RTP transfer only.
ptime: Defined as usual for RTP audio (see RFC 2327). ptime: Defined as usual for RTP audio (see RFC YYYY [5]).
maxptime: See [5] for its definition. The maxptime SHOULD be a maxptime: See RFC YYYY [5] for its definition. The maxptime
multiple of the duration of a single codec data frame (5 ms). SHOULD be a multiple of the duration of a single codec data
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:
skipping to change at page 10, line 31 skipping to change at page 10, line 31
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
6.2 MIME registration of BroadVoice32 6.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. The following parameters apply to RTP transfer only.
ptime: Defined as usual for RTP audio (see RFC 2327). ptime: Defined as usual for RTP audio (see RFC YYYY [5]).
maxptime: See [5] for its definition. The maxptime SHOULD be a maxptime: See RFC YYYY [5] for its definition. The maxptime
multiple of the duration of a single codec data frame (5 ms). SHOULD be a multiple of the duration of a single codec data
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:
skipping to change at page 11, line 33 skipping to change at page 11, line 34
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
7. Mapping to SDP Parameters 7. 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)
[6], 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"
as the encoding name. The RTP clock rate in "a=rtpmap" MUST as the encoding name. The RTP clock rate in "a=rtpmap" MUST
be 8000 for BV16 and 16000 for BV32. be 8000 for BV16 and 16000 for BV32.
- The parameters "ptime" and "maxptime" go in the SDP "a=ptime" - The parameters "ptime" and "maxptime" go in the SDP "a=ptime"
skipping to change at page 12, line 20 skipping to change at page 12, line 20
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 7.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 [7] with the BV16 and BV32 RTP payload formats. model [6] with the BV16 and BV32 RTP payload formats.
8. Security Considerations 8. 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, [8]). 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 9. Congestion Control
The general congestion control considerations for transporting RTP data The general congestion control considerations for transporting RTP
apply to BV16 and BV32 audio over RTP as well, see RTP [1] and any data apply to BV16 and BV32 audio over RTP as well, see RTP [1]
applicable RTP profile like AVP [8]. BV16 and BV32 do not have and any applicable RTP profile like AVP [7]. BV16 and BV32 do not
any built-in mechanism for reducing the bandwidth. Packing more frames have any built-in mechanism for reducing the bandwidth. Packing
in each RTP payload can reduce the number of packets sent and hence the more frames in each RTP payload can reduce the number of packets
overhead from IP/UDP/RTP headers, at the expense of increased delay and sent and hence the overhead from IP/UDP/RTP headers, at the
reduced error robustness against packet losses. expense of increased delay and reduced error robustness against
packet losses.
10. Normative References 10. 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 et al., "SDP: Session Description Protocol",
draft-ietf-mmusic-sdp-new-17.txt, June 2004. draft-ietf-mmusic-sdp-new-20.txt, September 2004.
[6] M. Handley and V. Jacobson, "SDP: Session Description Protocol",
RFC 2327, Internet Engineering Task Force, April 1998.
[7] 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.
[8] 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 10.1 Informative References
[4] Cable Television Laboratories, Inc., PacketCable(TM) 1.1 [4] Cable Television Laboratories, Inc., PacketCable(TM) 1.1
Audio/Video Codecs Specification, PKT-SP-CODEC 1.1-I01-040621, Audio/Video Codecs Specification, PKT-SP-CODEC 1.1-I01-040621,
June 21, 2004. June 21, 2004.
11. Authors' Addresses 11. 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
Expires: January 25, 2005
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 Copyright (C) The Internet Society (2004). 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.
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.
 End of changes. 

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