[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-hiwasaki-avt-rtp-uemclip) 00 01 02 03 04 05 06 RFC 5686

Audio/Video Transport                                        Y. Hiwasaki
Internet-Draft                                                 H. Ohmuro
Intended status: Standards Track                         NTT Corporation
Expires: November 15, 2007                                  May 14, 2007


              RTP payload format for UEMCLIP speech codec
                     draft-ietf-avt-rtp-uemclip-00

Status of this Memo

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

   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.

   This Internet-Draft will expire on November 15, 2007.

Copyright Notice

   Copyright (C) The IETF Trust (2007).














Hiwasaki & Ohmuro       Expires November 15, 2007               [Page 1]

Internet-Draft       RTP Payload Format for UEMCLIP             May 2007


Abstract

   This document describes the RTP payload format of an ITU-T G.711
   enhanced speech codec, UEMCLIP.  The bitstream has a scalable
   structure with an embedded u-law bitstream, also known as PCMU, thus
   providing a handy transcoding operation between narrowband and
   wideband speech.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Media Format Background  . . . . . . . . . . . . . . . . . . .  4
   3.  Payload Format . . . . . . . . . . . . . . . . . . . . . . . .  6
     3.1.  RTP Header Usage . . . . . . . . . . . . . . . . . . . . .  6
     3.2.  Multiple frames in an RTP packet . . . . . . . . . . . . .  7
     3.3.  Payload Data . . . . . . . . . . . . . . . . . . . . . . .  7
       3.3.1.  Main Header  . . . . . . . . . . . . . . . . . . . . .  7
       3.3.2.  Sub-layer data . . . . . . . . . . . . . . . . . . . . 11
   4.  G.711 interoperability . . . . . . . . . . . . . . . . . . . . 13
   5.  Congestion Control Considerations  . . . . . . . . . . . . . . 14
   6.  Payload Format Parameters  . . . . . . . . . . . . . . . . . . 15
     6.1.  Media type registration  . . . . . . . . . . . . . . . . . 15
     6.2.  Mapping to SDP Parameters  . . . . . . . . . . . . . . . . 16
       6.2.1.  Dynamic transmission definition  . . . . . . . . . . . 16
     6.3.  Offer-answer Model Considerations  . . . . . . . . . . . . 17
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 19
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 20
   9.  Normative References . . . . . . . . . . . . . . . . . . . . . 21
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22
   Intellectual Property and Copyright Statements . . . . . . . . . . 23



















Hiwasaki & Ohmuro       Expires November 15, 2007               [Page 2]

Internet-Draft       RTP Payload Format for UEMCLIP             May 2007


1.  Introduction

   This document specifies the payload format for sending UEMCLIP
   encoded speech using the Real-time Transport Protocol (RTP) [3].
   UEMCLIP is an enhanced version of u-law ITU-T G.711, and designed to
   help the market for smooth transition towards the forthcoming
   wideband communication environment and while maintaining the
   interoperability and less transcoding load with the existing
   terminals, in which the implementation of G.711 is mandatory.

   The payload format is described in Section 3.  The interoperability
   with G.711 issues are discussed in Section 4.  In Section 6.1, a
   media type registration for UEMCLIP RTP payload format is provided.

1.1.  Terminology

   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 [1].
































Hiwasaki & Ohmuro       Expires November 15, 2007               [Page 3]

Internet-Draft       RTP Payload Format for UEMCLIP             May 2007


