Internet Engineering Task Force                 Yoshihiro Kikuchi - Toshiba
Internet Draft                                       Toshiyuki Nomura - NEC
Document: draft-ietf-avt-rtp-mpeg4-es-01.txt draft-ietf-avt-rtp-mpeg4-es-02.txt         Shigeru Fukunaga - Oki
                                              Yoshinori Matsui - Matsushita
                                                       Hideaki Kimata - NTT
                                                               May 31,
                                                               July 6, 2000

             RTP payload format for MPEG-4 Audio/Visual streams

Status of this Memo

   This document is an Internet-Draft and is in full conformance with all
      provisions of Section 10 of RFC2026 [1].

   Internet-Drafts are working documents of the Internet Engineering Task
   Force (IETF), its areas, and its working groups. Note that other groups
   may also distribute working documents as Internet-Drafts. Internet-Drafts
   are draft documents valid for a maximum of six months and may be updated,
   replaced, or obsoleted by other documents at any time. It is
   inappropriate to use Internet- Drafts as reference material or to cite
   them other than as "work in progress."
   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt
   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

                                   Abstract

   This document describes RTP payload formats for the carriage carrying of MPEG-4 Audio
   and Visual streams[2][3], and an RTCP format for MPEG-4 upstream
   messages functionalities[4]. In this specification, bitstreams[2][3]. For the purpose of directly mapping MPEG-4
   Audio/Visual bitstreams are directly mapped into onto RTP packets. The packets, it provides specifications for
   the use of RTP header fields
   usage and the also specifies fragmentation rule for MPEG-4 Visual and Audio bitstreams
   are specified. rules. It
   also specifies an RTCP packet usage to carry the MPEG-4
   upstream messages. In addition, provides specifications for MIME type registrations and SDP usages
   for the MPEG-4 Audio and Visual streams are defined in this document. use of
   SDP.

1. Introduction

1.1 Why MPEG-4 Audio/Visual RTP format needed?

   The RTP payload formats described in this Internet-Draft specify a way of
   how MPEG-4 Audio and Visual streams are to be fragmented and mapped
   directly onto RTP packets.

   These RTP payload formats enable to carry MPEG-4 Audio/Visual streams
   without using the synchronization and stream management functionality of
   MPEG-4 Systems [6]. Such RTP payload format would be used within systems
   where their own stream management functionality is provided and thus such
   functionality in MPEG-4 Systems is not necessary. H.323 terminals could be are an
   example where of such RTP payload formats are
   used. systems. MPEG-4 Audio/Visual streams are not managed by
   MPEG-4 Systems Object Descriptors
   of MPEG-4 Systems[6]  but by H.245. The streams are directly
   mapped onto RTP packets without using the synchronization functionality
   of MPEG-4
   Systems [6]. Systems. Other examples are SIP and RTSP where attribute of the
   video stream (e.g. media type, packetization format and configuration) is
   specified in MIME and SDP parameters.

   The semantics of RTP headers in such cases need to be clearly defined,
   including the association with the MPEG-4 Audio/Visual data elements.  In
   addition, it would be beneficial to define the fragmentation rule rules of RTP
   packets for MPEG-4 Video streams so as to enhance error resiliency by
   utilizing the error resilience tools provided inside the MPEG-4 Video
   stream.  However, these items are not covered  These issues, however, have yet to be addressed by other RTP
   payload format
   proposals.

1.2 specifications.

1.1 MPEG-4 Visual RTP payload format

   MPEG-4 Visual is a visual coding standard with many new functionalities: features: high
   coding efficiency, efficiency; high error resiliency, multiple resiliency; multiple, arbitrary shaped
   object based coding, shape
   object-based coding; etc. [2]. It covers a wide range of bitrate from
   several
   scores of Kbps to many several Mbps. It also covers a wide variety of networks
   networks, ranging from guarantied those guaranteed to be almost error-free to mobile
   networks with high error rate due rates.

   With respect to its error resilience functionalities.

   A the fragmentation rule rules for an MPEG-4 visual bitstream into RTP packets is
   defined in this document. Since document, since MPEG-4 Visual is used for a wide variety
   of networks, it is desirable not to apply too much restriction to the
   fragmentation.  A on
   fragmentation, and a fragmentation rule like such as "a single video packet
   shall always be mapped on a single RTP packet" may be inappropriate. On
   the other hand, a careless careless, media unaware fragmentation may cause
   degradation
   of the in error resiliency and the bandwidth efficiency. The
   fragmentation
   rule rules described in this document is are flexible but manage to
   define the minimum rules and guidelines for preventing the meaningless fragmentation and to for
   utilizing the error resilience functionality of MPEG-4 visual.

   For video coding media such as H.261 or MPEG-1/2,

   While the additional media specific RTP header works effectively defined for recovering. e.g., of a such video
   coding tools as H.261 or MPEG-1/2 is effective in helping to recover
   picture
   header headers corrupted by packet losses. However, losses, in MPEG-4 Visual there are
   already error resilience functionalities inside MPEG-4 Visual to recover for recovering corrupt headers. These
   functionalities headers,
   and these can commonly be used on RTP/IP network networks, as well as on other networks.

   (H.223/mobile, MPEG-2/TS, etc.) Therefore, That is why no extra RTP header fields
   are defined in the MPEG-4 Visual RTP payload format.

1.3 Consideration on the format proposed here.

