idnits 2.17.1 

draft-ietf-avt-rtp-g718-00.txt:

  Checking boilerplate required by RFC 5378 and the IETF Trust (see
  https://trustee.ietf.org/license-info):
  ----------------------------------------------------------------------------

  ** It looks like you're using RFC 3978 boilerplate.  You should update this
     to the boilerplate described in the IETF Trust License Policy document
     (see https://trustee.ietf.org/license-info), which is required now.

  -- Found old boilerplate from RFC 3978, Section 5.1 on line 14.

  -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on
     line 1238.

  -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1215.

  -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1222.

  -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1228.


  Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
  ----------------------------------------------------------------------------

     No issues found here.

  Checking nits according to https://www.ietf.org/id-info/checklist :
  ----------------------------------------------------------------------------

     No issues found here.

  Miscellaneous warnings:
  ----------------------------------------------------------------------------

  == The copyright year in the IETF Trust Copyright Line does not match the
     current year

  -- The document seems to lack a disclaimer for pre-RFC5378 work, but may
     have content which was first submitted before 10 November 2008.  If you
     have contacted all the original authors and they are all willing to grant
     the BCP78 rights to the IETF Trust, then this is fine, and you can ignore
     this comment.  If not, you may need to add the pre-RFC5378 disclaimer. 
     (See the Legal Provisions document at
     https://trustee.ietf.org/license-info for more information.)

  -- The document date (October 23, 2008) is 5657 days in the past.  Is this
     intentional?


  Checking references for intended status: Proposed Standard
  ----------------------------------------------------------------------------

     (See RFCs 3967 and 4897 for information about using normative references
     to lower-maturity documents in RFCs)

  -- Looks like a reference, but probably isn't: '4340' on line 591

  == Unused Reference: 'RFC5104' is defined on line 1156, but no explicit
     reference was found in the text

  == Unused Reference: 'RFC4340' is defined on line 1181, but no explicit
     reference was found in the text

  -- Possible downref: Non-RFC (?) normative reference: ref. 'AMR-WB'

  -- Possible downref: Non-RFC (?) normative reference: ref. 'G.718'

  ** Obsolete normative reference: RFC 4288 (Obsoleted by RFC 6838)

  ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866)

  -- Obsolete informational reference (is this intentional?): RFC 2326
     (Obsoleted by RFC 7826)

  -- Obsolete informational reference (is this intentional?): RFC 5117
     (Obsoleted by RFC 7667)


     Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 12 comments (--).

     Run idnits with the --verbose option for more detailed information about
     the items above.

--------------------------------------------------------------------------------

1	Audio/Video Transport WG                                  Ari Lakaniemi
2	Internet Draft                                              Ye-Kui Wang
3	Intended status: Standards track                                  Nokia
4	Expires: April 2009                                    October 23, 2008

6	                 RTP payload format for G.718 speech/audio
7	                      draft-ietf-avt-rtp-g718-00.txt

9	Status of this Memo

11	   By submitting this Internet-Draft, each author represents that any
12	   applicable patent or other IPR claims of which he or she is aware
13	   have been or will be disclosed, and any of which he or she becomes
14	   aware will be disclosed, in accordance with Section 6 of BCP 79.

16	   Internet-Drafts are working documents of the Internet Engineering
17	   Task Force (IETF), its areas, and its working groups.  Note that
18	   other groups may also distribute working documents as Internet-
19	   Drafts.

21	   Internet-Drafts are draft documents valid for a maximum of six months
22	   and may be updated, replaced, or obsoleted by other documents at any
23	   time.  It is inappropriate to use Internet-Drafts as reference
24	   material or to cite them other than as "work in progress."

26	   The list of current Internet-Drafts can be accessed at
27	   http://www.ietf.org/ietf/1id-abstracts.txt

29	   The list of Internet-Draft Shadow Directories can be accessed at
30	   http://www.ietf.org/shadow.html

32	   This Internet-Draft will expire on April 23, 2009.

34	Copyright Notice

36	   Copyright (C) The IETF Trust (2008).

38	Abstract

40	   This document specifies the Real-Time Transport Protocol (RTP)
41	   payload format for the Embedded Variable Bit-Rate (EV-VBR)
42	   speech/audio codec, specified in ITU-T G.718. A media type
43	   registration for this RTP payload format is also included.

45	Conventions used in this document

47	   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
48	   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
49	   document are to be interpreted as described in RFC 2119 [RFC2119].

51	Table of Contents

53	   1. Introduction...................................................3
54	   2. Background.....................................................3
55	      2.1. The G.718 codec...........................................3
56	      2.2. Benefits of layered design................................5
57	      2.3. Transmitting layered data.................................5
58	      2.4. Scaling scenarios & rate control..........................6
59	   3. G.718 RTP payload format.......................................7
60	      3.1. Payload Structure.........................................7
61	         3.1.1. Payload Header.......................................7
62	         3.1.2. G.718 transport blocks...............................8
63	      3.2. Handling the Encoded data................................10
64	      3.3. G.718 scaling............................................13
65	      3.4. CRC verification.........................................13
66	      3.5. G.718 session............................................14
67	      3.6. Cross-stream/cross-layer timing synchronization..........14
68	      3.7. RTP Header usage.........................................14
69	   4. Payload Format Parameters.....................................15
70	      4.1. Media Type Registration..................................15
71	      4.2. Mapping to SDP Parameters................................17
72	      4.3. Offer/answer considerations..............................17
73	      4.4. Declarative usage of SDP.................................18
74	      4.5. SDP examples.............................................18
75	   5. Security Considerations.......................................20
76	   6. Congestion control............................................21
77	   7. IANA Considerations...........................................21
78	   APPENDIX A: Payload examples.....................................22
79	      A.1. Simple payload examples..................................22
80	         A.1.1. All the layers in the same payload..................22
81	         A.1.2. Layers in separate RTP streams......................23
82	      A.2. Advanced examples........................................24
83	         A.2.1. Different update rate for subset of layers..........24
84	         A.2.2. Redundant frames with limited set of layers.........25
85	   8. References....................................................27
86	      8.1. Normative References.....................................27
87	      8.2. Informative References...................................28
88	   Author's Addresses...............................................29
89	   Intellectual Property Statement..................................29
90	   Disclaimer of Validity...........................................30
91	   Copyright Statement..............................................30
92	   Acknowledgment...................................................30
93	   9. Open Issues...................................................30
94	   10. Changes Log..................................................31

96	1. Introduction

98	   The International Telecommunication Union (ITU-T) Recommendation
99	   G.718 [G.718] specifies the Embedded Variable Bit Rate (EV-VBR)
100	   speech/audio codec. This document specifies the Real-time Transport
101	   Protocol (RTP) [RFC3550] payload format for this codec.

103	2. Background

105	2.1. The G.718 codec

107	   G.718 is an embedded variable rate speech codec having a layered
108	   design. The bitstream of the G.718 core codec consists of a core
109	   layer, denoted as L1, and four enhancement layers, denoted as L2-L5.
110	   The bit-rates of the G.718 core codec range from 8 kbit/s (core layer
111	   only) to 32 kbit/s (with all layers up to L5). Furthermore, the G.718
112	   codec supports also discontinuous transmission (DTX) and comfort
113	   noise generation (CNG) by sending Silence Descriptor (SID) frames
114	   during periods of non-active input signal, resulting in a reduced
115	   bit-rate. The sampling frequency of the core codec is 16 kHz and the
116	   codec operates on 20 ms frames. The G.718 codec is also capable of
117	   narrowband operation with audio input and/or output at 8 kHz sampling
118	   frequency.

120	   While transmitting/receiving the core layer L1 is enough for
121	   successful decoding of the audio content, each of the enhancement
122	   layers Ln (n being 2 to 5, inclusive) provides an improvement to
123	   reconstructed audio quality. Thus, the core layer ensures the basic
124	   communication while the enhancement layers can be used to improve the
125	   perceptual quality. Furthermore, enhancement layers are dependent on
126	   all the lower layers in a sense that successful decoding of layer Ln
127	   requires also all the layers Lm with m<n to be available.

129	   The sizes, sampling rates and possible outputs of the G.718 core
130	   codec layers L1-L5 are summarized in Table 1 below, where "Bytes"
131	   column indicates the number of bytes per encoded data unit for a
132	   layer, NB and WB denotes narrowband and wideband, respectively. The
133	   "Bytes" column in other tables has the same meaning. Note that for
134	   layers L1 and L2, the corresponding output may either be NB or WB,
135	   depending on the rendering device and the application requirement,
136	   regardless of the sampling rate of the encoded data.

138	                           Table 1: G.718 layers

140	        Layer   Bytes   Cumulative bit-rate   Sampling rate   Output
141	      -----------------------------------------------------------------_
142	         L1       20        8 kbit/s           8 or 16 kHz    NB or WB
143	         L2       10       12 kbit/s           8 or 16 kHz    NB or WB
144	         L3       10       16 kbit/s           16 kHz         WB
145	         L4       20       24 kbit/s           16 kHz         WB
146	         L5       20       32 kbit/s           16 kHz         WB

148	   The G.718 codec includes also an operating mode that is compatible
149	   with the Adaptive Multi-Rate Wideband (AMR-WB) codec [AMR-WB], for
150	   which the RTP payload format is specified in [RFC4867]. In this AMR-
151	   WB interoperable mode, layers L1, L2 are replaced by L1' consisting
152	   of AMR-WB encoded data. Furthermore, together with L1' modified L3'
153	   is used instead of L3. The usage of layers L4 and L5 is not affected
154	   by transmitting AMR-WB data in the lower layers. If layer L3' is
155	   present in the encoded bit-stream, the base layer L1' must use the
156	   AMR-WB mode 2 with the bit-rate of 12.65 kbits/s. Otherwise (the
157	   encoded bit-stream contains only the L1' layer), any of the 9 AMR-WB
158	   coding modes 0, 1, 2, 3, 4, 5, 6, 7, and 8 correspond to the bit-
159	   rates of 6.60, 8.85, 12.65, 14.25, 15.85, 18.25, 19.85, 23.05, and
160	   23.85 kbit/s, respectively, may be in use. Table 2 summarizes the
161	   AMR-WB interoperable mode when more than one layer may be present.

163	          Table 2: G.718 layers in the AMR-WB interoperable mode

165	        Layer   Bytes   Cumulative bit-rate   Sampling rate   Output
166	      -----------------------------------------------------------------_
167	         L1'      32       12.8 kbit/s           16 kHz          WB
168	         L3'       9       16.4 kbit/s           16 kHz          WB
169	         L4       20       24.4 kbit/s           16 kHz          WB
170	         L5       20       32.4 kbit/s           16 kHz          WB

172	   Note that the bit-rate for the raw bit-stream of AMR-WB mode 2 is
173	   12.65 kbits/s. However, after counting the padding bits to make each
174	   encoded data unit byte-aligned, as in the octet-aligned mode
175	   specified in [RFC4867], the resulting bit-rate is then 12.8 kbits/s.

177	   In the AMR-WB interoperable mode, when the base layer L1' is
178	   transported in its own RTP packet stream, the packetisation specified
179	   in [RFC4867] MUST be used, to enable legacy RFC4867 receivers to
180	   receive the base layer L1'.

182	   ITU-T SG16 is currently working on a set of extension layers in order
183	   to provide a so-called super-wideband (SWB) audio and stereophonic
184	   encoding extensions on top of the G.718 core codec. Further details
185	   and the usage of these layers are TBD.

187	   The main application of the G.718 codec is telephony. Other expected
188	   applications include audio/video conferencing and streaming.

190	2.2. Benefits of layered design

192	   The layered design enables simple scalability of the transmitted
193	   stream simply by conveying a suitable number of layers. The number of
194	   layers used in a session may be selected for example based on the
195	   capacity of the transmission channel, current transmission
196	   conditions, characteristics of the source signal or available
197	   processing capacity.

199	   Another obvious benefit of the layered codec design is the
200	   possibility to exploit the scalability to support congestion control
201	   by transmitting/dropping some of the (higher) enhancement layers in
202	   order to alleviate congestion in the network. See more detailed
203	   discussion on the congestion control in section 6.

205	   Furthermore, the layered design also implicitly provides possibility
206	   for unequal error detection/protection by employing different levels
207	   of protection on core layer and enhancement layers.

209	2.3. Transmitting layered data

211	   In principle there are two basic approaches to carry the data from a
212	   layered encoder:

214	   1. All the layers are carried within a single RTP session.

216	   2. The encoded data is divided over multiple RTP sessions, each
217	      session carrying a subset of layers. This is also referred to as
218	      Multi-Session Transmission (MST).

220	   The first choice is the most efficient in terms of exploitation of
221	   transmission bandwidth. Furthermore, using only one packet to carry
222	   all encoded data layers of a frame requires less resources also from
223	   the end-systems (and intermediate systems) since the number of
224	   packets is kept at minimum and only single RTP packet stream needs to
225	   be handled. However, this option requires any intermediate network
226	   element performing the scaling operation to be fully media-aware
227	   since removing encoded layers requires modification of the payload.
228	   Furthermore, the intermediate network element needs to be within the
229	   security context to enable the meaningful manipulation of the
230	   payload, in case secure transport is employed. This might not be
231	   feasible in all systems/scenarios, but some special-purpose devices
232	   such as e.g. media gateways in cellular telephone systems may be able
233	   to implement this kind of media-aware functionality.

235	   The second alternative transmitting selected subsets of layers in
236	   separate RTP sessions facilitates simple scalability in intermediate
237	   network elements without the requirement of being fully media-aware.
238	   One use case of this alternative is layered multicast [McCanne]. On
239	   the other hand, this approach introduces separate packet header
240	   overhead for each subset of layers for those low-delay application
241	   scenarios wherein aggregation of data from multiple frames is not
242	   ideal. In this case, when the size of the encoded data block per
243	   single layer is in the range of 10 to 20 bytes, the packetisation may
244	   result in relatively high amount of protocol overhead, which might be
245	   an expensive solution on bandwidth-limited links. Another drawback of
246	   this approach is somewhat more complex session setup and the
247	   additional complexity associated with handling of several concurrent
248	   RTP sessions. However, this is a trade-off that enables simple
249	   scalability also by intermediate network elements that are not aware
250	   of the details of the transmitted media.

252	2.4. Scaling scenarios & rate control

254	   In principle there are three different ways to make use of the
255	   layered design to control the bandwidth usage:

257	   1. A sender decides to change the number of layers it is transmitting
258	   (for example due to congestion control constrains)

260	   2. A receiver or an intermediate network element instructs a sender
261	      to change the number of layers it is transmitting

263	   3. An intermediate network element passes forward only a subset of
264	      layers it receives

266	   The most appropriate mechanism depends on the application and the
267	   employed network topology. For example point-to-point conversational
268	   audio connection can easily introduce rate control by changing the
269	   number of transmitted layers, while in centralized audio/video
270	   conferencing scenario the conference server is a more appropriate
271	   point to implement the rate control instead of transmitting end-
272	   point. Please refer to [RFC5117] for extensive discussion on the
273	   different topologies and their implications to the transmission.

275	   However, the fundamental difference between these choices is that
276	   method 1 does not necessarily need any feedback from the receiver(s),
277	   while methods 2 and 3 require a signaling mechanism to support rate
278	   control.

280	3. G.718 RTP payload format

282	   The basic G.718 source data unit is one layer of an encoded frame.
283	   Since generally the term layer refers to time series of data
284	   representing certain encoding layer, in this specification we use the
285	   term Encoded Data Unit (EDU) to refer to a single layer of data from
286	   single encoded frame. Thus, each EDU has a (conceptual) frame number
287	   indicating its location in encoding/decoding order and a layer number
288	   indicating the encoding layer the EDU represents.

290	3.1. Payload Structure

292	   The G.718 payload format consists of a payload header, followed by
293	   one or more transport blocks (TB) forming the actual payload data.

295	    +-----------------+----------+----------+- /// -+----------+
296	    | Payload header  |  TB(1)   |  TB(2)   |          TB(n)   |
297	    +-----------------+----------+----------+- /// -+----------+

299	3.1.1. Payload Header

301	   The payload header consists of an 8-bit payload CRC checksum:

303	    +-+-+-+-+-+-+-+-+
304	    |     CRC       |
305	    +-+-+-+-+-+-+-+-+

307	   In the transmitting end the payload checksum is computed over the
308	   primary transport block (specified in section 3.1.2. ) of the payload
309	   using the generator polynomial

311	      C(z) = z^8 + z^4 + z^3 + z^2 + 1.

313	   Subsequent transport blocks are prepared in such a way that the
314	   payload checksum is valid for any integer number of contiguous
315	   transport blocks within one RTP packet starting from the beginning of
316	   the primary transport block.

318	   In the receiving end the payload CRC checksum can be used to verify
319	   the correct reception of any contiguous subset of transport blocks
320	   within one RTP packet starting from the beginning of the primary
321	   transport block (see section 3.4.  for detailed description).

323	3.1.2. G.718 transport blocks

325	   The basic building block of the G.718 RTP payload data is an G.718
326	   transport block (TB). There are two types of transport blocks:
327	   primary transport block and secondary transport block.

329	   The structure of the primary transport block is depicted below.

331	     0 1 2 3 4 5 6 7
332	    +-+-+-+-+-+-+-+-+----------------------------+
333	    |   L-ID    |NF | Encoded data               |
334	    +-+-+-+-+-+-+-+-+----------------------------+

336	   The structure of the secondary transport block is depicted below.

338	     0 1 2 3 4 5 6 7                              0 1 2 3 4 5 6 7
339	    +-+-+-+-+-+-+-+-+----------------------------+-+-+-+-+-+-+-+-+
340	    |   L-ID    |NF | Encoded data               |     Tail      |
341	    +-+-+-+-+-+-+-+-+----------------------------+-+-+-+-+-+-+-+-+

343	   The layer ID (L-ID) and the NF fields form the transport block
344	   header. The L-ID field is used to identify the layer structure of the
345	   encoded data carried in this G.718 transport block, and the NF field
346	   indicates the number of encoded frames with this layer structure
347	   carried in the Encoded data part following the transport block
348	   header. The Tail field of the secondary transport block carries a
349	   modified 8-bit CRC checksum computed over the transport block, as
350	   specified below.

352	             Author's note: For streaming or other applications that
353	             allow for relatively long end-to-end delay, sometimes it
354	             would be beneficial to aggregate more than 4 frames in one
355	             TB. Should the length of NF be larger?

357	   An G.718 RTP packet payload SHALL include exactly one primary
358	   transport block, which MAY be followed by one or more secondary
359	   transport blocks. The data fields of both transport block types are
360	   described below.

362	   L-ID Identification (6 bits) of the encoded data carried in this
363	        transport block. Table 3 below specifies the mapping between L-
364	        ID and the encoded data.

366	                Table 3: Layer identification (L-ID) values

368	          L-ID    Encoded data
369	        --------------------------------------
370	            0     Empty frame
371	            1     L1
372	            2     L1-L2
373	            3     L1-L3
374	            4     L1-L4
375	            5     L1-L5
376	            6     L2
377	            7     L2-L3
378	            8     L2-L4
379	            9     L2-L5
380	           10     L3
381	           11     L3-L4
382	           12     L3-L5
383	           13     L4
384	           14     L4-L5
385	           15     L5
386	           16     L1'
387	           17     L1', L3'
388	           18     L1', L3', L4
389	           19     L1', L3', L4-L5
390	           20     G.718 SID
391	           21     AMR-WB SID
392	           22-63  Reserved

394	             Author's note: The current approach provides maximum
395	             flexibility in terms of layer configuration. However,
396	             limiting choices would be one way to leave more bits for
397	             stereo & SWB layer configurations.

399	             Author's note: One suggested way to make sure we do not
400	             run out of L-ID values with the extension modes has been
401	             to make the mapping between L-ID and layer configuration
402	             dynamic (to be specified using SDP in session set-up).
403	             While this would provide effective usage of L-ID bits, it
404	             would require all elements processing the payload to be
405	             signaling-aware. A compromise solution would be to provide
406	             static mapping for selected layer configurations and leave
407	             'more exotic' cases to be dynamically mapped on session
408	             basis. The usage of this type of approach is FFS.

410	             Author's note: Yet another possible way is to do similar
411	             as in the SVC RTP payload format draft, i.e. to signal the
412	             bitrate etc. parameters for an operation point, and signal
413	             dependency between sessions using the MMUSIC decoding
414	             dependency draft. This way should be generic enough and
415	             applicable to future versions of scalable codecs. However,
416	             the above methods (using detailed layer configuration may
417	             provide more useful information as the bitrate etc. of
418	             each layer is fixed, not as flexible as in SVC.)

420	             Author's note: Yet another approach is to allocate L-ID
421	             according to different mode. For example, the mode with L1
422	             being present and the AMR-WB compatible mode (with L1'
423	             being present) use different value spaces of L-ID.

425	   NF   Number of frames in this transport block (2 bits) decreased by
426	        one. The number of frames is equal to the value of NF
427	        incremented by one. For example, value NF=0 indicates that the
428	        transport block carries one frame, and value NF=3 indicate that
429	        the transport block carries four frames. If the sender wants to
430	        encapsulate more than four frames per payload, several
431	        transport blocks need to be used.

433	   Encoded data

435	        Encoded data consists of EDUs as specified by the values L-ID
436	        and NF fields, arranged according to rules given in section
437	        3.2.  When L-ID is equal to 0 (empty frame), the encoded data
438	        field is not present (i.e. it consists of zero octet).

440	   Tail The 8-bit tail field of the secondary transport block carries a
441	        bit field that is needed to modify the partial CRC checksum
442	        over the payload data up to the end of this TB to match the
443	        payload CRC field value carried in the payload header.

445	        In the transmitter the Tail bits for a secondary TB(n) are
446	        computed by first computing the CRC checksum CRC(n) over the
447	        payload data from the beginning of the primary TB up to the end
448	        of TB(n) using the generator polynomial C(z) given above. The
449	        bits of the Tail field of TB(n) are set to zero value for the
450	        CRC computation. The transmitted value of the Tail field in
451	        TB(n) is obtained by bitwise XOR operation between the payload
452	        CRC field value carried in the payload header and the CRC(n)
453	        computed for TB(n).

455	3.2. Handling the Encoded data

457	   In order to provide unique mapping of EDUs to encoded frames, the
458	   following rules on sequence of frames and sequence of layers need to
459	   be followed when creating a payload:

461	   o  The frames within a payload MUST form a set of contiguous frames
462	      in decoding order, i.e. if a payload carries frames n and n+N, all
463	      frames between n and n+N in decoding order MUST also be present in
464	      the payload.

466	   o  The layers within a frame MUST form a contiguous set of layers,
467	      i.e. if layers Lx and Ly of a frame are included in the payload,
468	      all layers between Lx and Ly layers MUST also be present.

470	   The EDUs within a transport block are arranged according to the
471	   following rules:

473	   o  The EDUs within a transport block MUST be arranged in increasing
474	      order of layer number

476	   o  The EDUs with the same layer number within a transport block MUST
477	      be arranged in decoding order

479	   Explicit timing information for the transport blocks is not needed,
480	   since the ordering of EDUs in the payload and their mapping to
481	   transport blocks can be used to implicitly carry this information.
482	   The following rules apply:

484	   o  If the highest layer carried in transport block k is n, and the
485	      lowest layer carried by transport block k+1 is n+1, then the EDUs
486	      of transport block k and k+1 belong to the same encoded frame.
487	      Furthermore, if transport blocks k and k+1 carry EDUs belonging to
488	      the same encoded frame(s), these transport blocks MUST include the
489	      same number of EDUs.

491	   o  If the highest layer carried in transport block k is n, and the
492	      lowest layer carried by transport block k+1 is smaller than or
493	      equal to n, the EDUs of transport block k and k+1 belong to the
494	      two separate encoded frames, which are contiguous in decoding
495	      order.

497	   o  Multiple copies of an EDU MUST NOT be included in the payload.

499	   A set of EDUs can be allocated to transport blocks in several ways.
500	   For example each EDU can be encapsulated in its own transport block,
501	   all EDUs can be carried in single transport block, EDUs belonging to
502	   the same encoded frame can be encapsulated in dedicated transport
503	   block, or EDUs representing the same layer can be carried in their
504	   own transport blocks. Three examples on this with two frames with
505	   layers L1-L3 are given below. The first example illustrates the case
506	   using a single transport block for the whole payload, while the
507	   second payload example introduces separate transport blocks for each
508	   of the EDUs. The third example shows an approach where all layers are
509	   carried in dedicated transport blocks. The notation Fx-Ly is used to
510	   denote layer y of frame x.

512	   Example 1: All EDUs in a single transport block

514	     +---------+-----+-------+-------+-------+-------+-------+--------+
515	     | L-ID=3  |NF=1 | F1-L1 | F2-L1 | F1-L2 | F2-L2 | F1-L3 | F2-L3  |
516	     +---------+-----+-------+-------+-------+-------+-------+--------+

518	             Author's note: Currently, it is mandated that lower layer
519	             EDUs of later frames go before higher layer EDUs of
520	             earlier frames. This way is friendlier to adaptation
521	             (dropping of higher layers). However, if all layers are
522	             received, then the depacketizer needs to reorder the EDUs
523	             to their decoding order before feeding them to the
524	             decoder. Therefore, the other way around (i.e. lower layer
525	             EDUs of later frames go after higher layer EDUs of earlier
526	             frames, or EDUs in transport blocks are placed in decoding
527	             order) is more friendly to the depacketizer. Another
528	             benefit of the latter is that it does not introduce any
529	             end-to-end delay. Which way to be specified (or both
530	             allowed if needed) is FFS.

532	   Example 2: All EDUs in separate transport blocks

534	     +---------+-----+-------+---------+-----+-------+
535	     | L-ID=1  |NF=0 | F1-L1 | L-ID=1  |NF=0 | F2-L1 |
536	     +---------+-----+-------+---------+-----+-------+
537	     | L-ID=8  |NF=0 | F1-L2 | L-ID=8  |NF=0 | F2-L2 |
538	     +---------+-----+-------+---------+-----+-------+
539	     | L-ID=14 |NF=0 | F1-L3 | L-ID=14 |NF=0 | F2-L3 |
540	     +---------+-----+-------+---------+-----+-------+

542	   Example 3: Dedicated transport for EDUs of each layer

544	     +---------+-----+-------+-------+---------+-----+-------+-------+
545	     | L-ID=1  |NF=1 | F1-L1 | F2-L1 | L-ID=6  |NF=1 | F1-L2 | F2-L2 |
546	     +---------+-----+-------+-------+---------+-----+-------+-------+
547	     | L-ID=10 |NF=1 | F1-L3 | F2-L3 |
548	     +---------+-----+-------+-------+

550	   While the first example carrying data from all layers in the same
551	   transport block obviously consumes less bandwidth, the second example
552	   using separate transport block for each EDU, and the third example
553	   using dedicated transport blocks for each layer provide simple
554	   scaling possibility: while in the first case the removal of e.g.
555	   layer L3 (from each frame in the payload) would require changing the
556	   value of the L-ID in addition to removing the corresponding EDU(s),
557	   in the second and third options it is enough to just remove all
558	   transport blocks carrying L3 data and the remaining part of the
559	   payload can be left untouched (however the packet size information in
560	   high-layer protocol headers needs change).

562	3.3. G.718 scaling

564	   Some media-aware network elements (MANEs) MAY modify the G.718
565	   bitstream by dropping some of the layers in case congestion control
566	   or e.g. access link bandwidth requires such scaling to take place.
567	   Such MANEs are RTP translators (with the topology Topo-Translator as
568	   described in [RFC5117]), for which the rules for RTP translators
569	   specified in [RFC3550] apply.

571	   A payload can be either completely dropped or some of the transport
572	   blocks it carries can be discarded. In case full payloads are dropped
573	   to implement scaling, a packet containing the core layer L1 SHOULD
574	   NOT be discarded, since the decoding of higher layers of the same
575	   encoded frame is not possible without the core layer data being
576	   available. This means that payloads with L-ID values equal to 1 to 5,
577	   inclusive and 16 to 19, inclusive, SHOULD NOT be completely
578	   discarded.

580	             Author's note: To be checked whether the case of dropping
581	             a subset of the transport blocks in one packet also
582	             strictly follows the topology Topo-Translator.

584	   In case the payload is forwarded with modified content, at least the
585	   primary transport block MUST be preserved in the payload, while some
586	   of the secondary transport blocks at the end of the payload MAY be
587	   discarded.

589	3.4. CRC verification

591	   Both UDP-Lite [RFC3828] and DCCP [4340] provide partial checksum
592	   options, in which partially damaged payloads can be delivered to the
593	   application layer.  In cases wherein such a transport layer operation
594	   is in use, and the partial checksum service by the transport layer
595	   protects up to the RTP header and the payload header, the CRC
596	   checksum provided in the payload header can be used to verify whether
597	   an RTP packet payload contains corrupt transport blocks.

599	   In the receiving end the CRC verification is made in such a way that
600	   the CRC computation is started from the beginning of the primary TB,
601	   i.e. from the MSB of the first octet of the TB(1), and the
602	   computation is continued until the end of the payload data or until
603	   an erroneous TB is encountered. At the end of each TB a check MAY be
604	   performed: if the CRC value at the end of TB(n) matches the payload
605	   CRC value received in the payload header, the verification is
606	   successful and the data up TB(n) is valid. If the CRC value at the
607	   end of TB(n) does not match the payload CRC value received in the
608	   payload header, there is an error in the TB(n) and it MUST be
609	   discarded as corrupted. Furthermore, if the verification indicates
610	   corrupted TB(n), all subsequent transport blocks TB(m) with m>n MUST
611	   also be discarded.

613	3.5. G.718 session

615	   An G.718 session consists of one or several RTP sessions carrying
616	   encoded G.718 data according the payload format specified in section
617	   3.1.

619	3.6. Cross-stream/cross-layer timing synchronization

621	   In case an G.718 session consists of multiple RTP sessions, the RTP
622	   packets transmitted on separate RTP sessions need to be synchronized
623	   in order to enable reconstruction of the frames in the receiving end.
624	   Since each of the RTP sessions uses its own random initial value for
625	   the RTP timestamp, there is also a random offset between the RTP
626	   timestamps values carrying the EDUs belonging to the same encoded
627	   frame in different RTP sessions.

629	   The receiver MUST use the traditional RTCP based mechanism to
630	   synchronize streams by using the RTP and NTP timestamps of the RTCP
631	   Sender Reports (SR) it receives.

633	3.7. RTP Header usage

635	   This section specifies the usage of some fields of the RTP header
636	   (specified in section 5 of [RFC3550]) with the G.718 RTP payload
637	   format.  Setting of other RTP header fields is as specified in
638	   [RFC3550].

640	   The RTP timestamp corresponds to the sampling instant of the first
641	   encoded sample of the earliest frame in the payload. The timestamp
642	   clock frequency is 32 kHz.

644	   The marker bit (M) of each of the RTP streams of the session SHALL be
645	   set to value 1 if the payload carries an EDU belonging to the first
646	   frame after an inactive period, i.e. an EDU from the first frame of a
647	   talkspurt. For all other packets the marker bit is set to value 0.

649	4. Payload Format Parameters

651	   This section defines the parameters that may be used to configure
652	   optional features in the G.718 RTP transmission.

654	   The parameters are defined here as part of the media subtype
655	   registration for the G.718 codec.  Mapping of the parameters into the
656	   Session Description Protocol (SDP) [RFC4566] is also provided for
657	   those applications that use SDP.  In control protocols that do not
658	   use MIME or SDP, the media type parameters must be mapped to the
659	   appropriate format used with that control protocol.

661	4.1. Media Type Registration

663	   This registration is done using the template defined in RFC 4288
664	   [RFC4288] and following RFC 4855 [RFC4855].

666	   Type name:  audio

668	   Subtype name:  G718

670	   Required parameters:  none

672	   Optional parameters:

674	      mode:      This parameter MAY be used to indicate whether the
675	                 mode with layer L1 being present or the AMR-WB
676	                 compatible mode (with layer L1' being present) is in
677	                 use. If this parameter is not present or the value of
678	                 this parameter is equal to 0, the mode with layer L1
679	                 being present is in use. Otherwise, the AMR-WB
680	                 compatible mode is in use. When this parameter is
681	                 present, the value MUST be either 0 or 1.

683	      Author's note: When the upcoming stereo and SWB options are
684	      present, the semantics of this parameter may change.

686	      layers:    The numbers of the layers (in range from 1 to 5,
687	                 denoting layers from L1 to L5, respectively)
688	                 transmitted in this session, expressed as comma-
689	                 separated list of layer numbers. If the parameter is
690	                 present, at least layer L1 or L1' MUST be included in
691	                 the list of layers in one of the RTP sessions included
692	                 in the G.718 session. If the parameter is not present,
693	                 all layers up to layer L5 MAY be used in the session.

695	      Author's note: Why not use semantics similarly as L-ID?

697	      ptime:     The recommended length of time (in milliseconds)
698	                 represented by the media in a packet.  See Section 6
699	                 of [RFC4566].

701	      maxptime:  The maximum length of time (in milliseconds) that can
702	                 be encapsulated in a packet.  See Section 6 of
703	                 [RFC4566]

705	      Author's note: Some further study is needed to see if separate
706	      parameters for sending and receiving capabilities/preferences are
707	      needed -- especially for upcoming stereo and SWB options.

709	      Author's note: The support for upcoming SWB and stereo options
710	      needs to be taken into account. Basically we can either 1) extend
711	      the parameter "layers" to cover also this aspect, or 2) define
712	      separate parameter(s) for these new options when more details on
713	      the stereo/SWB support are available.

715	   Encoding considerations:

717	     This media type is framed and contains binary data; see Section 4.8
718	     of [RFC4288].

720	   Security considerations:  See Section 6 of RFC xxxx

722	   Interoperability considerations:  none

724	   Published specification:  RFC xxxx

726	   Applications which use this media type:

728	     For example Voice over IP, audio and video conferencing, audio
729	     streaming and voice messaging.

731	   Additional information:  none

733	   Person & email address to contact for further information:

735	     Ari Lakaniemi, ari.lakaniemi@nokia.com

737	   Intended usage:  COMMON
738	   Restrictions on usage:

740	     This media type depends on RTP framing, and hence is only defined
741	     for transfer via RTP [RFC3550]

743	   Author:

745	     Ari Lakaniemi, ari.lakaniemi@nokia.com

747	   Change controller:

749	     IETF Audio/Video Transport working group delegated from the IESG

751	4.2. Mapping to SDP Parameters

753	   The information carried in the media type specification has a
754	   specific mapping to fields of the SDP [RFC4566], which is commonly
755	   used to describe RTP sessions.  When SDP is used to specify sessions
756	   employing the G.718 codec, the mapping is as follows:

758	   o  The media type ("audio") goes in SDP "m=" as the media name.

760	   o  The media subtype ("G718") goes in SDP "a=rtpmap" as the encoding
761	      name.  The RTP clock rate in "a=rtpmap" MUST be 32000 for G.718.

763	      Author's note: The current choice for the RTP clock rate is a
764	      'placeholder'. The clock rate needs to be set according to SWB
765	      sampling rate, which is still T.B.D. Since the core codec employs
766	      16000 Hz sampling rate, an integer multiple of 16000 Hz seems to
767	      be a preferable choice.

769	   o  The parameters "ptime" and "maxptime" go in the SDP "a=ptime" and
770	      "a=maxptime" attributes, respectively.

772	   o  Any remaining parameters go in the SDP "a=fmtp" attribute by
773	      copying them directly from the media type string as a semicolon
774	      separated list of parameter=value pairs.

776	4.3. Offer/answer considerations

778	   The following considerations apply when using the SDP offer/answer
779	   [RFC3264] mechanism to negotiate the G.718 transport. The parameter
780	   "layers" MAY be used to indicate the layer configuration for the each
781	   RTP session belonging to current G.718 session an end-point making
782	   the offer is ready to transmit and wishes to receive.

784	   o  In case the G.718 session consists of a single RTP session, it is
785	      RECOMMENDED not to impose any layer restrictions for the session
786	      but to use the rate control functionality to set possible
787	      restrictions on usage of the higher or highest layers. If the
788	      offer includes a layer configuration parameter, the answer MAY use
789	      different configuration, but the highest layer in the answer MUST
790	      NOT be higher than the highest layer of the offered configuration.

792	      Author's note: Support for answer modifying the layer
793	      configuration is FFS.

795	   In case the G.718 session consists of multiple RTP sessions, the
796	   answer MUST use the layer configurations provided in the offer for
797	   the sessions it accepts.

799	4.4. Declarative usage of SDP

801	   In declarative usage, such as SDP in RTSP [RFC2326] or SAP [RFC2974],
802	   the parameter "layers" SHALL be interpreted to provide a set of
803	   layers that the sender may use in the session.

805	4.5. SDP examples

807	   Some example SDP session descriptions utilizing G.718 encodings are
808	   provided below.

810	   The first example illustrates the simple case where the G.718 session
811	   employing a single RTP session and the AVPF profile is offered, and
812	   the answer accepts the offer without any changes.

814	   Offer:

816	     m=audio 49120 RTP/AVPF 97
817	     a=rtpmap:97 G718/32000/1

819	   Answer:

821	     m=audio 49120 RTP/AVPF 97
822	     a=rtpmap:97 G718/32000/1

824	   The second example shows a bit more complex case where the G.718
825	   session using a single RTP session and the AVPF profile is offered
826	   with restriction to send/receive only with layers L1 and L2. The
827	   answer indicates that the other end-point is happy to receive (and
828	   send) layers up to L5.

830	   Offer:

832	     m=audio 49120 RTP/AVPF 97
833	     a=rtpmap:97 G718/32000/1
834	     a=fmtp:97 layers=1,2

836	   Answer:

838	     m=audio 49120 RTP/AVPF 97
839	     a=rtpmap:97 G718/32000/1
840	     a=fmtp:97 layers=1,2,3,4,5

842	   The third example shows an G.718 session using multiple RTP sessions
843	   with the AVPF profile. The answerer wishes to use only layers up to
844	   L3.

846	   Offer:

848	     m=audio 49120 RTP/AVPF 97
849	     a=rtpmap:97 G718/32000/1
850	     a=fmtp:97 layers=1,2
851	     a=mid=1

853	     m=audio 49122 RTP/AVPF 98
854	     a=rtpmap:98 G718/32000/1
855	     a=fmtp:98 layers=3
856	     a=mid=2
857	     a=depend:lay 1

859	     m=audio 49124 RTP/AVPF 99
860	     a=rtpmap:99 G718/32000/1
861	     a=fmtp:99 layers=4,5
862	     a=mid=3
863	     a=depend:lay 1 2

865	   Answer:

867	     m=audio 49120 RTP/AVPF 97
868	     a=rtpmap:97 G718/32000/1
869	     a=fmtp:97 layers=1,2
870	     a=mid=1

872	     m=audio 49120 RTP/AVPF 98
873	     a=rtpmap:98 G718/32000/1
874	     a=fmtp:98 layers=3
875	     a=mid=2
876	     a=depend:lay 1

878	   Note that the dependency signaling according to [smd-sdp] is used in
879	   the third example above to indicate the relationship between the
880	   layers distributed into separate RTP sessions.

882	5. Security Considerations

884	   RTP packets using the payload format defined in this specification
885	   are subject to the security considerations discussed in the RTP
886	   specification [RFC3550], and in any appropriate RTP profile (for
887	   example [RFC3551] or [RFC4585]).  This implies that confidentiality
888	   of the media streams is achieved by encryption; for example, through
889	   the application of SRTP [RFC3711].  Because the data compression used
890	   with this payload format is applied end-to-end, any encryption needs
891	   to be performed after compression.

893	   A potential denial-of-service threat exists for data encodings using
894	   compression techniques that have non-uniform receiver-end
895	   computational load.  The attacker can inject pathological datagrams
896	   into the stream that will increase the processing load of the decoder
897	   and may cause the receiver to be overloaded. For example inserting
898	   additional EDUs representing the higher enhancement layers on top of
899	   the ones actually transmitted may increase the decoder load. However,
900	   the G.718 codec is not particularly vulnerable to such an attack,
901	   since the majority of the computational load in an G.718 session is
902	   associated to the encoder.  Another form of possible attach might be
903	   forging of codec bit-rate control messages, which may result in
904	   encoder operating employing higher number of enhancement layers than
905	   originally intended and thereby requiring larger amount of
906	   computation resources. Therefore, the usage of data origin
907	   authentication and data integrity protection of at least the RTP
908	   packet is RECOMMENDED; for example, with SRTP [RFC3711].

910	   Note that the appropriate mechanism to ensure confidentiality and
911	   integrity of RTP packets and their payloads is very dependent on the
912	   application and on the transport and signaling protocols employed.

914	   Thus, although SRTP is given as an example above, other possible
915	   choices exist.

917	   Note that end-to-end security with either authentication, integrity
918	   or confidentiality protection will prevent a network element not
919	   within the security context from performing media-aware operations
920	   other than discarding complete packets.  To allow any (media-aware)
921	   intermediate network element to perform its operations, it is
922	   required to be a trusted entity which is included in the security
923	   context establishment.

925	6. Congestion control

927	   As scalable codec G.718 implicitly provides means for congestion
928	   control by providing a possibility for 'thinning' the bitstream. The
929	   RTP payload format according to this specification provides several
930	   different means for reducing the G.718 session bandwidth. The most
931	   appropriate mechanism (in terms of impact to the user experience)
932	   depends on the employed payload structure and also on the employed
933	   session configuration (single RTP session or multiple RTP sessions).
934	   The following means (in no particular order) can be used to assist
935	   congestion control procedures -- either by the sender or by the
936	   intermediate node.

938	   o  The transport blocks carrying the EDUs representing the highest
939	      layers within the payload may be dropped.

941	   o  The payloads carrying the EDUs representing the highest layers in
942	      an G.718 session are dropped.

944	   o  Transport blocks or payloads carrying EDUs belonging to redundant
945	      frames included in the payload are dropped.

947	7. IANA Considerations

949	   IANA is kindly requested to register a media type for the G.718 codec
950	   for RTP transport, as specified in section 4.1.  of this document.

952	APPENDIX A: Payload examples

954	   The G.718 payload structure enables flexible transport either by
955	   carrying all layers in the same payload or separating the layers into
956	   separate payloads. The following subsections illustrate different
957	   possibilities for transport by simple examples. Note that examples do
958	   not show the full payload structure to keep the illustration simple.

960	A.1. Simple payload examples

962	A.1.1. All the layers in the same payload

964	   The illustration below shows layers L1-L3 from two encoded frames
965	   encapsulated into separate payloads using single transport block.

967	    +-------+--------+-----+------+------+------+
968	    | RTP1  | L-ID=3 |NF=0 |F1-L1 |F1-L2 |F1-L3 |
969	    +-------+--------+-----+------+------+------+

971	    +-------+--------+-----+------+------+------+
972	    | RTP2  | L-ID=3 |NF=0 |F2-L1 |F2-L2 |F2-L3 |
973	    +-------+--------+-----+------+------+------+

975	   In case the same layers from two input frames are encapsulated into
976	   one payload using single transport block, the structure is as shown
977	   below.

979	    +-------+--------+-----+------+------+------+------+------+------+
980	    | RTP1  | L-ID=3 |NF=1 |F1-L1 |F2-L1 |F1-L2 |F2-L2 |F3-L3 |F2-L3 |
981	    +-------+--------+-----+------+------+------+------+------+------+

983	   The third example illustrates the case where the layers L1-L3 from
984	   two input frames are encapsulated into one payload using two separate
985	   transport blocks, the first one carrying L1 and the other one
986	   containing L2 and L3.

988	    +-------+--------+-----+------+------+
989	    | RTP1  | L-ID=1 |NF=1 |F1-L1 |F2-L1 |
990	    +-------+--------+-----+------+------+------+------+
991	            | L-ID=7 |NF=1 |F1-L2 |F2-L2 |F2-L2 |F2-L3 |
992	            +--------+-----+------+------+------+------+

994	A.1.2. Layers in separate RTP streams

996	   In this case the data for each layer is transmitted in its own
997	   payload.

999	   In the first example each transport block including a single EDU is
1000	   carried in its own RTP payload.

1002	    +-------+--------+-----+-----+    +-------+--------+-----+-----+
1003	    | RTP1a | L-ID=1 |NF=0 |F1-L1|    | RTP1b | L-ID=6 |NF=0 |F1-L2|
1004	    +-------+--------+-----+-----+    +-------+--------+-----+-----+

1006	    +-------+--------+-----+-----+    +-------+--------+-----+-----+
1007	    | RTP1c |L-ID=10 |NF=0 |F1-L3|    | RTP2a | L-ID=1 |NF=0 |F2-L1|
1008	    +-------+--------+-----+-----+    +-------+--------+-----+-----+

1010	    +-------+--------+-----+-----+    +-------+--------+-----+-----+
1011	    | RTP2b | L-ID=6 |NF=0 |F2-L2|    | RTP2c |L-ID=10 |NF=0 |F2-L3|
1012	    +-------+--------+-----+-----+    +-------+--------+-----+-----+

1014	   If the payloads carry data from two consecutive input frames, the
1015	   same encoded data as in the previous example is arranged as follows.

1017	    +-------+--------+-----+-----+-----+
1018	    | RTP1a | L-ID=1 |NF=1 |F1-L1|F2-L1|
1019	    +-------+--------+-----+-----+-----+

1021	    +-------+--------+-----+-----+-----+
1022	    | RTP1b | L-ID=6 |NF=1 |F1-L2|F2-L2|
1023	    +-------+--------+-----+-----+-----+

1025	    +-------+--------+-----+-----+-----+
1026	    | RTP1c |L-ID=10 |NF=1 |F1-L3|F2-L3|
1027	    +-------+--------+-----+-----+-----+

1029	A.2. Advanced examples

1031	A.2.1. Different update rate for subset of layers

1033	   An example employing different update rates (i.e. different number of
1034	   frames per packet) for selected subsets of layers. In these examples
1035	   all core codec layers L1-L5 are shown.

1037	    +-------+--------+-----+-----+-----+-----+-----+
1038	    | RTP1  | L-ID=1 |NF=3 |F1-L1|F2-L1|F3-L1|F4-L1|
1039	    +-------+--------+-----+-----+-----+-----+-----+

1041	    +-------+--------+-----+-----+-----+-----+-----+
1042	    | RTP2a | L-ID=7 |NF=1 |F1-L2|F2-L2|F1-L3|F2-L3|
1043	    +-------+--------+-----+-----+-----+-----+-----+

1045	    +-------+--------+-----+-----+-----+
1046	    | RTP3a |L-ID=14 |NF=0 |F1-L4|F1-L5|
1047	    +-------+--------+-----+-----+-----+

1049	    +-------+--------+-----+-----+-----+
1050	    | RTP3b |L-ID=14 |NF=0 |F2-L4|F2-L5|
1051	    +-------+--------+-----+-----+-----+

1053	    +-------+--------+-----+-----+-----+-----+-----+
1054	    | RTP2b | L-ID=7 |NF=1 |F3-L2|F4-L2|F3-L3|F4-L3|
1055	    +-------+--------+-----+-----+-----+-----+-----+

1057	    +-------+--------+-----+-----+-----+
1058	    | RTP3c |L-ID=14 |NF=0 |F3-L4|F3-L5|
1059	    +-------+--------+-----+-----+-----+

1061	    +-------+--------+-----+-----+-----+
1062	    | RTP3d |L-ID=14 |NF=0 |F4-L4|F4-L5|
1063	    +-------+--------+-----+-----+-----+

1065	A.2.2. Redundant frames with limited set of layers

1067	   An example transmitting layers L1-L3 as primary data and L1 (of the
1068	   previous frame) as redundant data is shown below. Each payload
1069	   carries one primary (i.e. new) frame in one transport block and one
1070	   redundant frame, which in this example is the frame preceding the
1071	   primary frame, in another transport block.

1073	    +-------+--------+-----+-----+--------+-----+-----+-----+-----+
1074	    | RTP1  | L-ID=1 |NF=0 |F0-L1| L-ID=3 |NF=0 |F1-L1|F1-L2|F1-L3|
1075	    +-------+--------+-----+-----+--------+-----+-----+-----+-----+

1077	    +-------+--------+-----+-----+--------+-----+-----+-----+-----+
1078	    | RTP2  | L-ID=1 |NF=0 |F1-L1| L-ID=3 |NF=0 |F2-L1|F2-L2|F2-L3|
1079	    +-------+--------+-----+-----+--------+-----+-----+-----+-----+

1081	    +-------+--------+-----+-----+--------+-----+-----+-----+-----+
1082	    | RTP3  | L-ID=1 |NF=0 |F2-L1| L-ID=3 |NF=0 |F3-L1|F3-L2|F3-L3|
1083	    +-------+--------+-----+-----+--------+-----+-----+-----+-----+

1085	   Alternatively, the payload carrying also redundant data for a subset
1086	   of layers can be arranged differently, as shown in the example below.

1088	    +-------+--------+-----+-----+-----+-----+--------+-----+-----+
1089	    | RTP1  | L-ID=3 |NF=0 |F0-L1|F0-L2|F0-L3| L-ID=1 |NF=0 |F1-L1|
1090	    +-------+--------+-----+-----+-----+-----+--------+-----+-----+

1092	    +-------+--------+-----+-----+-----+-----+--------+-----+-----+
1093	    | RTP2  | L-ID=3 |NF=0 |F1-L1|F1-L2|F1-L3| L-ID=1 |NF=0 |F2-L1|
1094	    +-------+--------+-----+-----+-----+-----+--------+-----+-----+

1096	    +-------+--------+-----+-----+-----+-----+--------+-----+-----+
1097	    | RTP3  | L-ID=3 |NF=0 |F2-L1|F2-L2|F2-L3| L-ID=1 |NF=0 |F3-L1|
1098	    +-------+--------+-----+-----+-----+-----+--------+-----+-----+

1100	   Now the first transport block carries the primary data and the second
1101	   transport block carries the redundant data, which in this case covers
1102	   the frame following the primary frame. The benefit of this approach
1103	   is that the redundant data is included in the last (secondary)
1104	   transport block of the payload, which might be beneficial for
1105	   possible payload scaling operation within the network.

1107	8. References

1109	8.1. Normative References

1111	   [AMR-WB]  3GPP TS 26.171, "Adaptive Multi-Rate Wideband (AMR-WB)
1112	             speech codec; General description (Release 7)", v7.0.0,
1113	             September 2006.

1115	   [G.718]   ITU-T Recommendation G.718, "Frame Error Robust Narrowband
1116	             and Wideband Embedded Variable Bit-Rate Coding of Speech
1117	             and Audio from 8-32 Kbit/s", (consented) May 2008.

1119	   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
1120	             Requirement Levels", BCP 14, RFC 2119, March 1997.

1122	   [RFC3264] Rosenberg, J., Schulzrinne, H., "An Offer/Answer Model with
1123	             Session Description Protocol (SDP)", RFC 3264, June 2002.

1125	   [RFC3550] Schulzrinne, H., Casner, S., Frederick, R. and Jacobson,
1126	             V., "RTP: A Transport Protocol for Real-Time Applications",
1127	             STD 64, RFC 3550, July 2003.

1129	   [RFC3551] Schulzrinne, H., Casner, S., "RTP Profile for Audio and
1130	             Video Conferences with Minimal Control", STD 65, RFC 3551,
1131	             July 2003.

1133	   [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., Norrman,
1134	             K., "The Secure Real-Time Transport Protocol (SRTP)", RFC
1135	             3711, March 2004.

1137	   [RFC4288] Freed, N., Klensin, J., "Media Type Specifications and
1138	             Registration Procedures", BCP 13, RFC 4288, December 2005.

1140	   [RFC4566] Handley, M., Jacobson, V. and Perkins, C., "SDP: Session
1141	             Description Protocol", RFC 4566, July 2006.

1143	   [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., Rey, J.,
1144	             "Extended RTP Profile for Real-Time Transport Control
1145	             Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, July
1146	             2006.

1148	   [RFC4855] Casner, S., "Media Type Registration of RTP Payload
1149	             Formats", RFC 4855, February 2007.

1151	   [RFC4867] Sjoberg, J., Westerlund, M., Lakaniemi, A., Xie, Q., "RTP
1152	             Payload Format and File Storage Format fort he Adaptive
1153	             Multi-Rate (AMR) and Adaptive Multi-Rate Wideband (AMR-WB)
1154	             Audio Codecs", RFC 4867, April 2007.

1156	   [RFC5104] Wenger, S., Chandra, U., Westerlund, M., Burman, B., "Codec
1157	             Control Messages in the RTP Audio-Visual Profile with
1158	             Feedback (AVPF)", RFC 5104, Feburary 2008.

1160	   [smd-sdp] Schierl, T., Wenger, S., "Signaling media decoding
1161	             dependency in Session Description Protocol (SDP)", draft-
1162	             schierl-mmusic-layered-codec-04 (work in progress), June
1163	             2007.

1165	8.2. Informative References

1167	   [McCanne] McCanne, S., Jacobson, V., and Vetterli, M., "Receiver-
1168	             driven layered multicast", in Proc. of ACM SIGCOMM'96,
1169	             pages 117--130, Stanford, CA, August 1996.

1171	   [RFC2326] Schulzrinne, H., Rao, A., Lanphier, R., "Real Time
1172	             Streaming Protocol (RTSP)", RFC 2326, April 1998.

1174	   [RFC2974] Handley, M., Perkins, C., Whelan, E., "Session Announcement
1175	             Protocol", RFC 2974, October 2000.

1177	   [RFC3828] Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E.,
1178	             Fairhurst, G., "The Lightweight User Datagram Protocol
1179	             (UDP-Lite)", RFC 3828, July 2004.

1181	   [RFC4340] Kohler, E., Handley, M., Floyd, S., "Data Congestion
1182	             Control Protocol (DCCP)", RFC 4340, March 2006.

1184	   [RFC5117] Westerlund, M., Wenger, S., "RTP Topologies", RFC 5117,
1185	             January 2008.

1187	Author's Addresses

1189	   Ari Lakaniemi
1190	   Nokia
1191	   P.O.Box 407
1192	   FIN-00045 Nokia Group, FINLAND

1194	   Phone: +358-71-8008000
1195	   Email: ari.lakaniemi@nokia.com

1197	   Ye-Kui Wang
1198	   Nokia Research Center
1199	   P.O. Box 1000
1200	   33721 Tampere
1201	   Finland

1203	   Phone: +358-50-466-7004
1204	   EMail: ye-kui.wang@nokia.com

1206	Intellectual Property Statement

1208	   The IETF takes no position regarding the validity or scope of any
1209	   Intellectual Property Rights or other rights that might be claimed to
1210	   pertain to the implementation or use of the technology described in
1211	   this document or the extent to which any license under such rights
1212	   might or might not be available; nor does it represent that it has
1213	   made any independent effort to identify any such rights.  Information
1214	   on the procedures with respect to rights in RFC documents can be
1215	   found in BCP 78 and BCP 79.

1217	   Copies of IPR disclosures made to the IETF Secretariat and any
1218	   assurances of licenses to be made available, or the result of an
1219	   attempt made to obtain a general license or permission for the use of
1220	   such proprietary rights by implementers or users of this
1221	   specification can be obtained from the IETF on-line IPR repository at
1222	   http://www.ietf.org/ipr.

1224	   The IETF invites any interested party to bring to its attention any
1225	   copyrights, patents or patent applications, or other proprietary
1226	   rights that may cover technology that may be required to implement
1227	   this standard.  Please address the information to the IETF at
1228	   ietf-ipr@ietf.org.

1230	Disclaimer of Validity

1232	   This document and the information contained herein are provided on an
1233	   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
1234	   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
1235	   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
1236	   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
1237	   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
1238	   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

1240	Copyright Statement

1242	   Copyright (C) The IETF Trust (2008).

1244	   This document is subject to the rights, licenses and restrictions
1245	   contained in BCP 78, and except as set forth therein, the authors
1246	   retain all their rights.

1248	Acknowledgment

1250	   Funding for the RFC Editor function is currently provided by the
1251	   Internet Society.

1253	9. Open Issues

1255	   1) Support of super-wideband (SWB) audio and stereophonic encoding
1256	      extensions to ITU-T G.718 currently being worked on by ITU-T is to
1257	      be specified after ITU-T completes the work in that regards.

1259	        a. Some further study is needed to see if separate parameters
1260	          for sending and receiving capabilities/preferences are needed
1261	          -- especially for upcoming stereo and SWB options.

1263	        b. The support for upcoming SWB and stereo options needs to be
1264	          taken into account. Basically we can either 1) extend the
1265	          parameter "layers" to cover also this aspect, or 2) define
1266	          separate parameter(s) for these new options when more details
1267	          on the stereo/SWB support are available.

1269	   2) For streaming or other applications that allow for relatively long
1270	      end-to-end delay, sometimes it would be beneficial to aggregate
1271	      more than 4 frames in one Transport Block (TB). Should the length
1272	      of the NF field be larger?

