RFC3952 日本語訳

Network Working Group                                           A. Duric
Request for Comments: 3952                                         Telio
Category: Experimental                                       S. Andersen
                                                      Aalborg University
                                                           December 2004

Duricがコメントのために要求するワーキンググループA.をネットワークでつないでください: 3952年のTelioカテゴリ: 実験的なS.アンダーセンオールボア大学2004年12月

           Real-time Transport Protocol (RTP) Payload Format
             for internet Low Bit Rate Codec (iLBC) Speech

インターネットLow Bit Rate Codec(iLBC)スピーチのためのリアルタイムのTransportプロトコル(RTP)有効搭載量Format

Status of this Memo

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

Copyright(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)によって開発されたインターネットLow Bit Rate Codec(iLBC)スピーチのためにレアル-時間Transportプロトコル(RTP)ペイロード形式について説明します。 また、ドキュメントの中に、MIMEとSession記述プロトコル(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

1. 序論。 . . . . . . . . . . . . . . . . . . . . . . . . . 2 2. バックグラウンド。 . . . . . . . . . . . . . . . . . . . . . . . . . . 2 3. RTP有効搭載量形式。 . . . . . . . . . . . . . . . . . . . . . . 3 3.1. Bitstream定義. . . . . . . . . . . . . . . . . . . 3 3.2。 複数のiLBCがRTPパケット. . . . . . . . . . . 6 4で縁どっています。 IANA問題. . . . . . . . . . . . . . . . . . . . . . 7 4.1。 格納モード. . . . . . . . . . . . . . . . . . . . . . . 7 4.2。 iLBCのMIME登録。 . . . . . . . . . . . . . . . . 8 5. パラメタ. . . . . . . . . . . . . . . . . . . 9 6をSDPに写像します。 セキュリティ問題. . . . . . . . . . . . . . . . . . . . 11 7。 参照。 . . . . . . . . . . . . . . . . . . . . . . . . . . 11 7.1. 引用規格. . . . . . . . . . . . . . . . . . . 11 7.2。 有益な参照. . . . . . . . . . . . . . . . . . 12 8。 承認。 . . . . . . . . . . . . . . . . . . . . . . . 12人の作者のアドレス. . . . . . . . . . . . . . . . . . . . . . . . 12の完全な著作権宣言文. . . . . . . . . . . . . . . . . . . . . 13

Duric & Andersen              Experimental                      [Page 1]

RFC 3952           RTP Payload Format for iLBC Speech      December 2004

Duricとアンダーセン実験的な[1ページ]RFC3952RTP Payloadは2004年12月にiLBCのためにスピーチをフォーマットします。

1.  Introduction

1. 序論

   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パケットにpacketizeするように方法を提供します。 送付者はアプリケーションシナリオか転送ネットワークに基づいたパケット依存あたりのデータフレームが条件とさせる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].

キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはBCP14(RFC2119[2])で説明されるように本書では解釈されることであるべきです。

2.  Background

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 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]は30msのための400ビットのレートが基本の状態で20ms基本枠サイズのために8000Hzの各基本枠(20msか30ms)、16ビットの抽出された入力スピーチを出力フレームにフレーム・サイズと304ビット圧縮するアルゴリズムです。

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

コーデックは2つの基本枠の長さを支持します: 13.33kbit/sの30msとブロック独立している線形予測コーディング(LPC)アルゴリズムを使用する15.2kbit/sの20ms。 コーデックが20msのブロック長で作動すると、それは1 38バイトでpacketizedしなければならないブロックあたり304ビットを作り出します。 同様に、30msのブロック長のために、それは1 50バイトでpacketizedしなければならないブロックあたり400ビットを作り出します。 このアルゴリズムはパルス符号変調(PCM)から知られていることと同様のパケット損失へのパケット損失隠すこと(PLC)による制御応答でスピーチ記号化体系をもたらします、ITU-T G711規格[7]などのように。(それは、64kbit/sの固定ビット伝送速度で作動します)。 同時に、このアルゴリズムはコードの興奮している直線的な予測(CELP)から知られていることの近くでビット伝送速度に従った品質見返りがある固定ビット伝送速度コード化を可能にします。

Duric & Andersen              Experimental                      [Page 2]

RFC 3952           RTP Payload Format for iLBC Speech      December 2004