1.2 MPEG-4 Audio RTP payload format

   MPEG-4 Audio is a new kind of audio standard that integrates many
   different types of audio coding tools. It also supports a mechanism for
   representing synthesized sounds. Low-overhead MPEG-4 Audio Transport
   Multiplex (LATM) manages the sequence sequences of the compressed or the
   represented audio data by MPEG-4 Audio tools with relatively
   small overhead. In audio-only applications, the then, it is desirable for
   LATM-based MPEG-4 Audio
   bitstreams, therefore, are desirable bitstreams to be directly mapped into onto the RTP
   packets without using MPEG-4 Systems.

   Furthermore,

   For MPEG-4 Audio coding tools except synthesis tools, as is true for
   other audio coders, if the payload of a packet is a single audio frame, a
   packet loss does will not impair the decodability of adjacent packets. Therefore, a
   payload specific header for  On the
   other hands, MPEG-4 Audio synthesis tools may be sensitive to error. For
   example, an SA_access_unit in the payload may set a global value to a new
   value, which is not required as same as one
   for then references throughout the other audio coders.

1.4 MPEG-4 Audio/Visual upstream messaging on RTCP packets

   Some particular tools of MPEG-4 Audio/Visual support upstream messaging
   functionalities. These messages are extremely Audio/Visual specific,
   since coders directly use these messages for controlling coding
   parameters. From content to make a
   macro change in the point of view performance. In this case, an error in the payload
   influences all audio data produced after the error. In order to enhance
   error resiliency, the element of controlling parameters, these
   messages SA_access_unit that makes the above
   macro change should be transmitted without delay. Therefore, these messages
   are directly mapped onto some kind of low delay RTCP packets. across several SA_access_unit
   repeatedly. The use of
   this type number of RTCP packets is limited to repetition will be dependent on the case when network
   condition. Therefore, the additional media specific header for recovering
   errors will not be required for MPEG-4 upstream
   functionalities in some particular profiles are used (e.g. MPEG-4 Visual
   Advanced Real Time Simple Profile, NEWPRED tool). Audio.

2. Conventions used in this document

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

3. RTP Packetization of MPEG-4 Visual bitstream

   This section specifies the RTP packetization rule rules for MPEG-4 Visual content.
   An MPEG-4 Visual bitstream is mapped directly onto the RTP payload
   without any addition of extra header fields or any removal of any Visual
   syntax elements. The Combined Configuration/Elementary streams stream mode is
   used so that the configuration information is will be carried in to the same RTP
   port as the elementary stream. (see 6.2.1 "Start codes" of ISO/IEC
   14496-2 14496-
   2 [2][9][4]) The configuration information MAY additionally be specified
   by some out-of-band means; in H.323 terminals, H.245 codepoint
   "decoderConfigurationInformation" MAY be used for this purpose; in
   systems using MIME content type and SDP parameters, e.g. SIP and RTSP,
   the optional parameter "config" MAY be used to specify the configuration
   information. (see 5.1 and 5.2)

   When the short video header mode is used, the RTP payload format used MAY
   be that specified for H.263
   specified in the relevant RFCs or in other standards MAY be used. relevant
   standards.

   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |V=2|P|X|  CC   |M|     PT      |       sequence number         | RTP
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           timestamp                           | Header
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           synchronization source (SSRC) identifier            |
   +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
   |            contributing source (CSRC) identifiers             |
   |                             ....                              |
   +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
   |                                                               | RTP
   |       MPEG-4 Visual stream (byte aligned)                     | Payload
   |                                                               |
   |                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                               :...OPTIONAL RTP padding        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

        Figure 1 - An RTP packet for MPEG-4 Visual stream

3.1 Use of RTP header fields usage for MPEG-4 Visual

   Payload Type (PT): Distinct payload Payload type should is to be specifically assigned to specify as the
   MPEG-4 Visual RTP payload format. If the dynamic payload type this assignment is used, to be carried out
   dynamically, it is specified can be performed by some such out-of-band means (e.g. as H.245, SDP,
   etc.) that the MPEG-4 Visual payload format is used for the corresponding
   RTP packet.
   etc.

   Extension (X) bit: Defined by the RTP profile used.

   Sequence Number: Increment Incremented by one for each RTP data packet sent. It
   starts sent,
   starting, for security reasons, with a random initial value for security reasons. value.

   Marker (M) bit: The marker bit is set to one to indicate the last RTP
   packet (or only RTP packet) of a VOP.

   Timestamp: The timestamp indicates the composition time, or the
   presentation time in a no-compositor decoder by adding a decoder. A constant random
   offset offset, which is
   random, is added for security reasons. For a video object plane, it is
   defined by as vop_time_increment (in units of
   1/vop_time_increment_resolution seconds) plus the cumulative number of
   whole seconds specified by module_time_base
   and and, if present, time_code of
   Group_of_VideoObjectPlane() if present. fields.  In the case of interlaced video, a
   VOP consists will consist of lines from two fields fields, and the timestamp indicates will
   indicate the composition time of the first field. If the RTP packet
   contains only configuration information and/or
   Group_of_VideoObjectPlane(),
   Group_of_VideoObjectPlane() fields, the composition time of the subsequent next VOP
   in the coding order is used. If the RTP packet contains only
   visual_object_sequence_end_code,
   visual_object_sequence_end_code information, the composition time of the
   immediately preceding VOP in the coding order is used.

   Unless

   The resolution of the timestamp is set to its default value of 90KHz,
   unless specified by an out-of-band means (e.g. SDP parameter or MIME
   parameter as defined in section 6), the resolution of the timestamp is
   set to its default (90KHz). 5).

   SSRC, CC and CSRC fields are used as described in RFC 1889 [8].

