draft-ietf-avt-rtp-g718-00.txt   draft-ietf-avt-rtp-g718-01.txt 
Audio/Video Transport WG Ari Lakaniemi Audio/Video Transport WG Ari Lakaniemi
Internet Draft Ye-Kui Wang Internet Draft Nokia
Intended status: Standards track Nokia Intended status: Standards track Ye-Kui Wang
Expires: April 2009 October 23, 2008 Expires: October 2009 Huawei Technologies
April 28, 2009
RTP payload format for G.718 speech/audio RTP payload format for G.718 speech/audio
draft-ietf-avt-rtp-g718-00.txt draft-ietf-avt-rtp-g718-01.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any This Internet-Draft is submitted to IETF in full conformance with the
applicable patent or other IPR claims of which he or she is aware provisions of BCP 78 and BCP 79. This document may contain material
have been or will be disclosed, and any of which he or she becomes from IETF Documents or IETF Contributions published or made publicly
aware will be disclosed, in accordance with Section 6 of BCP 79. available before November 10, 2008. The person(s) controlling the
copyright in some of this material may not have granted the IETF
Trust the right to allow modifications of such material outside the
IETF Standards Process. Without obtaining an adequate license from
the person(s) controlling the copyright in such materials, this
document may not be modified outside the IETF Standards Process, and
derivative works of it may not be created outside the IETF Standards
Process, except to format it for publication as an RFC or to
translate it into languages other than English.
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 months Internet-Drafts are draft documents valid for a maximum of six months
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 April 23, 2009. This Internet-Draft will expire on October 28, 2009.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2008). Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Abstract Abstract
This document specifies the Real-Time Transport Protocol (RTP) This document specifies the Real-Time Transport Protocol (RTP)
payload format for the Embedded Variable Bit-Rate (EV-VBR) payload format for the Embedded Variable Bit-Rate (EV-VBR)
speech/audio codec, specified in ITU-T G.718. A media type speech/audio codec, specified in ITU-T G.718. A media type
registration for this RTP payload format is also included. registration for this RTP payload format is also included.
Conventions used in this document Conventions used in this document
skipping to change at page 2, line 23 skipping to change at page 2, line 36
1. Introduction...................................................3 1. Introduction...................................................3
2. Background.....................................................3 2. Background.....................................................3
2.1. The G.718 codec...........................................3 2.1. The G.718 codec...........................................3
2.2. Benefits of layered design................................5 2.2. Benefits of layered design................................5
2.3. Transmitting layered data.................................5 2.3. Transmitting layered data.................................5
2.4. Scaling scenarios & rate control..........................6 2.4. Scaling scenarios & rate control..........................6
3. G.718 RTP payload format.......................................7 3. G.718 RTP payload format.......................................7
3.1. Payload Structure.........................................7 3.1. Payload Structure.........................................7
3.1.1. Payload Header.......................................7 3.1.1. Payload Header.......................................7
3.1.2. G.718 transport blocks...............................8 3.1.2. G.718 transport blocks...............................8
3.2. Handling the Encoded data................................10 3.2. Handling the Encoded data................................11
3.3. G.718 scaling............................................13 3.3. G.718 scaling............................................13
3.4. CRC verification.........................................13 3.4. CRC verification.........................................14
3.5. G.718 session............................................14 3.5. G.718 session............................................14
3.6. Cross-stream/cross-layer timing synchronization..........14 3.6. Cross-stream/cross-layer timing synchronization..........14
3.7. RTP Header usage.........................................14 3.7. RTP Header usage.........................................15
4. Payload Format Parameters.....................................15 4. Payload Format Parameters.....................................15
4.1. Media Type Registration..................................15 4.1. Media Type Registration..................................15
4.2. Mapping to SDP Parameters................................17 4.2. Mapping to SDP Parameters................................17
4.3. Offer/answer considerations..............................17 4.3. Offer/answer considerations..............................18
4.4. Declarative usage of SDP.................................18 4.4. Declarative usage of SDP.................................18
4.5. SDP examples.............................................18 4.5. SDP examples.............................................18
5. Security Considerations.......................................20 5. Security Considerations.......................................20
6. Congestion control............................................21 6. Congestion control............................................21
7. IANA Considerations...........................................21 7. IANA Considerations...........................................22
APPENDIX A: Payload examples.....................................22 APPENDIX A: Payload examples.....................................23
A.1. Simple payload examples..................................22 A.1. Simple payload examples..................................23
A.1.1. All the layers in the same payload..................22 A.1.1. All the layers in the same payload..................23
A.1.2. Layers in separate RTP streams......................23 A.1.2. Layers in separate RTP streams......................24
A.2. Advanced examples........................................24 A.2. Advanced examples........................................25
A.2.1. Different update rate for subset of layers..........24 A.2.1. Different update rate for subset of layers..........25
A.2.2. Redundant frames with limited set of layers.........25 A.2.2. Redundant frames with limited set of layers.........26
8. References....................................................27 8. References....................................................28
8.1. Normative References.....................................27 8.1. Normative References.....................................28
8.2. Informative References...................................28 8.2. Informative References...................................29
Author's Addresses...............................................29 Author's Addresses...............................................30
Intellectual Property Statement..................................29
Disclaimer of Validity...........................................30
Copyright Statement..............................................30
Acknowledgment...................................................30 Acknowledgment...................................................30
9. Open Issues...................................................30 9. Open Issues...................................................30
10. Changes Log..................................................31 10. Changes Log..................................................31
1. Introduction 1. Introduction
The International Telecommunication Union (ITU-T) Recommendation The International Telecommunication Union (ITU-T) Recommendation
G.718 [G.718] specifies the Embedded Variable Bit Rate (EV-VBR) G.718 [G.718] specifies the Embedded Variable Bit Rate (EV-VBR)
speech/audio codec. This document specifies the Real-time Transport speech/audio codec. This document specifies the Real-time Transport
Protocol (RTP) [RFC3550] payload format for this codec. Protocol (RTP) [RFC3550] payload format for this codec.
skipping to change at page 5, line 15 skipping to change at page 5, line 25
and the usage of these layers are TBD. and the usage of these layers are TBD.
The main application of the G.718 codec is telephony. Other expected The main application of the G.718 codec is telephony. Other expected
applications include audio/video conferencing and streaming. applications include audio/video conferencing and streaming.
2.2. Benefits of layered design 2.2. Benefits of layered design
The layered design enables simple scalability of the transmitted The layered design enables simple scalability of the transmitted
stream simply by conveying a suitable number of layers. The number of stream simply by conveying a suitable number of layers. The number of
layers used in a session may be selected for example based on the layers used in a session may be selected for example based on the
capacity of the transmission channel, current transmission capacity of the transmission channel, current transmission conditions,
conditions, characteristics of the source signal or available characteristics of the source signal or available processing capacity.
processing capacity.
Another obvious benefit of the layered codec design is the Another obvious benefit of the layered codec design is the
possibility to exploit the scalability to support congestion control possibility to exploit the scalability to support congestion control
by transmitting/dropping some of the (higher) enhancement layers in by transmitting/dropping some of the (higher) enhancement layers in
order to alleviate congestion in the network. See more detailed order to alleviate congestion in the network. See more detailed
discussion on the congestion control in section 6. discussion on the congestion control in section 6.
Furthermore, the layered design also implicitly provides possibility Furthermore, the layered design also implicitly provides possibility
for unequal error detection/protection by employing different levels for unequal error detection/protection by employing different levels
of protection on core layer and enhancement layers. of protection on core layer and enhancement layers.
skipping to change at page 5, line 49 skipping to change at page 6, line 11
The first choice is the most efficient in terms of exploitation of The first choice is the most efficient in terms of exploitation of
transmission bandwidth. Furthermore, using only one packet to carry transmission bandwidth. Furthermore, using only one packet to carry
all encoded data layers of a frame requires less resources also from all encoded data layers of a frame requires less resources also from
the end-systems (and intermediate systems) since the number of the end-systems (and intermediate systems) since the number of
packets is kept at minimum and only single RTP packet stream needs to packets is kept at minimum and only single RTP packet stream needs to
be handled. However, this option requires any intermediate network be handled. However, this option requires any intermediate network
element performing the scaling operation to be fully media-aware element performing the scaling operation to be fully media-aware
since removing encoded layers requires modification of the payload. since removing encoded layers requires modification of the payload.
Furthermore, the intermediate network element needs to be within the Furthermore, the intermediate network element needs to be within the
security context to enable the meaningful manipulation of the security context to enable the meaningful manipulation of the payload,
payload, in case secure transport is employed. This might not be in case secure transport is employed. This might not be feasible in
feasible in all systems/scenarios, but some special-purpose devices all systems/scenarios, but some special-purpose devices such as e.g.
such as e.g. media gateways in cellular telephone systems may be able media gateways in cellular telephone systems may be able to implement
to implement this kind of media-aware functionality. this kind of media-aware functionality.
The second alternative transmitting selected subsets of layers in The second alternative transmitting selected subsets of layers in
separate RTP sessions facilitates simple scalability in intermediate separate RTP sessions facilitates simple scalability in intermediate
network elements without the requirement of being fully media-aware. network elements without the requirement of being fully media-aware.
One use case of this alternative is layered multicast [McCanne]. On One use case of this alternative is layered multicast [McCanne]. On
the other hand, this approach introduces separate packet header the other hand, this approach introduces separate packet header
overhead for each subset of layers for those low-delay application overhead for each subset of layers for those low-delay application
scenarios wherein aggregation of data from multiple frames is not scenarios wherein aggregation of data from multiple frames is not
ideal. In this case, when the size of the encoded data block per ideal. In this case, when the size of the encoded data block per
single layer is in the range of 10 to 20 bytes, the packetisation may single layer is in the range of 10 to 20 bytes, the packetisation may
skipping to change at page 6, line 44 skipping to change at page 7, line 6
to change the number of layers it is transmitting to change the number of layers it is transmitting
3. An intermediate network element passes forward only a subset of 3. An intermediate network element passes forward only a subset of
layers it receives layers it receives
The most appropriate mechanism depends on the application and the The most appropriate mechanism depends on the application and the
employed network topology. For example point-to-point conversational employed network topology. For example point-to-point conversational
audio connection can easily introduce rate control by changing the audio connection can easily introduce rate control by changing the
number of transmitted layers, while in centralized audio/video number of transmitted layers, while in centralized audio/video
conferencing scenario the conference server is a more appropriate conferencing scenario the conference server is a more appropriate
point to implement the rate control instead of transmitting end- point to implement the rate control instead of transmitting end-point.
point. Please refer to [RFC5117] for extensive discussion on the Please refer to [RFC5117] for extensive discussion on the different
different topologies and their implications to the transmission. topologies and their implications to the transmission.
However, the fundamental difference between these choices is that However, the fundamental difference between these choices is that
method 1 does not necessarily need any feedback from the receiver(s), method 1 does not necessarily need any feedback from the receiver(s),
while methods 2 and 3 require a signaling mechanism to support rate while methods 2 and 3 require a signaling mechanism to support rate
control. control.
3. G.718 RTP payload format 3. G.718 RTP payload format
The basic G.718 source data unit is one layer of an encoded frame. The basic G.718 source data unit is one layer of an encoded frame.
Since generally the term layer refers to time series of data Since generally the term layer refers to time series of data
skipping to change at page 8, line 25 skipping to change at page 8, line 35
| L-ID |NF | Encoded data | | L-ID |NF | Encoded data |
+-+-+-+-+-+-+-+-+----------------------------+ +-+-+-+-+-+-+-+-+----------------------------+
The structure of the secondary transport block is depicted below. The structure of the secondary transport block is depicted below.
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+----------------------------+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+----------------------------+-+-+-+-+-+-+-+-+
| L-ID |NF | Encoded data | Tail | | L-ID |NF | Encoded data | Tail |
+-+-+-+-+-+-+-+-+----------------------------+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+----------------------------+-+-+-+-+-+-+-+-+
The layer ID (L-ID) and the NF fields form the transport block The layer ID (L-ID) and the NF fields form the transport block header.
header. The L-ID field is used to identify the layer structure of the The L-ID field is used to identify the layer structure of the encoded
encoded data carried in this G.718 transport block, and the NF field data carried in this G.718 transport block, and the NF field
indicates the number of encoded frames with this layer structure indicates the number of encoded frames with this layer structure
carried in the Encoded data part following the transport block carried in the Encoded data part following the transport block header.
header. The Tail field of the secondary transport block carries a The Tail field of the secondary transport block carries a modified 8-
modified 8-bit CRC checksum computed over the transport block, as bit CRC checksum computed over the transport block, as specified
specified below. below.
Author's note: For streaming or other applications that Author's note: For streaming or other applications that
allow for relatively long end-to-end delay, sometimes it allow for relatively long end-to-end delay, sometimes it
would be beneficial to aggregate more than 4 frames in one would be beneficial to aggregate more than 4 frames in one
TB. Should the length of NF be larger? TB. Should the length of NF be larger?
An G.718 RTP packet payload SHALL include exactly one primary An G.718 RTP packet payload SHALL include exactly one primary
transport block, which MAY be followed by one or more secondary transport block, which MAY be followed by one or more secondary
transport blocks. The data fields of both transport block types are transport blocks. The data fields of both transport block types are
described below. described below.
L-ID Identification (6 bits) of the encoded data carried in this L-ID Identification (6 bits) of the encoded data carried in this
transport block. Table 3 below specifies the mapping between L- transport block. Table 3 below specifies the mapping between L-
ID and the encoded data. ID and the encoded data.
Table 3: Layer identification (L-ID) values Table 3: Layer identification (L-ID) values
skipping to change at page 10, line 27 skipping to change at page 10, line 38
one. The number of frames is equal to the value of NF one. The number of frames is equal to the value of NF
incremented by one. For example, value NF=0 indicates that the incremented by one. For example, value NF=0 indicates that the
transport block carries one frame, and value NF=3 indicate that transport block carries one frame, and value NF=3 indicate that
the transport block carries four frames. If the sender wants to the transport block carries four frames. If the sender wants to
encapsulate more than four frames per payload, several encapsulate more than four frames per payload, several
transport blocks need to be used. transport blocks need to be used.
Encoded data Encoded data
Encoded data consists of EDUs as specified by the values L-ID Encoded data consists of EDUs as specified by the values L-ID
and NF fields, arranged according to rules given in section and NF fields, arranged according to rules given in section 3.2.
3.2. When L-ID is equal to 0 (empty frame), the encoded data When L-ID is equal to 0 (empty frame), the encoded data field
field is not present (i.e. it consists of zero octet). is not present (i.e. it consists of zero octet).
Tail The 8-bit tail field of the secondary transport block carries a Tail The 8-bit tail field of the secondary transport block carries a
bit field that is needed to modify the partial CRC checksum bit field that is needed to modify the partial CRC checksum
over the payload data up to the end of this TB to match the over the payload data up to the end of this TB to match the
payload CRC field value carried in the payload header. payload CRC field value carried in the payload header.
In the transmitter the Tail bits for a secondary TB(n) are In the transmitter the Tail bits for a secondary TB(n) are
computed by first computing the CRC checksum CRC(n) over the computed by first computing the CRC checksum CRC(n) over the
payload data from the beginning of the primary TB up to the end payload data from the beginning of the primary TB up to the end
of TB(n) using the generator polynomial C(z) given above. The of TB(n) using the generator polynomial C(z) given above. The
skipping to change at page 12, line 19 skipping to change at page 12, line 31
+---------+-----+-------+-------+-------+-------+-------+--------+ +---------+-----+-------+-------+-------+-------+-------+--------+
| L-ID=3 |NF=1 | F1-L1 | F2-L1 | F1-L2 | F2-L2 | F1-L3 | F2-L3 | | L-ID=3 |NF=1 | F1-L1 | F2-L1 | F1-L2 | F2-L2 | F1-L3 | F2-L3 |
+---------+-----+-------+-------+-------+-------+-------+--------+ +---------+-----+-------+-------+-------+-------+-------+--------+
Author's note: Currently, it is mandated that lower layer Author's note: Currently, it is mandated that lower layer
EDUs of later frames go before higher layer EDUs of EDUs of later frames go before higher layer EDUs of
earlier frames. This way is friendlier to adaptation earlier frames. This way is friendlier to adaptation
(dropping of higher layers). However, if all layers are (dropping of higher layers). However, if all layers are
received, then the depacketizer needs to reorder the EDUs received, then the depacketizer needs to reorder the EDUs
to their decoding order before feeding them to the to their decoding order before feeding them to the decoder.
decoder. Therefore, the other way around (i.e. lower layer Therefore, the other way around (i.e. lower layer EDUs of
EDUs of later frames go after higher layer EDUs of earlier later frames go after higher layer EDUs of earlier frames,
frames, or EDUs in transport blocks are placed in decoding or EDUs in transport blocks are placed in decoding order)
order) is more friendly to the depacketizer. Another is more friendly to the depacketizer. Another benefit of
benefit of the latter is that it does not introduce any the latter is that it does not introduce any end-to-end
end-to-end delay. Which way to be specified (or both delay. Which way to be specified (or both allowed if
allowed if needed) is FFS. needed) is FFS.
Example 2: All EDUs in separate transport blocks Example 2: All EDUs in separate transport blocks
+---------+-----+-------+---------+-----+-------+ +---------+-----+-------+---------+-----+-------+
| L-ID=1 |NF=0 | F1-L1 | L-ID=1 |NF=0 | F2-L1 | | L-ID=1 |NF=0 | F1-L1 | L-ID=1 |NF=0 | F2-L1 |
+---------+-----+-------+---------+-----+-------+ +---------+-----+-------+---------+-----+-------+
| L-ID=8 |NF=0 | F1-L2 | L-ID=8 |NF=0 | F2-L2 | | L-ID=8 |NF=0 | F1-L2 | L-ID=8 |NF=0 | F2-L2 |
+---------+-----+-------+---------+-----+-------+ +---------+-----+-------+---------+-----+-------+
| L-ID=14 |NF=0 | F1-L3 | L-ID=14 |NF=0 | F2-L3 | | L-ID=14 |NF=0 | F1-L3 | L-ID=14 |NF=0 | F2-L3 |
+---------+-----+-------+---------+-----+-------+ +---------+-----+-------+---------+-----+-------+
Example 3: Dedicated transport for EDUs of each layer Example 3: Dedicated transport for EDUs of each layer
skipping to change at page 13, line 28 skipping to change at page 13, line 47
Such MANEs are RTP translators (with the topology Topo-Translator as Such MANEs are RTP translators (with the topology Topo-Translator as
described in [RFC5117]), for which the rules for RTP translators described in [RFC5117]), for which the rules for RTP translators
specified in [RFC3550] apply. specified in [RFC3550] apply.
A payload can be either completely dropped or some of the transport A payload can be either completely dropped or some of the transport
blocks it carries can be discarded. In case full payloads are dropped blocks it carries can be discarded. In case full payloads are dropped
to implement scaling, a packet containing the core layer L1 SHOULD to implement scaling, a packet containing the core layer L1 SHOULD
NOT be discarded, since the decoding of higher layers of the same NOT be discarded, since the decoding of higher layers of the same
encoded frame is not possible without the core layer data being encoded frame is not possible without the core layer data being
available. This means that payloads with L-ID values equal to 1 to 5, available. This means that payloads with L-ID values equal to 1 to 5,
inclusive and 16 to 19, inclusive, SHOULD NOT be completely inclusive and 16 to 19, inclusive, SHOULD NOT be completely discarded.
discarded.
Author's note: To be checked whether the case of dropping Author's note: To be checked whether the case of dropping
a subset of the transport blocks in one packet also a subset of the transport blocks in one packet also
strictly follows the topology Topo-Translator. strictly follows the topology Topo-Translator.
In case the payload is forwarded with modified content, at least the In case the payload is forwarded with modified content, at least the
primary transport block MUST be preserved in the payload, while some primary transport block MUST be preserved in the payload, while some
of the secondary transport blocks at the end of the payload MAY be of the secondary transport blocks at the end of the payload MAY be
discarded. discarded.
skipping to change at page 27, line 23 skipping to change at page 28, line 23
[G.718] ITU-T Recommendation G.718, "Frame Error Robust Narrowband [G.718] ITU-T Recommendation G.718, "Frame Error Robust Narrowband
and Wideband Embedded Variable Bit-Rate Coding of Speech and Wideband Embedded Variable Bit-Rate Coding of Speech
and Audio from 8-32 Kbit/s", (consented) May 2008. and Audio from 8-32 Kbit/s", (consented) May 2008.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3264] Rosenberg, J., Schulzrinne, H., "An Offer/Answer Model with [RFC3264] Rosenberg, J., Schulzrinne, H., "An Offer/Answer Model with
Session Description Protocol (SDP)", RFC 3264, June 2002. Session Description Protocol (SDP)", RFC 3264, June 2002.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R. and Jacobson, [RFC3550]Schulzrinne, H., Casner, S., Frederick, R. and Jacobson, V.,
V., "RTP: A Transport Protocol for Real-Time Applications", "RTP: A Transport Protocol for Real-Time Applications", STD
STD 64, RFC 3550, July 2003. 64, RFC 3550, July 2003.
[RFC3551] Schulzrinne, H., Casner, S., "RTP Profile for Audio and [RFC3551] Schulzrinne, H., Casner, S., "RTP Profile for Audio and
Video Conferences with Minimal Control", STD 65, RFC 3551, Video Conferences with Minimal Control", STD 65, RFC 3551,
July 2003. July 2003.
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., Norrman, [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., Norrman,
K., "The Secure Real-Time Transport Protocol (SRTP)", RFC K., "The Secure Real-Time Transport Protocol (SRTP)", RFC
3711, March 2004. 3711, March 2004.
[RFC4288] Freed, N., Klensin, J., "Media Type Specifications and [RFC4288] Freed, N., Klensin, J., "Media Type Specifications and
skipping to change at page 29, line 16 skipping to change at page 30, line 16
Ari Lakaniemi Ari Lakaniemi
Nokia Nokia
P.O.Box 407 P.O.Box 407
FIN-00045 Nokia Group, FINLAND FIN-00045 Nokia Group, FINLAND
Phone: +358-71-8008000 Phone: +358-71-8008000
Email: ari.lakaniemi@nokia.com Email: ari.lakaniemi@nokia.com
Ye-Kui Wang Ye-Kui Wang
Nokia Research Center Huawei Technologies
P.O. Box 1000 400 Somerset Corp Blvd, Suite 602
33721 Tampere Bridgewater, NJ 08807, USA
Finland
Phone: +358-50-466-7004
EMail: ye-kui.wang@nokia.com
Intellectual Property Statement
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.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions Phone: +1-908-541-3518
contained in BCP 78, and except as set forth therein, the authors EMail: yekuiwang@huawei.com
retain all their rights.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
9. Open Issues 9. Open Issues
1) Support of super-wideband (SWB) audio and stereophonic encoding 1) Support of super-wideband (SWB) audio and stereophonic encoding
extensions to ITU-T G.718 currently being worked on by ITU-T is to extensions to ITU-T G.718 currently being worked on by ITU-T is to
skipping to change at page 31, line 44 skipping to change at page 31, line 44
7) It might be better to change the semantics of the media type 7) It might be better to change the semantics of the media type
parameter 'layers' to be similar as that for L-ID. parameter 'layers' to be similar as that for L-ID.
8) Offer/answer with answer being capable of modifying the layer 8) Offer/answer with answer being capable of modifying the layer
configuration is FFS. configuration is FFS.
9) Some references need to be updated in the final draft. 9) Some references need to be updated in the final draft.
10. Changes Log 10. Changes Log
From draft-lakaniemi-avt-rtp-evbr-04 to draft-ietf-avt-rtp-g718-00 From draft-ietf-avt-rtp-g718-00 to draft-ietf-avt-rtp-g718-01
- Changed the media sub-type name "EV-VBR" to "G718", and replaced - Updated the boiler template.
"EV-VBR" with "G.718" in all text.
- Changed Ye-Kui Wang's affiliation and address.
 End of changes. 28 change blocks. 
118 lines changed or deleted 83 lines changed or added

This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/