[要約] RFC 3952は、iLBC音声のためのRTPペイロード形式を定義しています。このRFCの目的は、インターネット上での低ビットレートの音声通信をサポートするための標準化を提供することです。
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
インターネット低ビット レート コーデック (iLBC) 音声用のリアルタイム トランスポート プロトコル (RTP) ペイロード フォーマット
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.
このメモは、インターネット コミュニティ向けの実験プロトコルを定義します。いかなる種類のインターネット標準も指定しません。改善のための議論と提案が求められます。このメモの配布は無制限です。
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).
このドキュメントでは、Global IP Sound (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 コーデック [1] によって生成された圧縮 iLBC 音声を、RTP ペイロード タイプとして使用するためにどのようにフォーマットできるかについて説明します。コーデック データ フレームを RTP パケットにパケット化するためのメソッドが提供されています。送信者は、アプリケーション シナリオに応じて、またはトランスポート ネットワークの状態、帯域幅制限、遅延要件、パケット損失許容度に基づいて、パケットごとに 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 BCP 14, RFC 2119 [2].
この文書のキーワード「しなければならない」、「してはならない」、「必須」、「しなければならない」、「してはならない」、「すべきである」、「すべきではない」、「推奨」、「してもよい」、「任意」は次のとおりです。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.
Global IP Sound (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] は、8000 Hz、16 ビットのサンプリングされた入力音声の各基本フレーム (20 ミリ秒または 30 ミリ秒) を、30 ミリ秒の基本フレーム サイズの場合は 400 ビット、基本フレーム サイズの場合は 304 ビットのレートで出力フレームに圧縮するアルゴリズムです。20msの基本フレームサイズ。
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) アルゴリズムを使用して、2 つの基本フレーム長 (13.33 kbit/s で 30 ms、15.2 kbit/s で 20 ms) をサポートします。コーデックが 20 ミリ秒のブロック長で動作する場合、ブロックあたり 304 ビットが生成され、これを 38 バイトでパケット化する必要があります。同様に、ブロック長が 30 ミリ秒の場合、ブロックあたり 400 ビットが生成され、これを 50 バイトでパケット化する必要があります。このアルゴリズムにより、ITU-T G711 標準 [7] などのパケット損失隠蔽 (PLC) を備えたパルス符号変調 (PCM) で知られているものと同様に、パケット損失に対する応答が制御された音声符号化システムが実現します。64 kbit/s の固定ビット レート。同時に、このアルゴリズムにより、符号励起線形予測 (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 kHz のサンプリング レート クロックを使用するため、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 プロファイルで指定されているとおりであるべきです (SHOULD)。たとえば、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 ミリ秒の音声の 1 フレームを記述するために使用されるビットの総数は 304 で、これは 38 バイトに収まり、ビット レートは 15.20 kbit/s になります。フレーム長が 30 ms の音声の場合、使用されるビットの総数は 400 で、50 バイトに収まり、ビット レートは 13.33 kbit/s になります。ビットストリーム定義では、ビットはビットエラーまたは損失感度に応じて 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.
各クラスのフレーム長が 20/30 ミリ秒の場合を見ると、クラス 1 ビットは合計 6/8 バイト (48/64 ビット) を占め、クラス 2 ビットは 8/12 バイト (64/96 ビット) を占め、クラス 3 ビットは 24/30 バイト (191/239 ビット) を占めます。このビットの分散により、不均等レベル保護 (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 ビットは、テーブルで指定されている順序 (上から下) にソートされなければなりません (MUST)。さらに、クラス 2 のすべてのビットは (上から下に) ソートされなければならず、クラス 3 のすべてのビットは同じ順序でソートされなければなりません。
More than one iLBC frame may be included in a single RTP packet by a sender.
送信者によって、複数の iLBC フレームが 1 つの 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 に収まる量を超える iLBC フレームを 1 つの RTP パケットに含めるべきではありません。
o Frames MUST NOT be split between RTP packets.
o フレームを RTP パケット間で分割してはなりません (MUST NOT)。
o Frames of the different modes (20 ms and 30 ms) MUST NOT be included within the same packet.
o 異なるモード (20 ミリ秒と 30 ミリ秒) のフレームを同じパケット内に含めてはなりません (MUST NOT)。
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 パケット内のオクテットの総数を数え、そのオクテット カウントをフレームあたりの予想オクテット数 (フレームあたり 32/50) で割ることです。
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 The file begins with a header that includes only a magic number to identify that it is an iLBC file.
図 2、ストレージ形式の図 ファイルは、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 ms フレーム サイズ モードの場合:「#!iLBC30\n」、または 16 進形式の「0x23 0x21 0x69 0x4C 0x42 0x43 0x33 0x30 0x0A」、
o for 20 ms frame size mode:"#!iLBC20\n", or "0x23 0x21 0x69 0x4C 0x42 0x43 0x32 0x30 0x0A" in hexadecimal form.
o 20 ms フレーム サイズ モードの場合:「#!iLBC20\n」、または 16 進形式の「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] で定義されているように、送信中に失われた音声フレームは「空のフレーム」として保存されなければなりません (MUST)。
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: 各パケットにカプセル化できるメディアの最大量。ミリ秒単位の時間で表されます。時間は、パケット内に存在するメディアが表す時間の合計として計算されるものとします (SHALL)。時間はフレーム サイズの倍数である必要があります。この属性はおそらくオーディオ データに対してのみ意味がありますが、意味がある場合は他のメディア タイプでも使用できます。これはメディア属性であり、文字セットには依存しません。この属性は 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).
mode: 各パケットにカプセル化される iLBC オペレーティング フレーム モード (20 または 30 ミリ秒)。値は 0、20、および 30 です (0 は予約されており、20 は優先 20 ミリ秒フレーム サイズを表し、30 は優先 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 3952. Audio data is binary data, and must be encoded for non-binary transport; the Base64 encoding is suitable for email.
エンコーディングに関する考慮事項: このタイプは、RTP (RFC 3550) と、RFC 3952 のセクション 4.1 で説明されている保存ファイル方式の両方を介した転送用に定義されています。オーディオ データはバイナリ データであり、非バイナリ転送用にエンコードする必要があります。Base64 エンコーディングは電子メールに適しています。
Security considerations: See Section 6 of RFC 3952.
セキュリティに関する考慮事項: RFC 3952 のセクション 6 を参照してください。
Public specification: Please refer to RFC 3951 [1].
公開仕様: RFC 3951 [1] を参照してください。
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)
マジックナンバー: ASCII 文字列: o 30 ms フレーム サイズ モード "#!iLBC30\n" (または 0x23 0x21 0x69 0x4C 0x42 0x43 0x33 0x30 0x0A (16 進数)) o 20 ms フレーム サイズ モード "#!iLBC20\n" (または0x23 0x21 0x69 0x4C 0x42 0x43 0x32 0x30 0x0A (16 進数)
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
詳細についての連絡先および電子メール アドレス: alan.duric@telio.no
Intended usage: COMMON. It is expected that many VoIP applications will use this type.
使用目的: 一般。多くの 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 メディア タイプ仕様で伝送される情報には、RTP セッションを記述するために一般的に使用されるセッション記述プロトコル (SDP) [5] のフィールドへの特定のマッピングがあります。SDP を使用して iLBC コーデックを使用するセッションを指定する場合、マッピングは次のようになります。
o The MIME type ("audio") goes in SDP "m=" as the media name.
o MIME タイプ (「audio」) は、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」は、それぞれ SDP の「a=ptime」および「a=maxptime」属性に入ります。
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 パラメータ「mode」は、MIME メディア タイプ文字列から「mode=value」として直接コピーすることで、SDP「a=fmtp」属性に組み込まれます。
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 a=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 ms フレーム サイズ モードが使用される場合、リモート iLBC エンコーダは、MIME メディア タイプ文字列から直接コピーすることによって、SDP "a=fmtp" 属性の "mode" パラメータを、parameter=value で区切られたセミコロンとして受信するものとします。ここで、パラメータは "モード」であり、値は 0 と 20 です (0 は予約されており、20 は推奨される 20 ミリ秒のフレーム サイズを表します)。20 ms フレーム サイズ モードが使用される場合の iLBC を記述するための SDP でのメディア表現の例は次のとおりです。
m=audio 49120 RTP/AVP 97
a=rtpmap:97 iLBC/8000
a=fmtp:97 mode=20
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.
「mode」パラメータの双方向特性を強調することが重要です。双方向セッションの両側は同じ「mode」値を使用しなければなりません。
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.
つまり、「mode=20」のオファーが「mode=30」の回答を受け取ると、両方の参加者が「mode=30」を使用することになります。同様に、「mode=30」というオファーと「mode=20」という回答では、両方の参加者が「mode=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 は、特定の値ではどのモードが使用されるかを区別することが不可能になるため、iLBC 動作モードを指定する目的には使用できません (たとえば、ptime=60 の場合、区別することが不可能になります)。パケットが 2 つの 30 ミリ秒のフレームまたは 3 つの 20 ミリ秒のフレームを伝送している場合など)。
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.
この形式はエンコードされた音声を転送するため、主なセキュリティ問題には音声自体の機密性と認証が含まれます。ペイロード形式自体にはセキュリティ メカニズムが組み込まれていません。メディア ストリームの機密性は暗号化によって実現されるため、SRTP [6] などの外部メカニズムをその目的に使用してもよい(MAY)。このペイロード形式で使用されるデータ圧縮はエンドツーエンドで適用されます。したがって、暗号化は圧縮後に 2 つの操作間で競合することなく実行できます。
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] Andersen, S.、Duric, A.、Astrom, H.、Hagen, R.、Kleijn, W.、および J. Linden、「インターネット低ビット レート コーデック (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] Bradner, S.、「要件レベルを示すために RFC で使用するキーワード」、BCP 14、RFC 2119、1997 年 3 月。
[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.、Frederick, R.、および V. Jacobson、「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] Handley、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.、McGrew, D.、Naslund, M.、Carrara, E.、および K. Norrman、「The Secure Real-time Transport Protocol」、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.
Henry Sinnreich、Patrik Faltstrom、Alan Johnston、Jean-Francois Mule の皆様には、iLBC イニシアチブへの多大なご支援と、貴重なフィードバックとコメントをいただきました。
Authors' Addresses
著者の住所
Alan Duric Telio AS Stoperigt. 2 Oslo, N-0250 Norway
アラン・デュリック・テリオ AS ストペリグト。2 オスロ、N-0250 ノルウェー
Phone: +47 21673505
EMail: alan.duric@telio.no
Soren Vang Andersen Department of Communication Technology Aalborg University Fredrik Bajers Vej 7A 9200 Aalborg Denmark
Soren Vang Andersen コミュニケーション技術学部 オールボー大学 Fredrik Bajers Vej 7A 9200 オールボー デンマーク
Phone: ++45 9 6358627
EMail: 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.
この文書およびここに含まれる情報は「現状のまま」で提供され、寄稿者、寄稿者が代表または後援する組織（存在する場合）、インターネット協会およびインターネット エンジニアリング タスク フォースは、明示的または明示的または明示的に、すべての保証を否認します。ここに記載された情報の使用がいかなる権利も侵害しないことの黙示的な保証、または商品性や特定の目的への適合性の黙示的な保証を含みますが、これに限定されません。
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.
IETF 事務局に提出された IPR 開示のコピー、および利用可能になるライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような所有権の使用に対する一般ライセンスまたは許可を取得しようとする試みの結果を入手できます。IETF オンライン IPR リポジトリ (http://www.ietf.org/ipr) から入手してください。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF は、利害関係者に対し、この規格の実装に必要とされる可能性のある技術をカバーする著作権、特許、特許出願、またはその他の所有権について注意を喚起するよう呼びかけています。情報は IETF (ietf-ipr@ietf.org) に送信してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC エディター機能の資金は現在、インターネット協会によって提供されています。