3.2 Fragmentation of MPEG-4 Visual bitstream

   A fragmented MPEG-4 Visual bitstream is mapped directly onto the RTP
   payload without any addition of extra header fields or any removal of any
   Visual syntax elements. The Combined Configuration/Elementary streams
   mode is used. The following rules apply for the fragmentation.

   (1) The configuration Configuration information and Group_of_VideoObjectPlane() fields
   SHALL be placed at the beginning of the RTP payload (just after the RTP
   header) or just after the header of the syntactically upper layer
   function.

   (2) If one or more headers exist in the RTP payload, the RTP payload
   SHALL begin with the header of the syntactically highest function.
   Note: The visual_object_sequence_end_code is regarded as the lowest
   function.

   (3) A header SHALL NOT be split into a plurality of RTP packets.

   (4) Two or more VOPs SHALL be fragmented into different RTP packets so
   that one RTP packet consists of the data bytes associated with an a unique
   presentation time (that is indicated to in the timestamp field in the RTP
   packet header).

   (5) A single video packet SHOULD NOT be split into a plurality of RTP
   packets. The size of a video packet SHOULD be adjusted in such a way that
   the resulting RTP packet is not larger than the path-MTU. A video packet
   MAY be split into a plurality of RTP packets when the size of the video
   packet is large.
   (Rule (5) does not apply to the enhancement layer of the scalable streams
   where the video packet is not supported.)

   Here, header means:
   - Configuration information (Visual Object Sequence Header, Visual Object
     Header and Video Object Layer Header)
   - visual_object_sequence_end_code
   - The header of the entry point function for an elementary stream
     (Group_of_VideoObjectPlane() or the header of VideoObjectPlane(),
     video_plane_with_short_header(), MeshObject() or FaceObject())
   - The video packet header (video_packet_header() excluding
     next_resync_marker())
   - The header of gob_layer()
   See 6.2.1 "Start codes" of ISO/IEC 14496-2[2][9][4] for the definition of
   the configuration information and the entry point functions.

   The video packet starts with the VOP header or the video packet header,
   followed by motion_shape_texture(), and ends with next_resync_marker() or
   next_start_code).
   next_start_code().

3.3 Examples of packetized MPEG-4 Visual bitstream

   Considering the fact that MPEG-4 Visual is used on covers a wide variety of networks
   ranging from
   several scores of Kbps to many several Mbps, and from those guaranteed networks which are to
   be almost error-free to mobile networks with high error rate, rates, it is
   desirable not to apply too much restriction to the on fragmentation. On the
   other hand, a
   careless careless, media unaware fragmentation will cause degradation of the
   in error resiliency and the bandwidth efficiency. The fragmentation criteria
   described in 3.2 are flexible but to define the minimum rules to prevent
   meaningless fragmentation.

   For video coding media such as H.261 or MPEG-1/2, the additional media
   specific RTP header works effectively for recovering, e.g., of a picture
   header corrupted by packet losses. However, there is an error resilience
   functionality inside MPEG-4 Visual to recover corrupt headers. This
   functionality can commonly be used on RTP/IP network as well as other
   networks. (H.223/mobile, MPEG-2/TS, etc.) Therefore, there is no strong
   reason to define MPEG-4 Visual specific extra RTP header fields.

   Figure 2 shows examples of RTP packets generated based on the criteria
   described in 3.2

   (a) is an example of the first RTP packet or the random access point of
   an MPEG-4 visual bitstream. This RTP packet contains bitstream containing the configuration information.
   According to the criterion (1), the Visual Object Sequence Header(VS header)
   is placed at the beginning of the RTP payload, and preceding the Visual
   Object Header and the Video Object Layer Header(VO header, VOL
   header) follow it. header).
   Since the fragmentation rule defined in 3.2 guarantees that the
   configuration information, starting with
   visual_object_sequence_start_code, is always placed at the beginning of
   the RTP payload, RTP receivers can detect the random access point by
   checking if the first 32-bit field of the RTP payload is
   visual_object_sequence_start_code.

   (b) is another example of the RTP packet containing the configuration
   information. The difference It differs from the example (a) is in that this the RTP packet also
   contains a video packet in the VOP following the configuration
   information. Since the length of the configuration information is
   relatively short (typically several ten bytes), scores of bytes) and an RTP packet containing
   only the configuration information may thus increase the overhead. Therefore, overhead, the
   configuration information and the immediately following GOV and/or (a
   part of) VOP can be effectively packetized into a single RTP packet like as in
   this example.

   (c) is an example of the RTP packet that contains
   Group_of_VideoObjectPlane(GOV). Following the criterion (1), the GOV is
   placed at the beginning of the RTP payload. It is would be a waste of RTP/IP
   header overhead to generate a an RTP packet containing only a GOV whose
   length is 7 bytes. Therefore, (a part of) the following VOP can be placed
   in the same RTP packet as shown in (c).

   (d) is an example of the case where one video packet is packetized into
   one RTP packet. When the packet-loss rate of the underlying network is
   high, this kind of packetization is recommended. It is strongly recommended to set
   resync_marker_disable to 0 in the VOL header to enable the adjustment of
   the video packet size. Even when the RTP packet containing the VOP header
   is discarded by a packet loss, the other RTP packets can be decoded by
   using the HEC(Header Extension Code) information in the video packet
   header. No extra RTP header field is necessary.

   (e) is an example of the case where more than one video packets are
   packetized into one RTP packet. This kind of packetization is effective
   to save the overhead of RTP/IP headers if when the bit-rate of the
   underlying network is low. However, it will decrease the packet-loss
   resiliency because multiple video packets are discarded by a single RTP
   packet loss. The adequate optimal number of video packets in a an RTP packet and the
   length of the RTP packet
   length depend can be determined considering the packet-loss
   rate and the bit-rate of the underlying network.

   Figure 3 shows examples of RTP packets prohibited by the criteria of 3.2.

   Fragmentation of a header into multiple RTP packets, like as in (a), will not
   only increase the overhead of RTP/IP headers but also decrease the error
   resiliency. Therefore, it is prohibited by the criterion (3).

   When concatenating more than one video packets into an RTP packet, VOP
   header or video_packet_header() shall not be placed in the middle of the
   RTP payload. The packetization like as in (b) is not allowed by the criterion
   (2). This is because (2)
   due to the aspect of the error resiliency. Comparing this example with
   Figure 2(c), 2(d), although two video packets are mapped onto two RTP packets
   in both
   cases. However, there is a difference between cases, the packet-loss resiliency.
   When resiliency is not identical. Namely, if
   the second RTP packet is lost, both video packets 1 and 2 are lost in the
   case of Figure 3(b) whereas only video packet 2 is lost in the case of
   Figure 2(c). 2(d).

   An RTP packet containing more than one VOPs, like as in (c), is not allowed.

       +------+------+------+------+
   (a) | RTP  |  VS  |  VO  | VOL  |
       |header|header|header|header|
       +------+------+------+------+

       +------+------+------+------+------------+
   (b) | RTP  |  VS  |  VO  | VOL  |Video Packet|
       |header|header|header|header|            |
       +------+------+------+------+------------+

       +------+-----+------------------+
   (c) | RTP  | GOV |Video Object Plane|
       |header|     |                  |
       +------+-----+------------------+

       +------+------+------------+  +------+------+------------+
   (d) | RTP  | VOP  |Video Packet|  | RTP  |  VP  |Video Packet|
       |header|header|    (1)     |  |header|header|    (2)     |
       +------+------+------------+  +------+------+------------+

       +------+------+------------+------+------------+------+------------+
   (e) | RTP  |  VP  |Video Packet|  VP  |Video Packet|  VP  |Video Packet|
       |header|header|     (1)    |header|    (2)     |header|    (3)     |
       +------+------+------------+------+------------+------+------------+

        Figure 2 - Examples of RTP packetized MPEG-4 Visual bitstream

       +------+-------------+  +------+------------+------------+
   (a) | RTP  |First half of|  | RTP  |Last half of|Video Packet|
       |header|  VP header  |  |header|  VP header |            |
       +------+-------------+  +------+------------+------------+

       +------+------+----------+  +------+---------+------+------------+
   (b) | RTP  | VOP  |First half|  | RTP  |Last half|  VP  |Video Packet|
       |header|header| of VP(1) |  |header| of VP(1)|header|    (2)     |
       +------+------+----------+  +------+---------+------+------------+

       +------+------+------------------+------+------------------+
   (c) | RTP  | VOP  |Video Object Plane| VOP  |Video Object Plane|
       |header|header|        (1)       |header|       (2)        |
       +------+------+------------------+------+------------------+

   Figure 3 - Examples of prohibited RTP packetization for MPEG-4 Visual
   bitstream