2.  Media Format Background

   UEMCLIP stands for "U-law EMbedded Coder for Low-delay IP
   communication", and is basically an enhanced version of u-law ITU-T
   G.711, otherwise known as PCMU [8].  It is developed for VoIP (Voice
   over Internet Protocol) applications, and is especially suitable for
   wideband multi-point conferencing.  The main goal of this codec is to
   provide a wideband communication platform that is highly
   interoperable with existing terminals equipped with G.711, and to
   stimulate the market to gradually shift to the wideband
   communication.  Because the G.711 bitstream is embedded in the
   bitstream, costly transcoding would be avoided especially when
   interoperating with narrowband terminals.

   This document does not discuss the implementation detail of the
   encoder and decoder, but only describes the bitstream format.  The
   implementation detail will be available by other means.

   Because of its scalable nature, there are a number of sub-bitstreams
   (layer data) with in a UEMCLIP bitstream.  By choosing appropriate
   sub-layers, the codec can adapt to the following requirements:

   o  Sampling frequency,

   o  Number of channels,

   o  Speech quality, and

   o  Bit-rate.

   The current implementation of UEMCLIP codec includes three sub-
   coders, as shown in Table 1.  The core layer is G.711 core, and other
   two are quality and bandwidth enhancement layers with bit-rate of 16
   kbit/s each.

   +-------+---------------------+----------+--------------------------+
   | Layer | Description         | Bit-rate | Coding algorithm         |
   +-------+---------------------+----------+--------------------------+
   |   a   | G.711 core          |       64 | u-law PCM                |
   |       |                     |          |                          |
   |   b   | Lower-band          |       16 | Time domain block        |
   |       | enhancement         |          | quantization             |
   |       |                     |          |                          |
   |   c   | Higher-band         |       16 | MDCT block quantization  |
   +-------+---------------------+----------+--------------------------+

                      Table 1: Sub-layer description




Hiwasaki & Ohmuro       Expires November 15, 2007               [Page 4]

Internet-Draft       RTP Payload Format for UEMCLIP             May 2007


   Based on these sub-layers, UEMCLIP codec operates in four modes as
   shown in Table 2.  Here, "Fs" is the sampling frequency in kHz.  The
   absent Modes 2 and 5 are reserved for future extension to 32 kHz
   sampling modes.  As the mode definition is expected to grow, any
   other modes not defined in this table MUST NOT be used for
   compatibility and interoperability reasons.

   +------+----+----+-------+-------+-------+-------------+------------+
   | Mode | Ch | Fs | Layer | Layer | Layer |    Bit-rate |      Total |
   |      |    |    |   a   |   b   |   c   | w/o headers |   bit-rate |
   |      |    |    |       |       |       |      [kbps] |     [kbps] |
   +------+----+----+-------+-------+-------+-------------+------------+
   |   0  |  1 |  8 |   x   |   -   |   -   |          64 |       68.8 |
   |      |    |    |       |       |       |             |            |
   |   1  |  1 | 16 |   x   |   -   |   x   |          80 |       85.6 |
   |      |    |    |       |       |       |             |            |
   |   2  |  - |  - |   -   |   -   |   -   |           - |          - |
   |      |    |    |       |       |       |             |            |
   |   3  |  1 |  8 |   x   |   x   |   -   |          80 |       85.6 |
   |      |    |    |       |       |       |             |            |
   |   4  |  1 | 16 |   x   |   x   |   x   |          96 |      102.4 |
   |      |    |    |       |       |       |             |            |
   |   5  |  - |  - |   -   |   -   |   -   |           - |          - |
   +------+----+----+-------+-------+-------+-------------+------------+

                         Table 2: Mode description

   UEMCLIP bitstream contains internal headers and other side-
   information apart from the layer data.  This results in total bit-
   rate larger than the sum of the layers shown in the above table.  The
   detail of the internal headers and auxiliary information are
   described in Section 3.3.1.

   Defining the sampling frequency and the number of channels does not
   result in a singular mode, i.e., there can be multiple modes for the
   same sampling frequency or number of channels.  The supported modes
   would differ from the implementations, thus the sender and the
   receiver must exchange what mode to use for transmission.













Hiwasaki & Ohmuro       Expires November 15, 2007               [Page 5]

Internet-Draft       RTP Payload Format for UEMCLIP             May 2007