Duricとアンダーセン実験的な[2ページ]RFC3952RTP Payloadは2004年12月にiLBCのためにスピーチをフォーマットします。

3.  RTP Payload Format

3. RTP有効搭載量形式

   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個のmsフレームと8kHzの標本抽出率時計を使用するので、RTPタイムスタンプが1秒の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パケットあたり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]                |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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ヘッダー[3]| +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | | + iLBC[1]の1個以上のフレーム| | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Figure 1, Packet format diagram

図1、Packet形式ダイヤグラム

   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.

packetizedコード化されたiLBCスピーチのRTPヘッダーには、期待値が[3]で説明されるようにあります。 MビットのSHOULDの使用法は適切なRTPが輪郭を描く指定されたコネとしてそうです、例えば、RFC3551[4]が送付者が沈黙(すなわち、あらゆるフレーム間隔にフレームを送る)を抑圧しないなら、Mビットがいつもゼロになると指定します。 1つの当時のコーデックデータが縁どる以上が単一の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プロフィールがこのコード化のためのペイロードタイプを選任すると予想されるものとするか、またはそれが完了していないなら、ダイナミックレンジにおけるペイロードタイプは送付者によって選ばれるものとします。

3.1.  Bitstream definition

3.1. Bitstream定義

   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

20msスピーチの1個のフレームについて説明するのに使用されるビットの総数は304です(15.20kbit/sのレートを38バイトうまくはめ込んで、少しもたらします)。 30msのフレームの長さがあるケースのために、ビットの総数が使用したスピーチは400です(13.33kbit/sのレートを50バイトうまくはめ込んで、少しもたらします)。 bitstream定義では、それらの噛み付いている誤りか損失感度に従って、ビットは3つのクラスに分配されます。 最も敏感なビット(クラス1)は中に最初に、置かれます。

Duric & Andersen              Experimental                      [Page 3]

RFC 3952           RTP Payload Format for iLBC Speech      December 2004

Duricとアンダーセン実験的な[3ページ]RFC3952RTP Payloadは2004年12月にiLBCのためにスピーチをフォーマットします。

   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.

各フレームへのbitstream。 それほど敏感でないビット(クラス2)はクラスの後に1ビット置かれます。 最も敏感でないビット(クラス3)は各フレームのためにbitstreamの端に置かれます。

   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/30msを見て、各クラスのために長さのケースを縁どってください: 1ビットが合計6/8バイト(48/64ビット)占領するクラス、2ビットが8/12バイト(64/96ビット)占領するクラス、および3ビットが24/30バイト(191/239ビット)占領するクラス。 ビットのこの分配は不ぞろいなレベル保護(ULP)の使用を可能にします。 詳細な噛み付いている配分は以下のテーブルに示されます。 量子化インデックスが、より多くのクラスの間に配布されるとき、より重要なビットは最も低いクラスのものです。

Duric & Andersen              Experimental                      [Page 4]

RFC 3952           RTP Payload Format for iLBC Speech      December 2004

Duricとアンダーセン実験的な[4ページ]RFC3952RTP Payloadは2004年12月にiLBCのためにスピーチをフォーマットします。

   Bitstream structure:

Bitstream構造:

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