4. RTP Packetization of MPEG-4 Audio bitstream

   When tools defined in

   This section specifies RTP packetization rules for MPEG-4 Systems are not used Audio
   bitstreams. MPEG-4 Audio stream is streams are formatted by LATM (Low-overhead
   MPEG-4 Audio Transport Multiplex)
   format[5], tool[5], and the LATM-based streams are
   then mapped onto RTP packets as described the subsequent
   section. three sections below.

4.1 RTP Packet Format

   The LATM consists

   LATM-based streams consist of the a sequence of audioMuxElements that include
   one or more audio frames. A complete audioMuxElement or the a part of
   audioMuxElements one
   SHALL be mapped directly onto the an RTP payload without any removal of any
   audioMuxElement syntax elements as shown in (see Figure 4. 4). The first byte of each
   audioMuxElement SHALL be located at the first payload location of in an RTP
   packet.

   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |V=2|P|X|  CC   |M|     PT      |       sequence number         |RTP
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           timestamp                           |Header
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           synchronization source (SSRC) identifier            |
   +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
   |            contributing source (CSRC) identifiers             |
   |                             ....                              |
   +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
   |                                                               |RTP
   :                 audioMuxElement (byte aligned)                :Payload
   |                                                               |
   |                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                               :...OPTIONAL RTP padding        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                Figure 4 - An RTP packet for MPEG-4 Audio

   It is required for the audioMuxElement

   In order to indicate decode the audioMuxElement, the following muxConfigPresent
   information is required to be indicated by an out-of-band means.

   muxConfigPresent: If this information value is set to 1, the audioMuxElement SHALL
   include an indication bit "useSameStreamMux" and MAY include the
   configuration information for audio compression "StreamMuxConfig". The
   useSameStreamMux bit indicates whether the StreamMuxConfig element in the
   previous frame is applied in the current frame.

4.2 Use of RTP Header Fields Usage for MPEG-4 Audio

   Payload Type (PT): Distinct payload Payload type should is to be specifically assigned to specify as the
   MPEG-4 Audio RTP payload format. If the dynamic payload type this assignment is used, to be carried out
   dynamically, it is specified can be performed by some such out-of-band means (e.g. as H.245, SDP,
   etc.) that the MPEG-4 Audio payload format is used for the corresponding
   RTP packet.
   etc.

   Marker (M) bit: The marker bit indicates audioMuxElement boundaries. This
   bit It
   is set to one to mark indicate that the RTP packet contains a complete
   audioMuxElement or the last fragment of an audioMuxElement.

   Timestamp: The timestamp indicates the composition time, or the presentation time
   in a no-compositor decoder. Timestamps are recommended to start at a
   random value for security reasons.

   Unless specified by an out-of-band means, the resolution of the timestamp
   is set to its default (90 kHz). value of 90 kHz.

   Sequence Number: Increment Incremented by one for each RTP packet sent. It starts sent, starting,
   for security reasons, with a random value for security reasons. value.

   SSRC, CC and CSRC fields are used as described in RFC 1889 [8].

4.3 Fragmentation of MPEG-4 Audio bitstream

   It is desirable to put one audioMuxElement per in each RTP packet. The If the
   size of an audioMuxElement is tried to can be adjusted such kept small enough that the resulting size of the
   RTP packet is containing it does not larger than exceed the path-MTU. If size of the path-MTU, this is not possible,
   will be no problem. If it cannot, the audioMuxElement MAY be fragmented
   and spread across several packets based on the multiple packets, following rules. the rules below:

   (1) "payloadMux" "payloadMux", which consists of payload elements elements, MAY be fragmented
   into
   across several RTP packets packets, so that one RTP packet consists each of those RTP packets will
   contain one or more payload elements. A Individual payload element elements
   themselves SHOULD NOT be fragmented.

   (2) If the audioMuxElement includes StreamMuxConfig, StreamMuxConfig
   SHALL be included into in the RTP packet containing that contains the first payload
   element.

