[要約] RFC 5686は、低遅延IP通信のためのmU-law UEMCLIP音声コーデックのRTPペイロード形式に関するものです。このRFCの目的は、UEMCLIP音声コーデックの特性と要件を定義し、そのRTPペイロード形式を提供することです。
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
低遅延IP通信（UEMCLIP）音声コーデック用のMU-LAW埋め込みコーデックのRTPペイロード形式
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.
このドキュメントでは、ITU-T G.711の強化された音声コーデックである低遅延IP通信（UEMCLIP）のMU-LAW埋め込みコーダーのRTPペイロード形式について説明します。BitStreamには、PCMUとも呼ばれるU-Law BitStreamが埋め込まれたスケーラブルな構造があるため、狭帯域とワイドバンド音声の間に便利なトランスコーディング操作が提供されます。
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.
Copyright（c）2009 IETF Trustおよび文書著者として特定された人。全著作権所有。
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.
このドキュメントは、BCP 78およびIETFドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション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.
このドキュメントには、2008年11月10日までに公開または公開されたIETFドキュメントまたはIETFの寄付からの資料が含まれている場合があります。IETF標準プロセスの外。そのような資料の著作権を制御する人から適切なライセンスを取得せずに、このドキュメントはIETF標準プロセスの外側に変更されない場合があり、その派生作業は、ITF標準プロセスの外側で作成されない場合があります。RFCとしての出版またはそれを英語以外の言語に翻訳するため。
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
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]を使用して、UEMCLIPエンコード（低遅延IP通信用のMU-LAW Embedded Coder）スピーチを送信するためのペイロード形式を指定します。UemClipは、U-Law ITU-T G.711 [ITU-T-G.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.
一般的に言えば、コーデックはSDP交換を使用して交渉され、変更されることに注意する必要があります。また、[RFC3550]は、メディアトランスコーディングがノードで行われない場合がある一般的なRTPミキサーと翻訳モデルを定義します。これらの場合、組み込み構造の設計概念は役に立ちません。ただし、メディアとRTCPパケット[RFC5117]を終了する一般的に展開されているマルチポイント制御ユニット（MCU）、および狭帯域とワイドバンド端子が共存する場合、コストの高いトランスコーディングが一般的に展開されているマルチポイント制御ユニット（MCU）で避けられない場合があります。この埋め込まれたビットストリーム構造は、メディアのトランスコーディングを単純なビットストリームの切り捨てに減らすことができます。
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.
メディア形式の背景と基本的なアイデアについては、セクション2で説明します。ペイロード形式の詳細については、セクション3に記載されています。G.711のトランスコーディングの問題についてはセクション4で説明し、輻輳制御の考慮事項はセクションにあります。5.セクション6では、UEMCLIP RTPペイロードフォーマットおよびセッション説明プロトコル（SDP）マッピングのメディアタイプ登録のペイロード形式パラメーターが提供されます。セキュリティ上の考慮事項とIANAの考慮事項は、それぞれセクション7とセクション8で扱われます。
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].
「必須」、「そうしない」、「必須」、「必要」、「しない」、「そうしない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[RFC2119]に記載されているように解釈される。
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-Law ITU-T G.711の拡張バージョンです。これは、Voice over Internet Protocol（VoIP）アプリケーションを対象としており、その主な目標は、G.711を装備した既存の端子と非常に相互運用可能な広帯域通信プラットフォームを提供し、市場を刺激して広帯域通信の使用に徐々に移行することです。広く展開されているマルチポイント会議システムでは、パケットは通常、[RFC5117]で定義されているように、RTCPターミネート（RTP制御プロトコル）MCU、「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:
スケーラブルな性質のため、UemClipビットストリームには多くのサブビットストリーム（サブレイヤー）があります。適切なサブ層を選択することにより、コーデックは次の要件に適応できます。
o Sampling frequency,
o サンプリング周波数、
o Number of channels,
o チャネルの数、
o Speech quality, and
o 音声品質、および
o Bit-rate.
o ビットレート。
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.
UEMCLIPコーデックは20 msフレームで動作し、表1に示すように3つのサブコダーが含まれています。コア層は64 kbit/sのU-Law G.711です。 - それぞれ16 kbit/sのレート。
+-------+---------------------+----------+--------------------------+
| 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
表1：サブ層の説明
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.
これらのサブ層に基づいて、UEMCLIPコーデックは表2に示すように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
表2：モードの説明
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.
UEMCLIP BitStreamには、レイヤーデータとは別に内部ヘッダーと他のサイド情報が含まれています。これにより、上記の表に示されているレイヤーの合計よりも合計ビット率が大きくなります。内部ヘッダーと補助情報の詳細については、セクション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.
サンプリング周波数とチャネルの数を定義しても、特異なモードにはなりません。つまり、同じサンプリング頻度またはチャネルの数に複数のモードが存在する可能性があります。サポートされているモードは、実装間で異なります。したがって、送信者と受信機は、送信に使用するモードをネゴシエートする必要があります。
As an RTP payload, the UEMCLIP bitstream can contain one or more frames as shown in Figure 1.
RTPペイロードとして、UEMCLIPビットストリームには、図1に示すように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
図1：RTPペイロード形式
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 BitStreamにはスケーラブルな構造があります。したがって、信号の一部をデコードすることにより、信号を再構築することができます。UemClipフレームは、図2に示すように、メインヘッダー（MH）で構成され、1つ以上のサブレイヤー（SLS）が続きます。
+--+-------+//-+
|MH| SL #1 |...|
+--+-------+//-+
Figure 2: A UEMCLIP Frame (Bitstream Format)
図2：UEMCLIPフレーム（ビットストリーム形式）
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.
サブ層として、コア層、つまり「レイヤーA」は常に含まれている必要があります。コア層の位置は、MHフィールドに直接従うことができる場合とそうでない場合があることに注意してください。デコーダーは、サブレイヤーの順序が任意であるため、適切なデコードのレイヤーインデックスを常に参照する必要があります。
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.
UemClip BitStreamには、モードとサンプリング周波数（FS）の次の情報は明示的に含まれていません。前に説明したように、この情報は、たとえばSDPを使用して接続を確立する際に交換する必要があります。
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.
ペイロードタイプ：このパケット形式のRTPペイロードタイプの割り当ては、このドキュメントの範囲外です。ただし、ダイナミックレンジのペイロードタイプが割り当てられることが予想されます。
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データパケットの最初の音声信号サンプルのサンプリングインスタントがエンコードされます。UemClipストリームの場合、RTPタイムスタンプは、8000または16000（Hz）の時計に基づいて前進する必要があります。セッション中にオーディオサンプリングレートが変更される場合がある場合、RTPタイムスタンプレートは、モード範囲で指定された最大レート（Hz）に等しくなければなりません（セクション6.2.1を参照）。これは、UEMCLIPペイロードタイプのRTPタイムスタンプレートがセッション中に変更されてはならないことを意味します。たとえば、16 kHzのオーディオサンプリングモードへの移行が許可されている8 kHzオーディオサンプリングを備えたUemClipストリームの場合、RTPタイムスタンプは16 kHzクロックレートを使用して常に前進する必要があります。固定されたオーディオサンプリングモードの場合、RTPタイムスタンプレートは、サンプリングレートに応じて8 kHzまたは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、または沈黙圧縮）のアプリケーションに使用される場合、パケットが連続して送信されていない沈黙期間後の最初のパケットは、RTPデータヘッダーのマーカービットを1に設定する必要があります。他のすべてのパケットのマーカービットはゼロでなければなりません。DTXのないアプリケーションは、マーカービットをゼロに設定する必要があります。
More than one UEMCLIP frame may be included in a single RTP packet by a sender. However, senders have the following additional restrictions:
送信者による単一のRTPパケットには、複数のUEMCLIPフレームが含まれる場合があります。ただし、送信者には次の追加の制限があります。
o A single RTP packet SHOULD NOT include more UEMCLIP frames than will fit in the path MTU.
o 単一のRTPパケットには、パスMTUに収まるよりも多くのUEMCLIPフレームを含めるべきではありません。
o All frames contained in a single RTP packet MUST be of the same mode.
o 単一のRTPパケットに含まれるすべてのフレームは、同じモードでなければなりません。
o Frames MUST NOT be split between RTP packets.
o フレームをRTPパケット間で分割してはなりません。
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は、遅延が品質に大きな影響を与えるテレフォニーアプリケーション向けに設計されているため、遅延を低くするためにパケットあたりのフレームが少なくなることが望ましいです。
In a UEMCLIP bitstream, all numbers are encoded in a network byte order.
UemClip BitStreamでは、すべての数値がネットワークバイト順序でエンコードされます。
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.
メインヘッダー（MH）はフレームの上部に配置され、6バイトのサイズがあります。メインヘッダーの内容を図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)
図3：Uemclipメインヘッダー形式（MH）
Mixing information (MX): 8 bits
ミキシング情報（MX）：8ビット
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.
情報フィールドの混合。このフィールドは、Topo-RTCPターミネート-MCUがこれらのフィールドを解釈するために使用される場合にのみ関連します。フィールドの詳細については、セクション3.3.1.1を参照してください。
Packet-loss Concealment information (PC): 40 bits
パケット損失の隠蔽情報（PC）：40ビット
Packet-loss concealment (PLC) information field. See Section 3.3.1.2.
パケット損失の隠蔽（PLC）情報フィールド。セクション3.3.1.2を参照してください。
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|C|R|V| PW1 |
|1|1|1| |
+-+-+-+-+-+-+-+-+
Figure 4: Mixing Information Field (MX)
図4：情報フィールドの混合（MX）
Check bit #1 (C1): 1 bit
ビット＃1（c1）を確認する：1ビット
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).
V1およびPW1の有効フラグ。このビットは「1」であることは、両方のパラメーターが有効であることを示し、「0」はパラメーターを無視する必要があることを示します。これらのパラメーターのいずれかが無効である場合、このビットは「0」に設定する必要があります。このフラグは、主にUemClipを意識したTopo-RTCPターミネート-MCUを対象としています。このフラグは、G.711から上向きのトランスコーディングの場合、「0」に設定する必要があります（セクション4を参照）。
Reserved bit #1 (R1): 1 bit
予約ビット＃1（R1）：1ビット
This bit should be ignored. The default of this bit is 0.
このビットは無視する必要があります。このビットのデフォルトは0です。
VAD flag #1 (V1): 1 bit
Vad Flag＃1（V1）：1ビット
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
パワー＃1（PW1）：5ビット
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.
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)
図5：PLC情報フィールド（PC）
Check bit #2 (C2): 1 bit
ビット＃2（c2）を確認する：1ビット
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).
V2、K、U1、P1、U2、P2、およびPW2の有効フラグ。フラグが「1」の場合、これらのパラメーターがすべて有効であることを意味し、「0」はパラメーターを無視する必要があることを意味します。これらのパラメーターのいずれかが無効である場合、このビットは「0」に設定する必要があります。C1と同様に、G.711から上向きのトランスコーディングの場合、このフラグは「0」に設定する必要があります（セクション4を参照）。
Reserved bit #2 (R2): 2 bits
予約ビット＃2（R2）：2ビット
These bits should be ignored. The default of these bits are 0.
これらのビットは無視する必要があります。これらのビットのデフォルトは0です。
VAD flag #2 (V2): 1 bit
Vad Flag＃2（V2）：1ビット
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.
パケット損失の隠蔽に使用するように設計された現在のフレームの音声アクティビティ検出フラグ。これは、ミキシング情報のV1と同じではない場合があり、RTPヘッダーのマーカービットと同期しない場合があります。このフラグに基づくDTX判断は推奨されません。
Frame indicator (K): 4 bits
フレームインジケーター（k）：4ビット
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.
この値は、U2、P2、およびPW2のフレームオフセットを示しています。音声の品質を維持するために、音声機能パラメーターを別のフレームのPLC情報として運ぶことがより良いアイデアであるため、このフレームのオフセット値は、パラメーターを関連付けるフレームを提供します。値は「0」と「15」の範囲です。たとえば、現在のフレーム番号がnの場合、値kはu2、p2、およびpw2がn-kのフレームに関連付けられていることを示します。フレームインジケーターは、1つのUEMCLIPフレームが単一のRTPパケットに含まれている場合のRTPシーケンス番号の差に等しくなります。
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
ピッチラグ＃1（P1）：7ビット
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].
現在のフレームのピッチコード。実際のピッチラグは、8 kHzサンプリングレートのP1 20サンプルとして計算されます。ピッチラグは20 <=ピッチ長<= 120でなければなりません。「0x65」と「0x7F」の範囲のコードは使用されません。ピッチラグを取得するには、G.711付録I [ITU-T-G.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
ピッチラグ＃2（P2）：7ビット
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.
オフセットフレームのピッチコード。オフセット値はKとして定義されます。計算方法は、オフセットフレームの信号に基づいていることを除いて、「P1」と同一です。
Power #2 (PW2): 8 bits
パワー＃2（PW2）：8ビット
Signal power code of the offset frame. The offset value is defined as K.
オフセットフレームの信号電源コード。オフセット値はKとして定義されます。
Reserved bits #3 (R3): 8 bits
予約ビット＃3（R3）：8ビット
These bits should be ignored. The default of all bits are "0".
これらのビットは無視する必要があります。すべてのビットのデフォルトは「0」です。
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.
サブレイヤー（SL）は、図6に示すように、レイヤービットストリームが続くサブヘッダーです。サブヘッダーは、レイヤーの位置とバイト数を示します。
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)
図6：サブレイヤー形式（SL）
Channel index (CI): 2 bits
チャネルインデックス（CI）：2ビット
Indicates the channel number. For all modes given in Table 2, this should be "0". The detail is given in Table 3.
チャネル番号を示します。表2に示すすべてのモードについて、これは「0」でなければなりません。詳細を表3に示します。
Frequency index (FI): 2 bits
周波数インデックス（FI）：2ビット
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
品質指数（QI）：2ビット
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
予約＃4（R4）：2ビット
Not used (reserved). The default value is "0".
使用されていない（予約）。デフォルト値は「0」です。
Sub-layer Size (SB): 8 bits
サブ層サイズ（SB）：8ビット
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.
表1に示すすべてのレイヤーについて、レイヤーインデックスを表3に示します。
+-------+----+----+----+
| Layer | CI | FI | QI |
+-------+----+----+----+
| a | 0 | 0 | 0 |
| | | | |
| b | 0 | 0 | 1 |
| | | | |
| c | 0 | 1 | 0 |
+-------+----+----+----+
Table 3: Layer Indices
表3：層インデックス
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.
セクション2に示されているように、U-LAWエンコードG.711ビットストリーム（レイヤーA）はUEMCLIPビットストリームのコア層であり、常に埋め込まれています。これは、UemClip BitStreamからG.711へのメディアトランスコーディングでは、デコードと再エンコードの手順を実行する必要がないことを意味しますが、簡単な抽出で十分です。ただし、これは、メインヘッダー（MH）の補助情報を個別に割り当てる必要があるため、G.711からUemClipへのトランスコード、つまり逆の手順には適用されません。このメディアトランスコーディングは、[RFC5117]のMCU（Topo-RTCP-Termination-MCU）を終了するRTCPを使用したメディア翻訳者（Topo-Media-Translator）またはポイントツーマルチポイント、およびすべての要件に役立つことに注意する必要があります。申し込み。これは、この種のトランスコーディングデバイスがRTPメディアパケットとともにRTCPパケットを書き換える必要があることを意味します。
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へのトランスコーディングは、適切なサブレイヤーを見つけることで簡単に実行できます。フレーム内では、トランスコダーは「0x00」のレイヤーインデックスを持つサブレイヤーを探す必要があります。その後のLDは、SB*8ビットのサイズ（UEMCLIPのフレームが20 ms、SB = 160）です。実際の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 BitStreamがA-Lawでエンコードされている場合、まずU-Lawに変換してコアレイヤーになります。UemClipフレームサイズは20ミリ秒であるため、U-LawエンコードG.711ビットストリームは、コア層になるには160サンプルのチャンクでなければなりません。メインヘッダーの内容の場合、UEMCLIPエンコーダーが使用できない場合、次のガイドラインに従う必要があります。
o The check bits for mixing and PLC (C1 and C2) are set to 0.
o ミキシングとPLC（C1およびC2）のチェックビットは0に設定されています。
o The reserved bits (R1 to R3) in MH are set to respective default values.
o MHの予約ビット（R1〜R3）は、それぞれのデフォルト値に設定されています。
For the core layer (i.e., u-law G.711 bitstream), it should have the following sub-layer header:
コアレイヤー（つまり、U-Law G.711 BitStream）の場合、次のサブレイヤーヘッダーが必要です。
o All CI, FI, QI, and R4 MUST be 0.
o すべてのCI、FI、QI、およびR4は0でなければなりません。
o Sub-layer size (SB) MUST be 160 for a 20-ms frame.
o サブ層サイズ（SB）は、20 msフレームで160でなければなりません。
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]を介して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ヘッダーからのオーバーヘッドを減らすことができます。遅延の増加は品質の低下を意味するため、慎重に治療する必要があります。
This registration is done using the template defined in [RFC4288] and following [RFC4855].
この登録は、[RFC4288]および[RFC4855]で定義されたテンプレートを使用して行われます。
Media type name: audio
メディアタイプ名：オーディオ
Media subtype name: UEMCLIP
メディアサブタイプ名：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.
レート：サンプリングレートを定義し、8000または16000でなければなりません。詳細については、RFC 5686（このRFC）のセクション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。1つのモードのみが指定されている場合、セッション中にモードを変更してはならないことを意味します。指定されていない場合、モード伝送は表4に指定されているように単一モードにデフォルトです。詳細については、RFC 5686（このRFC）のセクション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（このRFC）のセクション7「セキュリティ上の考慮事項」を参照してください。
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-Lawエンコードの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.
使用法の制限：このメディアタイプはRTPフレーミングに依存するため、RTPを介した転送に対してのみ定義されます。
Person & email address to contact for further information:
Yusuke Hiwasaki <hiwasaki.yusuke@lab.ntt.co.jp>
Author: Yusuke Hiwasaki
著者：hiwasaki Yusuke
Change Controller: IETF Audio/Video Transport Working Group delegated from the IESG
Change Controller：IETFオーディオ/ビデオトランスポートワーキンググループIESGから委任
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.
エンコーディングパラメーター：これはオーディオストリームであるため、エンコードパラメーターはオーディオチャネルの数を示し、表2で定義されているものから選択されたものから「1」にデフォルトする必要があります。これはオプションです。
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のフレーム長は20ミリ秒です。したがって、「a = ptime」の引数は「20」の倍数でなければなりません。SDPにリストされていない場合、デフォルトで最小サイズの「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 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を参照）。
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 Codecはモード数（ビットレート）で動作できるため、エンコーダーまたはデコーダーが動作できるモードの範囲を指定することが望ましいです。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.
UemClipデコーダーは、任意のモードでビットストリームを受け入れる必要がありますが、実装はセッション中に動的モードの変更に適応できない場合があります。このため、アプリケーションは、1つの固定モードまたは動的に変更できる複数のモードで動作することを選択できます。モードを固定し、変更が許可されていない場合、これはペイロードタイプごとに単一モードを指定することで示すことができます。
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
表4：デフォルトモード
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.
「a = rtpmap」で指定されたより小さなクロックレートと組み合わせて、より大きなサンプリング周波数（FS）を伴う帰属モードは使用されないことに注意してください。つまり、モード0と3は、「a = rtpmap」で8000と16000の両方のクロックレートを持つペイロードタイプで指定できることを意味しますが、モード1と4は8000のクロックレートを持つものでは指定できません。
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.
SDPメッセージの交換に関連する手順は、[RFC3264]に従う必要があります。以下は、オファーアンスワーエクスチェンジでUEMCLIPペイロード形式を使用するセマンティクスに関する詳細なリストです。
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 オファーは、処理できるUEMCLIPペイロードタイプ、つまりサンプリング周波数、チャネル番号、およびFMTPパラメーターのすべての可能な組み合わせを優先順序で提供する必要があります。トランスミッション帯域幅が制限されている場合、制限に従って提供する必要があります。
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 複数のUEMCLIPペイロードタイプが提供される場合、Answererが単一のUEMCLIPペイロードタイプを選択して返信することをお勧めします。
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 提供/応答SDPでは、知られていないFMTPパラメーターは無視する必要があります。不明/未定義のパラメーターを提供する必要がある場合、回答者は回答メッセージからエントリを削除する必要があります。
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.
o 提供された条件が応答者の機能に適合しない場合、当然、条件のいずれにも答えてはなりません。また、セッションは可能であれば再入力に進むことがあります。条件（モード）が決定される場合、提供者と応答者はこの条件で送信する必要があります。
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:
オファーがセッション中にモード（0,1,3、および4）を動的に切り替えることを望んでいることを示す場合、提供されるSDPの例は次のとおりです。
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:
応答者がモード1と0でのみ動作できるが、セッション中にそれらのモードを動的に切り替えることができる場合、回答者はモード3と4のエントリを削除し、次のように回答する必要があります。
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.
その結果、両方ともモード1または0のいずれかで通信を開始し、セッション中にそれらのモードを動的に切り替えることができます。
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:
一方、応答者がモード1または0で通信できる場合、セッション中にモードを切り替えることができない場合、そのような回答の例は次のとおりです。
v=0
o=lena 549947322 549947322 IN IP4 anshost.example.org
s=-
c=IN IP4 anshost.example.org
t=0 0
m=audio 5004 RTP/AVP 96
a=rtpmap:96 UEMCLIP/16000/1
a=fmtp:96 mode=1
As a result, both will start communicating in Mode 1. It should be noted that mode change during this session is not allowed because the answerer responded with a single mode, and answerer selected Mode 1 above Mode 0 according to the offered order.
その結果、両方ともモード1で通信を開始します。このセッション中のモード変更は、応答者が単一のモードで応答し、応答者がモード0を上記のモード0より上に選択した順序に従って選択したため、このセッション中に変更が許可されていないことに注意する必要があります。
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:
オファーがセッション中にモード変更を望まないが、モード4または1のビットストリームを受信できる場合、SDPはある程度見えるはずです。
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:
また、応答者がモード1で通信することを好む場合、回答は次のとおりです。
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.
回答に対して1つのUemClipペイロードタイプを選択することをお勧めします。
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.
「PTIME」属性は、目的のパケット化間隔を示すために使用されます。指定されていない場合、デフォルトは20になります。UemClipは20 msフレームを使用するため、20の倍数のPTIME値はパケットごとに複数のフレームを意味します。以下の例では、PTIMEは60に設定されています。これは、オファーが各パケットで3つのフレームを受け取ることを望んでいることを意味します。
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).
モード仕様が存在しない場合、デフォルトで固定モードになり、この場合はモード1（セクション6.2.1を参照）になります。
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.
この仕様で定義されたペイロード形式を使用したRTPパケットは、RTP仕様[RFC3550]および適切なプロファイルで説明されているセキュリティに関する考慮事項の対象となります。これは、該当するプロファイルが他の手段を指定しない限り、メディアストリームの機密性が暗号化によって達成されることを意味します。
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.
不均一なレシーバー末端計算負荷を備えた圧縮技術を使用したデータエンコードのデータには、潜在的なサービス拒否脅威が存在します。攻撃者は、デコードしてレシーバーの出力を過負荷にするために複雑なストリームに病理学的データグラムを挿入できます。ただし、このドキュメントで説明されているUemClipは、有意な不均一性を示しません。
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.
もう1つの潜在的な脅威は、違法な層指数またはバイト番号によるメモリ攻撃です。デコーダーの実装者は、示された数値が破損している可能性があり、適切なサブ層を指していないことを常に認識している必要があり、ビットストリームの境界を越えて読みを強制する可能性があります。デコーダーの実装は、そのようなインデックスのレイヤーを拒否することをお勧めします。
One new media subtype (audio/UEMCLIP) has been registered by IANA. For details, see Section 6.1.
1つの新しいメディアサブタイプ（Audio/UemClip）がIANAによって登録されています。詳細については、セクション6.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] International Telecommunications Union、「音声周波数のパルスコード変調（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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、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] Rosenberg、J。およびH. Schulzrinne、「セッション説明プロトコル（SDP）のオファー/回答モデル」、RFC 3264、2002年6月。
[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.、Frederick、R。、およびV. Jacobson、「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] Freed、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] Handley、M.、Jacobson、V。、およびC. Perkins、「SDP：セッション説明プロトコル」、RFC 4566、2006年7月。
[RFC4855] Casner, S., "Media Type Registration of RTP Payload Formats", RFC 4855, February 2007.
[RFC4855] Casner、S。、「RTPペイロードフォーマットのメディアタイプ登録」、RFC 4855、2007年2月。
[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] Westerlund、M。およびS. Wenger、「RTP Topologies」、RFC 5117、2008年1月。
[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.
[ITU-T-G.711Appendix1] International Telecommunications Union、「音声周波数のパルスコード変調（PCM）、付録I：G.711とのパケット損失の隠蔽のための高品質の低複雑さアルゴリズム」、ITU-T推奨G.711付録I、1999年9月。
Authors' Addresses
著者のアドレス
Yusuke Hiwasaki NTT Corporation 3-9-11 Midori-cho, Musashino-shi Tokyo 180-8585 Japan
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
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