Network Working Group A. Duric
Request for Comments: 3952 Telio
Category: Experimental S. Andersen
Aalborg University
December 2004
Real-time Transport Protocol (RTP) Payload Format
for internet Low Bit Rate Codec (iLBC) Speech
Status of this Memo
このメモの位置付け
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのためにExperimentalプロトコルを定義します。それはどんな種類のインターネット標準を指定しません。改善のための議論や提案が要求されています。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2004).
著作権（C）インターネット協会（2004）。
Abstract
抽象
This document describes the Real-time Transport Protocol (RTP) payload format for the internet Low Bit Rate Codec (iLBC) Speech developed by Global IP Sound (GIPS). Also, within the document there are included necessary details for the use of iLBC with MIME and Session Description Protocol (SDP).
この文書では、グローバルIPサウンド（GIPS）が開発した、インターネット低ビットレートコーデック（iLBCの）スピーチのためのリアルタイムトランスポートプロトコル（RTP）ペイロード形式について説明します。また、ドキュメント内のMIMEおよびセッション記述プロトコル（SDP）とiLBCのの使用のために必要な詳細が含まれています。
Table of Contents
目次
1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Background. . . . . . . . . . . . . . . . . . . . . . . . . . . 2
3. RTP Payload Format. . . . . . . . . . . . . . . . . . . . . . . 3
3.1. Bitstream definition . . . . . . . . . . . . . . . . . . . 3
3.2. Multiple iLBC frames in a RTP packet . . . . . . . . . . . 6
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
4.1. Storage Mode . . . . . . . . . . . . . . . . . . . . . . . 7
4.2. MIME registration of iLBC. . . . . . . . . . . . . . . . . 8
5. Mapping to SDP Parameters . . . . . . . . . . . . . . . . . . . 9
6. Security Considerations . . . . . . . . . . . . . . . . . . . . 11
7. References. . . . . . . . . . . . . . . . . . . . . . . . . . . 11
7.1. Normative References . . . . . . . . . . . . . . . . . . . 11
7.2. Informative References . . . . . . . . . . . . . . . . . . 12
8. Acknowledgements. . . . . . . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 13
This document describes how compressed iLBC speech, as produced by the iLBC codec [1], may be formatted for use as an RTP payload type. Methods are provided to packetize the codec data frames into RTP packets. The sender may send one or more codec data frames per packet depending on the application scenario or based on the transport network condition, bandwidth restriction, delay requirements and packet-loss tolerance.
この文書は、iLBCのコーデックによって生成されるように、どのように圧縮さiLBCのスピーチを説明[1]、RTPペイロードタイプとして使用するためにフォーマットされ得ます。方法はRTPパケットにコーデックデータフレームをパケット化するために設けられています。送信者は、アプリケーションシナリオに応じて、またはトランスポートネットワークの状態、帯域幅制限、遅延要求およびパケット損失許容度に基づいて、パケットごとに一つ以上のコーデックデータフレームを送信することができます。
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 BCP 14, RFC 2119 [2].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますBCP 14、RFC 2119に記載されるように解釈される[2]。
Global IP Sound (GIPS) has developed a speech compression algorithm for use in IP based communications [1]. The iLBC codec enables graceful speech quality degradation in the case of lost frames, which occurs in connection with lost or delayed IP packets.
グローバルIPサウンド（GIPS）は、IPベースの通信に使用するための音声圧縮アルゴリズムを開発した[1]。 iLBCのコーデックは、損失または遅延IPパケットに関連して発生する失われたフレームの場合には、優雅な音声品質の劣化を可能にします。
This codec is suitable for real time communications such as, telephony and videoconferencing, streaming audio, archival and messaging.
このコーデックは、このような、電話やビデオ会議、ストリーミングオーディオ、アーカイブおよびメッセージングなどのリアルタイム通信に適しています。
The iLBC codec [1] is an algorithm that compresses each basic frame (20 ms or 30 ms) of 8000 Hz, 16-bit sampled input speech, into output frames with rate of 400 bits for 30 ms basic frame size and 304 bits for 20 ms basic frame size.
iLBCのコーデックは、[1] 30秒基本フレームサイズとのために304ビット、400ビットのレートと出力フレームに8000ヘルツ、16ビットサンプリングされた入力音声の各基本フレーム（20ミリ秒または30ミリ秒）圧縮アルゴリズムであります20ミリ秒の基本フレームサイズ。
The codec supports two basic frame lengths: 30 ms at 13.33 kbit/s and 20 ms at 15.2 kbit/s, using a block independent linear-predictive coding (LPC) algorithm. When the codec operates at block lengths of 20 ms, it produces 304 bits per block which MUST be packetized in 38 bytes. Similarly, for block lengths of 30 ms it produces 400 bits per block which MUST be packetized in 50 bytes. This algorithm results in a speech coding system with a controlled response to packet losses similar to what is known from pulse code modulation (PCM) with a packet loss concealment (PLC), such as ITU-T G711 standard [7], which operates at a fixed bit rate of 64 kbit/s. At the same time, this algorithm enables fixed bit rate coding with a quality-versus-bit rate tradeoff close to what is known from code-excited linear prediction (CELP).
ブロック独立した線形予測符号化（LPC）アルゴリズムを使用して、13.33キロビット/秒で30秒および15.2キロビット/秒で20 MS：コーデックは、2つの基本的なフレーム長をサポートします。コーデックは、20ミリ秒のブロック長で動作するとき、それは、38バイト単位でパケット化されなければならないブロック当たり304ビットを生成します。同様に、30ミリ秒のブロック長のためには、50バイト単位でパケット化されなければならないブロック当たり400ビットを生成します。で動作するようITU-T G711標準としてパケット損失隠蔽（PLC）のパルス符号変調（PCM）から知られているものと同様のパケット損失、[7]に制御された応答を有するシステムを音声符号化、このアルゴリズムの結果64キロビット/秒の固定ビットレート。同時に、このアルゴリズムは、コード励起線形予測（CELP）から知られているものに近い品質対ビットレートのトレードオフを有する固定ビットレート符号化を可能にします。
The iLBC codec uses 20 or 30 ms frames and a sampling rate clock of 8 kHz, so the RTP timestamp MUST be in units of 1/8000 of a second. The RTP payload for iLBC has the format shown in the figure bellow. No addition header specific to this payload format is required.
iLBCのコーデックは、20個のまたは30ミリ秒のフレームを使用し、8キロヘルツのサンプリングレートクロックので、RTPタイムスタンプは、第二の1/8000単位でなければなりません。 iLBCのためのRTPペイロードは、図ベローズに示すフォーマットを有しています。このペイロード形式に固有の追加ヘッダが必要とされません。
This format is intended for the situations where the sender and the receiver send one or more codec data frames per packet. The RTP packet looks as follows:
このフォーマットは、送信者と受信者がパケットごとに1つのまたは複数のコーデックデータフレームを送信する状況のために意図されます。次のようにRTPパケットになります。
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 [3] |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| |
+ one or more frames of iLBC [1] |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1, Packet format diagram
図1は、パケットフォーマット図
The RTP header of the packetized encoded iLBC speech has the expected values as described in [3]. The usage of M bit SHOULD be as specified in the applicable RTP profile, for example, RFC 3551 [4] specifies that if the sender does not suppress silence (i.e., sends a frame on every frame interval), the M bit will always be zero. When more then one codec data frame is present in a single RTP packet, the timestamp is, as always, the oldest data frame represented in the RTP packet.
パケット符号化iLBCの音声のRTPヘッダは、[3]で説明されるように期待値を有しています。 Mビットの使用は、該当RTPプロファイルで指定されるように、例えば、RFC 3551 [4]送信者が無音（すなわち、すべてのフレーム区間にフレームを送信する）を抑制しない場合、Mビットは常になることを指定しゼロ。もっとそしてあるコーデックデータフレームは単一のRTPパケット内に存在する場合、タイムスタンプは、いつものように、RTPパケットで表現最も古いデータフレームです。
The assignment of an RTP payload type for this new packet format is outside the scope of this document, and will not be specified here. It is expected that the RTP profile for a particular class of applications will assign a payload type for this encoding, or if that is not done, then a payload type in the dynamic range shall be chosen by the sender.
この新しいパケットフォーマットのためのRTPペイロードタイプの課題は、この文書の範囲外であり、ここで指定されることはありません。アプリケーションの特定のクラスのためのRTPプロファイルは、この符号化のためのペイロードタイプを割り当てるか、またはそれが行われない場合には、ダイナミックレンジにおけるペイロードタイプは、送信者によって選択されなければならないことが予想されます。
The total number of bits used to describe one frame of 20 ms speech is 304, which fits in 38 bytes and results in a bit rate of 15.20 kbit/s. For the case with a frame length of 30 ms speech the total number of bits used is 400, which fits in 50 bytes and results in a bit rate of 13.33 kbit/s. In the bitstream definition, the bits are distributed into three classes according to their bit error or loss sensitivity. The most sensitive bits (class 1) are placed first in the bitstream for each frame. The less sensitive bits (class 2) are placed after the class 1 bits. The least sensitive bits (class 3) are placed at the end of the bitstream for each frame.
20ミリ秒の音声の一つのフレームを記述するために使用されるビットの総数は、15.20キロビット/秒のビットレートでは38のバイトと結果に収まる304、です。 13.33キロビット/秒のビットレートでは50のバイトと結果に収まる使用されるビットの総数は400である30ミリ秒の音声のフレーム長を有する場合について。ビットストリーム定義では、ビットは、そのビット誤りまたは損失の感度に応じて3つのクラスに分配されます。最も敏感なビット（クラス1）は、フレーム毎にビットストリーム内に最初に配置されています。あまり敏感なビット（クラス2）はクラス1ビットの後に配置されています。前記敏感なビット（クラス3）は、各フレームのビットストリームの末尾に配置されています。
Looking at the 20/30 ms frame length cases for each class: The class 1 bits occupy a total of 6/8 bytes (48/64 bits), the class 2 bits occupy 8/12 bytes (64/96 bits), and the class 3 bits occupy 24/30 bytes (191/239 bits). This distribution of the bits enables the use of uneven level protection (ULP). The detailed bit allocation is shown in the table below. When a quantization index is distributed between more classes the more significant bits belong to the lowest class.
クラス1ビットは6/8バイト（64分の48ビット）の合計を占め、クラス2ビットが8/12バイト（96分の64ビット）を占有し、各クラスの20/30ミリ秒のフレーム長の場合を見てみますクラス3ビットが24/30バイト（239分の191ビット）を占めます。ビットのこの分布は、不均一なレベルの保護（ULP）の使用を可能にします。詳細ビット割り当てを以下の表に示されています。量子化インデックスは、複数のクラス間で分散されたときに上位ビットは最も低いクラスに属します。
Bitstream structure:
ビットストリーム構造：
------------------------------------------------------------------+
Parameter | Bits Class <1,2,3> |
| 20 ms frame | 30 ms frame |
----------------------------------+---------------+---------------+
Split 1 | 6 <6,0,0> | 6 <6,0,0> |
LSF 1 Split 2 | 7 <7,0,0> | 7 <7,0,0> |
LSF Split 3 | 7 <7,0,0> | 7 <7,0,0> |
------------------+---------------+---------------+
Split 1 | NA (Not Appl.)| 6 <6,0,0> |
LSF 2 Split 2 | NA | 7 <7,0,0> |
Split 3 | NA | 7 <7,0,0> |
------------------+---------------+---------------+
Sum | 20 <20,0,0> | 40 <40,0,0> |
----------------------------------+---------------+---------------+
Block Class. | 2 <2,0,0> | 3 <3,0,0> |
----------------------------------+---------------+---------------+
Position 22 sample segment | 1 <1,0,0> | 1 <1,0,0> |
----------------------------------+---------------+---------------+
Scale Factor State Coder | 6 <6,0,0> | 6 <6,0,0> |
----------------------------------+---------------+---------------+
Sample 0 | 3 <0,1,2> | 3 <0,1,2> |
Quantized Sample 1 | 3 <0,1,2> | 3 <0,1,2> |
Residual : | : : | : : |
State : | : : | : : |
Samples : | : : | : : |
Sample 56 | 3 <0,1,2> | 3 <0,1,2> |
Sample 57 | NA | 3 <0,1,2> |
------------------+---------------+---------------+
Sum | 171 <0,57,114>| 174 <0,58,116>|
----------------------------------+---------------+---------------+
Stage 1 | 7 <6,0,1> | 7 <4,2,1> |
CB for 22/23 Stage 2 | 7 <0,0,7> | 7 <0,0,7> |
sample block Stage 3 | 7 <0,0,7> | 7 <0,0,7> |
------------------+---------------+---------------+
Sum | 21 <6,0,15> | 21 <4,2,15> |
----------------------------------+---------------+---------------+
Stage 1 | 5 <2,0,3> | 5 <1,1,3> |
Gain for 22/23 Stage 2 | 4 <1,1,2> | 4 <1,1,2> |
sample block Stage 3 | 3 <0,0,3> | 3 <0,0,3> |
------------------+---------------+---------------+
Sum | 12 <3,1,8> | 12 <2,2,8> |
----------------------------------+---------------+---------------+
Stage 1 | 8 <7,0,1> | 8 <6,1,1> |
sub-block 1 Stage 2 | 7 <0,0,7> | 7 <0,0,7> |
Stage 3 | 7 <0,0,7> | 7 <0,0,7> |
------------------+---------------+---------------+
Stage 1 | 8 <0,0,8> | 8 <0,7,1> |
sub-block 2 Stage 2 | 8 <0,0,8> | 8 <0,0,8> |
Indices Stage 3 | 8 <0,0,8> | 8 <0,0,8> |
for CB ------------------+---------------+---------------+
sub-blocks Stage 1 | NA | 8 <0,7,1> |
sub-block 3 Stage 2 | NA | 8 <0,0,8> |
Stage 3 | NA | 8 <0,0,8> |
------------------+---------------+---------------+
Stage 1 | NA | 8 <0,7,1> |
sub-block 4 Stage 2 | NA | 8 <0,0,8> |
Stage 3 | NA | 8 <0,0,8> |
------------------+---------------+---------------+
Sum | 46 <7,0,39> | 94 <6,22,66> |
----------------------------------+---------------+---------------+
Stage 1 | 5 <1,2,2> | 5 <1,2,2> |
sub-block 1 Stage 2 | 4 <1,1,2> | 4 <1,2,1> |
Stage 3 | 3 <0,0,3> | 3 <0,0,3> |
------------------+---------------+---------------+
Stage 1 | 5 <1,1,3> | 5 <0,2,3> |
sub-block 2 Stage 2 | 4 <0,2,2> | 4 <0,2,2> |
Stage 3 | 3 <0,0,3> | 3 <0,0,3> |
Gains for ------------------+---------------+---------------+
sub-blocks Stage 1 | NA | 5 <0,1,4> |
sub-block 3 Stage 2 | NA | 4 <0,1,3> |
Stage 3 | NA | 3 <0,0,3> |
------------------+---------------+---------------+
Stage 1 | NA | 5 <0,1,4> |
sub-block 4 Stage 2 | NA | 4 <0,1,3> |
Stage 3 | NA | 3 <0,0,3> |
------------------+---------------+---------------+
Sum | 24 <3,6,15> | 48 <2,12,34> |
-------------------------------------------------------------------
Empty frame indicator | 1 <0,0,1> | 1 <0,0,1> |
-------------------------------------------------------------------
SUM 304 <48,64,192> 400 <64,96,240>
Table 3.1 The bitstream definition for iLBC.
表3.1 iLBCのためのビットストリームの定義。
When packetized into the payload, all the class 1 bits MUST be sorted in order (from top and down) as they were specified in the table. Additionally, all the class 2 bits MUST be sorted (from top and down) and all the class 3 bits MUST be sorted in the same sequential order.
ペイロードにパケット化するとき、すべてのクラス1ビットは、それらがテーブルで指定されたように（上および下から）順にソートされなければなりません。また、全てのクラス2ビット（トップダウンで）ソートする必要があり、すべてのクラス3ビットが同じ順序でソートされなければなりません。
More than one iLBC frame may be included in a single RTP packet by a sender.
複数iLBCのフレームは、送信者が、単一のRTPパケットに含まれてもよいです。
It is important to observe that senders have the following additional restrictions:
送信者は、次の追加の制限を持っていることを観察することが重要です。
o SHOULD NOT include more iLBC frames in a single RTP packet than will fit in the MTU of the RTP transport protocol.
oはRTPトランスポートプロトコルのMTUに収まるよりも、単一のRTPパケットに、よりiLBCのフレームを含むべきではありません。
o Frames MUST NOT be split between RTP packets.
OフレームはRTPパケットに分割してはなりません。
o Frames of the different modes (20 ms and 30 ms) MUST NOT be included within the same packet.
O異なるモード（20ミリ秒と30ミリ秒）のフレームは同じパケット内に含まれてはいけません。
It is RECOMMENDED that the number of frames contained within an RTP packet are consistent with the application. For example, in telephony and other real time applications where delay is important, the delay is lower depending on the amount of frames per packet (i.e., fewer frames per packet, the lower the delay). Whereas for bandwidth constrained links or delay insensitive streaming messaging application, one or more frames per packet would be acceptable.
RTPパケット内に含まれるフレームの数は、アプリケーションと一致することをお勧めします。例えば、遅延が重要な電話および他のリアルタイムアプリケーションでは、遅延は、パケットあたりのフレームの量に応じて低くなる（すなわち、パケット当たりの少ないフレーム、遅延低いです）。帯域幅の制約のリンクまたは遅延鈍感なストリーミングメッセージングアプリケーションのためのに対し、パケットごとに1つ以上のフレームが許容可能です。
Information describing the number of frames contained in an RTP packet is not transmitted as part of the RTP payload. The way to determine the number of iLBC frames is to count the total number of octets within the RTP packet, and divide the octet count by the number of expected octets per frame (32/50 per frame).
RTPパケットに含まれるフレームの数を示す情報は、RTPペイロードの一部として送信されません。 iLBCのフレームの数を決定する方法は、RTPパケット内のオクテットの総数をカウントし、フレーム当たり期待オクテット（フレームあたり50分の32）の数でオクテット数を分割することです。
One new MIME sub-type as described in this section has been registered.
このセクションで説明するように、1つの新しいMIMEサブタイプが登録されています。
The storage mode is used for storing speech frames (e.g., as a file or email attachment).
ストレージモード（例えば、ファイルまたは電子メールの添付ファイルとして）音声フレームを格納するために使用されます。
+------------------+
| Header |
+------------------+
| Speech frame 1 |
+------------------+
: :
+------------------+
| Speech frame n |
+------------------+
Figure 2, Storage format diagram
図2は、記憶フォーマット図
The file begins with a header that includes only a magic number to identify that it is an iLBC file.
ファイルは、iLBCのファイルであることを識別するための唯一のマジックナンバーを含むヘッダで始まります。
The magic number for iLBC file MUST correspond to the ASCII character string:
iLBCのファイルのマジックナンバーはASCII文字列に対応している必要があります：
o for 30 ms frame size mode:"#!iLBC30\n", or "0x23 0x21 0x69 0x4C 0x42 0x43 0x33 0x30 0x0A" in hexadecimal form,
O 30ミリ秒のフレームサイズモード用： "！＃iLBC30 \ nを"、または "0x23 0x21で0x69の0x4C 0x42に0x43この0x33の0x30から0x0Aを" 16進形式で、
o for 20 ms frame size mode:"#!iLBC20\n", or "0x23 0x21 0x69 0x4C 0x42 0x43 0x32 0x30 0x0A" in hexadecimal form.
O 20msフレームサイズモード用：16進数で "＃iLBC20 \ nを！"、または "0x23 0x21で0x69の0x4C 0x42に0x43この0x32の0x30から0x0Aを"。
After the header, follow the speech frames in consecutive order.
ヘッダの後、連続した順序で音声フレームをたどります。
Speech frames lost in transmission MUST be stored as "empty frames", as defined in [1].
[1]で定義されるように、送信中に失われた音声フレームは、「空のフレーム」として記憶されなければなりません。
MIME media type name: audio
MIMEメディアタイプ名：オーディオ
MIME subtype: iLBC
MIMEサブタイプ：iLBCの
Optional parameters:
オプションのパラメータ：
All of the parameters does apply for RTP transfer only.
すべてのパラメータは、RTP転送だけに適用されます。
maxptime:The maximum amount of media which can be encapsulated in each packet, expressed as time in milliseconds. The time SHALL be calculated as the sum of the time the media present in the packet represents. The time SHOULD be a multiple of the frame size. This attribute is probably only meaningful for audio data, but may be used with other media types if it makes sense. It is a media attribute, and is not dependent on charset. Note that this attribute was introduced after RFC 2327, and non updated implementations will ignore this attribute.
maxptime：各パケットにカプセル化することができる媒体の最大量は、ミリ秒単位の時間として表さ。時間は、パケット内のメディアの存在を表す時間の合計として計算します。時間は、フレームサイズの倍数でなければなりません。この属性は、おそらく、音声データに対してのみ意味があり、それは理にかなっている場合は、他のメディアタイプで使用することができます。これは、メディア属性であり、文字セットに依存していません。この属性は、RFC 2327の後に導入し、非更新の実装は、この属性を無視することに注意してください。
mode: The iLBC operating frame mode (20 or 30 ms) that will be encapsulated in each packet. Values can be 0, 20 and 30 (where 0 is reserved, 20 stands for preferred 20 ms frame size and 30 stands for preferred 30 ms frame size).
モード：各パケットにカプセル化されるiLBCの動作フレームモード（20または30ミリ秒）。値は（0は予約され、好適な30ミリ秒のフレームサイズのための好ましい20msフレーム・サイズ及び30のスタンド20スタンド）0、20及び30であることができます。
ptime: Defined as usual for RTP audio (see [5]).
PTIME：RTPオーディオ用にいつものように定義された（[5]を参照）。
Encoding considerations: This type is defined for transfer via both RTP (RFC 3550) and stored-file methods as described in Section 4.1, of RFC
符号化の考慮事項：セクション4.1に記載したように、このタイプは、両方のRTP（RFC 3550）と格納されたファイルの方法を介して転送するために定義され、RFCの
3952. Audio data is binary data, and must be encoded for
non-binary transport; the Base64 encoding is suitable for
email.
Security considerations: See Section 6 of RFC 3952.
セキュリティの考慮事項：RFC 3952のセクション6を参照してください。
Public specification: Please refer to RFC 3951 [1].
公開された仕様：[1] RFC 3951を参照してください。
Additional information: The following applies to stored-file transfer methods:
追加情報：以下は、保存されたファイルの転送方法に適用されます。
Magic number:
ASCII character string for:
o 30 ms frame size mode "#!iLBC30\n" (or 0x23 0x21
0x69 0x4C 0x42 0x43 0x33 0x30 0x0A in hexadecimal)
o 20 ms frame size mode "#!iLBC20\n" (or 0x23 0x21
0x69 0x4C 0x42 0x43 0x32 0x30 0x0A in hexadecimal)
File extensions: lbc, LBC Macintosh file type code: none Object identifier or OID: none
ファイル拡張子：LBC、LBC Macintoshファイルタイプコード：なしオブジェクト識別子またはOID：なし
Person & email address to contact for further information: alan.duric@telio.no
人とEメールアドレスは、詳細のために連絡する：alan.duric@telio.no
Intended usage: COMMON. It is expected that many VoIP applications will use this type.
意図している用法：COMMON。多くのVoIPアプリケーションは、このタイプを使用することが期待されます。
Author/Change controller: alan.duric@telio.no IETF Audio/Video transport working group
著者/変更コントローラ：alan.duric@telio.no IETFオーディオ/ビデオトランスポートワーキンググループ
The information carried in the MIME media type specification has a specific mapping to fields in the Session Description Protocol (SDP) [5], which is commonly used to describe RTP sessions. When SDP is used to specify sessions employing the iLBC codec, the mapping is as follows:
MIMEメディアタイプの仕様で搬送される情報は、[5]、一般にRTPセッションを記述するために使用されるセッション記述プロトコル（SDP）内のフィールドに特定のマッピングを有します。 SDPは、iLBCのコーデックを使用するセッションを指定するために使用される場合、以下のように、マッピングは次のとおりです。
o The MIME type ("audio") goes in SDP "m=" as the media name.
O MIMEタイプ（「オーディオ」）は、メディア名としてSDP「m =」に進みます。
o The MIME subtype (payload format name) goes in SDP "a=rtpmap" as the encoding name.
O（ペイロードフォーマット名）MIMEサブタイプは、符号化名としてSDPの「a = rtpmap」に進みます。
o The parameters "ptime" and "maxptime" go in the SDP "a=ptime" and "a=maxptime" attributes, respectively.
Oパラメータの "PTIME" と "maxptime" は、それぞれ、 "A = PTIME" と "A = maxptimeは" 属性SDPに行きます。
o The parameter "mode" goes in the SDP "a=fmtp" attribute by copying it directly from the MIME media type string as "mode=value".
Oパラメータ「モード」は、「モード=値」としてMIMEメディアタイプ文字列から直接コピーすることで、「=のfmtp」属性SDPになります。
When conveying information by SDP, the encoding name SHALL be "iLBC" (the same as the MIME subtype).
SDPによって情報を伝達する場合、エンコーディング名が「iLBCの」（MIMEサブタイプと同じ）でなければなりません。
An example of the media representation in SDP for describing iLBC might be:
iLBCのを説明するためのSDP内のメディア表現の例があるかもしれません。
m=audio 49120 RTP/AVP 97 a=rtpmap:97 iLBC/8000
M =オーディオ49120 RTP / AVP 97 = rtpmap：97 iLBCの/ 8000
If 20 ms frame size mode is used, remote iLBC encoder SHALL receive "mode" parameter in the SDP "a=fmtp" attribute by copying them directly from the MIME media type string as a semicolon separated with parameter=value, where parameter is "mode", and values can be 0 and 20 (where 0 is reserved and 20 stands for preferred 20 ms frame size). An example of the media representation in SDP for describing iLBC when 20 ms frame size mode is used might be:
20ミリ秒のフレームサイズモードが使用される場合、リモートiLBCのエンコーダは、パラメータが "パラメータ=値で分離セミコロンとしてMIMEメディアタイプ文字列から直接コピーすることによって、SDPの「=のfmtp」属性を「モード」パラメータを受けなければなりませんモード」、および値は、0と20（好ましい20msフレームサイズの0は予約されており、20スタンド）とすることができます。 20ミリ秒のフレームサイズモードを使用する場合iLBCのを説明するためのSDP内のメディア表現の例があるかもしれません。
m=audio 49120 RTP/AVP 97 a=rtpmap:97 iLBC/8000 a=fmtp:97 mode=20
M =オーディオ49120 RTP / AVP 97 = rtpmap：97モード= 20：iLBCの/ 8000 = 97のfmtp
It is important to emphasize the bi-directional character of the "mode" parameter - both sides of a bi-directional session MUST use the same "mode" value.
双方向セッションの両側が同じ「モード」値を使用しなければならない - 「モード」パラメータの双方向の文字を強調することが重要です。
The offer contains the preferred mode of the offerer. The answerer may agree to that mode by including the same mode in the answer, or may include a different mode. The resulting mode used by both parties SHALL be the lower of the bandwidth modes in the offer and answer.
オファーは、オファーの優先モードが含まれています。回答は答えに同じモードを含むことにより、そのモードに同意することができる、または異なるモードを含むことができます。両当事者によって使用される結果のモードが提供と答えにおける帯域幅モードの下でなければなら。
That is, an offer of "mode=20" receiving an answer of "mode=30" will result in "mode=30" being used by both participants. Similarly, an offer of "mode=30" and an answer of "mode=20" will result in "mode=30" being used by both participants.
すなわち、の答え受信「モード= 20」のオファー「モード= 30」は、「モード= 30」が両方の参加者によって使用されていることになります。同様に、「モード= 30」のオファーとの答えが「モード= 20」は、「モード= 30」になり、両方の参加者によって使用されています。
This is important when one end point utilizes a bandwidth constrained link (e.g., 28.8k modem link or slower), where only the lower frame size will work.
一方の端点のみが下部フレームのサイズが動作する帯域幅制約リンク（例えば、28.8Kモデムリンクまたはより遅い）を利用する場合、このことは重要です。
Parameter ptime can not be used for the purpose of specifying iLBC operating mode, due to fact that for the certain values it will be impossible to distinguish which mode is about to be used (e.g., when ptime=60, it would be impossible to distinguish if packet is carrying 2 frames of 30 ms or 3 frames of 20 ms, etc.).
パラメータPTIMEは、特定の値のために、例えば、ときPTIME = 60、区別することは不可能だろう（使用されようとしているモードを区別することは不可能になるという事実に、指定iLBCの動作モードの目的のために使用することはできませんパケット等、30ミリ秒または20ミリ秒の3つのフレームの2つのフレームを運んでいる場合）。
Note that the payload format (encoding) names are commonly shown in upper case. MIME subtypes are commonly shown in lower case. These names are case-insensitive in both places. Similarly, parameter names are case-insensitive both in MIME types and in the default mapping to the SDP a=fmtp attribute
ペイロード形式（符号化）の名前は、一般的に大文字で示されていることに留意されたいです。 MIMEサブタイプは一般に小文字で示されています。これらの名前は、両方の場所で大文字と小文字を区別しません。同様に、パラメータ名は、MIMEタイプおよびSDPのA =のfmtp属性にデフォルトのマッピングの両方で大文字と小文字を区別しません
RTP packets using the payload format defined in this specification are subject to the general security considerations discussed in [3] and any appropriate profile (e.g., [4]).
本明細書で定義されたペイロードフォーマットを使用して、RTPパケットが[3]、任意の適切なプロファイルで議論一般的なセキュリティの考慮の対象となっている（例えば、[4]）。
As this format transports encoded speech, the main security issues include confidentiality and authentication of the speech itself. The payload format itself does not have any built-in security mechanisms. Confidentiality of the media streams is achieved by encryption, therefore external mechanisms, such as SRTP [6], MAY be used for that purpose. The data compression used with this payload format is applied end-to-end; hence encryption may be performed after compression with no conflict between the two operations.
この形式は、符号化された音声を転送するように、メインのセキュリティ問題は、音声自体の機密性と認証が含まれます。ペイロード形式自体は、任意の組み込みのセキュリティメカニズムを持っていません。メディアストリームの機密性は、暗号化によって[6]、その目的のために使用することができるようSRTPしたがって外部のメカニズムを、実現されます。このペイロードフォーマットに使用されるデータ圧縮は、エンドツーエンドで適用されます。したがって、暗号化は、二つの操作の間には衝突して圧縮した後に行ってもよいです。
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 which are complex to decode and cause the receiver to become overloaded. However, the encodings covered in this document do not exhibit any significant non-uniformity.
潜在的なサービス拒否の脅威は、不均一な受信端計算負荷を有する圧縮技術を用いて、データ符号化のために存在します。攻撃者が復号及び過負荷になるために受信機を引き起こすのに複雑であるストリームに病理学的なデータグラムを注入することができます。しかし、本書で取り上げエンコーディングは、有意な不均一性を示しません。
[1] Andersen, S., Duric, A., Astrom, H., Hagen, R., Kleijn, W., and J. Linden, "Internet Low Bit Rate Codec (iLBC)", RFC 3951, December 2004.
[1]アンダーセン、S.、Duric、A.、Astrom、H.、ハーゲン、R.、Kleijn、W.、及びJ.リンデン、 "インターネット低ビットレートコーデック（iLBCの）"、RFC 3951、2004年12月。
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[2]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[3] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
[3] Schulzrinneと、H.、Casner、S.、フレデリック、R.、およびV.ヤコブソン、 "RTP：リアルタイムアプリケーションのためのトランスポートプロトコル"、STD 64、RFC 3550、2003年7月。
[4] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video Conferences with Minimal Control", STD 65, RFC 3551, July 2003.
[4] Schulzrinneと、H.とS. Casner、 "最小量のコントロールがあるオーディオとビデオ会議システムのためのRTPプロフィール"、STD 65、RFC 3551、2003年7月。
[5] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998.
[5]ハンドリー、M.およびV. Jacobson氏、 "SDP：セッション記述プロトコル"、RFC 2327、1998年4月。
[6] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol", RFC 3711, March 2004.
[6] Baugher、M.、マグリュー、D.、Naslund、M.、カララ、E.、およびK. Norrman、 "セキュアリアルタイムトランスポートプロトコル"、RFC 3711、2004年3月。
[7] ITU-T Recommendation G.711, available online from the ITU bookstore at http://www.itu.int.
[7] ITU-T勧告G.711、ITU http://www.itu.intで書店からオンラインで入手可能。
Henry Sinnreich, Patrik Faltstrom, Alan Johnston and Jean-Francois Mule for great support of the iLBC initiative and for valuable feedback and comments.
iLBCのイニシアチブの素晴らしいサポートのための貴重なフィードバックやコメントのためのヘンリーSinnreich、パトリックFaltstrom、アラン・ジョンストンとジャン=フランソワミュール。
Authors' Addresses
著者のアドレス
Alan Duric Telio AS Stoperigt. 2 Oslo, N-0250 Norway
Stoperigt ASアランDuric Telio。 2オスロ、N-0250ノルウェー
Phone: +47 21673505 EMail: alan.duric@telio.no
電話：+47 21673505 Eメール：alan.duric@telio.no
Soren Vang Andersen Department of Communication Technology Aalborg University Fredrik Bajers Vej 7A 9200 Aalborg Denmark
通信技術オールボー大学フレデリックBajers道路7A 9200オールボーデンマークのソレン・ヴァン・アンデルセン部門
Phone: ++45 9 6358627 EMail: sva@kom.auc.dk
電話：++ 45 9 6358627 Eメール：sva@kom.auc.dk
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2004).
著作権（C）インターネット協会（2004）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the IETF's procedures with respect to rights in IETF Documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 IETF文書の権利に関するIETFの手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。