5. RTCP Packetization of MPEG-4 upstream messages

   This section specifies the usage of particular RTCP packets to carry the
   upstream messages generated using the MPEG-4 Audio/Visual upstream
   messaging functionalities. In the current specification, NEWPRED in the
   MPEG-4 Visual Advance Real Time Simple (ARTS) Profile[4] is only the tool
   which uses this RTCP payload specification. This particular RTCP packet
   SHALL ONLY be used when it is indicated by some out of band means that
   the corresponding MPEG-4 Visual codec is compliant with the ARTS profile
   and it is indicated in the configuration information of the MPEG-4 visual
   bitstream that the NEWPRED tool is enabled (newpred_enable is set to 1).

5.1. Abstract of NEWPRED in the ARTS profile
   NEWPRED in the ARTS profile is an error resilience tool using the
   upstream messages from the decoder to the encoder.  As the inter-frame
   coding is used in the MPEG-4 Visual standard, the image degradation by
   packet loss will be propagated to the after several frames.  In order to
   prevent the temporal error propagation, the reference frames of the
   inter-frame coding are switched according to the upstream messages in the
   NEWPRED.  As the correct frames are used as the reference frame, the
   error propagation is refreshed.

   As neither the re-transmission nor the intra refresh are used, the coding
   efficiency can be kept high.  And the NEWPRED can achieve the faster
   error recovery than the intra refresh.

   There are two types of upstream messages; acknowledged message (NP_ACK)
   and non-acknowledged message (NP_NACK).  NP_ACK and/or NP_NACK messages
   are transmitted on the particular RTCP packets in the NEWPRED.  The
   selecting methods of reference frames are dependent on the kind of used
   messages.

5.2. Particular RTCP packets keep low delay

   The real-time Audio/Visual transmission is more sensitive to delay and
   does not require full reliability.  For Audio/Visual applications it is
   more effective to send the MPEG-4 upstream message packets as soon as
   possible, i.e. as soon as a loss is detected, without adding any random
   delays.

5.3.  Congestion control

   In the cases of the demand type of intra refresh or the re-transmission,
   the amount of bits during the congestion is larger than that in the error
   free terms.  Therefore they may cause some another congestion.  While in
   the NEWPRED, as the intra-frame coding is not used, the increased amount
   of bits is much lower than that of the intra refresh or the re-
   transmission even in the case of packet loss.  Therefore NEWPRED causes
   less additional burden for the congestion.

   The amount of the upstream messages is dependent on the strategy of the
   selecting methods of reference frames of the encoder and that of the
   sending upstream messages of the decoder.  In order to avoid congestion,
   the amount of upstream message packets should be small. In the NEWPRED,
   the decoder can control the amount of them by not sending some upstream
   messages; For example, in the case that the NP_NACK messages are mainly
   used to select the reference frames in the encoder, the decoder may not
   send the NP_ACK messages even if it receives downstream data.  On the
   other hand, in the case that the NP_ACK messages are mainly used in the
   encoder, the decoder may not send the NP_NACK messages. The amount of the
   upstream messages is at most 5% (normally about 1%) of the visual
   downstream data.

   Especially the amount of NP_ACK messages is decreased in the case of
   packet loss.  Therefore the NP_ACK message has no additional burden for
   the congestion.  On the other hand, NP_NACK messages corresponding to the
   lost packets are usually sent after the congestion, because the decoder
   detects the packet loss after the next downstream packet reaches.
   Therefore the NP_NACK message has less additional burden for the
   congestion, too.

   And to reduce the number of particular RTCP packets, multiple upstream
   messages can be concatenated in the payload of one particular RTCP
   packet.  In this case, it is desirable to send these concatenated
   messages as soon as possible.

   The particular RTCP transmission interval is according to the interval of
   the decoding the visual downstream data.  Both the receiving interval of
   the visual RTP packet and the decoding time for each packet data have
   some jitter for themselves.  Therefore the particular RTCP transmission
   interval has some jitter for itself.  It is effective for the congestion
   control, and there is no need to add any random delays.  This means that
   the size of sending jitter is enough to avoid another congestion only in
   case of the unicast.

5.4. Limiting to Unicast

   The NEWPRED can work in multicast only in the case that the number of
   decoders is small.  However in order to avoid the additional congestion,
   the NEWPRED over RTP/RTCP SHALL NOT be used in multicast.

5.5. Relations with SR and RR
   The particular low delay RTCP packets for the MPEG-4 upstream messages
   SHALL be treated as the completely different kind of packets from the
   normal RTCP packets; such as SR, RR and so on.

   For example, if the particular RTCP packets would be included in the
   calculation of RTCP sending interval, the RR packets should be generated
   in the timing of the particular low delay RTCP packets.  In this case,
   the interval of the RR packets would be smaller than 5 seconds, and the
   number of the normal RTCP packets is much increased. It is bad for the
   congestion.

   Therefore all particular RTCP packets SHALL be ignored to analyze the
   information in the sender and receiver reports (SR and RR), and only
   normal RTCP packets are used.

   Multiple particular RTCP packets can be concatenated without any
   intervening separators to form a compound RTCP packet.  The normal
   compound RTCP packet SHOULD start with SR or RR packets. However in the
   case of compound particular RTCP packet, other normal RTCP packets SHALL
   NOT be included, and only particular RTCP packets SHALL be included in
   one compound particular RTCP packet.