------------------------------------------------------------------+ パラメタ| ビットクラス<1、2、3>。| | 20msフレーム| 30msフレーム| ----------------------------------+---------------+---------------+ 分裂1| 6 <6、0、0>。| 6 <6、0、0>。| LSF1分裂2| 7 <7、0、0>。| 7 <7、0、0>。| LSF分裂3| 7 <7、0、0>。| 7 <7、0、0>。| ------------------+---------------+---------------+ 分裂1| Na(Applでない。)| 6 <6、0、0>。| LSF2分裂2| Na| 7 <7、0、0>。| 分裂3| Na| 7 <7、0、0>。| ------------------+---------------+---------------+ 合計| 20 <20、0、0>。| 40 <40、0、0>。| ----------------------------------+---------------+---------------+ ブロックのクラス。 | 2 <2、0、0>。| 3 <3、0、0>。| ----------------------------------+---------------+---------------+ 位置22のサンプルセグメント| 1 <1、0、0>。| 1 <1、0、0>。| ----------------------------------+---------------+---------------+ 位取り因数州の符号化器| 6 <6、0、0>。| 6 <6、0、0>。| ----------------------------------+---------------+---------------+ サンプル0| 3 <0、1、2>。| 3 <0、1、2>。| サンプル1であると量子化されます。| 3 <0、1、2>。| 3 <0、1、2>。| 残差: | : : | : : | 州: | : : | : : | サンプル: | : : | : : | サンプル56| 3 <0、1、2>。| 3 <0、1、2>。| サンプル57| Na| 3 <0、1、2>。| ------------------+---------------+---------------+ 合計| 171 <0、57,114>| 174 <0、58,116>| ----------------------------------+---------------+---------------+ ステージ1| 7 <6、0、1>。| 7 <4、2、1>。| 22/23ステージ2へのCB| 7 <0、0、7>。| 7 <0、0、7>。| サンプルブロックStage3| 7 <0、0、7>。| 7 <0、0、7>。| ------------------+---------------+---------------+ 合計| 21 <6、0、15>。| 21 <4、2、15>。| ----------------------------------+---------------+---------------+ ステージ1| 5 <2、0、3>。| 5 <1、1、3>。| 22/23舞台2に獲得してください。| 4 <1、1、2>。| 4 <1、1、2>。| サンプルブロックStage3| 3 <0、0、3>。| 3 <0、0、3>。| ------------------+---------------+---------------+ 合計| 12 <3、1、8>。| 12 <2、2、8>。| ----------------------------------+---------------+---------------+ ステージ1| 8 <7、0、1>。| 8 <6、1、1>。| サブブロック1Stage2| 7 <0、0、7>。| 7 <0、0、7>。| ステージ3| 7 <0、0、7>。| 7 <0、0、7>。| ------------------+---------------+---------------+

Duric & Andersen              Experimental                      [Page 5]

RFC 3952           RTP Payload Format for iLBC Speech      December 2004

Duricとアンダーセン実験的な[5ページ]RFC3952RTP Payloadは2004年12月にiLBCのためにスピーチをフォーマットします。

                            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>

ステージ1| 8 <0、0、8>。| 8 <0、7、1>。| サブブロック2Stage2| 8 <0、0、8>。| 8 <0、0、8>。| インデックスリストは3を上演します。| 8 <0、0、8>。| 8 <0、0、8>。| CBのために------------------+---------------+---------------+ サブブロックStage1| Na| 8 <0、7、1>。| サブブロック3Stage2| Na| 8 <0、0、8>。| ステージ3| Na| 8 <0、0、8>。| ------------------+---------------+---------------+ ステージ1| Na| 8 <0、7、1>。| サブブロック4Stage2| Na| 8 <0、0、8>。| ステージ3| Na| 8 <0、0、8>。| ------------------+---------------+---------------+ 合計| 46 <7、0、39>。| 94 <6、22、66>。| ----------------------------------+---------------+---------------+ ステージ1| 5 <1、2、2>。| 5 <1、2、2>。| サブブロック1Stage2| 4 <1、1、2>。| 4 <1、2、1>。| ステージ3| 3 <0、0、3>。| 3 <0、0、3>。| ------------------+---------------+---------------+ ステージ1| 5 <1、1、3>。| 5 <0、2、3>。| サブブロック2Stage2| 4 <0、2、2>。| 4 <0、2、2>。| ステージ3| 3 <0、0、3>。| 3 <0、0、3>。| 獲得します。------------------+---------------+---------------+ サブブロックStage1| Na| 5 <0、1、4>。| サブブロック3Stage2| Na| 4 <0、1、3>。| ステージ3| Na| 3 <0、0、3>。| ------------------+---------------+---------------+ ステージ1| Na| 5 <0、1、4>。| サブブロック4Stage2| Na| 4 <0、1、3>。| ステージ3| Na| 3 <0、0、3>。| ------------------+---------------+---------------+ 合計| 24 <3、6、15>。| 48 <2、12、34>。| ------------------------------------------------------------------- 空のフレームインディケータ| 1 <0、0、1>。| 1 <0、0、1>。| ------------------------------------------------------------------- 合計304<48、64,192>400<64、96,240>。

   Table 3.1 The bitstream definition for iLBC.

テーブル3.1 iLBCのためのbitstream定義。

   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.