1274	   3) On layer structure and configuration signalling. Currently, a
1275	      unique layer ID is assigned for any possible layer combinations.

1277	      See the editing notes below Table 3 for other possible approaches.
1278	      One of the alternative ways may be chosen in the final draft.

1280	   4) Currently, it is mandated that lower layer EDUs of later frames go
1281	      before higher layer EDUs of earlier frames in a transport block.
1282	      This way is friendlier to adaptation (dropping of higher layers).
1283	      However, if all layers are received, then the depacketizer needs
1284	      to reorder the EDUs to their decoding order before feeding them to
1285	      the decoder. Therefore, the other way around (i.e. lower layer
1286	      EDUs of later frames go after higher layer EDUs of earlier frames,
1287	      or EDUs in transport blocks are placed in decoding order) is more
1288	      friendly to the depacketizer. Another benefit of the latter is
1289	      that it does not introduce any end-to-end delay. Which way to be
1290	      specified (or both allowed if needed) is FFS.

1292	   5) MANEs dropping RTP packets are RTP translators. But are those
1293	      MANEs dropping a subset of the transport blocks in one packet also
1294	      RTP translators?

1296	   6) The RTCP based cross-session synchronization is not possible until
1297	      the first RTCP SRs are received in all sessions. This implies that
1298	      decoding only a subset of layers may be possible until RTCP SRs in
1299	      all sessions have been received. This may imposes higher end-to-
1300	      end delay or higher bandwidth for RTCP data, and the approach may
1301	      not work perfectly for some multicast topologies. There is a study
1302	      ongoing by some AVT members. Once there is an acceptable solution
1303	      fouthe draft documenting that solution may be referenced in this
1304	      draft.

1306	   7) It might be better to change the semantics of the media type
1307	      parameter 'layers' to be similar as that for L-ID.

1309	   8) Offer/answer with answer being capable of modifying the layer
1310	      configuration is FFS.

1312	   9) Some references need to be updated in the final draft.

1314	10. Changes Log

1316	   From draft-lakaniemi-avt-rtp-evbr-04 to draft-ietf-avt-rtp-g718-00

1318	   - Changed the media sub-type name "EV-VBR" to "G718", and replaced
1319	     "EV-VBR" with "G.718" in all text.