3.  Payload Format

   As an RTP payload, UEMCLIP bitstream can contain one or more frames
   as shown in Figure 1.

     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                      RTP Header                               |
    +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
    |                                                               |
    |                 one or more frames of UEMCLIP                 |
    |                                                               |
    +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

                       Figure 1: RTP payload format

   UEMCLIP bitstream has a scalable structure, thus it is possible to
   reconstruct the signal by decoding a part of it.  A UEMCLIP frame is
   composed of a main header followed by one or more sub-layers.  As a
   sub-layer, the core layer, i.e., "Layer a", MUST always be included.
   It should be noted that the location of the base layer may not be
   located at the top.  The decoder MUST always refer to the layer ID
   for proper decoding.  The bitstream, for the case of enhancement
   header with length 0, is shown in Figure 2, where sub-layer #1 can be
   any arbitrary sub-layer data.

                 +--+-------+-------+-------+-------+//-+
                 |MH| SD #1 | SD #2 | SD #3 | SD #4 |...|
                 |  |       |       |       |       |   |
                 +--+-------+-------+-------+-------+//-+

               Figure 2: A UEMCLIP frame (bitstream format)

   The UEMCLIP bitstream does not include the following information: a)
   the codec type, b) Mode, c) I/O sampling frequency, and d) encoder
   version.  As described before, these information SHOULD be exchanged
   while establishing a connection, for example, by means of SDP.

3.1.  RTP Header Usage

   Each RTP packet starts with a fixed RTP header, as explained in [3].
   The following fields of the RTP fixed header used specifically for
   UEMCLIP streams are emphasized:







Hiwasaki & Ohmuro       Expires November 15, 2007               [Page 6]

Internet-Draft       RTP Payload Format for UEMCLIP             May 2007


   Payload type:  The assignment of an RTP payload type for this packet
      format is outside the scope of this document, however, it is
      expected that a payload type in the dynamic range shall be
      assigned.

   Timestamp:  This encodes the sampling instant of the first speech
      signal sample in the RTP data packet.  For UEMCLIP streams, the
      RTP timestamp MUST be a multiple of 8 kHz, and in case the
      sampling rate can change during a session, this figure should
      equal to the maximum rate (in Hz) given in Table 2 .

   Marker bit:  If the codec is used for applications with discontinuous
      transmission (DTX, or silence compression), the first packet after
      a silence period during which packets have not been transmitted
      contiguously SHOULD have the marker bit in the RTP data header set
      to one.  The marker bit in all other packets MUST be zero.
      Applications without DTX MUST set the marker bit to zero.

3.2.  Multiple frames in an RTP packet

   More than one UEMCLIP frame may be included in a single RTP packet by
   a sender.  However, senders have the following additional
   restrictions:

   o  SHOULD NOT include more UEMCLIP frames in a single RTP packet than
      will fit in the MTU of the RTP transport protocol.

   o  All frames contained in a single RTP packet MUST be of the same
      length, i.e., they MUST have the same bit rate (octets per frame).

   o  Frames MUST NOT be split between RTP packets.

   It is RECOMMENDED that the number of frames contained within an RTP
   packet be consistent with the application.  Since UEMCLIP is designed
   form a telephony application where delay is important, then the fewer
   frames per packet the lower the delay, is preferable.

3.3.  Payload Data

3.3.1.  Main Header

   The main header (MH) is placed at the top of a payload and has size
   of 10 bytes with additional optional enhanced header size.  The
   content of the main header is defined in Figure 3.







Hiwasaki & Ohmuro       Expires November 15, 2007               [Page 7]