5.6.  MPEG-4 Visual upstream message packets definition
        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |V=2|P|   UMT   | PT=RTCP_MP4U  |           length              |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                              SSRC                             |
       +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
       |       MPEG-4 Upstream Messages Payload (byte aligned)         |
       |                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                               :             padding           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   version (V): 2 bits
        Identifies the version of RTP, which is the same in RTCP packets as
       in RTP data packets.

   padding (P): 1 bit
        If the padding bit is set, this RTCP packet contains some additional
        padding octets at the end which are not part of the control
        information. The last octet of the padding is a count of how many
        padding octets should be ignored. In the case several upstream
        messages are mapped onto one RTCP packet, padding should only be
        required on the last individual message.

   upstream message type (UMT): 5 bits
       Identifies the type of the MPEG-4 upstream messages.
       0:       forbidden
       1:       MPEG-4 Visual NEWPRED in the ARTS Profile
       2-63:    reserved
       In this internet-draft, only the NEWPRED in the ARTS profile is
       assigned as the candidate of the UMT for the moment.  Some other
       MPEG-4 Audio/Visual applications using the upstream messages may be
       assigned in the future.

   packet type (PT): 8 bits
       The value of the packet type (PT) identifier is the constant
       RTCP_MP4U (TBD).

   SSRC: 32 bits
       SSRC is the synchronization source identifier for the sender of this
       packet.

   MPEG-4 Upstream Message Payload: variable
        The syntax and semantics of the MPEG-4 upstream messages are defined
        in the ISO/IEC 14496-2/3[4][5]. All messages are byte aligned.
        Normally one message is mapped onto one RTCP packet, and several
        messages with same UMT could be continuously mapped onto one RTCP
        packet.  One message SHALL NOT be fragmented into different RTCP
        packets.

6. MIME type registration for MIME type registration for MPEG-4 Audio/Visual streams

   The following sections describe the MIME type registrations for the MPEG-
   4 MPEG-4
   Audio/Visual streams. MIME type registration and SDP usage for the MPEG-4
   Visual stream are described in sections 6.1 Sections 5.1 and 6.2, respectively. 5.2, respectively, while
   MIME type registration and SDP usage for the MPEG-4 Audio stream are
   described in sections 6.3 Sections 5.3 and 6.4, 5.4, respectively.

   (In the following sections, the RFC number "XXXX" represents the RFC
   number, which should be assigned for this Internet Draft.)

6.1

5.1 MIME type registration for MPEG-4 Visual

   MIME media type name: video
   MIME subtype name: MP4V

   Required parameters: none

   Optional parameters:
     rate: This parameter is used only for RTP transport. It indicates the
     resolution of
     resolution of the timestamp field in the RTP header. If this parameter
     is not specified, its default value of 90000 (90KHz) is used.

     profile-level-id: A decimal representation of MPEG-4 Visual Profile
     Level indication value (profile_and_level_indication) defined in Table
     G-1 of ISO/IEC 14496-2 [2][4].

     config: A hexadecimal representation of an octet string that expresses
     the MPEG-4 Visual configuration information, as defined in subclause
     6.2.1 Start codes of ISO/IEC14496-2[2][4][9]. The configuration
     information is mapped onto the octet string in an MSB-first basis. The
     first bit of the configuration information SHALL be located at the MSB
     of the first octet. The configuration information indicated by this
     parameter SHALL be the same as the configuration information in the timestamp field
     corresponding MPEG-4 Visual stream, except for
     first_half_vbv_occupancy and latter_half_vbv_occupancy, if exist,
     which may vary in the RTP header. If this repeated configuration information inside an
     MPEG-4 Visual stream (See 6.2.1 Start codes of ISO/IEC14496-2).

     The parameter
     is not specified, "profile-level-id" MAY be used in the default value of 90000 (90KHz) is used.

     profile-level-id: A decimal representation of capability
     exchange procedure to indicate MPEG-4 Visual Profile and Level indication value (profile_and_level_indication) defined in Table
     G-1
     combination of ISO/IEC 14496-2 [2][4].

     mpeg4-newpred-upstream-message: A boolean number which the MPEG-4 Visual codec is capable. The parameter
     "config" MAY be used to indicate the
     receiver capability configuration of sending the upstream message of NEWPRED in
     corresponding MPEG-4 video. The upstream messages are delivered on visual bitstream, but SHALL NOT be used to
     indicate the particular
     RTCP packets which are described codec capability in section 5. This optional exist
     when and only when the "profile-level-id" is 145, 146, 147 or 148
     (Advance Real Time Simple Profile/Level 1, 2, 3 or 4). capability exchange procedure.

     Example usages for these parameters are show bellow: are:
       - MPEG-4 Visual Simple Profile/Level 1:
          Content-type: video/mp4v; profile-level-id=1

       - MPEG-4 Visual Core Profile/Level 2:
          Content-type: video/mp4v; profile-level-id=34

       - MPEG-4 Visual Advanced Real Time Simple Profile/Level 1, upstream
       message is used: 1:
          Content-type: video/mp4v; profile-level-id=145; mpeg4-newpred-
          upstream-message=1 profile-level-id=145

   Published specification:
     The specification of specifications for MPEG-4 Visual stream is streams are presented in ISO/IEC
     14469-2[2][4][9]. The RTP payload format is described in RFCXXXX.

   Encoding considerations:
     A video bitstream
     Video bitstreams must be generated according to the MPEG-4 Visual
     specification
     specifications (ISO/IEC 14496-2). The A video bitstream is binary data, data and
     must be encoded for non-binary transport; transport (for Email, the Base64
     encoding is
     suitable for Email. sufficient).  This type is also defined for transfer via
     RTP. The RTP packets must MUST be packetized according to the MPEG-4 Visual
     RTP payload format defined in RFCXXXX.

   Security considerations:
     See section 9 6 of RFCXXXX.

   Interoperability considerations:
     MPEG-4 Visual provides a large and rich set of tools for the coding of
     visual objects. In order to allow For effective implementations implementation of the standard, subsets
     of the MPEG-4 Visual tool sets have been identified,
     that can be used provided for use in specific
     applications. These subsets, called 'Profiles', limit the size of the
     tool set a decoder has is required to implement. For each of
     these Profiles, In order to restrict
     computational complexity, one or more Levels have been set, restricting the
     computational complexity. are set for each Profiles.
     A Profile@Level combination allows:

     o a codec builder to implement only the subset of the standard he
     needs, while maintaining interworking with other MPEG-4 devices built
     to
     included in the same combination, and

     o checking whether MPEG-4 devices comply with the standard
     ('conformance testing').

     The visual stream SHALL be compliant with the MPEG-4 Visual
     Profile@Level specified by the parameter "profile-level-id". The
     interoperability
     Interoperability between a sender and a receiver may be achieved by
     specifying the parameter "profile-level-id" in MIME content, or by
     exchanging this parameter
     arranging in the capability exchange procedure. procedure to set this parameter
     mutually to the same value.

   Applications which use this media type:
     Audio and visual streaming and conferencing tools, Internet messaging
     and e-mail Email applications.

   Additional information: none

   Person & email address to contact for further information:
     The authors of RFCXXXX. (See section 9) 8)

   Intended usage: COMMON

   Author/Change controller:
     The authors of RFCXXXX. (See section 9)