ペイロードにpacketizedされると、それらがテーブルで指定されたとき、1ビットを分類しなければならないすべてのクラスが注文されます(先端と下にから)。 さらに、すべてのクラスは2ビットそうしなければなりません。分類されたコネが同じ連続したオーダーであったに違いないなら3ビット分類されていて(先端と下にからの)すべてのクラスになってください。

3.2.  Multiple iLBC frames in a RTP packet

3.2. RTPパケットの複数のiLBCフレーム

   More than one iLBC frame may be included in a single RTP packet by a
   sender.

1個以上のiLBCフレームが単一のRTPパケットで送付者によって入れられるかもしれません。

Duric & Andersen              Experimental                      [Page 6]

RFC 3952           RTP Payload Format for iLBC Speech      December 2004

Duricとアンダーセン実験的な[6ページ]RFC3952RTP Payloadは2004年12月にiLBCのためにスピーチをフォーマットします。

   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 SHOULD NOTはRTPトランスポート・プロトコルのMTUをうまくはめ込むよりiLBCが単一のRTPパケットで縁どる以上を含んでいます。

   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 同じパケットの中に異なったモード(20msと30ms)のフレームを含んではいけません。

   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パケットの中に含まれたフレームの数がアプリケーションと一致しているのは、RECOMMENDEDです。 例えば、電話と遅れが重要である他のリアルタイムのアプリケーションでは、1パケットあたりのフレームの量によって、遅れは低いです(すなわち、より少ない1パケットあたりのフレームに、遅れは、より低いです)。 神経の鈍いストリーミングのメッセージングアプリケーション、1つまたは以上が、帯域幅にリンクを抑制するか、または延着していますが、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パケットの中で八重奏の総数を数えて、フレーム(1フレームあたり32/50)あたりの予想された八重奏の数に八重奏カウントを割ることです。

4.  IANA Considerations

4. IANA問題

   One new MIME sub-type as described in this section has been
   registered.

このセクションで説明される1つの新しいMIMEサブタイプが示されました。

4.1.  Storage Mode

4.1. 格納モード

   The storage mode is used for storing speech frames (e.g., as a file
   or email attachment).

格納モードは、スピーチフレーム(例えば、ファイルかメール付属としての)を格納するのに使用されます。

   +------------------+
   | Header           |
   +------------------+
   | Speech frame 1   |
   +------------------+
   :                  :
   +------------------+
   | Speech frame n   |
   +------------------+

+------------------+ | ヘッダー| +------------------+ | スピーチフレーム1| +------------------+ : : +------------------+ | スピーチフレームn| +------------------+

   Figure 2, Storage format diagram

図2、Storage形式ダイヤグラム

Duric & Andersen              Experimental                      [Page 7]

RFC 3952           RTP Payload Format for iLBC Speech      December 2004

Duricとアンダーセン実験的な[7ページ]RFC3952RTP Payloadは2004年12月にiLBCのためにスピーチをフォーマットします。

   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 または、「30msに関して、サイズモードを縁どってください」という#!iLBC30\n」、「0×23 0×21 0×69 0x4C0x42 0×43、0×33、0×30 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に関して、サイズモードを縁どってください」という#!iLBC20\n」、「0×23 0×21 0×69 0x4C0x42 0×43、0×32、0×30 0x0A、」 16進では、形成してください。

   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]で定義されるように「空のフレーム」としてトランスミッションでなくされたスピーチフレームを格納しなければなりません。

4.2.  MIME Registration of iLBC