Internet-Draft       RTP Payload Format for UEMCLIP             May 2007


    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     ID        |             BS                |      MX       |
   |               |                               |               |
   |0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5|0 1 2 3 4 5 6 7|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                              PC                               |
   |                                                               |
   |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|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   PC(cont'd)  |      ES       |             EH                |
   |               |               |         (if exists)           |
   |2 3 4 5 6 7 8 9|0 1 2 3 4 5 6 7|                             ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-//+-+-+-+

                 Figure 3: UEMCLIP main header format (MH)

   Identification (ID):  8 bits

      The value should be "0x95".

   Byte size (BS):  16 bits

      Indicates the byte size of the following UEMCLIP payload.  This
      means that the RTP header size, ID and BS are not included.  It is
      encoded in network byte-order.

   Mixing information (MX):  8 bits

      Mixing information field.

   Packet-loss Concealment information (PC):  40 bits

      Packet-loss concealment (PLC) information field.

   Enhanced-header Size (ES):  8 bits

      Size of EH (enhanced header) in bytes.

   Enhanced header (EH):  8*ES bits

      Content of the enhanced header.  When ES is 0, the enhanced header
      is non-existent.








Hiwasaki & Ohmuro       Expires November 15, 2007               [Page 8]

Internet-Draft       RTP Payload Format for UEMCLIP             May 2007


3.3.1.1.  Mixing information field

                            0 1 2 3 4 5 6 7
                           +-+-+-+-+-+-+-+-+
                           |C|R|V|   PW1   |
                           |1|1|1|         |
                           | | | |0 1 2 3 4|
                           +-+-+-+-+-+-+-+-+

                  Figure 4: Mixing information field (MX)

   Check bit #1 (C1):  1 bit

      Validity flag of V1 and PW1.  This bit being "1" indicates that
      both parameters are valid, and "0" indicates that the parameters
      should be ignored.

   Reserved bit #1 (R1):  1 bit

      This bit should be ignored.

   VAD flag #1 (V1):  1 bit

      Voice activity detection flag of the current frame.  This flag
      being "1" indicates that the frame is an active (voice) segment,
      and "0" indicates that it is an inactive (non-voice) or a silent
      segment.

   Power #1 (PW1):  5 bits

      Signal power code of the current frame.

3.3.1.2.  PLC information field

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |C|C|R|V|   K   |R|     P1      |R|     P2      |      PW2      |
   |2|3|2|2|       |3|             |4|             |               |
   | | | | |0 1 2 3| |0 1 2 3 4 5 6| |0 1 2 3 4 5 6|0 1 2 3 4 5 6 7|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      R5       |
   |               |
   |0 1 2 3 4 5 6 7|
   +-+-+-+-+-+-+-+-+

                   Figure 5: PLC information field (PC)





Hiwasaki & Ohmuro       Expires November 15, 2007               [Page 9]

Internet-Draft       RTP Payload Format for UEMCLIP             May 2007


   Check bit #2 (C2):  1 bit

      Validity flag of V2, K, P1, P2, and PW2.  If the flag is "1", it
      means that all these parameters are valid, and "0" means that the
      parameters should be ignored.  If any of these parameters is
      invalid, C1 should be set to "0".

   Check bit #3 (C3):  1 bit

      Payload validity indicator.  This flag is normally set to "0".  If
      a received packet has this flag set to "1", the payload data
      should be ignored and packet-loss concealment should be performed
      by the receiver.  This flag is used in case of a multi-point
      conferencing, where the upstream packet was lost and the mixing
      server did not execute packet-loss concealment.

   Reserved bit #2 (R2):  1 bit

      This bit should be ignored.

   VAD flag #2 (V2):  1 bit

      Voice activity detection flag of the current frame.  This may be
      as same as V1 in the mixing information.

   Frame indicator (K):  4 bits

      This value indicates the frame offset of P2 and PW2.  Since it is
      a better idea to carry the pitch and power parameters as PLC
      information in a different frame, this frame offset value gives
      which frame the parameters are to be associated with.  Since there
      are 4 bits allocated, it ranges between "0" and "15".

   Reserved bit #3 (R3):  1 bit

      This bit should be ignored.

   Pitch lag #1 (P1):  7 bits

      Pitch code of the current frame.  The actual pitch lag is
      calculated as P1+20 samples in 8-kHz sampling rate.  Pitch lag
      must be 20 <= pitch length <= 120.  Codes ranging between "0x65"
      and "0x7F" are not used.

   Reserved bit #4 (R4):  1 bit






Hiwasaki & Ohmuro       Expires November 15, 2007              [Page 10]

Internet-Draft       RTP Payload Format for UEMCLIP             May 2007


      This bit should be ignored.

   Pitch lag #2 (P2):  7 bits

      Pitch code of the offset frame.  The actual pitch lag is
      calculated as P2+20 samples in 8-kHz sampling rate.  Pitch lag
      must be 20 <= pitch length <= 120.  Codes ranging between "0x65"
      and "0x7F" are not used.  The offset value is defined as K.

   Power #2 (PW2):  8 bits

      Signal power code of the offset frame.  The offset value is
      defined as K.

   Reserved bits #5 (R5):  8 bits

      These bits should be ignored.

3.3.2.  Sub-layer data

   Sub-layer data (SD) is a sub-header followed by layer bitstreams, as
   shown in Figure 6.  The sub-header indicates the layer location and
   the number of bytes.

     0                   1                   2
     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   . . .
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+//-+-+-+
    | CI| FI| QI| R6|      SB       |               LD         ...  |
    |   |   |   |   |               |                               |
    |0 1|0 1|0 1|0 1|0 1 2 3 4 5 6 7|                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+//-+-+-+

                      Figure 6: Sub-layer format (SD)

   Channel index (CI):  2 bits

      Indicates the channel number.  For all modes given in Table 2,
      this should be "0x1".  The detail is given in Table 3.

   Frequency index (FI):  2 bits

      Indicates the frequency number. "0" means that the layer is in the
      base frequency band, higher number means that the layer is in
      respective frequency band.  The detail is given in Table 3.







Hiwasaki & Ohmuro       Expires November 15, 2007              [Page 11]

Internet-Draft       RTP Payload Format for UEMCLIP             May 2007


   Quality index (QI):  2 bits

      Indicates the quality layer number. "0" means that the layer is in
      the base layer, and higher number means that the layer is in
      respective quality layer.  The detail is given in Table 3.

   Reserved #6 (R6):  2 bits

      Not used (reserved).  The value must be "0".

   Sub-layer Size (SB):  8 bits

      Indicates the byte size of the following sub-layer data.

   Layer Data (LD):  SB*8 bits

      The actual sub-layer data.

3.3.2.1.  Layer index encoding

   The layer index is encoded using values of channel number, quality
   number, and frequency-band number encoded with 2-bits each, in the
   appearing order.  The last 2 bits are reserved for future use, and
   all implementation should ignore this field.  For all the layers
   shown in Table 1, the layer indices are shown in Table 3.

                         +-------+----+----+----+
                         | Layer | CI | FI | QI |
                         +-------+----+----+----+
                         |   a   |  0 |  0 |  0 |
                         |       |    |    |    |
                         |   b   |  0 |  0 |  1 |
                         |       |    |    |    |
                         |   c   |  0 |  1 |  0 |
                         +-------+----+----+----+

                          Table 3: Layer indices














Hiwasaki & Ohmuro       Expires November 15, 2007              [Page 12]

Internet-Draft       RTP Payload Format for UEMCLIP             May 2007


4.  G.711 interoperability

   As given in Section 2, u-law encoded G.711 bitstream (Layer a) is the
   core layer of a UEMCLIP bitstream, and is always embedded.  This
   means that transcoding from UEMCLIP bitstream to G.711 does not have
   to undergo decoding and re-encoding procedures, but simple extraction
   would only suffice.  However, this does not apply for the reverse
   procedure, i.e., transcoding from G.711 to UEMCLIP, because the side
   information in the main header must be assigned separately.

   The transcoding from UEMCLIP to u-law G.711 can be done easily by
   finding an appropriate sub-layer.  The transcoder should look for a
   sub-layer with the layer index of 0x00, and subsequent LD which has
   size of SB*8 bits (usually for 20 ms frame, SB=160) are the actual
   G.711 bitstream data.  It should be noted that transcoder should not
   always expect the core layer to be located right after the main
   header.

   On the other hand, the transcoding from G.711 to UEMCLIP is not
   entirely straight-forward.  Since there are no means to generate
   enhancement sub-layers, a G.711 bitstream can only be converted to
   UEMCLIP Mode 0 bitstream.  If the original G.711 bitstream is encoded
   in A-law, it should first be converted to u-law to become the core
   layer.  Because the default packetization size is 20 ms, u-law
   encoded G.711 bitstream MUST be a 160-sample chunk.  For the main
   header contents, when the UEMCLIP encoder is not available, it should
   follow the following guidelines.

   o  ID must be set "0x95".

   o  Byte size (BS) should be set 7 bytes of the main header, plus sub-
      header size (2) added with number of samples in G.711 (SB) .

   o  The enhanced-header size (ES) set to "0x00".

   o  The check bit for mixing and PLC (C1 and C2) should be set 0.

   o  The payload validity indicator (C3) should be set 0.

   For the core layer (i.e., u-law G.711 bitstream), it should have the
   following sub-layer header:

   o  All CI, FI, QI, R6 MUST be 0.

   o  Sub-layer size (SB) MUST be 160 for 20 ms frame.






Hiwasaki & Ohmuro       Expires November 15, 2007              [Page 13]

Internet-Draft       RTP Payload Format for UEMCLIP             May 2007


5.  Congestion Control Considerations

   The general congestion control considerations for transporting RTP
   data apply to UEMCLIP over RTP [3] as well as any applicable RTP
   profile like AVP [4].  UEMCLIP does not have any built-in mechanism
   for reducing the bandwidth.  Packing more frames in each RTP payload
   can reduce the number of packets sent, and hence the overhead from
   IP/UDP/RTP headers, at the expense of increased delay and reduced
   error robustness against packet losses.










































Hiwasaki & Ohmuro       Expires November 15, 2007              [Page 14]

Internet-Draft       RTP Payload Format for UEMCLIP             May 2007


6.  Payload Format Parameters

6.1.  Media type registration

   This registration is done using the template defined in [5] and
   following [7].

   MIME media type name:  audio

   MIME media subtype name:  UEMCLIP

   Required parameters:  Mode information: this defines bit-rate,
      sampling frequency and layer structure of the bitstream.  This
      parameter is necessary because the this is not signaled within the
      bitstream.

   Optional parameters:  none.

   Encoding considerations:  This type is defined for transferring
      UEMCLIP-encoded data via RTP using the payload format specified in
      Section 3 "Payload Format".  Audio data is binary data and must be
      encoded for non-binary transport; the Base64 encoding is suitable
      for e-mail.

   Security considerations:  See Section 7 "Security Considerations" of
      this document.

   Interoperability considerations:  This media is interoperable with
      u-law encoded ITU-T G.711. see Section 4 "G.711 interoperability"
      of this document.

   Published specification:  (T.B. assigned)

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

   Additional information:  None

   Intended usage:  COMMON

   Person & email address to contact for further information:  Yusuke
      Hiwasaki <hiwasaki.yusuke@lab.ntt.co.jp>

   Author:







Hiwasaki & Ohmuro       Expires November 15, 2007              [Page 15]

Internet-Draft       RTP Payload Format for UEMCLIP             May 2007


      Author:  Yusuke Hiwasaki

      Change Controller:  IETF Audio/Video Transport Working Group
         delegated from the IESG

6.2.  Mapping to SDP Parameters

   Payload type:  Since it is not registered in [4], any RTP packets
      that carry UEMCLIP as payload type MUST be treated as a dynamic
      payload type.

   Codec name:  MIME registered codec name should be used.

   Sampling Frequency:  Depending on the mode to communicate, sampling
      frequency MUST be selected from the ones defined in Table 2.

   Channel numbers:  It SHOULD default to "1", as selected from the ones
      defined in Table 2.

   Packet intervals:  Since frame length of any UEMCLIP is 20 ms, when
      specifying a=ptime line, the argument MUST be a multiple of "20".
      When not listed in SDP, it should also default to the minimum
      size: "20".

   Bandwidth:  As described in [6], bandwidth line is OPTIONAL.  When
      there is no bandwidth restrictions, the numbers MUST be the
      largest value out of the Table 2, and the unit should be "kbit/s"
      with the fraction raised to the unit, including header overheads
      down to Layer 3.  If any restrictions apply, then the value MUST
      be the largest of the Table 2 that satisfy the restriction, by the
      same calculation procedure.  It MUST NOT encode with bit-rate
      larger than the answered bit-rate bandwidth.

   UMECLIP specific:  Any description specific to UEMCLIP are defined in
      the Format Specification Parameters (fmtp).  Each parameters MUST
      be separated with ";", and if any attributes (value) exists, it
      MUST be defined with "+".  For compatibility reasons, any
      application/terminal MUST ignore any parameters that does not
      appear below.  This is to ensure the upper-compatibility with
      later added parameters for the future enhancements.

6.2.1.  Dynamic transmission definition

   Since UEMCLIP codec can operate in number of modes, it is desirable
   to specify the range of modes that an encoder or a decoder can
   operate at.

   UEMCLIP decoders are designed to accept bitstreams in any modes.



Hiwasaki & Ohmuro       Expires November 15, 2007              [Page 16]

Internet-Draft       RTP Payload Format for UEMCLIP             May 2007


   However, the implementation limitation may fail to adopt to the
   dynamic bit-rate change.  Thus introduced here is two concepts:
   "dynamic mode" (denoted as "dynmode"), where the dynamic mode (bit-
   rate) change is allowed, and "fixed mode" (denoted as "fixmode"),
   where the change is not permitted.  Both modes MUST be used
   exclusively.

   "fixmode" is used to specify no modification of the operating mode
   (bit-rate) during the session.  It MUST operate exclusively to
   "dynmode".  It should specify the possible combination of mode
   numbers, delimited by commas ",".  When offering a "fixmode", the
   offerer SHOULD list the mode numbers in descending priority order.
   The answerer MUST select a single suitable mode number and reply as
   "fixmode" with one argument.

   On the other hand, "dynmode" is used to allow modification of the
   operating mode during the session.  It MUST operate exclusively to
   "fixmode".  The offerer should specify the possible combination of
   mode numbers, delimited by commas ",".  The answerer can either
   select a number of suitable modes and reply as "dynmode" in the same
   manner, or select a single suitable mode number and reply as
   "fixmode" with one argument.

   The mode numbers that can be specified as arguments to "fixmode" or
   "dynmode" are restricted by a combination of a sampling frequency and
   a number of audio channels, as shown in Table 2.  This is because SDP
   binds a payload type to a combination of a sampling frequency and a
   number of audio channels.  When a "fixmode" or "dynmode" is not
   given, it MUST be interpreted as being defaulting to the fixed mode
   ("fixmode") and MUST use the default value specified in Table 4.

         +---------+----------+------------------+--------------+
         | Fs [Hz] | Channels | Selectable modes | Default mode |
         +---------+----------+------------------+--------------+
         |    8000 |     1    |        0,3       |       0      |
         |         |          |                  |              |
         |   16000 |     1    |        1,4       |       1      |
         +---------+----------+------------------+--------------+

                          Table 4: Default modes

6.3.  Offer-answer Model Considerations

   The procedures related to exchanging SDP messages MUST follow [2].

   o  When multiple UEMCLIP dynamic payload type number is offered, an
      answerer SHOULD select a single payload type number, i.e., one
      sampling frequency and channel condition.



Hiwasaki & Ohmuro       Expires November 15, 2007              [Page 17]

Internet-Draft       RTP Payload Format for UEMCLIP             May 2007


   o  The ptime SHOULD be 20.

   o  An offerer SHOULD offer every possible combination of sampling
      frequency, channel number, and fmtp parameters including dynamic/
      fixed mode.  When the transmission bandwidth is restricted, it
      MUST be offered in accordance to the restriction.

   o  When offering/answering SDP, any fmtp parameters which are
      undefined MUST be ignored.  If any unknown/undefined parameters
      should be offered, an answerer MUST delete the entry from the
      answer message.  In this case, the offerer MUST use the default
      value for any deleted parameters.

   o  If a dynamic mode ("dynmode") is offered, an answerer MUST select
      either "dynmode" or "fixmode", according to ones capabilities.
      When fixed mode ("fixmode") is offered, an answerer MUST only
      answer "fixmode".  In the case of answering fixed mode
      ("fixmode"), answerer MUST select a single mode out of offered
      mode, regardless of dynamic/fixed mode specification.  If a mode
      is not offered at all, the session MUST default to fixed mode, and
      the default mode value, as shown in Table 4, MUST be used, based
      on the sampling frequency and number of channels specified
      elsewhere.

   o  When an offered condition does not fit an answerer's capabilities,
      it naturally MUST not answer the conditions, and session MAY
      proceed to re-INVITE, if possible.  If a condition (mode) is
      decided upon, an offerer and an answerer MUST transmit on this
      condition.






















Hiwasaki & Ohmuro       Expires November 15, 2007              [Page 18]

Internet-Draft       RTP Payload Format for UEMCLIP             May 2007


7.  Security Considerations

   RTP packets using the payload format defined in this specification
   are subject to the security considerations discussed in the RTP
   specification [3] and any appropriate profiles.  This implies that
   confidentiality of the media streams is achieved by encryption.

   A potential denial-of-service threat exists for data encoding using
   compression techniques that have non-uniform receiver-end
   computational load.  The attacker can inject pathological datagrams
   into the stream that are complex to decode and cause the receiver
   output to become overloaded.  However, UEMCLIP covered in this
   document do not exhibit any significant non-uniformity.

   Another potential threats are memory attacks by illegal layer indices
   or byte numbers.  The implementor of the decoder should always be
   aware that the indicated numbers may be corrupted and does not point
   to the right sub-layer or the allows reading beyond the bitstream
   boundaries.
































Hiwasaki & Ohmuro       Expires November 15, 2007              [Page 19]

Internet-Draft       RTP Payload Format for UEMCLIP             May 2007


8.  IANA Considerations

   It is requested that one new media subtype (audio/UEMCLIP) is
   registered by IANA.  For details, see Section 6.1.















































Hiwasaki & Ohmuro       Expires November 15, 2007              [Page 20]

Internet-Draft       RTP Payload Format for UEMCLIP             May 2007


9.  Normative References

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

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

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

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

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

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

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

   [8]  Casner, S., "Media Type Registration of Payload Formats in the
        RTP Profile for Audio and Video Conferences", RFC 4856,
        February 2007.
























Hiwasaki & Ohmuro       Expires November 15, 2007              [Page 21]

Internet-Draft       RTP Payload Format for UEMCLIP             May 2007


Authors' Addresses

   Yusuke Hiwasaki
   NTT Corporation
   3-9-11 Midori-cho,
   Musashino-shi
   Tokyo  180-8585
   Japan

   Phone: +81(422)59-4815
   Email: hiwasaki.yusuke@lab.ntt.co.jp


   Hitoshi Ohmuro
   NTT Corporation
   3-9-11 Midori-cho,
   Musashino-shi
   Tokyo  180-8585
   Japan

   Phone: +81(422)59-2151
   Email: ohmuro.hitoshi@lab.ntt.co.jp





























Hiwasaki & Ohmuro       Expires November 15, 2007              [Page 22]

Internet-Draft       RTP Payload Format for UEMCLIP             May 2007


Full Copyright Statement

   Copyright (C) The IETF Trust (2007).

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

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


Intellectual Property

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

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

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


Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).





Hiwasaki & Ohmuro       Expires November 15, 2007              [Page 23]


Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/