6.2 8)

5.2 SDP usage of MPEG-4 Visual

   The MIME media type video/MP4V string is mapped to fields in the Session
   Description Protocol (SDP), RFC 2327, as follows:

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

   o The MIME subtype (MP4V) goes in SDP "a=rtpmap" as the encoding name.

   o The optional parameter "rate" goes in "a=rtpmap" as the clock rate.

   o The optional parameter "profile-level-id" and "config" MAY go in the
   "a=fmtp" line. The
   optional parameter "mpeg4-newpred-upstream-message" MAY go in "a=fmtp"
   line, when and only when line to indicate the "profile-level-id" is 145, 146, 147 or
   148(Advance Real Time Simple Profile/Level 1, 2, 3 or 4). The format coder capability and
   syntax of these parameters is the configuration,
   respectively. These parameters are expressed as a MIME media type string string,
   in the form of as a semicolon separated list of parameter=value pairs.

   The followings following are some examples of the media representation in SDP:

   Simple Profile/Level 1, rate=90000(90KHz), "profile-level-id" and
   "config" are present in "a=fmtp" line:
     m=video 49170/2 RTP/AVP 98
     a=rtpmap:98 MP4V/90000
     a=fmtp:98 profile-level-id=1;
     config=000001B001000001B5090000010000000120008440FA282C2090A21F

   Core Profile/Level 2, rate=90000(90KHz), "profile-level-id" is present in
   "a=fmtp" line:
     m=video 49170/2 RTP/AVP 98
     a=rtpmap:98 MP4V/90000
     a=fmtp:98 profile-level-id=1 profile-level-id=34

   Advance Real Time Simple Profile/Level 1, rate=25(25Hz), "profile-level-
   id" and "      newpred-            mpeg4-        upstream-message" are is present in "a=fmtp" line:
     m=video 49170/2 RTP/AVP 98
     a=rtpmap:98 MP4V/25
     a=fmtp:98 profile-level-id=145; mpeg4-newpred-upstream-message=1

6.3 profile-level-id=145

5.3 MIME type registration of MPEG-4 Audio

   MIME media type name: audio

   MIME subtype name: MP4A

   Required parameters:
     rate: the rate parameter indicates the RTP time stamp clock rate. The
     default value is 90000. Other rates CAN be specified only if it would
     be they are
     set to the same value with as the audio sampling rate (number of samples
     per second).

   Optional parameters:
     profile-level-id: a decimal representation of MPEG-4 Audio Profile
     Level indication value defined in ISO/IEC 14496-1 [11]. This parameter
     indicates the capability of subsets in which MPEG-4 Audio tools. tool subsets the decoder is capable of
     using.

     object: a decimal representation of the MPEG-4 Audio Object Type value
     defined in ISO/IEC 14496-3 [5]. This parameter specifies the tool to
     be used by the coder. It CAN be used to limit the capability within
     the specified "profile-level-id".

     bitrate: the data rate for the audio bit stream.

     cpresent: this parameter indicates whether audio payload configuration
     data is has been multiplexed into the an RTP payload (See section 4.1 in this
     document).

     config: a hexadecimal representation of an octet string indicating that expresses
     the audio payload configuration data "StreamMuxConfig" "StreamMuxConfig", as defined in
     ISO/IEC 14496-3 [5]. The configuration Configuration data is mapped into onto the octet
     string in an MSB-first basis. The first bit of the configuration data shall
     SHALL be located at the MSB of the first octet. In the last octet,
     zero-padding
     bits bits, if necessary, shall follow the configuration data, if necessary. data.
     If the size of the configuration data is quite large, such large
     config data is RECOMMENDED to be indicated by in-band mode (cpresent
     is set to 1).

     ptime: RECOMMENDED duration of each packet in milliseconds.

   Published specification:
     The payload
     Payload format specification is specifications are described in this document. The
     specification of encoding is Encoding
     specifications are provided in ISO/IEC 14496-3 [3][5].

   Encoding considerations:
     This type is only defined for transfer via RTP [RFC YYYY, draft-ietf-
     avt-rtp-new]. RTP.

   Security considerations:
     See section 9 Section 6 of RFCXXXX.

   Interoperability considerations:
     MPEG-4 Audio provides a large and rich set of tools for the coding of
     visual
     audio objects. In order to allow For effective implementations implementation of the standard, subsets of
     the MPEG-4 Audio tool sets have been identified similar to those used in MPEG-4 Audio (See Visual have
     been provided (see section 6.1). 5.1).

     The audio stream SHALL be compliant with the MPEG-4 Audio
     Profile@Level specified by the parameter "profile-level-id". The
     interoperability
     Interoperability between a sender and a receiver may be achieved by
     specifying the parameter "profile-level-id" in MIME content, or by
     exchanging this parameter
     arranging in the capability exchange procedure. procedure to set this parameter
     mutually to the same value. Furthermore, the "object" parameter can be
     used to limit the capability within the specified Profile@Level in
     capability exchange.

   Applications which use this media type:
     Audio and video streaming and conferencing tools.

   Additional information: none

   Personal & email address to contact for further information:
     See section 9 Section 8 of RFCXXXX.

   Intended usage: COMMON

   Author/Change controller:
     See section 9 Section 8 of RFCXXXX.

