[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: July 27, 2008                                  January 24, 2008


     RTP payload format for mU-law EMbedded Codec for Low-delay IP
                  communication (UEMCLIP) speech codec
                     draft-ietf-avt-rtp-uemclip-03

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 July 27, 2008.

Copyright Notice

   Copyright (C) The IETF Trust (2008).













Hiwasaki & Ohmuro         Expires July 27, 2008                 [Page 1]

Internet-Draft       RTP Payload Format for UEMCLIP         January 2008


Abstract

   This document describes the RTP payload format of a U-law EMbedded
   Coder for Low-delay IP communication (UEMCLIP), an enhanced speech
   codec of ITU-T G.711.  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  . . . . . . . . . . . . . . . . . . . . . . 11
   4.  Transcoding between UEMCLIP and G.711  . . . . . . . . . . . . 13
   5.  Congestion Control Considerations  . . . . . . . . . . . . . . 15
   6.  Payload Format Parameters  . . . . . . . . . . . . . . . . . . 16
     6.1.  Media type registration  . . . . . . . . . . . . . . . . . 16
     6.2.  Mapping to SDP Parameters  . . . . . . . . . . . . . . . . 17
       6.2.1.  Mode specification . . . . . . . . . . . . . . . . . . 18
     6.3.  Offer-Answer Model Considerations  . . . . . . . . . . . . 18
       6.3.1.  Offer-Answer Guidelines  . . . . . . . . . . . . . . . 19
       6.3.2.  Examples . . . . . . . . . . . . . . . . . . . . . . . 19
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 22
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 23
   9.  Normative References . . . . . . . . . . . . . . . . . . . . . 24
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25
   Intellectual Property and Copyright Statements . . . . . . . . . . 26

















Hiwasaki & Ohmuro         Expires July 27, 2008                 [Page 2]

Internet-Draft       RTP Payload Format for UEMCLIP         January 2008


1.  Introduction

   This document specifies the payload format for sending "U-law
   EMbedded Coder for Low-delay IP communication" (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 while achieving a very little transcoding
   load with the existing terminals, in which the implementation of
   G.711 is mandatory.  This property is very useful for RTP
   translators, for example, in cases where transcoding is unavoidable
   such as when narrowband and wideband terminals co-exist in a multi-
   point conference.

   The background and the basic idea of the media format is described in
   Section 2.  The details of the payload format are given in Section 3.
   The transcoding issues with G.711 are discussed in Section 4, and the
   considerations for congestion control are in Section 5.  In
   Section 6, the payload format parameters for a media type
   registration for UEMCLIP RTP payload format and SDP mappings are
   provided.  The security considerations and IANA considerations are
   dealt in Section 7 and Section 8, respectively.

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 July 27, 2008                 [Page 3]

Internet-Draft       RTP Payload Format for UEMCLIP         January 2008


2.  Media Format Background

   UEMCLIP is basically an enhanced version of u-law ITU-T G.711,
   otherwise known as PCMU [8].  It is targeted at Voice over Internet
   Protocol (VoIP) applications, and its main goal 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.  In ordinary one-
   to-one sessions, a common codec is usually negotiated, but when this
   is not possible, e.g., in multi-point conferencing, the packets would
   have to go through some kind of RTP translators [3].  Because the
   G.711 bitstream is embedded in the bitstream, costly transcoding can
   be avoided.

   This document does not discuss the implementation details of the
   encoder and decoder, but only describes the bitstream format.

   Because of its scalable nature, there are a number of sub-bitstreams
   (sub-layer) 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 UEMCLIP codec operates at 20-ms frame, and includes three sub-
   coders as shown in Table 1.  The core layer is u-law G.711 at 64
   kbit/s, 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

   Based on these sub-layers, UEMCLIP codec operates in four modes as



Hiwasaki & Ohmuro         Expires July 27, 2008                 [Page 4]

Internet-Draft       RTP Payload Format for UEMCLIP         January 2008


   shown in Table 2.  Here, "Fs" is the sampling frequency in kHz.  The
   absent Modes 2 and 5 are reserved for possible 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 between implementations, thus the sender and the
   receiver must negotiate what mode to use for transmission.














Hiwasaki & Ohmuro         Expires July 27, 2008                 [Page 5]

Internet-Draft       RTP Payload Format for UEMCLIP         January 2008


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 (MH) followed by one or more (up to three)
   sub-layers (SL) as shown in Figure 2.

                            +--+-------+//-+
                            |MH| SL #1 |...|
                            +--+-------+//-+

               Figure 2: A UEMCLIP frame (bitstream format)

   As a sub-layer, the core layer, i.e., "Layer a", MUST always be
   included.  It should be noted that the location of the core layer may
   not be located at the top.  The decoder MUST always refer to the
   layer ID for proper decoding.

   The UEMCLIP bitstream does not explicitly include the following
   information: mode and sampling frequency (Fs).  As described before,
   this information MUST 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:

   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.



Hiwasaki & Ohmuro         Expires July 27, 2008                 [Page 6]

Internet-Draft       RTP Payload Format for UEMCLIP         January 2008


   Timestamp:  This encodes the sampling instant of the first speech
      signal sample in the RTP data packet.  For UEMCLIP streams, the
      RTP timestamp MUST advance based on a clock rate which is multiple
      of 8000 (Hz), and in case the sampling rate can change during a
      session, this number should equal to the maximum rate (in Hz)
      given in the mode range (see Section 6.2.1).  This implies that
      the clock rate MUST NOT change during a session.  For example,
      during an 8-kHz session where a transition to a 16-kHz mode is
      allowed, the time stamp must always advance using 16-kHz clock
      rate.  For a session using a fixed mode, it should be either 8 or
      16 kHz, based on the sampling rate.

   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  A single RTP packet SHOULD NOT include more UEMCLIP frames than
      will fit in the path MTU.

   o  All frames contained in a single RTP packet MUST be of the same
      mode.

   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
   for telephony application where delay has a great impact on the
   quality, then fewer frames per packet for lower delay, is preferable.

3.3.  Payload Data

   In a UEMCLIP bitstream, all numbers are encoded in a network byte-
   order.

3.3.1.  Main Header

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



Hiwasaki & Ohmuro         Expires July 27, 2008                 [Page 7]

Internet-Draft       RTP Payload Format for UEMCLIP         January 2008


    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     ID        |             BS                |      MX       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                              PC                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   PC(cont'd)  |      ES       |          EH (if exist)     ...|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+//-+-+

                 Figure 3: UEMCLIP main header format (MH)

   Identification (ID):  8 bits

      The value MUST be "0x95".

   Byte size (BS):  16 bits

      Indicates the size in bytes of the rest of the UEMCLIP frame,
      i.e., the frame size minus 3 bytes (of ID and BS).

   Mixing information (MX):  8 bits

      Mixing information field.  See Section 3.3.1.1.

   Packet-loss Concealment information (PC):  40 bits

      Packet-loss concealment (PLC) information field.  See
      Section 3.3.1.2.

   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.

3.3.1.1.  Mixing information field

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

                  Figure 4: Mixing information field (MX)



Hiwasaki & Ohmuro         Expires July 27, 2008                 [Page 8]

Internet-Draft       RTP Payload Format for UEMCLIP         January 2008


   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.  If any of these parameters is invalid, this
      bit should be set to "0".  This flag is used in cases when a
      Multi-point Control Unit (MCU) is a signal mixer and the MCU tries
      to send an information from a location where an upstream packet is
      lost (thus the information is invalid and should be marked with
      "0").  This flag should be set to "0" in case of upward
      transcoding from G.711 (See Section 4).

   Reserved bit #1 (R1):  1 bit

      This bit should be ignored.  The default of this bit is 0.

   VAD flag #1 (V1):  1 bit

      Voice activity detection flag of the current frame, designed to be
      used for MCU operations.  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.  This flag is
      specifically designed for mixing information.  DTX judgment based
      this flag is not recommended.

   Power #1 (PW1):  5 bits

      Signal power code of the current frame.

3.3.1.2.  PLC information field

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

                   Figure 5: PLC information field (PC)

   Check bit #2 (C2):  1 bit







Hiwasaki & Ohmuro         Expires July 27, 2008                 [Page 9]

Internet-Draft       RTP Payload Format for UEMCLIP         January 2008


      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, this bit should be set to "0".  Similarly to C1, this
      flag should be set to "0" in case of upward transcoding from G.711
      (See Section 4).

   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.  The default of this bit is 0.

   VAD flag #2 (V2):  1 bit

      Voice activity detection flag of the current frame, designed to be
      used for packet-loss concealment.  This may not be as same as V1
      in the mixing information, and may not be synchronous to the
      marker bit in the RTP header.  DTX judgment based this flag is not
      recommended.

   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.  The default of this bit is 1.

   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.





Hiwasaki & Ohmuro         Expires July 27, 2008                [Page 10]

Internet-Draft       RTP Payload Format for UEMCLIP         January 2008


   Reserved bit #4 (R4):  1 bit

      This bit should be ignored.  The default of this bit is 1.

   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.  The default of all bits are "0".

3.3.2.  Sub-layer

   Sub-layer (SL) 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         ...  |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+//-+-+-+

                      Figure 6: Sub-layer format (SL)

   Channel index (CI):  2 bits

      Indicates the channel number.  For all modes given in Table 2,
      this should be "0".  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 July 27, 2008                [Page 11]

Internet-Draft       RTP Payload Format for UEMCLIP         January 2008


   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 default value is "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.

   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 July 27, 2008                [Page 12]

Internet-Draft       RTP Payload Format for UEMCLIP         January 2008


4.  Transcoding between UEMCLIP and G.711

   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 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.  It
   should be noted that an RTP device that is transcoding between those
   media types is an RTP translator [3] and all the requirements apply.
   This means that a transcoding device of this sort MUST rewrite RTCP
   packets, together with the RTP media packets.

   The transcoding from UEMCLIP to u-law G.711 can be done easily by
   finding an appropriate sub-layer.  Within a frame, the transcoder
   should look for a sub-layer with layer index "0x00", and subsequent
   LD which has size of SB*8 bits (UEMCLIP has a 20-ms frame thus,
   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 a UEMCLIP frame size is 20 ms, u-law encoded G.711
   bitstream MUST be a 160-sample chunk to become a core layer.  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.

   o  The reserved bits (R1 to R5) should be set with default values.

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




Hiwasaki & Ohmuro         Expires July 27, 2008                [Page 13]

Internet-Draft       RTP Payload Format for UEMCLIP         January 2008


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

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
















































Hiwasaki & Ohmuro         Expires July 27, 2008                [Page 14]

Internet-Draft       RTP Payload Format for UEMCLIP         January 2008


5.  Congestion Control Considerations

   The bandwidth of a UEMCLIP bitstream can be reduced by stripping down
   sub-layers.  Note that this means that the bitstream mode of the
   payload is changed, and the range of modes that a bitstream can be
   modified to (see Section 6.2.1) is obtained by offer-answer
   negotiation as given in Section 6.3.  If the bitrate is modified by
   means of stripping, BS field of the bitstream MUST be modified
   accordingly.

   The general congestion control considerations for transporting RTP
   data also apply to UEMCLIP over RTP [3] as well as any applicable RTP
   profile like AVP [4].  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.  It should be treated with care
   because increased delay means reduced quality.


































Hiwasaki & Ohmuro         Expires July 27, 2008                [Page 15]

Internet-Draft       RTP Payload Format for UEMCLIP         January 2008


6.  Payload Format Parameters

6.1.  Media type registration

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

   Media type name:  audio

   Media subtype name:  UEMCLIP

   Required parameters:

      Rate:  Defines the sampling rate, and MUST be either 8000 or
         16000.  See Section 6.2.1 "Mode specification" of RFC xxxx
         (this RFC) for details.

   Optional parameters:

      ptime:  See RFC 4566 [6].

      maxptime:  See RFC 4566 [6].

      mode:  Indicates the range of dynamically changeable modes during
         a session.  Possible values are comma separated list of modes
         from the supported mode set: 0, 1, 3, and 4.  If only one mode
         is specified, it means that the mode must not be changed during
         the session.  When not specified, the mode transmission
         defaults to a singular mode as specified in Table 4.  See
         Section 6.2.1 "Mode specification" of RFC xxxx (this RFC) for
         details.

   Encoding considerations:  This type is defined for transferring
      UEMCLIP-encoded data via RTP using the payload format specified in
      Section 3 "Payload Format" of RFC xxxx (this RFC).  This media
      type is framed every 20 ms and is binary.

   Security considerations:  See Section 7 "Security Considerations" of
      RFC xxxx (this RFC).

   Interoperability considerations:  This media may be readily
      transcoded to u-law encoded ITU-T G.711.  See Section 4
      "Transcoding between UEMCLIP and G.711" of RFC xxxx (this RFC).

   Published specification:  RFC xxxx (This RFC)






Hiwasaki & Ohmuro         Expires July 27, 2008                [Page 16]

Internet-Draft       RTP Payload Format for UEMCLIP         January 2008


   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:

      Author:  Yusuke Hiwasaki

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

6.2.  Mapping to SDP Parameters

   The media types audio/UEMCLIP are mapped to fields in the Session
   Description Protocol (SDP) [6] as follows:

   Media name:  The "m=" line of SDP MUST be audio.

   Encoding name:  Registered media subtype name should be used for the
      "a=rtpmap" line.

   Sampling Frequency:  Depending on the mode, clock rate (sampling
      frequency) specified in "a=rtpmap" MUST be selected from the ones
      defined in Table 2.  See Section 6.2.1 for details.

   Encoding parameters:  Since this is an audio stream, the encoding
      parameters indicate the number of audio channels, and this SHOULD
      default to "1", as selected from the ones defined in Table 2.
      This is OPTIONAL.

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

   UMECLIP specific:  Any description specific to UEMCLIP are defined in
      the Format Specification Parameters ("a=fmtp").  Each parameter
      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 it does not
      understand.  This is to ensure the upper-compatibility with
      parameters added in future enhancements.  The mode specification
      parameters should be defined here (see Section 6.2.1).



Hiwasaki & Ohmuro         Expires July 27, 2008                [Page 17]

Internet-Draft       RTP Payload Format for UEMCLIP         January 2008


6.2.1.  Mode specification

   Since UEMCLIP codec can operate in number of modes (bit-rates), it is
   desirable to specify the range of modes that an encoder or a decoder
   can operate at.  When exchanging SDP messages, an offerer should
   specify all possible combination of mode numbers as arguments to
   "mode=" in "a=fmtp" line, delimited by commas ",".  In case of
   specifying multiple modes, those SHOULD appear in the descending
   priority order.

   Although UEMCLIP decoders SHOULD accept bitstreams in any modes, an
   implementation may fail to adopt to the dynamic mode changes during a
   session.  For this reason, an application may choose to operate
   either with one fixed mode or with multiple modes that can be
   dynamically changed.  If the mode is to be fixed and changes are not
   allowed, this can be indicated by specifying a single mode per
   payload type.

   The mode numbers that can be specified in a payload type as arguments
   to "mode" are restricted by a combination of a clock rate and a
   number of audio channels.  This is because SDP binds a payload type
   to a combination of a sampling frequency and a number of audio
   channels.  Table 4 gives selectable mode numbers that attributed with
   clock rates.  When mode specifications are not given at all, a
   payload type MUST default to a single mode using the default value
   specified in this table.

        +------------+----------+------------------+--------------+
        | Clock rate | Channels | Selectable modes | Default mode |
        +------------+----------+------------------+--------------+
        |       8000 |     1    |        0,3       |       0      |
        |            |          |                  |              |
        |      16000 |     1    |      0,1,3,4     |       1      |
        +------------+----------+------------------+--------------+

                          Table 4: Default modes

   It should be noted that a mode attributed with a larger sampling
   frequency (Fs) is not used in conjunction with smaller clock rates
   specified in "a=rtpmap".  This means that Modes 0 and 3 can be
   specified in a payload type having clock rate of both 8000 and 16000
   in "a=rtpmap", but Modes 1 and 4 cannot be specified with one having
   clock rate of 8000.

6.3.  Offer-Answer Model Considerations






Hiwasaki & Ohmuro         Expires July 27, 2008                [Page 18]

Internet-Draft       RTP Payload Format for UEMCLIP         January 2008


6.3.1.  Offer-Answer Guidelines

   The procedures related to exchanging SDP messages MUST follow [2].
   Followings are additional guidelines for establishing a session using
   an offer-answer model.

   o  An offerer SHOULD offer every possible combination of UEMCLIP
      payload type it can handle, i.e., sampling frequency, channel
      number, and fmtp parameters, in a preferred order.  When the
      transmission bandwidth is restricted, it MUST be offered in
      accordance to the restriction.

   o  When multiple UEMCLIP payload types are offered, it is RECOMMENDED
      that the answerer selects a single UEMCLIP payload type and
      answers it back.

   o  In a UEMCLIP payload type, an answerer MUST answer back suitable
      mode number(s) as a subset () of what has been offered.

   o  In an offering/answering SDP, any fmtp parameters which are not
      known 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  A receiver of an SDP message MUST only use specified payload types
      and modes.  When a mode specification is missing, i.e., a mode is
      not specified at all, the session MUST default to one single mode
      without mode changes during a session.  For this case, the default
      mode values, as shown in Table 4, MUST be used based on the
      sampling frequency and number of channels.  This table must be
      looked up only when there are no mode specifications, thus the
      offerer/answerer MUST NOT assume that the default modes are always
      available when it is not in the specified list of modes.

   o  When an offered condition does not fit an answerer's capabilities,
      it naturally MUST NOT answer any of 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.

6.3.2.  Examples

   When an offerer indicates that he/she wishes to dynamically switch
   between modes (0,1,3, and 4) during a session, an example of an
   offered SDP can be:





Hiwasaki & Ohmuro         Expires July 27, 2008                [Page 19]

Internet-Draft       RTP Payload Format for UEMCLIP         January 2008


     v=0
     o=john 51050101 51050101 IN IP4 offhost.example.com
     s=-
     c=IN IP4 offhost.example.com
     t=0 0
     m=audio 5004 RTP/AVP 96
     a=rtpmap:96 UEMCLIP/16000/1
     a=fmtp:96 mode=4,1,3,0

   It should be noted that the listed modes appears in the offerer's
   preference.

   When an answerer can only operate in Modes 1 and 0 but can
   dynamically switch between those modes during a session, an answerer
   MUST delete the entries of Mode 3 and 4, and answer back as:

     v=0
     o=lena 549947322 549947322 IN IP4 anshost.example.org
     s=-
     c=IN IP4 anshost.example.org
     t=0 0
     m=audio 5004 RTP/AVP 96
     a=rtpmap:96 UEMCLIP/16000/1
     a=fmtp:96 mode=1,0

   As a result, both would start communicating in either Mode 1 or 0,
   and can dynamically switch between those modes during the session

   On the other hand, when the answerer is capable of communicating
   either in Modes 1 or 0, and cannot switch between modes during a
   session, an example of such answer is as follows:

     v=0
     o=lena 549947322 549947322 IN IP4 anshost.example.org
     s=-
     c=IN IP4 anshost.example.org
     t=0 0
     m=audio 5004 RTP/AVP 96
     a=rtpmap:96 UEMCLIP/16000/1
     a=fmtp:96 mode=1

   As a result, both will start communicating in Mode 1.  It should be
   noted that mode change during this session is not allowed because the
   answerer responded with a single mode, and answerer selected Mode 1
   above Mode 0 according to the offered order.

   If an offerer does not want a mode change during a session but is
   capable of receiving either Modes 4 or 1 bitstreams, the SDP should



Hiwasaki & Ohmuro         Expires July 27, 2008                [Page 20]

Internet-Draft       RTP Payload Format for UEMCLIP         January 2008


   somewhat look like:

     v=0
     o=john 51050101 51050101 IN IP4 offhost.example.com
     s=-
     c=IN IP4 offhost.example.com
     t=0 0
     m=audio 5004 RTP/AVP 96 97
     a=rtpmap:96 UEMCLIP/16000/1
     a=fmtp:96 mode=4
     a=rtpmap:97 UEMCLIP/16000/1
     a=fmtp:97 mode=1

   and if the answerer prefers to communicate in Mode 1, an answer would
   be:

     v=0
     o=lena 549947322 549947322 IN IP4 anshost.example.org
     s=-
     c=IN IP4 anshost.example.org
     t=0 0
     m=audio 5004 RTP/AVP 97
     a=rtpmap:97 UEMCLIP/16000/1
     a=fmtp:97 mode=1

   Please note that it is RECOMMENDED to select a single UEMCLIP payload
   type for answers.

   The "ptime" attribute is used to denote the desired packetization
   interval.  When not specified, it SHOULD default to 20.  Since
   UEMCLIP uses 20 msec frames, ptime values of multiples of 20 imply
   multiple frames per packet.  In the example below, the ptime is set
   to 60, and this means that offerer wants to receive 3 frames in each
   packet.

     v=0
     o=kosuke 2890844730 2890844730 IN IP4 anotherhost.example.com
     s=-
     c=IN IP4 anotherhost.example.com
     t=0 0
     m=audio 5004 RTP/AVP 96
     a=ptime:60
     a=rtpmap:96 UEMCLIP/16000/1

   When mode specification is not present, it should default to a fixed
   mode, and in this case, Mode 1 (see Section 6.2.1).





Hiwasaki & Ohmuro         Expires July 27, 2008                [Page 21]

Internet-Draft       RTP Payload Format for UEMCLIP         January 2008


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 by
   other means.

   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 and may force reading beyond the bitstream
   boundaries.































Hiwasaki & Ohmuro         Expires July 27, 2008                [Page 22]

Internet-Draft       RTP Payload Format for UEMCLIP         January 2008


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 July 27, 2008                [Page 23]

Internet-Draft       RTP Payload Format for UEMCLIP         January 2008


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 July 27, 2008                [Page 24]

Internet-Draft       RTP Payload Format for UEMCLIP         January 2008


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 July 27, 2008                [Page 25]

Internet-Draft       RTP Payload Format for UEMCLIP         January 2008


Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

   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 July 27, 2008                [Page 26]


Html markup produced by rfcmarkup 1.108, available from http://tools.ietf.org/tools/rfcmarkup/