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



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.

この文書では、低遅延IP通信(UEMCLIP)用μ則埋め込みコーダ、ITU-T G.711の拡張音声コーデックのRTPペイロードフォーマットを記述する。ビットストリームは、このように狭帯域と広帯域音声の間に便利なトランスコーディング操作を提供し、また、PCMUとして知られている組み込みのu-lawのビットストリームと拡張性の高い構造を有しています。

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.

この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD 1)の最新版を参照してください。このメモの配布は無制限です。

Copyright Notice


Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.

著作権(C)2009 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents ( 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.

この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント(に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクション4.eに記載されており、BSDライセンスで説明したように、保証なしで提供されているよう簡体BSDライセンスのテキストを含める必要があり、この文書から抽出されました。

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 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
1. はじめに

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.

この文書では、リアルタイムトランスポートプロトコル(RTP)[RFC3550]を用いて音声(低遅延IP通信のためにMU-法則埋め込まコーダー)UEMCLIPでエンコードされた送信用のペイロード形式を指定します。 UEMCLIPは、U-法のITU-T G.711 [ITU-TG.711]を強化して、非常に小さなメディアトランスコーディングの負荷を達成しながら、それは今後の広帯域通信環境へのスムーズな移行のための市場を支援するために設計された独自のコーデックですG.711の実装が必須である既存の端末、。

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 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.

背景とメディアフォーマットの基本的な考え方は、ペイロードフォーマットの詳細はセクション4に記載されている第3 G.711とトランスコーディングの問題に記載されている第2節に記載され、および輻輳制御のための考察は、セクションに記載されてい第6 5.は、UEMCLIP RTPペイロードフォーマットおよびセッション記述プロトコル用のメディアタイプ登録のためのペイロード・フォーマット・パラメータ(SDP)のマッピングが提供されます。セキュリティ上の考慮事項とIANAの考慮事項は、それぞれ、第7及び第8節で対処されています。

1.1. Terminology
1.1. 用語

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

この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[RFC2119]に記載されているように解釈されます。

2. Media Format Background
2. Media形式の背景

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.

UEMCLIPは、そうでなければPCMU [RFC4856]として知られているU-法ITU-T G.711の拡張バージョンです。これは、インターネットプロトコル(VoIP)アプリケーション、ボイスオーバーを対象に、その主な目的は、G.711を搭載した既存の端末と高い相互運用性があり、徐々に広帯域通信を使用してに移行する市場を刺激するために、広帯域通信プラットフォームを提供することを目的とします。 [RFC5117]で定義されるように広く展開されているマルチポイント会議システムでは、パケットは、通常、RTCP-終端(RTP制御プロトコル)マイコン、「TOPO-RTCP-終端-MCU」を経ます。 G.711のビットストリームがビットストリームに埋め込まれているので、高価なメディアトランスコーディングは、この場合には避けることができます。

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 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.

これらのサブ層に基づいて、ここで、表2に示すようにUEMCLIPコーデックは4つのモードで動作し、「CH」は、チャネルの数であり、「FS」はkHzのサンプリング周波数です。現在のバージョンは、シングルチャネル動作をサポートし、マルチチャンネル機能を持​​つ将来の拡張があるかもしれないことに留意すべきです。不在モード2および5は32 kHzのサンプリングモードへの可能な将来の拡張のために予約されています。モード定義が成長すると予想されるので、この表に定義されていない任意の他のモードは、互換性と相互運用性の理由のために使用してはいけません。

   | 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


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.

UEMCLIPビットストリームは、スケーラブルな構造を有しています。従って、それの一部をデコードして信号を再構成することが可能です。 UEMCLIPフレームは、図2に示すように、1つまたは複数(3個まで)のサブ層(SLS)、続いてメインヘッダ(MH)から構成されています。

                            |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.


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
3.1. RTPヘッダーの使用

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:

各RTPパケットは、[RFC3550]で説明したように、固定されたRTPヘッダで始まります。 UEMCLIPストリームのために特別に使用されるRTPの固定ヘッダの次のフィールドが強調されます。

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.

タイムスタンプ:これは、RTPデータパケットにおける第1の音声信号サンプルのサンプリングの瞬間をコードします。 UEMCLIPストリームは、RTPタイムスタンプは、クロックのいずれか8000または16000(Hz)とに基づいて進行しなければなりません。オーディオサンプリングレートがセッション中に変更することができる場合には、RTPタイムスタンプレートは、モードの範囲で与えられた最大速度(Hz単位)(セクション6.2.1を参照)に等しくなければなりません。これはUEMCLIPペイロードタイプのためのRTPタイムスタンプ率はセッション中に変更しないでなければならないことを意味します。例えば、16 kHzのオーディオサンプリングモードへの移行が許可されている8kHzの音声サンプリングとUEMCLIPストリームに対して、RTPタイムスタンプは、常に、16 kHzのクロックレートを使用して前進しなければなりません。固定オーディオサンプリングモードの場合、RTPタイムスタンプレートは、サンプリングレートに応じて、いずれか8、または16 kHzであるべきです。

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.

マーカビット:コーデックは、不連続送信(DTX、または無音圧縮)を持つアプリケーションに使用される場合、パケットが連続的に送信されていない時に無音期間の後の最初のパケットが1に設定されたRTPデータヘッダ内のマーカビットを有しているべきです。他のすべてのパケットでマーカービットはゼロでなければなりません。 DTXのないアプリケーションはゼロにマーカービットを設定しなければなりません。

3.2. Multiple Frames in an RTP Packet
3.2. RTPパケットに複数のフレーム

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

RTPパケット内に含まれるフレームの数は、アプリケーションと一致することが推奨されます。 UEMCLIPは遅延が品質に大きな影響を有するテレフォニーアプリケーションのために設計されているため、より低遅延のためのパケットごと次いで少ないフレームが、好ましいです。

3.3. Payload Data
3.3. ペイロードデータ

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


3.3.1. Main Header
3.3.1. メインヘッダ

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 for details of the fields.


Packet-loss Concealment information (PC): 40 bits


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

パケット損失隠蔽(PLC)情報フィールド。項を参照してください。 Mixing Information Field。情報フィールドをミキシング
                            0 1 2 3 4 5 6 7
                           |C|R|V|   PW1   |
                           |1|1|1|         |

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. 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.

MCUの動作のために使用されるように設計され、現在のフレームの音声アクティビティ検出フラグ。 「1」であるこのフラグは、フレームがアクティブ(音声)セグメントであることを示し、「0」は、それが非アクティブ(非音声)または無音区間であることを示しています。このフラグは、具体的に情報を混合するために設計されています。このフラグに基づくDTX判断は推奨されません。

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.

現在のフレームの信号パワーコード。コードは "A層" の平方(RMS)の平均平方根を計算し、これは[ITU-T-G.711]をG.711のU-法則を用いてRMS符号化することによって得られます。 Rとして符号化されたRMSを表す、次にPW1はPW1 =((〜R)>> 2)&0x1Fの、 "〜"、 ">>"、 "&" は1の補数演算、右シフト、およびビット単位であるANDによって得られます演算子、それぞれ。 PLC Information Field。 PLC情報フィールド
    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)


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

V / UVフラグ#1(U1):1ビット

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.

現在のフレームの有声音/無声音信号インジケータ。 「0」フレームは有声信号セグメント、および「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. To obtain the pitch lag, any pitch estimation method can be used, such as the one used in G.711 Appendix I [Appendix I: A high quality low-complexity algorithm for packet loss concealment with G.711"">ITU-T-G.711Appendix1].

現在のフレームのピッチコード。実際のピッチラグは、8 kHzのサンプリングレートでP1 + 20サンプルとして算出されます。ピッチラグは、「0x65」および「から0x7F」が使用されていない間の範囲20 <=ピッチ長<= 120コードでなければなりません。 G.711のパケット損失隠蔽のための高品質低複雑性アルゴリズム「」> ITU-TG:ピッチラグを得るために、任意のピッチ推定方法は、G.711付録I [付録Iで使用されるものとして、使用することができます.711Appendix1]。

V/UV flag #2 (U2): 1 bit

V / UVフラグ#2(U2):1ビット

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.

オフセットフレームの有声音/無声音信号インジケータ。 「0」フレームは有声信号セグメント、および「1」であることを示している、このフラグは、無声信号セグメントであることを示しています。オフセット値は、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
3.3.2. サブレイヤ

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.

周波数番号を示します。 「0」は、層が、ベース周波数帯であることを意味し、より高い数の層がそれぞれの周波数帯域であることを意味します。詳細は表3に示されています。

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.

質の層の数を示します。 「0」は、層が、ベース層であることを意味し、より高い数の層がそれぞれの品質層であることを意味します。詳細は表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

レイヤのデータ(LD):SB * 8ビット

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.


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.

UEMCLIPからU-lawのG.711へのトランスコーディングは、適切なサブ層を見つけることによって容易に行うことができます。フレーム内で、トランスコーダは、SB * 8ビットの大きさを有する層「0×00」のインデックス、およびその後のLD(UEMCLIPは、このように20ミリ秒のフレームを有し、= 160 SB)であると副層になるはず実際のG.711ビットストリームデータ。トランスコーダは、常にコア層は右メインヘッダの後に配置されることを期待してはならないことに留意すべきです。

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:

一方、G.711からUEMCLIPへのトランスコードは完全に簡単ではありません。エンハンスメント・サブレイヤを生成する手段がないため、G.711ビットストリームのみUEMCLIPモード0ビットストリームに変換することができます。元のG.711ビットストリームを則で符号化されている場合は、第一のコア層になるようにU字法則に変換されなければなりません。 UEMCLIPフレームサイズが20ミリ秒であるため、U-法則エンコードG.711ビットストリームは、コア層になるように160サンプルのチャンクでなければなりません。メインヘッダの内容については、UEMCLIPエンコーダが使用できない場合、それはこれらのガイドラインに従うべきです。

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.

O MH内の予約ビット(R3にR1)をそれぞれのデフォルト値に設定されています。

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

RTPデータを転送するための一般的な輻輳制御の考慮もRTP [RFC3550]だけでなく、オーディオビジュアルのプロフィールのような任意の適用可能なRTPプロファイル(AVP)[RFC3551]の上にUEMCLIPに適用されます。

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

UEMCLIPビットストリームの帯域幅は、より低いビットレートのモードに変更することによって低減することができます。 UEMCLIPの埋め込み層構造は、ダイナミックモードが変化した場合に、輻輳を制御するのに役立つことができる(セクション6.2.1を参照)が使用可能であり、セクション6.3で与えられるモードの範囲が提供アンサーネゴシエーションにより得られます。ビットレートがRTPトランスレータやミキサー[RFC3550]に変更されたとき、これは、適切なRTCP処理を含むことに留意すべきです。

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.

各RTPペイロードに複数のフレームを充填するパケット損失に対する増加遅延および減少エラー耐性を犠牲にして、IP / UDP / RTPヘッダから送信されたパケットの数、したがってオーバーヘッドを低減することができます。遅延の増加が減少した品質を意味するので、それは注意して扱われるべきです。

6. Payload Format Parameters
6.1. Media Type Registration
6.1. メディアタイプ登録

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.

レート:サンプリングレートを定義し、それは詳細についてはRFC 5686(このRFC)のどちらか8000または16000を参照してください6.2.1項「モードの​​指定」でなければなりません。

Optional parameters:


ptime: See RFC 4566 [RFC4566].

PTIME:RFC 4566 [RFC4566]を参照してください。

maxptime: See RFC 4566 [RFC4566].

maxptime: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.

モード:セッション中に動的に変更モードの範囲を示します。可能な値はサポートされているモード設定からモードのコンマ区切りのリストである:一つのモードを指定した場合は0、1、3、および4は、モードがセッション中に変更されてはならないことを意味します。指定しない場合、特異モードに伝送デフォルトは、詳細はRFC 5686(このRFC)の表4を参照のセクション6.2.1「モード指定」で指定されるように。

Encoding considerations: This media type is framed and contains binary data. See Section 4.8 of RFC 4288.

エンコードの考慮事項:このメディアタイプは、フレームとバイナリデータが含まれています。 RFC 4288のセクション4.8を参照してください。

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

セキュリティに関する考慮事項:RFC 5686のセクション7「セキュリティに関する考慮事項」(この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).

相互運用性の考慮:このメディアは容易にU-法則でエンコードされたITU-T G.711にトランスコードすることができます。 RFC 5686(このRFC)の第4節 "UEMCLIPとG.711の間のトランスコーディング" を参照してください。

Published specification: RFC 5686 (this RFC)

公開された仕様:RFC 5686(この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 <>

人とEメールアドレスは、詳細のために連絡する:祐介Hiwasaki <>

Author: Yusuke Hiwasaki

あうてょr: ゆすけ ひわさき

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


6.2. Mapping to SDP Parameters
6.2. SDPパラメータへのマッピング

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

次のようにメディアタイプオーディオ/ UEMCLIPは、セッション記述プロトコル(SDP)内のフィールドに[RFC4566]をマッピングされます。

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

メディア名:SDPの「M =」の行は、オーディオでなければなりません。

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

名前エンコード:登録メディアサブタイプ名は「A = rtpmap」行のために使用されるべきです。

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.

サンプリング周波数:モードの「a = rtpmap」で指定された、クロック・レート(サンプリング周波数)に応じて、詳細については表2を参照のセクション6.2.1で定義されたものの中から選択しなければなりません。

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".

パケット時間:任意UEMCLIPのフレーム長は、従って、「A = PTIME」の引数が「20」の倍数でなければならず、20ミリ秒です。 「20」:SDPに記載されていない場合には、それはまた、最小サイズをデフォルトにする必要があります。

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 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).

UMECLIP特定:UEMCLIPに固有の説明は、フォーマット仕様のパラメータ(「A =のfmtp」)で定義されています。 、および任意の属性(値)が存在する場合、それは「=」で定義する必要があり、「」各パラメータを用いて分離しなければなりません。互換性の理由から、任意のアプリケーション/端末は、それが理解していないすべてのパラメータを無視しなければなりません。これは、将来の拡張に追加パラメータを用いて上位互換性を確保することです。モードの指定は、(6.2.1項を参照)、ここでなされるべきです。

6.2.1. Mode Specification
6.2.1. モードの仕様

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.

UEMCLIPコーデックモード(ビットレート)の数で動作することができるので、エンコーダまたはデコーダが動作可能なモードの範囲を指定することが望ましいです。 SDPメッセージを交換する場合、提供者は「」カンマで区切られ、「A =のfmtp」の行では、「モード=」の引数として、モード番号のすべての可能な組み合わせを指定する必要があります。複数のモードを指定する場合には、それらは、降順の優先度順に表示されます。

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.

「モード」の引数としてペイロードタイプで指定できるモードの数は、クロックレートの組み合わせ及びオーディオチャネルの数によって制限されます。 SDPは、サンプリング周波数及びオーディオチャネルの数の組み合わせにペイロードタイプに結合するためです。表4は、クロック・レートで起因する選択可能なモード番号を提供します。モードの仕様が全く与えられていない場合には、ペイロードタイプは、この表で指定されたデフォルト値を使用して、単一モードをデフォルトとしなければなりません。

        | 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.

より大きなサンプリング周波数(FS)と帰属モードが「A = rtpmap」で指定されたより小さなクロック・レートに関連して使用されていないことに留意すべきです。これは、モード0及び3の「a = rtpmap」に8000と16000の両方のクロック・レートを有するペイロードタイプに指定することができるが、モード1および4は8000のクロックレートを有するものと指定することはできないことを意味します。

6.3. Offer-Answer Model Considerations
6.3. オファー回答モデルの考慮事項
6.3.1. Offer-Answer Guidelines
6.3.1. オファー回答ガイドライン

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 UEMCLIPペイロードタイプでは、回答者は、提供されたもののサブセットのような適切なモード番号(複数可)をバック答えなければなりません。これは送信され、受信されたストリーム上の対称性の仮定があることを意味し、オファー側はそれを提供しないモードで送ってはいけません。

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 SDPメッセージの受信機は、指定されたペイロードタイプとモードを使用しなければなりません。モードの指定が欠落している場合、すなわち、モードが全く指定されていない、セッションは、セッション中にモードを変更することなく、1つのモードをデフォルトとしなければなりません。この場合、デフォルトモード値は、表4に示すように、サンプリング周波数及びチャネルの数に基づいて使用されなければなりません。この表にはモードの仕様が存在しない場合にのみ、見上げなければなりません。このように、オファー側/アンサーは、モードの指定のリストにない場合、デフォルトモードは常に利用可能であると仮定してはいけません。

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.


6.3.2. Examples
6.3.2. 例

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 s=- c=IN IP4 t=0 0 m=audio 5004 RTP/AVP 96 a=rtpmap:96 UEMCLIP/16000/1 a=fmtp:96 mode=4,1,3,0

V = 0 0 =ジョン51050101 51050101 IN IP4 S = - C = IN IP4 T = 0、M =オーディオ5004 RTP / AVP 96 = rtpmap:96 UEMCLIP / 1分の16000 =のfmtp:96モード= 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 s=- c=IN IP4 t=0 0 m=audio 5004 RTP/AVP 96 a=rtpmap:96 UEMCLIP/16000/1 a=fmtp:96 mode=1,0

V = 0 0 =レナ549947322 549947322 IN IP4 S = - C = IN IP4 T = 0、M =オーディオ5004 RTP / AVP 96 = rtpmap:96 UEMCLIP / 1分の16000 =のfmtp:96モード= 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 s=- c=IN IP4 t=0 0 m=audio 5004 RTP/AVP 96 a=rtpmap:96 UEMCLIP/16000/1 a=fmtp:96 mode=1

V = 0 0 =レナ549947322 549947322 IN IP4 S = - C = IN IP4 T = 0、M =オーディオ5004 RTP / AVP 96 = rtpmap:96 UEMCLIP / 1分の16000 =のfmtp:96モード= 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 somewhat look like:


v=0 o=john 51050101 51050101 IN IP4 s=- c=IN IP4 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

V = 0 0 =ジョン51050101 51050101 IN IP4 S = - C = IN IP4 T = 0、M =オーディオ5004 RTP / AVP 96 97 = rtpmap:96 UEMCLIP / 1分の16000 =のfmtp:96モード= 4 A = rtpmap:97 UEMCLIP / 1分の16000 A =のfmtp:97モード= 1

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


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

V = 0 0 =レナ549947322 549947322 IN IP4 S = - C = IN IP4 T = 0、M =オーディオ5004 RTP / AVP 97 = rtpmap:97 UEMCLIP / 1分の16000 =のfmtp:97モード= 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.


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

V = 0 0 =浩輔2890844730 2890844730 IN IP4 S = - C = IN IP4 T = 0、M =オーディオ5004 RTP / AVP 96 = PTIME:60 = rtpmap:96 UEMCLIP / 1分の16000

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
8. IANAの考慮事項

One new media subtype (audio/UEMCLIP) has been registered by IANA. For details, see Section 6.1.

一つの新しいメディアサブタイプ(オーディオ/ UEMCLIP)はIANAによって登録されています。詳細については、6.1節を参照してください。

9. References
9.1. Normative References
9.1. 引用規格

[ITU-T-G.711] International Telecommunications Union, "Pulse code modulation (PCM) of voice frequencies", ITU-T Recommendation G.711, November 1988.

[ITU-T G.711-]国際電気通信連合、 "パルス符号変調(PCM)音声周波数の"、ITU-T勧告G.711、1988年11月。

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

[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。

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

[RFC3264]ローゼンバーグ、J.とH. Schulzrinneと、RFC 3264、2002年6月 "セッション記述プロトコル(SDP)とのオファー/アンサーモデル"。

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

[RFC3550] Schulzrinneと、H.、Casner、S.、フレデリック、R.、およびV.ヤコブソン、 "RTP:リアルタイムアプリケーションのためのトランスポートプロトコル"、STD 64、RFC 3550、2003年7月。

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

[RFC3551] Schulzrinneと、H.とS. Casner、 "最小量のコントロールがあるオーディオとビデオ会議システムのためのRTPプロフィール"、STD 65、RFC 3551、2003年7月。

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

[RFC4288]解放され、N.とJ. Klensin、 "メディアタイプの仕様と登録手順"、BCP 13、RFC 4288、2005年12月。

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

[RFC4566]ハンドリー、M.、ヤコブソン、V.、およびC.パーキンス、 "SDP:セッション記述プロトコル"、RFC 4566、2006年7月。

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

[RFC4855] Casner、S.、RFC 4855、2007年2月 "RTPペイロード形式のメディアタイプ登録"。

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

[RFC4856] Casner、S.、「オーディオおよびビデオ会議用RTPプロファイルにおけるペイロード形式のメディアタイプ登録」、RFC 4856、2007年2月。

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

[RFC5117]ウェスター、M.とS.ベンゲル監督、 "RTPトポロジ"、RFC 5117、2008年1月。

9.2. Informative References
9.2. 参考文献

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


Authors' Addresses


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

ゆすけ ひわさき んっt こrぽらちおん 3ー9ー11 みどりーちょ、 むさしのーし ときょ 180ー8585 じゃぱん

Phone: +81(422)59-4815 EMail:

電話:+81(422)59から4815 Eメール

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

ひとし おhむろ んっt こrぽらちおん 3ー9ー11 みどりーちょ、 むさしのーし ときょ 180ー8585 じゃぱん

Phone: +81(422)59-2151 EMail:

電話:+81(422)59から2151 Eメール