4.2. iLBCのMIME登録

   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を調節してください。 フレームの倍数がサイズであったならSHOULDを調節してください。 この属性は、たぶんオーディオデータだけには重要ですが、理解できるなら、他のメディアタイプで使用されるかもしれません。 それは、メディア属性であり、charsetに依存していません。 この属性がRFC2327の後に導入されたことに注意してください。そうすれば、非アップデートされた実現はこの属性を無視するでしょう。

   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か30ms)。 値は、0と、20と30であるかもしれません(0が予約されているところでは、都合のよい20msフレーム・サイズのための20個のスタンドと都合のよい30msのための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

問題をコード化します: このタイプは転送のためにRFCのセクション4.1で説明されるRTP(RFC3550)と格納されたファイル方法の両方を通して定義されます。

Duric & Andersen              Experimental                      [Page 8]

RFC 3952           RTP Payload Format for iLBC Speech      December 2004

Duricとアンダーセン実験的な[8ページ]RFC3952RTP Payloadは2004年12月にiLBCのためにスピーチをフォーマットします。

            3952.  Audio data is binary data, and must be encoded for
            non-binary transport; the Base64 encoding is suitable for
            email.

3952. オーディオデータを2進のデータであり、非バイナリー輸送のためにコード化しなければなりません。 Base64コード化はメールに適しています。

   Security considerations:
            See Section 6 of RFC 3952.

セキュリティ問題: RFC3952のセクション6を見てください。

   Public specification:
            Please refer to RFC 3951 [1].

公共の仕様: RFC3951[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 「30msフレーム・サイズモード」#!iLBC30\n」、(0×23 0×21 0×69 0x4C0x42 0×43、16進の0×30 0x0A) o20がmsする0×33が」 #!サイズモードiLBC20を縁どっている、\n」(0×23 0×21 0×69 0x4C0x42 0×43、0×32、16進の0×30 0x0A)

            File extensions: lbc, LBC
            Macintosh file type code: none
            Object identifier or OID: none

ファイル拡張子: lbc、LBCマッキントッシュファイルの種類コード: なにも、Object識別子か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.

意図している用法: 一般的。 多くのVoIPアプリケーションがこのタイプを使用すると予想されます。

   Author/Change controller:
            alan.duric@telio.no
            IETF Audio/Video transport working group

コントローラを書くか、または変えてください: alan.duric@telio.no IETF Audio/ビデオ輸送ワーキンググループ

5.  Mapping To SDP Parameters

5. パラメタをSDPに写像します。

   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メディアで運ばれた情報はSession記述プロトコル(SDP)で[5]をさばきます。([5]は、RTPセッションについて説明するのに一般的に使用されます)。 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"に入ります。

Duric & Andersen              Experimental                      [Page 9]

RFC 3952           RTP Payload Format for iLBC Speech      December 2004

Duricとアンダーセン実験的な[9ページ]RFC3952RTP Payloadは2004年12月にiLBCのためにスピーチをフォーマットします。

   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 「モードは値と等しい」ので直接メディアタイプが結ぶMIMEからそれをコピーすることによって、「モード」というパラメタはSDP"a=fmtp"属性に入ります。

   When conveying information by SDP, the encoding name SHALL be "iLBC"
   (the same as the MIME subtype).

SDPで情報を伝達するとき、存在というコード化名のSHALL、"iLBC"です(MIME「副-タイプ」と同じ)。

   An example of the media representation in SDP for describing iLBC
   might be:

SDPのiLBCについて説明するメディア表現に関する例は以下の通りです。

      m=audio 49120 RTP/AVP 97
      a=rtpmap:97 iLBC/8000

オーディオの49120RTP/AVP97m=a=rtpmap: 97iLBC/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:

20msフレーム・サイズモードが使用されているなら、リモートiLBCエンコーダSHALLは、セミコロンが値がパラメタが「モード」であり、0と20であるかもしれない(0が都合のよい20msフレーム・サイズのための予約されるのと20個のスタンドであるところ)パラメタ=価値で分離しながら直接メディアタイプが結ぶMIMEからそれらをコピーすることによって、SDP"a=fmtp"属性における「モード」パラメタを受け取ります。 SDPの20msフレーム・サイズモードが使用されているときiLBCについて説明するメディア表現に関する例は以下の通りです。

      m=audio 49120 RTP/AVP 97
      a=rtpmap:97 iLBC/8000
      a=fmtp:97 mode=20

オーディオの49120RTP/AVP97m=a=rtpmap: 97iLBC/8000a=fmtp: 97モード=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.

「モード」パラメタの双方向のキャラクタを強調するのは重要です--双方向のセッションの両側は同じ「モード」値を使用しなければなりません。

   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.

申し出は申出人の最もよく使われる方法を含んでいます。 answererは答えに同じモードを含んでいることによってそのモードに同意するか、または異なったモードを含むかもしれません。 結果として起こるモードは帯域幅の下側が申し出と答えでモードであったなら双方でSHALLを使用しました。

   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モデムリンクの、または、より遅い)(下側のフレーム・サイズだけが働く)を利用するとき、これは重要です。

Duric & Andersen              Experimental                     [Page 10]

RFC 3952           RTP Payload Format for iLBC Speech      December 2004

Duricとアンダーセン実験的な[10ページ]RFC3952RTP Payloadは2004年12月にiLBCのためにスピーチをフォーマットします。

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

iLBCオペレーティング・モードを指定する目的にパラメタptimeを使用できません、どのモードを区別するかが使用されていようとしているのが(ptime=60、例えば、パケットが30msの2個のフレームか20msなどの3個のフレームを運ぶなら、区別するのはいつ不可能でしょうか)ある値に、不可能になるという事実のため。

   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属性に大文字と小文字を区別しないです。

6.  Security Considerations

6. セキュリティ問題

   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]などの外部のメカニズムがそのために使用されるかもしれません。 このペイロード形式と共に使用されるデータ圧縮は、適用された終わりから終わりです。 したがって、暗号化は圧縮の後に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.