6.4

5.4 SDP usage of MPEG-4 Audio

   The MIME media type audio/MP4A string is mapped to fields in the Session
   Description Protocol (SDP), RFC 2327, as follows:

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

   o The MIME subtype (MP4A) goes in SDP "a=rtpmap" as the encoding name.

   o The required parameter "rate" goes in "a=rtpmap" as the clock rate.

   o The optional parameter "ptime" goes in SDP "a=ptime" attribute.

   o The optional parameter "profile-level-id" goes in the "a=fmtp" line to
   indicate the coder capability. The "object" parameter goes in the
   "a=fmtp" attribute. Any The payload-format-specific parameters "bitrate",
   "cpresent" and "config" go in the "a=fmtp" line. The format and syntax of these
   parameters is If the string after
   "config=" is quite large, such large config data should not be
   transmitted by SDP but should be transmitted by in-band mode. These
   parameters are expressed as a MIME media type string string, in the form of as a
   semicolon separated list of parameter=value pairs.

   The followings following are some examples of the media representation in SDP:

   For 6 kb/s CELP bitstream (the bitstreams (with an audio sampling rate of 8 kHz),
     m=audio 49230 RTP/AVP 96
     a=rtpmap:96 MP4A/8000
     a=fmtp:96 profile-level-id=9;object=8;cpresent=0;config=9128B1071070
     a=ptime:20

   For 64 kb/s AAC LC stereo bitstream (the bitstreams (with an audio sampling rate is of 24
   kHz),
     m=audio 49230 RTP/AVP 96
     a=rtpmap:96 MP4A/24000
     a=fmtp:96 profile-level-id=1; bitrate=64000; cpresent=0;
     config=9122620000

   In the above two examples, the audio configuration data is not multiplexed
   into the RTP payload and is described only in SDP. Furthermore, the
   "clock rate" is set to the audio sampling rate.

   If it is the clock rate has been set to its default, default value and it is necessary
   to obtain the audio sampling rate rate, this can be obtained done by parsing the
   "config" parameter. parameter (see the following example).

     m=audio 49230 RTP/AVP 96
     a=rtpmap:96 MP4A/90000
     a=fmtp:96 object=8; cpresent=0; config=9128B1071070

   The following example shows that the audio configuration data appears in
   the RTP payload. The value specified in "config" parameter is used as an
   initial value to setup coding parameters.

   m=audio 49230 RTP/AVP 96
   a=rtpmap:96 MP4A/90000
   a=fmtp:96 cpresent=1; config=9128B1071070

7. object=13; cpresent=1

6. Security Considerations

   RTP packets using the payload format defined in this specification are
   subject to the security considerations discussed in the RTP specification
   [8]. This implies that confidentiality of the media streams is achieved
   by encryption. Because the data compression used with this payload format
   is applied end-to-end, encryption may be performed on the compressed data
   so there is no conflict between the two operations.

   This payload type does not exhibit any significant non-uniformity in the
   receiver side computational complexity for packet processing  to cause a
   potential denial-of-service threat.

8.

7. References

   1  Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9,
      RFC 2026, October 1996.

   2 ISO/IEC 14496-2:1999, "Information technology - Coding of audio-visual
      objects - Part2: Visual", December 1999.

   3 ISO/IEC 14496-3:1999, "Information technology - Coding of audio-visual
      objects - Part3: Audio", December 1999.

   4 ISO/IEC 14496-2:1999/FDAM1:2000, December 1999.

   5 ISO/IEC 14496-3:1999/FDAM1:2000, December 1999.

   6 ISO/IEC 14496-1:1999, "Information technology - Coding of audio-visual
      objects - Part1: Systems", December 1999.

   7  Bradner, S., "Key words for use in RFCs to Indicate Requirement
      Levels", BCP 14, RFC 2119, March 1997

   8 H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson "RTP: A Transport
      Protocol for Real Time Applications",  RFC 1889, Internet Engineering
      Task Force, January 1996.

   9  ISO/IEC 14496-2/COR1, "Information technology - Coding of audio-visual
      objects - Part2: Visual, Technical corrigendum 1", March 2000.

9.

8. Author's Addresses

   Yoshihiro Kikuchi
   Toshiba corporation
   1, Komukai Toshiba-cho, Saiwai-ku, Kawasaki, 212-8582, Japan
   Email: yoshihiro.kikuchi@toshiba.co.jp

   Yoshinori Matsui
   Matsushita Electric Industrial Co., LTD.
   1006, Kadoma, Kadoma-shi, Osaka, Japan
   Email: matsui@drl.mei.co.jp

   Toshiyuki Nomura
   NEC Corporation
   4-1-1,Miyazaki,Miyamae-ku,Kawasaki,JAPAN
   Email: t-nomura@ccm.cl.nec.co.jp

   Shigeru Fukunaga
   Oki Electric Industry Co., Ltd.
   1-2-27 Shiromi, Chuo-ku, Osaka 540-6025 Japan.
   Email: fukunaga444@oki.co.jp

   Hideaki Kimata
   Nippon Telegraph and Telephone Corporation
   1-1, Hikari-no-oka, Yokosuka-shi, Kanagawa, Japan
   Email: kimata@nttvdt.hil.ntt.co.jp

Full Copyright Statement

   "Copyright (C) The Internet Society (date). All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph
   are included on all such copies and derivative works. However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.