doc: Add RFC documents

1 files changed, 1179 insertions, 0 deletions

diff --git a/doc/rfc/rfc5686.txt b/doc/rfc/rfc5686.txt
new file mode 100644
index 0000000..5382f79
--- /dev/null
+++ b/doc/rfc/rfc5686.txt
@@ -0,0 +1,1179 @@
+
+
+
+
+
+
+Network Working Group                                        Y. Hiwasaki
+Request for Comments: 5686                                     H. Ohmuro
+Category: Standards Track                                NTT Corporation
+                                                            October 2009
+
+
+     RTP Payload Format for mU-law EMbedded Codec for Low-delay IP
+                  Communication (UEMCLIP) Speech Codec
+
+Abstract
+
+   This document describes the RTP payload format of a mU-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.
+
+Status of This Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (c) 2009 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (http://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the BSD License.
+
+   This document may contain material from IETF Documents or IETF
+   Contributions published or made publicly available before November
+   10, 2008.  The person(s) controlling the copyright in some of this
+   material may not have granted the IETF Trust the right to allow
+   modifications of such material outside the IETF Standards Process.
+   Without obtaining an adequate license from the person(s) controlling
+   the copyright in such materials, this document may not be modified
+   outside the IETF Standards Process, and derivative works of it may
+
+
+
+Hiwasaki & Ohmuro           Standards Track                     [Page 1]
+
+RFC 5686             RTP Payload Format for UEMCLIP         October 2009
+
+
+   not be created outside the IETF Standards Process, except to format
+   it for publication as an RFC or to translate it into languages other
+   than English.
+
+Table of Contents
+
+   1. Introduction ....................................................2
+      1.1. Terminology ................................................3
+   2. Media Format Background .........................................3
+   3. Payload Format ..................................................5
+      3.1. RTP Header Usage ...........................................6
+      3.2. Multiple Frames in an RTP Packet ...........................6
+      3.3. Payload Data ...............................................7
+           3.3.1. Main Header .........................................7
+           3.3.2. Sub-Layer ..........................................10
+   4. Transcoding between UEMCLIP and G.711 ..........................11
+   5. Congestion Control Considerations ..............................12
+   6. Payload Format Parameters ......................................13
+      6.1. Media Type Registration ...................................13
+      6.2. Mapping to SDP Parameters .................................14
+           6.2.1. Mode Specification .................................15
+      6.3. Offer-Answer Model Considerations .........................16
+           6.3.1. Offer-Answer Guidelines ............................16
+           6.3.2. Examples ...........................................17
+   7. Security Considerations ........................................19
+   8. IANA Considerations ............................................19
+   9. References .....................................................19
+      9.1. Normative References ......................................19
+      9.2. Informative References ....................................20
+
+1.  Introduction
+
+   This document specifies the payload format for sending UEMCLIP-
+   encoded (mU-law EMbedded Coder for Low-delay IP communication) speech
+   using the Real-time Transport Protocol (RTP) [RFC3550].  UEMCLIP is a
+   proprietary codec that enhances u-law ITU-T G.711 [ITU-T-G.711] and
+   that is designed to help the market for smooth transition towards the
+   forthcoming wideband communication environment while achieving a very
+   small media transcoding load with the existing terminals, in which
+   the implementation of G.711 is mandatory.
+
+   It should be noted that, generally speaking, codecs are negotiated
+   and changed using an SDP exchange.  Also, [RFC3550] defines general
+   RTP mixer and translator models, where media transcoding may not take
+   place at the node.  For those cases, the design concept of the
+   embedded structure is not useful.  However, there are other cases
+   when costly transcoding is unavoidable in commonly deployed types of
+   Multi-point Control Units (MCUs), which terminate media and RTCP
+
+
+
+Hiwasaki & Ohmuro           Standards Track                     [Page 2]
+
+RFC 5686             RTP Payload Format for UEMCLIP         October 2009
+
+
+   packets [RFC5117], and when narrowband and wideband terminals
+   coexist.  This embedded bitstream structure can reduce the media
+   transcoding to a simple bitstream truncation.
+
+   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 Session Description
+   Protocol (SDP) mappings are provided.  The security considerations
+   and IANA considerations are dealt with 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 [RFC2119].
+
+2.  Media Format Background
+
+   UEMCLIP is an enhanced version of u-law ITU-T G.711, otherwise known
+   as PCMU [RFC4856].  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 using wideband communication.  In widely deployed
+   multi-point conferencing systems, the packets usually go through
+   RTCP-terminating (RTP Control Protocol) MCUs, "Topo-RTCP-terminating-
+   MCU" as defined in [RFC5117].  Because the G.711 bitstream is
+   embedded in the bitstream, costly media transcoding can be avoided in
+   this case.
+
+   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.
+
+
+
+Hiwasaki & Ohmuro           Standards Track                     [Page 3]
+
+RFC 5686             RTP Payload Format for UEMCLIP         October 2009
+
+
+   The UEMCLIP codec operates at a 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, the UEMCLIP codec operates in four modes
+   as shown in Table 2.  Here, "Ch" is the number of channels and "Fs"
+   is the sampling frequency in kHz.  It should be noted that the
+   current version only supports single-channel operation and there
+   might be future extensions with multi-channel capabilities.  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 |
+   |      |    |    |       |       |       |    [kbit/s] |   [kbit/s] |
+   +------+----+----+-------+-------+-------+-------------+------------+
+   |   0  |  1 |  8 |   x   |   -   |   -   |          64 |       67.2 |
+   |      |    |    |       |       |       |             |            |
+   |   1  |  1 | 16 |   x   |   -   |   x   |          80 |       84.0 |
+   |      |    |    |       |       |       |             |            |
+   |   2  |  - |  - |   -   |   -   |   -   |           - |          - |
+   |      |    |    |       |       |       |             |            |
+   |   3  |  1 |  8 |   x   |   x   |   -   |          80 |       84.0 |
+   |      |    |    |       |       |       |             |            |
+   |   4  |  1 | 16 |   x   |   x   |   x   |          96 |      100.8 |
+   |      |    |    |       |       |       |             |            |
+   |   5  |  - |  - |   -   |   -   |   -   |           - |          - |
+   +------+----+----+-------+-------+-------+-------------+------------+
+
+                         Table 2: Mode Description
+
+
+
+
+Hiwasaki & Ohmuro           Standards Track                     [Page 4]
+
+RFC 5686             RTP Payload Format for UEMCLIP         October 2009
+
+
+   The 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.
+
+3.  Payload Format
+
+   As an RTP payload, the 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
+
+   The 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 (SLs) 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
+   or may not immediately follow MH field.  The decoder MUST always
+   refer to the layer indices for proper decoding because the order of
+   the sub-layers is arbitrary.
+
+
+
+
+
+
+Hiwasaki & Ohmuro           Standards Track                     [Page 5]
+
+RFC 5686             RTP Payload Format for UEMCLIP         October 2009
+
+
+   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
+   [RFC3550].  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.
+
+   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 either at 8000 or
+      16000 (Hz).  In cases where the audio sampling rate can change
+      during a session, the RTP timestamp rate MUST be equal to the
+      maximum rate (in Hz) given in the mode range (see Section 6.2.1).
+      This implies that the RTP timestamp rate for UEMCLIP payload type
+      MUST NOT change during a session.  For example, for a UEMCLIP
+      stream with 8-kHz audio sampling, where a transition to a 16-kHz
+      audio sampling mode is allowed, the RTP time stamp must always
+      advance using the 16-kHz clock rate.  For a fixed audio sampling
+      mode, the RTP timestamp rate should be either 8 or 16 kHz,
+      depending 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.
+
+
+
+Hiwasaki & Ohmuro           Standards Track                     [Page 6]
+
+RFC 5686             RTP Payload Format for UEMCLIP         October 2009
+
+
+   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 applications 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 a size
+   of 6 bytes.  The content of the main header is shown in Figure 3.
+
+    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
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |      MX       |                      PC                       |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |          PC(cont'd)           |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+                 Figure 3: UEMCLIP Main Header Format (MH)
+
+   Mixing information (MX):  8 bits
+
+      Mixing information field.  This field is only relevant when Topo-
+      RTCP-terminating-MCUs are utilized to interpret these fields.  See
+      Section 3.3.1.1 for details of the fields.
+
+   Packet-loss Concealment information (PC):  40 bits
+
+      Packet-loss concealment (PLC) information field.  See
+      Section 3.3.1.2.
+
+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           Standards Track                     [Page 7]
+
+RFC 5686             RTP Payload Format for UEMCLIP         October 2009
+
+
+   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 mainly intended for a
+      UEMCLIP-conscious Topo-RTCP-terminating-MCU.  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.  The code is obtained by
+      calculating a root mean square (RMS) of "Layer a" and encoding
+      this RMS using G.711 u-law [ITU-T-G.711].  Denoting the encoded
+      RMS as R, then PW1 is obtained by PW1 = ((~R)>>2) & 0x1F, where
+      "~", ">>", "&" are one's complement arithmetic, right SHIFT, and
+      bitwise AND operators, respectively.
+
+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|R2 |V|   K   |U|     P1      |U|     P2      |      PW2      |
+   |2|   |2|       |1|             |2|             |               |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |      R3       |
+   |               |
+   +-+-+-+-+-+-+-+-+
+
+                   Figure 5: PLC Information Field (PC)
+
+
+
+
+
+
+Hiwasaki & Ohmuro           Standards Track                     [Page 8]
+
+RFC 5686             RTP Payload Format for UEMCLIP         October 2009
+
+
+   Check bit #2 (C2):  1 bit
+
+      Validity flag of V2, K, U1, P1, U2, 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).
+
+   Reserved bit #2 (R2):  2 bits
+
+      These bits should be ignored.  The default of these bits are 0.
+
+   VAD flag #2 (V2):  1 bit
+
+      Voice activity detection flag of the current frame, designed to be
+      used for packet-loss concealment.  This might not be the same as
+      V1 in the mixing information, and might 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 U2, P2, and PW2.  Since
+      it is a better idea to carry the speech feature parameters as PLC
+      information in a different frame to maintain the speech quality,
+      this frame offset value gives with which frame the parameters are
+      to be associated.  The value ranges between "0" and "15".  If the
+      current frame number is N, for example, the value K indicates that
+      U2, P2, and PW2 are associated with the frame of N-K.  The frame
+      indicator is equal to the difference in the RTP sequence number
+      when one UEMCLIP frame is contained in a single RTP packet.
+
+   V/UV flag #1 (U1):  1 bit
+
+      Voiced/Unvoiced signal indicator of the current frame.  This flag
+      being "0" indicates that the frame is a voiced signal segment, and
+      "1" indicates that it is an unvoiced signal segment.
+
+   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.  To obtain the pitch lag, any pitch
+      estimation method can be used, such as the one used in G.711
+      Appendix I [ITU-T-G.711Appendix1].
+
+
+
+
+Hiwasaki & Ohmuro           Standards Track                     [Page 9]
+
+RFC 5686             RTP Payload Format for UEMCLIP         October 2009
+
+
+   V/UV flag #2 (U2):  1 bit
+
+      Voiced/Unvoiced signal indicator of the offset frame.  This flag
+      being "0" indicates that the frame is a voiced signal segment, and
+      "1" indicates that it is an unvoiced signal segment.  The offset
+      value is defined as K.
+
+   Pitch lag #2 (P2):  7 bits
+
+      Pitch code of the offset frame.  The offset value is defined as K.
+      The calculation method is identical to "P1", except that it is
+      based on the signal of offset frame.
+
+   Power #2 (PW2):  8 bits
+
+      Signal power code of the offset frame.  The offset value is
+      defined as K.
+
+   Reserved bits #3 (R3):  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 |R4 |      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           Standards Track                    [Page 10]
+
+RFC 5686             RTP Payload Format for UEMCLIP         October 2009
+
+
+   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 #4 (R4):  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
+
+4.  Transcoding between UEMCLIP and G.711
+
+   As given in Section 2, the u-law-encoded G.711 bitstream (Layer a) is
+   the core layer of a UEMCLIP bitstream, and is always embedded.  This
+   means that media transcoding from the 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 auxiliary information in the main header (MH) must be assigned
+   separately.  It should be noted that this media transcoding is useful
+   for a Media Translator (Topo-Media-Translator) or a Point-to-
+   Multipoint Using RTCP Terminating MCU (Topo-RTCP-terminating-MCU) in
+   [RFC5117], and all the requirements apply.  This means that a
+   transcoding device of this sort MUST rewrite RTCP packets, together
+   with the RTP media packets.
+
+
+
+Hiwasaki & Ohmuro           Standards Track                    [Page 11]
+
+RFC 5686             RTP Payload Format for UEMCLIP         October 2009
+
+
+   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 a layer index of "0x00", and
+   subsequent LD that has a 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 the 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 straightforward.  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, a 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 these guidelines:
+
+   o  The check bits for mixing and PLC (C1 and C2) are set to 0.
+
+   o  The reserved bits (R1 to R3) in MH are set to respective default
+      values.
+
+   For the core layer (i.e., u-law G.711 bitstream), it should have the
+   following sub-layer header:
+
+   o  All CI, FI, QI, and R4 MUST be 0.
+
+   o  Sub-layer size (SB) MUST be 160 for a 20-ms frame.
+
+5.  Congestion Control Considerations
+
+   The general congestion control considerations for transporting RTP
+   data also apply to UEMCLIP over RTP [RFC3550] as well as any
+   applicable RTP profile like Audio-Visual Profile (AVP) [RFC3551].
+
+   The bandwidth of a UEMCLIP bitstream can be reduced by changing to
+   lower-bit-rate modes.  The embedded layer structure of UEMCLIP may
+   help to control congestion, when dynamic mode changing (see
+   Section 6.2.1) is available, and the range of modes is obtained by
+   offer-answer negotiation as given in Section 6.3.  It should be noted
+   that this involves proper RTCP handling when the bit-rate is modified
+   in an RTP translator or a mixer [RFC3550].
+
+
+
+
+
+
+
+
+Hiwasaki & Ohmuro           Standards Track                    [Page 12]
+
+RFC 5686             RTP Payload Format for UEMCLIP         October 2009
+
+
+   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.
+
+6.  Payload Format Parameters
+
+6.1.  Media Type Registration
+
+   This registration is done using the template defined in [RFC4288] and
+   following [RFC4855].
+
+   Media type name:  audio
+
+   Media subtype name:  UEMCLIP
+
+   Required parameters:
+
+      Rate:  Defines the sampling rate, and it MUST be either 8000 or
+         16000.  See Section 6.2.1 "Mode specification" of RFC 5686
+         (this RFC) for details.
+
+   Optional parameters:
+
+      ptime:  See RFC 4566 [RFC4566].
+
+      maxptime:  See RFC 4566 [RFC4566].
+
+      mode:  Indicates the range of dynamically changeable modes during
+         a session.  Possible values are a 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 5686 (this RFC) for
+         details.
+
+   Encoding considerations:  This media type is framed and contains
+      binary data.  See Section 4.8 of RFC 4288.
+
+   Security considerations:  See Section 7 "Security Considerations" of
+      RFC 5686 (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 5686 (this RFC).
+
+
+
+
+Hiwasaki & Ohmuro           Standards Track                    [Page 13]
+
+RFC 5686             RTP Payload Format for UEMCLIP         October 2009
+
+
+   Published specification:  RFC 5686 (this RFC)
+
+   Applications that use this media type:  Audio and video streaming and
+      conferencing tools.
+
+   Additional information:  None
+
+   Intended usage:  COMMON
+
+   Restrictions on usage:  This media type depends on RTP framing, and
+      hence is only defined for transfer via RTP.
+
+   Person & email address to contact for further information:
+      Yusuke Hiwasaki <hiwasaki.yusuke@lab.ntt.co.jp>
+
+   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) [RFC4566] 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" SHOULD 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 is defined in
+      the Format Specification Parameters ("a=fmtp").  Each parameter
+      MUST be separated with ";", and if any attribute (value) exists,
+      it MUST be defined with "=".  For compatibility reasons, any
+      application/terminal MUST ignore any parameters that it does not
+
+
+
+Hiwasaki & Ohmuro           Standards Track                    [Page 14]
+
+RFC 5686             RTP Payload Format for UEMCLIP         October 2009
+
+
+      understand.  This is to ensure the upper-compatibility with
+      parameters added in future enhancements.  The mode specification
+      should be made here (see Section 6.2.1).
+
+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 at which an encoder or a
+   decoder can operate.  When exchanging SDP messages, an offerer should
+   specify all possible combinations 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 adapt 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 are 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 a clock rate of both 8000 and
+   16000 in "a=rtpmap", but Modes 1 and 4 cannot be specified with one
+   having a clock rate of 8000.
+
+
+
+
+Hiwasaki & Ohmuro           Standards Track                    [Page 15]
+
+RFC 5686             RTP Payload Format for UEMCLIP         October 2009
+
+
+6.3.  Offer-Answer Model Considerations
+
+6.3.1.  Offer-Answer Guidelines
+
+   The procedures related to exchanging SDP messages MUST follow
+   [RFC3264].  The following is a detailed list on the semantics of
+   using the UEMCLIP payload format in an offer-answer exchange.
+
+   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 select a single UEMCLIP payload type and answer
+      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.  This means
+      that there is a symmetry assumption on sent and received streams,
+      and the offerer MUST NOT send in modes that it does not offer.
+
+   o  In an offering/answering SDP, any fmtp parameters that are not
+      known MUST be ignored.  If any unknown/undefined parameters should
+      be offered, an answerer MUST delete the entry from the answer
+      message.
+
+   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 the
+      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           Standards Track                    [Page 16]
+
+RFC 5686             RTP Payload Format for UEMCLIP         October 2009
+
+
+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 could be:
+
+     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
+
+
+
+
+
+Hiwasaki & Ohmuro           Standards Track                    [Page 17]
+
+RFC 5686             RTP Payload Format for UEMCLIP         October 2009
+
+
+   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
+   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-ms 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.
+
+
+
+
+
+
+
+
+
+
+Hiwasaki & Ohmuro           Standards Track                    [Page 18]
+
+RFC 5686             RTP Payload Format for UEMCLIP         October 2009
+
+
+     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).
+
+7.  Security Considerations
+
+   RTP packets using the payload format defined in this specification
+   are subject to the security considerations discussed in the RTP
+   specification [RFC3550] and any appropriate profiles.  This implies
+   that confidentiality of the media streams is achieved by encryption
+   unless the applicable profile specifies 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, the UEMCLIP covered in this
+   document do not exhibit any significant non-uniformity.
+
+   Another potential threat is 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 not point to
+   the right sub-layer, and they may force reading beyond the bitstream
+   boundaries.  It is advised that a decoder implementation reject
+   layers of such indices.
+
+8.  IANA Considerations
+
+   One new media subtype (audio/UEMCLIP) has been registered by IANA.
+   For details, see Section 6.1.
+
+9.  References
+
+9.1.  Normative References
+
+   [ITU-T-G.711]
+              International Telecommunications Union, "Pulse code
+              modulation (PCM) of voice frequencies", ITU-
+              T Recommendation G.711, November 1988.
+
+
+
+
+Hiwasaki & Ohmuro           Standards Track                    [Page 19]
+
+RFC 5686             RTP Payload Format for UEMCLIP         October 2009
+
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC3264]  Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
+              with Session Description Protocol (SDP)", RFC 3264,
+              June 2002.
+
+   [RFC3550]  Schulzrinne, H., Casner, S., Frederick, R., and V.
+              Jacobson, "RTP: A Transport Protocol for Real-Time
+              Applications", STD 64, RFC 3550, July 2003.
+
+   [RFC3551]  Schulzrinne, H. and S. Casner, "RTP Profile for Audio and
+              Video Conferences with Minimal Control", STD 65, RFC 3551,
+              July 2003.
+
+   [RFC4288]  Freed, N. and J. Klensin, "Media Type Specifications and
+              Registration Procedures", BCP 13, RFC 4288, December 2005.
+
+   [RFC4566]  Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
+              Description Protocol", RFC 4566, July 2006.
+
+   [RFC4855]  Casner, S., "Media Type Registration of RTP Payload
+              Formats", RFC 4855, February 2007.
+
+   [RFC4856]  Casner, S., "Media Type Registration of Payload Formats in
+              the RTP Profile for Audio and Video Conferences",
+              RFC 4856, February 2007.
+
+   [RFC5117]  Westerlund, M. and S. Wenger, "RTP Topologies", RFC 5117,
+              January 2008.
+
+9.2.  Informative References
+
+   [ITU-T-G.711Appendix1]
+              International Telecommunications Union, "Pulse code
+              modulation (PCM) of voice frequencies, Appendix I: A high
+              quality low-complexity algorithm for packet loss
+              concealment with G.711", ITU-T Recommendation G.711
+              Appendix I, September 1999.
+
+
+
+
+
+
+
+
+
+
+
+
+Hiwasaki & Ohmuro           Standards Track                    [Page 20]
+
+RFC 5686             RTP Payload Format for UEMCLIP         October 2009
+
+
+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           Standards Track                    [Page 21]
+