潜在的サービスの否定の脅威は、zデータの符号化のために不均等な受信端末コンピュータの負荷を持っている圧縮のテクニックを使用することで存在しています。 攻撃者によって、流れの中への解読するために複雑な病理学的なデータグラムを注入して、受信機は積みすぎられるようになることができます。 しかしながら、本書では覆われたencodingsは少しの重要な非の一様性も示しません。

7.  References

7. 参照

7.1.  Normative References

7.1. 引用規格

   [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)」、RFC3951(2004年12月)。

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

[2] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、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.、フレディリック、R.、およびV.ジェーコブソン、「RTP:」 「リアルタイムのアプリケーションのためのトランスポート・プロトコル」、STD64、RFC3550、2003年7月。

Duric & Andersen              Experimental                     [Page 11]

RFC 3952           RTP Payload Format for iLBC Speech      December 2004

Duricとアンダーセン実験的な[11ページ]RFC3952RTP Payloadは2004年12月にiLBCのためにスピーチをフォーマットします。

   [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プロフィールと最小量があるテレビ会議システムは制御します」、STD65、RFC3551、2003年7月。

   [5]  Handley, M. and V. Jacobson, "SDP: Session Description
        Protocol", RFC 2327, April 1998.

[5] ハンドレー、M.、およびV.ジェーコブソン、「SDP:」 「セッション記述プロトコル」、RFC2327、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.とジーターとM.とカラーラ、E.とK.Norrman、「安全なリアルタイムのトランスポート・プロトコル」RFC3711(2004年3月)。

7.2.  Informative References

7.2. 有益な参照

   [7]  ITU-T Recommendation G.711, available online from the ITU
        bookstore at http://www.itu.int.

[7] ITU-T Recommendation G.711、利用可能である、 http://www.itu.int のITU書店から、オンラインです。

8.  Acknowledgements

8. 承認

   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、アラン・ジョンストン、およびジャン・フランソワMule。

Authors' Addresses

作者のアドレス

   Alan Duric
   Telio AS
   Stoperigt. 2
   Oslo, N-0250
   Norway

StoperigtとしてのアランDuric Telio。 2 N-0250オスロ(ノルウェー)

   Phone:  +47 21673505
   EMail:  alan.duric@telio.no

以下に電話をしてください。 +47 21673505はメールされます: alan.duric@telio.no

   Soren Vang Andersen
   Department of Communication Technology
   Aalborg University
   Fredrik Bajers Vej 7A
   9200 Aalborg
   Denmark

コミュニケーション技術オールボア大学フレドリックBajers Vej 7A9200オールボアデンマークのゾーレンバングアンダーセン部

   Phone:  ++45 9 6358627
   EMail:  sva@kom.auc.dk

以下に電話をしてください。 + +45 9 6358627メール: sva@kom.auc.dk

Duric & Andersen              Experimental                     [Page 12]

RFC 3952           RTP Payload Format for iLBC Speech      December 2004

Duricとアンダーセン実験的な[12ページ]RFC3952RTP Payloadは2004年12月にiLBCのためにスピーチをフォーマットします。

Full Copyright Statement

完全な著作権宣言文

   Copyright (C) The Internet Society (2004).

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

このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。

   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.

このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。

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はどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でIETF Documentsの権利に関するIETFの手順に関する情報を見つけることができます。

   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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。

   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機能のための基金は現在、インターネット協会によって提供されます。

Duric & Andersen              Experimental                     [Page 13]

Duricであって、アンダーセンExperimentalです。[13ページ]