draft-ietf-avt-rtp-bv-00.txt   draft-ietf-avt-rtp-bv-01.txt 
Internet Draft Juin-Hwey Chen Internet Draft Juin-Hwey Chen
draft-ietf-avt-rtp-bv-00.txt Winnie Lee draft-ietf-avt-rtp-bv-01.txt Winnie Lee
July 9, 2004 Jes Thyssen August 25, 2004 Jes Thyssen
Expires: January 9, 2005 Broadcom Corporation Expires: February 25, 2005 Broadcom Corporation
RTP Payload Format for BroadVoice Speech Codecs RTP Payload Format for BroadVoice Speech Codecs
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.
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
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 Internet-
Drafts. 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."
skipping to change at page 2, line 20 skipping to change at page 2, line 20
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 Packets..............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
8. Security Considerations........................................12 8. Security Considerations........................................12
9. Normative References...........................................12 9. Congestion Control.............................................12
9.1 Informative References.....................................13 10. Normative References...........................................13
10. Authors' Addresses............................................13 10.1 Informative References....................................13
11. Authors' Addresses.............................................13
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 30 skipping to change at page 3, line 33
The BV16 codec was standardized by Cable Television Laboratories, The BV16 codec was standardized by Cable Television Laboratories,
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 RTP so the RTP timestamp MUST be in units of 1/8000 of a second. The
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 |
skipping to change at page 5, line 26 skipping to change at page 5, line 26
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|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.
o BroadVoice16 frames in an RTP packet MUST be consecutive. o BroadVoice16 frames in an RTP packet MUST be consecutive.
Since multiple BroadVoice16 frames in an RTP packet MUST be Since multiple BroadVoice16 frames in an RTP packet MUST be
consecutive, and since BroadVoice16 has a fixed frame size of 5 ms, consecutive, and since BroadVoice16 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 order 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 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 packet, 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 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.
skipping to change at page 8, line 7 skipping to change at page 8, line 7
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|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.
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 BroadVoice16 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 order 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 packet, 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. Storage Format
The storage format is used for storing speech frames, e.g., as a The storage format is used for storing speech frames, e.g., as a
file or e-mail attachment. file or e-mail attachment.
The file begins with a header that includes only a magic number to The file begins with a header that includes only a magic number to
identify the codec that is used. The magic number for the identify the codec that is used. The magic number for the
BroadVoice16 narrowband codec MUST correspond to the ASCII character BroadVoice16 narrowband codec MUST correspond to the ASCII character
string "#!BV16\n", or "0x23 0x21 0x42 0x56 0x31 0x36 0x0A" in string "#!BV16\n", or "0x23 0x21 0x42 0x56 0x31 0x36 0x0A" in
hexadecimal format. The magic number for the BroadVoice32 wideband hexadecimal format. The magic number for the BroadVoice32 wideband
codec MUST correspond to the ASCII character string "#!BV32\n", or codec MUST correspond to the ASCII character string "#!BV32\n", or
"0x23 0x21 0x42 0x56 0x33 0x32 0x0A". A file contains the encoded "0x23 0x21 0x42 0x56 0x33 0x32 0x0A". A file contains the encoded
bit stream of either BroadVoice16 or BroadVoice32, but not both. In bit stream of either BroadVoice16 or BroadVoice32, but not both. In
other words, BroadVoice16 frames and BroadVoice32 frames MUST NOT be other words, BroadVoice16 frames and BroadVoice32 frames MUST NOT be
mixed in the same file. mixed in the same file.
After the header that contains the magic number identifying the After the header that contains the magic number identifying the
codec used, the encoded codec data frames are stored in a sequential codec used, the encoded codec data frames are stored in a sequential
order, as shown below. 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 | | Header | Codec frame 1 | Codec frame 2 | ... | Codec frame N |
+--------+---------------+---------------+-----+---------------+ +--------+---------------+---------------+-----+---------------+
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.
skipping to change at page 11, line 34 skipping to change at page 11, line 34
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
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 [6], 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"
and "a=maxptime" attributes, respectively. and "a=maxptime" attributes, respectively.
- Any remaining parameters go in the SDP "a=fmtp" attribute by
copying them directly from the MIME media type string as a
semicolon separated list of parameter=value pairs.
An example of the media representation in SDP for describing BV16 An example of the media representation in SDP for describing BV16
might be: might be:
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
No special considerations are need for using the SDP Offer/Answer
model [7] 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, [7]). specification [1] and any appropriate profile (for example, [8]).
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. Normative References 9. 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 [8]. 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.
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", IETF RFC 1889, A Transport Protocol for Real-Time Applications", STD 64,
January 1996. 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, March 1997. Levels", BCP 14, RFC 2119, Internet Engineering Task Force,
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-17.txt, June 2004.
[6] M. Handley and V. Jacobson, "SDP: Session Description Protocol", [6] M. Handley and V. Jacobson, "SDP: Session Description Protocol",
IETF RFC 2327, April 1998. RFC 2327, Internet Engineering Task Force, April 1998.
[7] H. Schulzrinne, "RTP Profile for Audio and Video Conferences [7] J. Rosenberg and H. Schulzrinne, "An Offer/Answer Model with
with Minimal Control" IETF RFC 1890, January 1996. the Session Description Protocol (SDP)", RFC 3264, Internet
Engineering Task Force, June 2002.
9.1 Informative References [8] H. Schulzrinne and S. Casner, "RTP Profile for Audio and Video
Conferences with Minimal Control", STD 65, RFC 3551, Internet
Engineering Task Force, July 2003.
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.
10. 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
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
Expires: January 9, 2005
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.
 End of changes. 

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