draft-ietf-avt-rtp-g729-scal-wb-ext-02.txt   draft-ietf-avt-rtp-g729-scal-wb-ext-03.txt 
Network Working Group A. Sollaud Network Working Group A. Sollaud
Internet-Draft France Telecom Internet-Draft France Telecom
Expires: August 19, 2006 February 15, 2006 Expires: September 2, 2006 March 1, 2006
RTP payload format for the G.729EV audio codec RTP payload format for the G.729EV audio codec
draft-ietf-avt-rtp-g729-scal-wb-ext-02 draft-ietf-avt-rtp-g729-scal-wb-ext-03
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. 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
skipping to change at page 1, line 33 skipping to change at page 1, line 33
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." 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/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
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.
This Internet-Draft will expire on August 19, 2006. This Internet-Draft will expire on September 2, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The Internet Society (2006).
Abstract Abstract
This document specifies a real-time transport protocol (RTP) payload This document specifies a real-time transport protocol (RTP) payload
format to be used for the International Telecommunication Union format to be used for the International Telecommunication Union
(ITU-T) G.729EV audio codec. A media type registration is included (ITU-T) G.729EV audio codec. A media type registration is included
skipping to change at page 2, line 14 skipping to change at page 2, line 14
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Embedded bit rates considerations . . . . . . . . . . . . . . 4 3. Embedded bit rates considerations . . . . . . . . . . . . . . 4
4. RTP header usage . . . . . . . . . . . . . . . . . . . . . . . 4 4. RTP header usage . . . . . . . . . . . . . . . . . . . . . . . 4
5. Payload format . . . . . . . . . . . . . . . . . . . . . . . . 5 5. Payload format . . . . . . . . . . . . . . . . . . . . . . . . 5
5.1. Payload structure . . . . . . . . . . . . . . . . . . . . 5 5.1. Payload structure . . . . . . . . . . . . . . . . . . . . 5
5.2. Payload Header: MBS field . . . . . . . . . . . . . . . . 5 5.2. Payload Header: MBS field . . . . . . . . . . . . . . . . 5
5.3. Payload Header: FT field . . . . . . . . . . . . . . . . . 6 5.3. Payload Header: FT field . . . . . . . . . . . . . . . . . 7
5.4. Audio data . . . . . . . . . . . . . . . . . . . . . . . . 7 5.4. Audio data . . . . . . . . . . . . . . . . . . . . . . . . 7
6. Payload format parameters . . . . . . . . . . . . . . . . . . 8 6. Payload format parameters . . . . . . . . . . . . . . . . . . 8
6.1. Media type registration . . . . . . . . . . . . . . . . . 8 6.1. Media type registration . . . . . . . . . . . . . . . . . 8
6.2. Mapping to SDP parameters . . . . . . . . . . . . . . . . 9 6.2. Mapping to SDP parameters . . . . . . . . . . . . . . . . 10
6.3. Offer-answer model considerations . . . . . . . . . . . . 10 6.3. Offer-answer model considerations . . . . . . . . . . . . 10
7. Congestion control . . . . . . . . . . . . . . . . . . . . . . 11 7. Congestion control . . . . . . . . . . . . . . . . . . . . . . 12
8. Security considerations . . . . . . . . . . . . . . . . . . . 12 8. Security considerations . . . . . . . . . . . . . . . . . . . 12
9. IANA considerations . . . . . . . . . . . . . . . . . . . . . 12 9. IANA considerations . . . . . . . . . . . . . . . . . . . . . 13
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
10.1. Normative references . . . . . . . . . . . . . . . . . . . 12 10.1. Normative references . . . . . . . . . . . . . . . . . . . 13
10.2. Informative references . . . . . . . . . . . . . . . . . . 13 10.2. Informative references . . . . . . . . . . . . . . . . . . 13
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 15
Intellectual Property and Copyright Statements . . . . . . . . . . 15 Intellectual Property and Copyright Statements . . . . . . . . . . 16
1. Introduction 1. Introduction
The International Telecommunication Union (ITU-T) recommendation The International Telecommunication Union (ITU-T) recommendation
G.729EV [1] is a scalable and wideband extension of the G.729EV [1] is a scalable and wideband extension of the
recommendation G.729 [7] audio codec. This document specifies the recommendation G.729 [9] audio codec. This document specifies the
payload format for packetization of G.729EV encoded audio signals payload format for packetization of G.729EV encoded audio signals
into the real-time transport protocol (RTP). into the real-time transport protocol (RTP).
The payload format itself is described in Section 5. A media type The payload format itself is described in Section 5. A media type
registration and the details for the use of G.729EV with SDP are registration and the details for the use of G.729EV with SDP are
given in Section 6. given in Section 6.
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 this "SHOULD", "SHOULD NOT","RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [2]. document are to be interpreted as described in RFC 2119 [2].
skipping to change at page 4, line 22 skipping to change at page 4, line 22
significantly decrease the transmitted bit rate by sending only significantly decrease the transmitted bit rate by sending only
comfort noise parameters in special small frames called silence comfort noise parameters in special small frames called silence
insertion descriptors (SID). The receiver's decoder will generate insertion descriptors (SID). The receiver's decoder will generate
comfort noise according to the SID information. This operation of comfort noise according to the SID information. This operation of
sending low bit rate comfort noise parameters during silence periods sending low bit rate comfort noise parameters during silence periods
is usually called discontinuous transmission (DTX). is usually called discontinuous transmission (DTX).
G.729EV will be first released without support for DTX. Anyway, this G.729EV will be first released without support for DTX. Anyway, this
functionality is planned and will be defined in a separate annex functionality is planned and will be defined in a separate annex
later. Thus this specification provides DTX signalling, even if the later. Thus this specification provides DTX signalling, even if the
size of a SID frame is not yet standardized. size and content of a SID frame are not yet standardized.
3. Embedded bit rates considerations 3. Embedded bit rates considerations
The embedded property of G.729EV streams provides a mechanism to The embedded property of G.729EV streams provides a mechanism to
adjust the bandwidth demand. At any time, a sender can change its adjust the bandwidth demand. At any time, a sender can change its
sending bit rate without an external signalling, and the receiver sending bit rate without an external signalling, and the receiver
will be able to properly decode the frames. It may help to control will be able to properly decode the frames. It may help to control
congestion, since the bandwidth can be adjusted by selecting another congestion, since the bandwidth can be adjusted by selecting another
bit rate. bit rate.
skipping to change at page 6, line 25 skipping to change at page 6, line 25
| 7 | 24 kbps | | 7 | 24 kbps |
| 8 | 26 kbps | | 8 | 26 kbps |
| 9 | 28 kbps | | 9 | 28 kbps |
| 10 | 30 kbps | | 10 | 30 kbps |
| 11 | 32 kbps | | 11 | 32 kbps |
| 12-14 | (reserved) | | 12-14 | (reserved) |
| 15 | NO_MBS | | 15 | NO_MBS |
+-------+--------------+ +-------+--------------+
The MBS is used to tell the other party the maximum bit rate one can The MBS is used to tell the other party the maximum bit rate one can
receive. The encoder MUST follow the received MBS. It MUST NOT send receive. The encoder MUST NOT exceed the sending rate indicated by
frames at a bit rate higher than the received MBS. Thanks to the the received MBS. Thanks to the embedded property of the coding
embedded property of the coding scheme, note that it can send frames scheme, note that it can send frames at the MBS rate or any lower
at the MBS rate or any lower rate. As long as it does not exceed the rate. As long as it does not exceed the MBS, it can change its bit
MBS, it can change its bit rate at any time without previous notice. rate at any time without previous notice.
The MBS received is valid until the next MBS is received, i.e. a The MBS received is valid until the next MBS is received, i.e. a
newly received MBS value overrides the previous one. newly received MBS value overrides the previous one.
If a payload with an invalid MBS value is received, the MBS MUST be If a payload with an invalid MBS value is received, the MBS MUST be
ignored. ignored.
Note that the MBS is a codec bit rate, the actual network bit rate is Note that the MBS is a codec bit rate, the actual network bit rate is
higher and depends on the overhead of the underlying protocols. higher and depends on the overhead of the underlying protocols.
The MBS field MUST be set to 15 for packets sent to a multicast The MBS field MUST be set to 15 for packets sent to a multicast
group, and MUST be ignored on packets received from a multicast
group. group.
The MBS field MUST be set to 15 in all packets when the actual MBS The MBS field MUST be set to 15 in all packets when the actual MBS
value is sent through non-RTP means. This is out of the scope of value is sent through non-RTP means. This is out of the scope of
this specification. this specification.
See Section 7 for more details on the use of MBS for congestion
control.
5.3. Payload Header: FT field 5.3. Payload Header: FT field
FT (4 bits): Frame type of the frame(s) in this packet, as per the FT (4 bits): Frame type of the frame(s) in this packet, as per the
following table: following table:
+-------+---------------+------------+ +-------+---------------+------------+
| FT | encoding rate | frame size | | FT | encoding rate | frame size |
+-------+---------------+------------+ +-------+---------------+------------+
| 0 | 8 kbps | 20 octets | | 0 | 8 kbps | 20 octets |
| 1 | 12 kbps | 30 octets | | 1 | 12 kbps | 30 octets |
skipping to change at page 8, line 19 skipping to change at page 8, line 24
The parameters are defined here as part of the media subtype The parameters are defined here as part of the media subtype
registration for the G.729EV codec. A mapping of the parameters into registration for the G.729EV codec. A mapping of the parameters into
the Session Description Protocol (SDP) [5] is also provided for those the Session Description Protocol (SDP) [5] is also provided for those
applications that use SDP. In control protocols that do not use MIME applications that use SDP. In control protocols that do not use MIME
or SDP, the media type parameters must be mapped to the appropriate or SDP, the media type parameters must be mapped to the appropriate
format used with that control protocol. format used with that control protocol.
6.1. Media type registration 6.1. Media type registration
This registration is done using the template defined in RFC 4288 [8] [Note to RFC Editor: Please replace all occurrences of RFC XXXX by
and following RFC 3555 [9]. the RFC number assigned to this document, and all references to RFC
YYYY with the RFC number that will be assigned to the latest SDP
specification [5]]
This registration is done using the template defined in RFC 4288 [6]
and following RFC 3555 [7].
Type name: audio Type name: audio
Subtype name: G729EV Subtype name: G729EV
Required parameters: none Required parameters: none
Optional parameters: Optional parameters:
dtx: indicates that discontinuous transmission (DTX) is used or dtx: indicates that discontinuous transmission (DTX) is used or
preferred. DTX means voice activity detection and non preferred. DTX means voice activity detection and non
transmission of silent frames. Permissible values are 0 and 1. 0 transmission of silent frames. Permissible values are 0 and 1. 0
means no DTX. 0 is implied if this parameter is omitted. The means no DTX. 0 is implied if this parameter is omitted. The
first version of G.729EV will not support DTX. first version of G.729EV will not support DTX, but future annexes
are expected to add DTX support which can be signalled using this
parameter.
maxbitrate: the absolute maximum codec bit rate for the session. maxbitrate: the absolute maximum codec bit rate for the session, in
Permissible values are between 0 and 11 (see table in Section 5.2 bits per second. Permissible values are 8000, 12000, 14000,
of RFC XXXX). 11 is implied if this parameter is omitted. The 16000, 18000, 20000, 22000, 24000, 26000, 28000, 30000, and 32000.
maxbitrate restricts the range of bit rates which can be used. 32000 is implied if this parameter is omitted. The maxbitrate
Frames bit rate (FT) and MBS MUST NOT exceed this value. restricts the range of bit rates which can be used. The bit rates
indicated by FT and MBS fields in the RTP packets MUST NOT exceed
maxbitrate.
mbs: the initial value of MBS, that is the current maximum codec bit mbs: the current maximum codec bit rate supported as a receiver, in
rate supported as a receiver. Permissible values are between 0 bits per second. Permissible values are in the same set as for
and maxbitrate (see table in Section 5.2 of RFC XXXX). The the maxbitrate parameter, with the constraint that mbs MUST be
maximum MBS value is implied if this parameter is omitted. Note lower or equal to maxbitrate. If the mbs parameter is omitted, it
that this parameter will be dynamically updated by the MBS field is set to the maxbitrate value. So if both mbs and maxbitrate are
of the RTP packets sent, it is not an absolute value for the omitted, they are both set to 32000. The mbs parameter
session. The goal is to announce this value, prior to the sending corresponds to a MBS value in the RTP packets as per table in
of any packet, to avoid the remote sender to exceed the MBS at the Section 5.2 of RFC XXXX. Note that this parameter will be
beginning of the session. dynamically updated by the MBS field of the RTP packets sent, it
is not an absolute value for the session. The goal is to announce
this value, prior to the sending of any packet, to avoid the
remote sender to exceed the MBS at the beginning of the session.
ptime: the recommended length of time in milliseconds represented by ptime: the recommended length of time in milliseconds represented by
the media in a packet. See Section 6 of RFC 2327 [5]. the media in a packet. See Section 6 of RFC YYYY [5].
maxptime: the maximum length of time in milliseconds which can be maxptime: the maximum length of time in milliseconds which can be
encapsulated in a packet. See Section 8 of RFC 3267 [10] encapsulated in a packet. See Section 6 of RFC YYYY [5]
Encoding considerations: This media type is framed and contains Encoding considerations: This media type is framed and contains
binary data, see section 4.8 of RFC 4288 [8]. binary data, see section 4.8 of RFC 4288 [6].
Security considerations: See Section 8 of RFC XXXX Security considerations: See Section 8 of RFC XXXX
Interoperability considerations: none Interoperability considerations: none
Published specification: RFC XXXX Published specification: RFC XXXX
Applications which use this media type: Audio and video conferencing Applications which use this media type: Audio and video conferencing
tools. tools.
skipping to change at page 10, line 25 skipping to change at page 10, line 44
Example 1: default parameters Example 1: default parameters
m=audio 53146 RTP/AVP 98 m=audio 53146 RTP/AVP 98
a=rtpmap:98 G729EV/16000 a=rtpmap:98 G729EV/16000
Example 2: recommended packet duration of 40 ms (=2 frames), DTX off, Example 2: recommended packet duration of 40 ms (=2 frames), DTX off,
and initial MBS set to 26 kbps and initial MBS set to 26 kbps
m=audio 51258 RTP/AVP 99 m=audio 51258 RTP/AVP 99
a=rtpmap:99 G729EV/16000 a=rtpmap:99 G729EV/16000
a=fmtp:99 dtx=0; mbs=8 a=fmtp:99 dtx=0; mbs=26000
a=ptime:40 a=ptime:40
6.3. Offer-answer model considerations 6.3. Offer-answer model considerations
The following considerations apply when using SDP offer-answer The following considerations apply when using SDP offer-answer
procedures to negotiate the use of G.729EV payload in RTP: procedures to negotiate the use of G.729EV payload in RTP:
o Since G.729EV is an extension of G.729, the offerer SHOULD o Since G.729EV is an extension of G.729, the offerer SHOULD
announce G.729 support in its "m=audio" line, with G.729EV announce G.729 support in its "m=audio" line, with G.729EV
preferred. This will allow interoperability with both G.729EV and preferred. This will allow interoperability with both G.729EV and
skipping to change at page 11, line 15 skipping to change at page 11, line 33
o The "dtx" parameter concerns both sending and receiving, so both o The "dtx" parameter concerns both sending and receiving, so both
sides of a bi-directional session MUST use the same "dtx" value. sides of a bi-directional session MUST use the same "dtx" value.
If one party indicates it does not support DTX, DTX must be If one party indicates it does not support DTX, DTX must be
deactivated both ways. deactivated both ways.
o The "maxbitrate" parameter is bi-directional. If the offerer sets o The "maxbitrate" parameter is bi-directional. If the offerer sets
a maxbitrate value, the answerer MUST reply with a smaller or a maxbitrate value, the answerer MUST reply with a smaller or
equal value. The actual maximum bit rate for the session will be equal value. The actual maximum bit rate for the session will be
the minimum. the minimum.
o If the received value for "maxbitrate" is between 8000 and 32000
but not in the permissible values set, it SHOULD be read as the
closest lower valid value. If the received value is lower than
8000 or greater than 32000, the session MUST be rejected.
o The "mbs" parameter is not symmetric. Values in the offer and the o The "mbs" parameter is not symmetric. Values in the offer and the
answer are independent and take into account local constraints. answer are independent and take into account local constraints.
Anyway, one party MUST NOT start sending frames at a bit rate Anyway, one party MUST NOT start sending frames at a bit rate
higher than the "mbs" of the other party. higher than the "mbs" of the other party.
o If the received value for "mbs" is greater or equal to 8000 but
not in the permissible values set, it SHOULD be read as the
closest lower valid value. If the received value is lower than
8000, the session MUST be rejected.
o The parameters "ptime" and "maxptime" will in most cases not o The parameters "ptime" and "maxptime" will in most cases not
affect interoperability. The SDP offer-answer handling of the affect interoperability. The SDP offer-answer handling of the
"ptime" parameter is described in RFC 3264 [6]. The "maxptime" "ptime" parameter is described in RFC 3264 [8]. The "maxptime"
parameter MUST be handled in the same way. parameter MUST be handled in the same way.
Some special rules apply for mono-directional traffic: Some special rules apply for mono-directional traffic:
o For sendonly streams, the "mbs" parameter is useless and SHOULD o For sendonly streams, the "mbs" parameter is useless and SHOULD
NOT be used. NOT be used.
o For recvonly streams, the "mbs" parameter is the only way to o For recvonly streams, the "mbs" parameter is the only way to
communicate the MBS to the sender, since there is no RTP stream communicate the MBS to the sender, since there is no RTP stream
towards it. So to request a bit rate change, the receiver will towards it. So to request a bit rate change, the receiver will
skipping to change at page 12, line 20 skipping to change at page 12, line 47
RTP packets using the payload format defined in this specification RTP packets using the payload format defined in this specification
are subject to the general security considerations discussed in the are subject to the general security considerations discussed in the
RTP specification [3] and any appropriate profile (for example, RFC RTP specification [3] and any appropriate profile (for example, RFC
3551 [4]). 3551 [4]).
As this format transports encoded speech/audio, the main security As this format transports encoded speech/audio, the main security
issues include confidentiality, integrity protection, and issues include confidentiality, integrity protection, and
authentication of the speech/audio itself. The payload format itself authentication of the speech/audio itself. The payload format itself
does not have any built-in security mechanisms. Any suitable does not have any built-in security mechanisms. Any suitable
external mechanisms, such as SRTP [11], MAY be used. external mechanisms, such as SRTP [10], MAY be used.
This payload format and the G.729EV encoding do not exhibit any This payload format and the G.729EV encoding do not exhibit any
significant non-uniformity in the receiver-end computational load and significant non-uniformity in the receiver-end computational load and
thus in unlikely to pose a denial-of-service threat due to the thus in unlikely to pose a denial-of-service threat due to the
receipt of pathological datagrams. receipt of pathological datagrams.
9. IANA considerations 9. IANA considerations
It is requested that one new media subtype (audio/G729EV) is It is requested that one new media subtype (audio/G729EV) is
registered by IANA, see Section 6.1. registered by IANA, see Section 6.1.
skipping to change at page 13, line 5 skipping to change at page 13, line 30
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997. Levels", BCP 14, RFC 2119, March 1997.
[3] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, [3] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson,
"RTP: A Transport Protocol for Real-Time Applications", STD 64, "RTP: A Transport Protocol for Real-Time Applications", STD 64,
RFC 3550, July 2003. RFC 3550, July 2003.
[4] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video [4] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video
Conferences with Minimal Control", STD 65, RFC 3551, July 2003. Conferences with Minimal Control", STD 65, RFC 3551, July 2003.
[5] Handley, M. and V. Jacobson, "SDP: Session Description [5] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Protocol", RFC 2327, April 1998. Description Protocol", draft-ietf-mmusic-sdp-new-26 (work in
progress), January 2006.
[6] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with [6] Freed, N. and J. Klensin, "Media Type Specifications and
Registration Procedures", BCP 13, RFC 4288, December 2005.
[7] Casner, S. and P. Hoschka, "MIME Type Registration of RTP
Payload Formats", RFC 3555, July 2003.
[8] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with
Session Description Protocol (SDP)", RFC 3264, June 2002. Session Description Protocol (SDP)", RFC 3264, June 2002.
10.2. Informative references 10.2. Informative references
[7] International Telecommunications Union, "Coding of speech at 8 [9] International Telecommunications Union, "Coding of speech at 8
kbit/s using conjugate-structure algebraic-code-excited linear- kbit/s using conjugate-structure algebraic-code-excited linear-
prediction (CS-ACELP)", ITU-T Recommendation G.729, March 1996. prediction (CS-ACELP)", ITU-T Recommendation G.729, March 1996.
[8] Freed, N. and J. Klensin, "Media Type Specifications and [10] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Registration Procedures", BCP 13, RFC 4288, December 2005.
[9] Casner, S. and P. Hoschka, "MIME Type Registration of RTP
Payload Formats", RFC 3555, July 2003.
[10] Sjoberg, J., Westerlund, M., Lakaniemi, A., and Q. Xie, "Real-
Time Transport Protocol (RTP) Payload Format and File Storage
Format for the Adaptive Multi-Rate (AMR) and Adaptive Multi-
Rate Wideband (AMR-WB) Audio Codecs", RFC 3267, June 2002.
[11] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)", Norrman, "The Secure Real-time Transport Protocol (SRTP)",
RFC 3711, March 2004. RFC 3711, March 2004.
Author's Address Author's Address
Aurelien Sollaud Aurelien Sollaud
France Telecom France Telecom
2 avenue Pierre Marzin 2 avenue Pierre Marzin
Lannion Cedex 22307 Lannion Cedex 22307
France France
 End of changes. 30 change blocks. 
56 lines changed or deleted 79 lines changed or added

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