RFC4298 日本語訳
4298 RTP Payload Format for BroadVoice Speech Codecs. J.-H. Chen, W.Lee, J. Thyssen. December 2005. (Format: TXT=30099 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group J.-H. Chen
Request for Comments: 4298 W. Lee
Category: Standards Track J. Thyssen
Broadcom Corporation
December 2005
ワーキンググループJ.-Hをネットワークでつないでください。 コメントを求めるチェンRequest: 4298年のW.リーカテゴリ: 標準化過程J.テュッセンBroadcom社の2005年12月
RTP Payload Format for BroadVoice Speech Codecs
BroadVoiceスピーチコーデックのためのRTP有効搭載量形式
Status of This Memo
このメモの状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2005).
Copyright(C)インターネット協会(2005)。
Abstract
要約
This document describes the RTP payload format for the BroadVoice(R) narrowband and wideband speech codecs. The narrowband codec, called BroadVoice16, or BV16, has been selected by CableLabs as a mandatory codec in PacketCable 1.5 and has a CableLabs specification. The document also provides specifications for the use of BroadVoice with MIME and the Session Description Protocol (SDP).
このドキュメントはBroadVoice(R)狭帯域と広帯域スピーチコーデックのためにRTPペイロード形式について説明します。 BroadVoice16、またはBV16と呼ばれる狭帯域コーデックは、義務的なコーデックとしてPacketCable1.5でCableLabsによって選択されて、CableLabs仕様を持っています。 また、ドキュメントはMIMEとSession記述プロトコル(SDP)をBroadVoiceの使用のための仕様に提供します。
Chen, et al. Standards Track [Page 1] RFC 4298 RTP Payload Format for BroadVoice December 2005
チェン、他 規格は2005年12月にBroadVoiceのためにRFC4298RTP有効搭載量形式を追跡します[1ページ]。
Table of Contents
目次
1. Introduction ....................................................2
2. Background ......................................................2
3. RTP Payload Format for BroadVoice16 Narrowband Codec ............3
3.1. BroadVoice16 Bit Stream Definition .........................4
3.2. Multiple BroadVoice16 Frames in an RTP Packet ..............5
4. RTP Payload Format for BroadVoice32 Wideband Codec ..............6
4.1. BroadVoice32 Bit Stream Definition .........................6
4.2. Multiple BroadVoice32 Frames in an RTP Packet ..............8
5. IANA Considerations .............................................8
5.1. MIME Registration of BroadVoice16 for RTP ..................9
5.2. MIME Registration of BroadVoice32 for RTP ..................9
6. Mapping to SDP Parameters ......................................10
6.1. Offer-Answer Model Considerations .........................11
7. Security Considerations ........................................11
8. Congestion Control .............................................11
9. Acknowledgements ...............................................11
10. References ....................................................12
10.1. Normative References .....................................12
10.2. Informative References ...................................12
1. 序論…2 2. バックグラウンド…2 3. BroadVoice16狭帯域コーデックのためのRTP有効搭載量形式…3 3.1. BroadVoice16ビットストリーム定義…4 3.2. 複数のBroadVoice16がRTPパケットで縁どっています…5 4. BroadVoice32広帯域コーデックのためのRTP有効搭載量形式…6 4.1. BroadVoice32ビットストリーム定義…6 4.2. 複数のBroadVoice32がRTPパケットで縁どっています…8 5. IANA問題…8 5.1. RTPのためにBroadVoice16の登録をまねてください…9 5.2. RTPのためにBroadVoice32の登録をまねてください…9 6. SDPパラメタに写像します。10 6.1. 申し出答えモデル問題…11 7. セキュリティ問題…11 8. 混雑コントロール…11 9. 承認…11 10. 参照…12 10.1. 標準の参照…12 10.2. 有益な参照…12
1. Introduction
1. 序論
This document specifies the payload format for sending BroadVoice encoded speech or audio signals using the Real-time Transport Protocol (RTP) [1]. The sender may send one or more BroadVoice codec data frames per packet, depending on the application scenario, based on network conditions, bandwidth availability, delay requirements, and packet-loss tolerance.
このドキュメントはレアル-時間Transportプロトコル(RTP)[1]を使用することでコード化されたスピーチか音声信号をBroadVoiceに送るのにペイロード形式を指定します。 送付者は1パケットあたり1個以上のBroadVoiceコーデックデータフレームを送るかもしれません、アプリケーションシナリオによって、ネットワーク状態に基づいて、帯域幅の有用性、遅れ要件、およびパケット損失寛容。
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 RFC 2119 [2].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[2]で説明されるように本書では解釈されることであるべきですか?
2. Background
2. バックグラウンド
BroadVoice is a speech codec family developed for VoIP (Voice over Internet Protocol) applications, including Voice over Cable, Voice over DSL, and IP phone applications. BroadVoice achieves high speech quality with a low coding delay and relatively low codec complexity.
BroadVoiceはVoIP(インターネットプロトコルの上の声)アプリケーションのために発展するスピーチコーデック家族です、Cableの上のVoice、DSLの上のVoice、およびIP電話アプリケーションを含んでいて。 BroadVoiceは低いコード化遅れと比較的低いコーデックの複雑さで高いスピーチ品質を獲得します。
The BroadVoice codec family contains two codec versions. The narrowband version of BroadVoice, called BroadVoice16 [3], or BV16 for short, encodes 8 kHz-sampled narrowband speech at a bit rate of 16 kilobits/second, or 16 kbit/s. The wideband version of BroadVoice, called BroadVoice32, or BV32, encodes 16 kHz-sampled wideband speech at a bit rate of 32 kbit/s. The BV16 and BV32 use
BroadVoiceコーデック家は2つのコーデックバージョンを含みます。 BroadVoice16[3]、または略してBV16と呼ばれるBroadVoiceのバージョンが8のkHzで抽出された狭帯域スピーチをコード化する狭帯域は16 2番目、またはキロビット/16kbit/sについて少し評価します。 BroadVoice32、またはBV32と呼ばれるBroadVoiceのバージョンが16のkHzで抽出された広帯域スピーチをコード化する広帯域は32kbit/sについて少し評価します。 BV16とBV32使用
Chen, et al. Standards Track [Page 2] RFC 4298 RTP Payload Format for BroadVoice December 2005
チェン、他 規格は2005年12月にBroadVoiceのためにRFC4298RTP有効搭載量形式を追跡します[2ページ]。
very similar (but not identical) coding algorithms; they share most of their algorithm modules.
非常に同様の、そして、(同じでない)のコード化アルゴリズム。 彼らはそれらのアルゴリズムモジュールの大部分を共有します。
To minimize the delay in real-time two-way communications, both the BV16 and BV32 encode speech with a very small frame size of 5 ms without using any look ahead. By using a packet size as small as 5 ms if necessary, this allows VoIP systems based on BroadVoice to have a very low end-to-end system delay.
リアルタイムの双方向通信の遅れを最小にするために、先でどんな外観も使用しないで、BV16とBV32の両方が5msの非常にわずかなフレーム・サイズでスピーチをコード化します。 必要なら、5msと同じくらい小さくパケットサイズを使用することによって、BroadVoiceに基づくVoIPシステムはこれで安値が終わるために非常に終わっているシステム遅れを持つことができます。
BroadVoice also has relatively low codec complexity when compared with ITU-T standard speech codecs based on CELP (Coded Excited Linear Prediction), such as G.728, G.729, G.723.1, and G.722.2. Full-duplex implementations of the BV16 and BV32 take around 12 and 17 MIPS, respectively, on general-purpose 16-bit fixed-point digital signal processors (DSPs). The total memory footprints of the BV16 and BV32, including program size, data tables, and data RAM, are around 12 kwords each, or 24 kbytes.
また、BroadVoiceには、CELP(Excited Linear Predictionをコード化する)に基づくITU-T標準のスピーチコーデックと比べると、比較的低いコーデックの複雑さがあります、G.728や、G.729や、G.723.1や、G.722.2などのように。 BV16とBV32の全二重実現はおよそ12と17MIPSに、それぞれ取ります、汎用の16ビットの定点ディジタル信号プロセッサ(DSPs)の上で。 プログラムサイズ、データテーブル、およびデータRAMを含むBV16とBV32の総メモリーフットプリントはそれぞれ、または24キロバイトおよそ12kwordsです。
The PacketCable(TM) project of Cable Television Laboratories, Inc. (CableLabs(R)) has chosen the BV16 codec for use in VoIP telephone services provided by cable operators. More specifically, the BV16 codec was selected as one of the mandatory audio codecs in the PacketCable(TM) 1.5 Audio/Video Codecs Specification [8] and has been implemented by multiple vendors. The wideband version (BV32) has been developed by Broadcom but has not yet appeared in a public specification; since it is technically very similar to BV16, its payload format is also defined in this document.
PacketCable(TM)はCable Television研究所Inc.を突出させています。(CableLabs(R))はケーブルオペレータによって提供されたVoIP電話サービスにおける使用のためのBV16コーデックを選びました。 より明確に、BV16コーデックは、義務的なオーディオコーデックの1つとしてPacketCable(TM)1.5Audio/ビデオCodecs Specification[8]で選択されて、複数の業者によって実行されました。 広帯域バージョン(BV32)は、Broadcomによって開発されましたが、公共の仕様にまだ現れていません。 それが技術的にBV16と非常に同様であるので、また、ペイロード書式は本書では定義されます。
3. RTP Payload Format for BroadVoice16 Narrowband Codec
3. BroadVoice16狭帯域コーデックのためのRTP有効搭載量形式
The BroadVoice16 uses 5 ms frames and a sampling frequency of 8 kHz, so the RTP timestamp MUST be in units of 1/8000 of a second. The RTP timestamp indicates the sampling instant of the oldest audio sample represented by the frame(s) present in the payload. The RTP payload for the BroadVoice16 has the format shown in the figure below. No additional header specific to this payload format is required.
BroadVoice16が5個のmsフレームと8kHzのサンプリング周波数を使用するので、RTPタイムスタンプが1秒の1/8000のユニットにあるに違いありません。 RTPタイムスタンプはペイロードの現在のフレームによって表される中で最も古いオーディオのサンプルの標本抽出の瞬間を示します。 BroadVoice16のための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 [1] |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| |
| one or more frames of BroadVoice16 |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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ヘッダー[1]| +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | | | BroadVoice16の1個以上のフレーム| | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Chen, et al. Standards Track [Page 3] RFC 4298 RTP Payload Format for BroadVoice December 2005
チェン、他 規格は2005年12月にBroadVoiceのためにRFC4298RTP有効搭載量形式を追跡します[3ページ]。
If BroadVoice16 is used for applications with silence compression, the first BroadVoice16 packet after a silence period during which packets have not been transmitted contiguously SHOULD have the marker bit in the RTP data header set to one. The marker bit in all other packets is zero. Applications without silence suppression MUST set the marker bit to zero.
BroadVoice16がアプリケーションに使用されるなら、沈黙圧縮、パケットが近接して伝えられていない沈黙の期間の後の最初のBroadVoice16パケットがあるので、SHOULDはRTPデータヘッダーのマーカービットを1つにセットさせます。 他のすべてのパケットのマーカービットはゼロです。 沈黙抑圧のないアプリケーションはマーカービットをゼロに設定しなければなりません。
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.
この新しいパケット・フォーマットのためのRTPペイロードタイプの課題は、このドキュメントの範囲の外にあって、ここで指定されないでしょう。 特定のクラスのアプリケーションのためのRTPプロフィールがこのコード化のためのペイロードタイプを選任すると予想されるものとするか、またはそれが完了していないなら、ダイナミックレンジにおけるペイロードタイプは選ばれるものとします。
3.1. BroadVoice16 Bit Stream Definition
3.1. BroadVoice16ビットストリーム定義
The BroadVoice16 encoder operates on speech frames of 5 ms corresponding to 40 samples at a sampling rate of 8000 samples per second. For every 5 ms frame, the encoder encodes the 40 consecutive audio samples into 80 bits, or 10 octets. Thus, the 80-bit bit stream produced by the BroadVoice16 for each 5 ms frame is octet- aligned, and no padding bits are required. The bit allocation for the encoded parameters of the BroadVoice16 codec is listed in the following table.
BroadVoice16エンコーダは1秒あたり8000個のサンプルの標本抽出率で40個のサンプルに対応する5msのスピーチフレームを作動させます。 あらゆる5msフレームに関しては、エンコーダは40個の連続したオーディオのサンプルを80ビット、または10の八重奏にコード化します。 したがって、BroadVoice16によって作成された80ビットのビットストリームはそれぞれの5msフレームが八重奏であるので、並びました、そして、詰め物ビットは全く必要ではありません。 BroadVoice16コーデックのコード化されたパラメタのための噛み付いている配分は以下のテーブルに記載されています。
Encoded Parameter Codeword Number of bits per frame
------------------------------------------------------------
Line Spectrum Pairs L0,L1 7+7=14
Pitch Lag PL 7
Pitch Gain PG 5
Log-Gain LG 4
Excitation Vectors V0,...,V9 5*10=50
------------------------------------------------------------
Total: 80 bits
1フレームあたりのビットのコード化されたParameter Codeword Number------------------------------------------------------------ 線スペクトルペアL0、L1 7+7=14は立ち遅れPL7ピッチ利得未成年者不適当映画5ログ利得LG4励振ベクトルV0を売り込みます…V9 5*10=50------------------------------------------------------------ 以下を合計してください。 80ビット
The mapping of the encoded parameters in an 80-bit BroadVoice16 data frame is defined in the following figure. This figure shows the bit packing in "network byte order", also known as big-endian order. The bits of each 32-bit word are numbered 0 to 31, with the most significant bit on the left and numbered 0. The octets (bytes) of each word are transmitted with the most significant octet first. The bits of the data field for each encoded parameter are numbered in the same order, with the most significant bit on the left.
80ビットのBroadVoice16データフレームのコード化されたパラメタに関するマッピングは以下の図で定義されます。 この図は「ネットワークバイトオーダー」を大勢引きつけて、また、ビッグエンディアンオーダーとして知られていた状態でビットを示しています。 それぞれの32ビットの単語のビットは0〜31に付番されます、左の、そして、番号付の0で最も重要なビットで。 それぞれの単語の八重奏(バイト)は最初に、最も重要な八重奏で伝えられます。 同次でそれぞれのコード化されたパラメタのためのデータ・フィールドのビットに付番します、左で最も重要なビットで。
Chen, et al. Standards Track [Page 4] RFC 4298 RTP Payload Format for BroadVoice December 2005
チェン、他 規格は2005年12月にBroadVoiceのためにRFC4298RTP有効搭載量形式を追跡します[4ページ]。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| L0 | L1 | PL | PG | LG | V0|
| | | | | | |
|0 1 2 3 4 5 6|0 1 2 3 4 5 6|0 1 2 3 4 5 6|0 1 2 3 4|0 1 2 3|0 1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| V0 | V1 | V2 | V3 | V4 | V5 | V6 |
| | | | | | | |
|2 3 4|0 1 2 3 4|0 1 2 3 4|0 1 2 3 4|0 1 2 3 4|0 1 2 3 4|0 1 2 3|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V| V7 | V8 | V9 |
|6| | | |
|4|0 1 2 3 4|0 1 2 3 4|0 1 2 3 4|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | L0| L1| PL| 未成年者不適当映画| LG| V0| | | | | | | | |0 1 2 3 4 5 6|0 1 2 3 4 5 6|0 1 2 3 4 5 6|0 1 2 3 4|0 1 2 3|0 1| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | V0| V1| V2| V3| V4| V5| V6| | | | | | | | | |2 3 4|0 1 2 3 4|0 1 2 3 4|0 1 2 3 4|0 1 2 3 4|0 1 2 3 4|0 1 2 3| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |V| V7| V8| V9| |6| | | | |4|0 1 2 3 4|0 1 2 3 4|0 1 2 3 4| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: BroadVoice16 bit packing
図1: BroadVoice16はパッキングに噛み付きました。
3.2. Multiple BroadVoice16 Frames in an RTP Packet
3.2. RTPパケットの複数のBroadVoice16フレーム
More than one BroadVoice16 frame MAY be included in a single RTP packet by a sender. Senders have the following additional restrictions:
1個以上のBroadVoice16フレームが単一のRTPパケットで送付者によって入れられるかもしれません。 送付者には、以下の追加制限があります:
o SHOULD NOT include more BroadVoice16 frames in a single RTP
packet than will fit in the MTU of the RTP.
o SHOULD NOTはRTPのMTUをうまくはめ込むよりBroadVoice16が単一のRTPパケットで縁どる以上を含んでいます。
o MUST NOT split a BroadVoice16 frame between RTP packets.
o RTPパケットの間のBroadVoice16フレームを分けてはいけません。
o BroadVoice16 frames in an RTP packet MUST be consecutive.
o RTPパケットのBroadVoice16フレームは連続しているに違いありません。
Since multiple BroadVoice16 frames in an RTP packet MUST be consecutive, and since BroadVoice16 has a fixed frame size of 5 ms, recovering the timestamps of all frames within a packet is easy. The oldest frame within an RTP packet has the same timestamp as the RTP packet, as mentioned above. To obtain the timestamp of the frame that is N frames later than the oldest frame in the packet, one simply adds 5*N ms worth of time units to the timestamp of the RTP packet.
RTPパケットの複数のBroadVoice16フレームが連続するに違いなくて、BroadVoice16には5msの固定フレーム・サイズがあるので、パケットの中のすべてのフレームに関するタイムスタンプを回復するのは簡単です。 RTPパケットの中の最も古いフレームには、RTPパケットと同じタイムスタンプが上に言及されるようにあります。 パケットで最も古いフレームより遅くNフレームであるフレームに関するタイムスタンプを得るために、人は単にタイム・ユニットのRTPパケットに関するタイムスタンプに価値があった状態で5*N msを加えます。
It is RECOMMENDED that the number of frames contained within an RTP packet be consistent with the application. For example, in a telephony application where delay is important, the fewer frames per packet, the lower the delay; whereas, for a delay insensitive streaming or messaging application, many frames per packet would be acceptable.
RTPパケットの中に含まれたフレームの数がアプリケーションと一致しているのは、RECOMMENDEDです。 例えば、遅れが重要である電話アプリケーション、より少ない1パケットあたりのフレームでは、遅れは、より低いです。 ところが、遅れにおいて、神経の鈍いストリーミングかメッセージングアプリケーション、多くの1パケットあたりのフレームが許容できるでしょう。
Chen, et al. Standards Track [Page 5] RFC 4298 RTP Payload Format for BroadVoice December 2005
チェン、他 規格は2005年12月にBroadVoiceのためにRFC4298RTP有効搭載量形式を追跡します[5ページ]。
Information describing the number of frames contained in an RTP packet is not transmitted as part of the RTP payload. The only way to determine the number of BroadVoice16 frames is to count the total number of octets within the RTP payload, and divide the octet count by 10.
RTPパケットに含まれたフレームの数について説明する情報がRTPペイロードの一部として伝えられません。 BroadVoice16フレームの数を測定する唯一の方法は、RTPペイロードの中に八重奏の総数を数えて、八重奏カウントを10に割ることです。
4. RTP Payload Format for BroadVoice32 Wideband Codec
4. BroadVoice32広帯域コーデックのためのRTP有効搭載量形式
The BroadVoice32 uses 5 ms frames and a sampling frequency of 16 kHz, so the RTP timestamp MUST be in units of 1/16000 of a second. The RTP timestamp indicates the sampling instant of the oldest audio sample represented by the frame(s) present in the payload. The RTP payload for the BroadVoice32 has the format shown in the figure below. No additional header specific to this payload format is required.
BroadVoice32が5個のmsフレームと16kHzのサンプリング周波数を使用するので、RTPタイムスタンプが1秒の1/16000のユニットにあるに違いありません。 RTPタイムスタンプはペイロードの現在のフレームによって表される中で最も古いオーディオのサンプルの標本抽出の瞬間を示します。 BroadVoice32のための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 [1] |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| |
| one or more frames of BroadVoice32 |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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ヘッダー[1]| +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | | | BroadVoice32の1個以上のフレーム| | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
If BroadVoice32 is used for applications with silence compression, the first BroadVoice32 packet after a silence period during which packets have not been transmitted contiguously SHOULD have the marker bit in the RTP data header set to one. The marker bit in all other packets is zero. Applications without silence suppression MUST set the marker bit to zero.
BroadVoice32がアプリケーションに使用されるなら、沈黙圧縮、パケットが近接して伝えられていない沈黙の期間の後の最初のBroadVoice32パケットがあるので、SHOULDはRTPデータヘッダーのマーカービットを1つにセットさせます。 他のすべてのパケットのマーカービットはゼロです。 沈黙抑圧のないアプリケーションはマーカービットをゼロに設定しなければなりません。
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.
この新しいパケット・フォーマットのためのRTPペイロードタイプの課題は、このドキュメントの範囲の外にあって、ここで指定されないでしょう。 特定のクラスのアプリケーションのためのRTPプロフィールがこのコード化のためのペイロードタイプを選任すると予想されるものとするか、またはそれが完了していないなら、ダイナミックレンジにおけるペイロードタイプは選ばれるものとします。
4.1. BroadVoice32 Bit Stream Definition
4.1. BroadVoice32ビットストリーム定義
The BroadVoice32 encoder operates on speech frames of 5 ms corresponding to 80 samples at a sampling rate of 16000 samples per second. For every 5 ms frame, the encoder encodes the 80 consecutive audio samples into 160 bits, or 20 octets. Thus, the 160-bit bit stream produced by the BroadVoice32 for each 5 ms frame is octet- aligned, and no padding bits are required. The bit allocation for
BroadVoice32エンコーダは1秒あたり16000個のサンプルの標本抽出率で80個のサンプルに対応する5msのスピーチフレームを作動させます。 あらゆる5msフレームに関しては、エンコーダは80個の連続したオーディオのサンプルを160ビット、または20の八重奏にコード化します。 したがって、BroadVoice32によって作成された160ビットのビットストリームはそれぞれの5msフレームが八重奏であるので、並びました、そして、詰め物ビットは全く必要ではありません。 配分に噛み付きます。
Chen, et al. Standards Track [Page 6] RFC 4298 RTP Payload Format for BroadVoice December 2005
チェン、他 規格は2005年12月にBroadVoiceのためにRFC4298RTP有効搭載量形式を追跡します[6ページ]。
the encoded parameters of the BroadVoice32 codec is listed in the
following table.
Number of bits
Encoded Parameter Codeword per frame
---------------------------------------------------------------
Line Spectrum Pairs L0,L1,L2 7+5+5=17
Pitch Lag PL 8
Pitch Gain PG 5
Log-Gains (1st & 2nd subframes) LG0,LG1 5+5=10
Excitation Vectors (1st subframe) VA0,...,VA9 6*10=60
Excitation Vectors (2nd subframe) VB0,...,VB9 6*10=60
---------------------------------------------------------------
Total: 160 bits
BroadVoice32コーデックのコード化されたパラメタは以下のテーブルにリストアップされています。 1フレームあたりのビットEncoded Parameter Codewordの数--------------------------------------------------------------- 線SpectrumペアL0、L1、L2 7+5+5は17Pitch Lag PL8Pitch Gain未成年者不適当映画5Log-利得(1番目と2番目の「副-フレーム」)LG0と等しいです、10Excitation Vectors(最初の「副-フレーム」)のLG1 5+5=VA0…VA9 6*10=60Excitation Vectors(2番目の「副-フレーム」)VB0…VB9 6*10=60--------------------------------------------------------------- 以下を合計してください。 160ビット
The mapping of the encoded parameters in a 160-bit BroadVoice32 data frame is defined in the following figure. This figure shows the bit packing in "network byte order", also known as big-endian order. The bits of each 32-bit word are numbered 0 to 31, with the most significant bit on the left and numbered 0. The octets (bytes) of each word are transmitted with the most significant octet first. The bits of the data field for each encoded parameter are numbered in the same order, with the most significant bit on the left.
160ビットのBroadVoice32データフレームのコード化されたパラメタに関するマッピングは以下の図で定義されます。 この図は「ネットワークバイトオーダー」を大勢引きつけて、また、ビッグエンディアンオーダーとして知られていた状態でビットを示しています。 それぞれの32ビットの単語のビットは0〜31に付番されます、左の、そして、番号付の0で最も重要なビットで。 それぞれの単語の八重奏(バイト)は最初に、最も重要な八重奏で伝えられます。 同次でそれぞれのコード化されたパラメタのためのデータ・フィールドのビットに付番します、左で最も重要なビットで。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| L0 | L1 | L2 | PL | PG |LG0|
| | | | | | |
|0 1 2 3 4 5 6|0 1 2 3 4|0 1 2 3 4|0 1 2 3 4 5 6 7|0 1 2 3 4|0 1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LG0 | LG1 | VA0 | VA1 | VA2 | VA3 |
| | | | | | |
|2 3 4|0 1 2 3 4|0 1 2 3 4 5|0 1 2 3 4 5|0 1 2 3 4 5|0 1 2 3 4 5|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VA4 | VA5 | VA6 | VA7 | VA8 |VA9|
| | | | | | |
|0 1 2 3 4 5|0 1 2 3 4 5|0 1 2 3 4 5|0 1 2 3 4 5|0 1 2 3 4 5|0 1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VA9 | VB0 | VB1 | VB2 | VB3 | VB4 |
| | | | | | |
|2 3 4 5|0 1 2 3 4 5|0 1 2 3 4 5|0 1 2 3 4 5|0 1 2 3 4 5|0 1 2 3|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|VB4| VB5 | VB6 | VB7 | VB8 | VB9 |
| | | | | | |
|4 5|0 1 2 3 4 5|0 1 2 3 4 5|0 1 2 3 4 5|0 1 2 3 4 5|0 1 2 3 4 5|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | L0| L1| L2| PL| 未成年者不適当映画|LG0| | | | | | | | |0 1 2 3 4 5 6|0 1 2 3 4|0 1 2 3 4|0 1 2 3 4 5 6 7|0 1 2 3 4|0 1| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LG0| LG1| VA0| VA1| VA2| VA3| | | | | | | | |2 3 4|0 1 2 3 4|0 1 2 3 4 5|0 1 2 3 4 5|0 1 2 3 4 5|0 1 2 3 4 5| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | VA4| VA5| VA6| VA7| VA8|VA9| | | | | | | | |0 1 2 3 4 5|0 1 2 3 4 5|0 1 2 3 4 5|0 1 2 3 4 5|0 1 2 3 4 5|0 1| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | VA9| VB0| VB1| VB2| VB3| VB4| | | | | | | | |2 3 4 5|0 1 2 3 4 5|0 1 2 3 4 5|0 1 2 3 4 5|0 1 2 3 4 5|0 1 2 3| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |VB4| VB5| VB6| VB7| VB8| VB9| | | | | | | | |4 5|0 1 2 3 4 5|0 1 2 3 4 5|0 1 2 3 4 5|0 1 2 3 4 5|0 1 2 3 4 5| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: BroadVoice32 bit packing
図2: BroadVoice32はパッキングに噛み付きました。
Chen, et al. Standards Track [Page 7] RFC 4298 RTP Payload Format for BroadVoice December 2005
チェン、他 規格は2005年12月にBroadVoiceのためにRFC4298RTP有効搭載量形式を追跡します[7ページ]。
4.2. Multiple BroadVoice32 Frames in an RTP Packet
4.2. RTPパケットの複数のBroadVoice32フレーム
More than one BroadVoice32 frame MAY be included in a single RTP packet by a sender. Senders have the following additional restrictions:
1個以上のBroadVoice32フレームが単一のRTPパケットで送付者によって入れられるかもしれません。 送付者には、以下の追加制限があります:
o SHOULD NOT include more BroadVoice32 frames in a single RTP
packet than will fit in the MTU of the RTP.
o SHOULD NOTはRTPのMTUをうまくはめ込むよりBroadVoice32が単一のRTPパケットで縁どる以上を含んでいます。
o MUST NOT split a BroadVoice32 frame between RTP packets.
o RTPパケットの間のBroadVoice32フレームを分けてはいけません。
o BroadVoice32 frames in an RTP packet MUST be consecutive.
o RTPパケットのBroadVoice32フレームは連続しているに違いありません。
Since multiple BroadVoice32 frames in an RTP packet MUST be consecutive, and since BroadVoice32 has a fixed frame size of 5 ms, recovering the timestamps of all frames within a packet is easy. The oldest frame within an RTP packet has the same timestamp as the RTP packet, as mentioned above. To obtain the timestamp of the frame that is N frames later than the oldest frame in the packet, one simply adds 5*N ms worth of time units to the timestamp of the RTP packet.
RTPパケットの複数のBroadVoice32フレームが連続するに違いなくて、BroadVoice32には5msの固定フレーム・サイズがあるので、パケットの中のすべてのフレームに関するタイムスタンプを回復するのは簡単です。 RTPパケットの中の最も古いフレームには、RTPパケットと同じタイムスタンプが上に言及されるようにあります。 パケットで最も古いフレームより遅くNフレームであるフレームに関するタイムスタンプを得るために、人は単にタイム・ユニットのRTPパケットに関するタイムスタンプに価値があった状態で5*N msを加えます。
It is RECOMMENDED that the number of frames contained within an RTP packet be consistent with the application. For example, in a telephony application where delay is important, the fewer frames per packet, the lower the delay; whereas, for a delay insensitive streaming or messaging application, many frames per packet would be acceptable.
RTPパケットの中に含まれたフレームの数がアプリケーションと一致しているのは、RECOMMENDEDです。 例えば、遅れが重要である電話アプリケーション、より少ない1パケットあたりのフレームでは、遅れは、より低いです。 ところが、遅れにおいて、神経の鈍いストリーミングかメッセージングアプリケーション、多くの1パケットあたりのフレームが許容できるでしょう。
Information describing the number of frames contained in an RTP packet is not transmitted as part of the RTP payload. The only way to determine the number of BroadVoice32 frames is to count the total number of octets within the RTP payload, and divide the octet count by 20.
RTPパケットに含まれたフレームの数について説明する情報がRTPペイロードの一部として伝えられません。 BroadVoice32フレームの数を測定する唯一の方法は、RTPペイロードの中に八重奏の総数を数えて、八重奏カウントを20に割ることです。
5. IANA Considerations
5. IANA問題
Two new MIME sub-types, as described in this section, have been registered.
このセクションで説明される2つの新しいMIMEサブタイプが示されました。
The MIME names for the BV16 and BV32 codecs have been allocated from the IETF tree since these two codecs are expected to be widely used for Voice-over-IP applications, especially in Voice over Cable applications.
Voice-over-IPアプリケーションにこれらの2つのコーデックによって広く使用されると予想されて、IETF木からBV16とBV32コーデックのためのMIME名を割り当てました、特にCableアプリケーションの上のVoiceで。
Chen, et al. Standards Track [Page 8] RFC 4298 RTP Payload Format for BroadVoice December 2005
チェン、他 規格は2005年12月にBroadVoiceのためにRFC4298RTP有効搭載量形式を追跡します[8ページ]。
5.1. MIME Registration of BroadVoice16 for RTP
5.1. RTPのためにBroadVoice16の登録をまねてください。
MIME media type name: audio
MIMEメディア型名: オーディオ
MIME media subtype name: BV16
MIMEメディア「副-タイプ」は以下を命名します。 BV16
Required parameter: none
必要なパラメタ: なし
Optional parameters:
ptime: Defined as usual for RTP audio (see RFC 2327 [4]).
任意のパラメタ: ptime: RTPオーディオのためにいつものように定義されました。(RFC2327[4])を見てください。
maxptime: See RFC 3267 [7] for its definition. The maxptime
SHOULD be a multiple of the duration of a single codec data
frame (5 ms).
maxptime: 定義のためのRFC3267[7]を見てください。 maxptime SHOULD、単一のコーデックデータフレーム(5ms)の持続時間の倍数になってください。
Encoding considerations:
This type is defined for transferring BV16-encoded data via RTP
using the payload format specified in Section 3 of RFC 4298.
Audio data is binary data and must be encoded for non-binary
transport; the Base64 encoding is suitable for Email.
問題をコード化します: このタイプは、RTPを通してRFC4298のセクション3で指定されたペイロード形式を使用することでBV16によってコード化されたデータを移すために定義されます。 オーディオデータを2進のデータであり、非バイナリー輸送のためにコード化しなければなりません。 Base64コード化はメールに適しています。
Security considerations:
See Section 7 "Security Considerations" of RFC 4298.
セキュリティ問題: 「セキュリティ問題」というRFC4298のセクション7を見てください。
Public specification:
The BroadVoice16 codec has been specified in [3].
公共の仕様: BroadVoice16コーデックは[3]で指定されました。
Intended usage:
COMMON. It is expected that many VoIP applications, especially
Voice over Cable applications, will use this type.
意図している用法: 一般的。 多くのVoIPアプリケーション(特にCableアプリケーションの上のVoice)がこのタイプを使用すると予想されます。
Person & email address to contact for further information:
Juin-Hwey (Raymond) Chen
rchen@broadcom.com
詳細のために連絡する人とEメールアドレス: ジュアン-Hwey(レイモンド)チェン rchen@broadcom.com
Author/Change controller:
Author: Juin-Hwey (Raymond) Chen, rchen@broadcom.com
Change Controller: IETF Audio/Video Transport Working Group
delegated from the IESG
コントローラを書くか、または変えてください: 以下を書いてください。 ジュアン-Hwey(レイモンド)チェン、 rchen@broadcom.com 変化コントローラ: IESGから代表として派遣されたIETF Audio/ビデオTransport作業部会
5.2. MIME Registration of BroadVoice32 for RTP
5.2. RTPのためにBroadVoice32の登録をまねてください。
MIME media type name: audio
MIMEメディア型名: オーディオ
MIME media subtype name: BV32
MIMEメディア「副-タイプ」は以下を命名します。 BV32
Required parameter: none
必要なパラメタ: なし
Chen, et al. Standards Track [Page 9] RFC 4298 RTP Payload Format for BroadVoice December 2005
チェン、他 規格は2005年12月にBroadVoiceのためにRFC4298RTP有効搭載量形式を追跡します[9ページ]。
Optional parameters:
ptime: Defined as usual for RTP audio (see RFC 2327 [4]).
任意のパラメタ: ptime: RTPオーディオのためにいつものように定義されました。(RFC2327[4])を見てください。
maxptime: See RFC 3267 [7] for its definition. The maxptime
SHOULD be a multiple of the duration of a single codec data
frame (5 ms).
maxptime: 定義のためのRFC3267[7]を見てください。 maxptime SHOULD、単一のコーデックデータフレーム(5ms)の持続時間の倍数になってください。
Encoding considerations:
This type is defined for transferring BV32-encoded data via RTP
using the payload format specified in Section 4 of RFC 4298.
Audio data is binary data and must be encoded for non-binary
transport; the Base64 encoding is suitable for Email.
問題をコード化します: このタイプは、RTPを通してRFC4298のセクション4で指定されたペイロード形式を使用することでBV32によってコード化されたデータを移すために定義されます。 オーディオデータを2進のデータであり、非バイナリー輸送のためにコード化しなければなりません。 Base64コード化はメールに適しています。
Security considerations:
See Section 7 "Security Considerations" of RFC 4298.
セキュリティ問題: 「セキュリティ問題」というRFC4298のセクション7を見てください。
Intended usage:
COMMON. It is expected that many VoIP applications, especially
Voice over Cable applications, will use this type.
意図している用法: 一般的。 多くのVoIPアプリケーション(特にCableアプリケーションの上のVoice)がこのタイプを使用すると予想されます。
Person & email address to contact for further information:
Juin-Hwey (Raymond) Chen
rchen@broadcom.com
詳細のために連絡する人とEメールアドレス: ジュアン-Hwey(レイモンド)チェン rchen@broadcom.com
Author/Change controller:
Author: Juin-Hwey (Raymond) Chen, rchen@broadcom.com
Change Controller: IETF Audio/Video Transport Working Group
delegated from the IESG
コントローラを書くか、または変えてください: 以下を書いてください。 ジュアン-Hwey(レイモンド)チェン、 rchen@broadcom.com 変化コントローラ: IESGから代表として派遣されたIETF Audio/ビデオTransport作業部会
6. Mapping to SDP Parameters
6. パラメタをSDPに写像します。
The information carried in the MIME media type specification has a specific mapping to fields in the Session Description Protocol (SDP) [4], which is commonly used to describe RTP sessions. When SDP is used to specify sessions employing the BroadVoice16 or BroadVoice32 codec, the mapping is as follows:
タイプ仕様が特定のマッピングを持っているMIMEメディアで運ばれた情報はSession記述プロトコル(SDP)で[4]をさばきます。([4]は、RTPセッションについて説明するのに一般的に使用されます)。 SDPがBroadVoice16を使うセッションかBroadVoice32コーデックを指定するのに使用されるとき、マッピングは以下の通りです:
- The MIME type ("audio") goes in SDP "m=" as the media name.
- MIMEの種類(「オーディオ」)はメディア名としてSDP「m=」に行きます。
- The MIME subtype (payload format name) goes in SDP "a=rtpmap"
as the encoding name. The RTP clock rate in "a=rtpmap" MUST be
8000 for BV16 and 16000 for BV32.
- MIME「副-タイプ」(ペイロード形式名)はコード化名としてSDP"a=rtpmap"に入ります。 "a=rtpmap"のRTPクロックレートはBV32のためのBV16と16000のための8000でなければなりません。
- The parameters "ptime" and "maxptime" go in the SDP "a=ptime"
and "a=maxptime" attributes, respectively.
- パラメタの"ptime"と"maxptime"はそれぞれSDP"a=ptime"と"a=maxptime"属性に入ります。
Chen, et al. Standards Track [Page 10] RFC 4298 RTP Payload Format for BroadVoice December 2005
チェン、他 規格は2005年12月にBroadVoiceのためにRFC4298RTP有効搭載量形式を追跡します[10ページ]。
An example of the media representation in SDP for describing BV16 might be:
SDPのBV16について説明するメディア表現に関する例は以下の通りです。
m=audio 49120 RTP/AVP 97
a=rtpmap:97 BV16/8000
オーディオの49120RTP/AVP97m=a=rtpmap: 97BV16/8000
An example of the media representation in SDP for describing BV32 might be:
SDPのBV32について説明するメディア表現に関する例は以下の通りです。
m=audio 49122 RTP/AVP 99
a=rtpmap:99 BV32/16000
オーディオの49122RTP/AVP99m=a=rtpmap: 99BV32/16000
6.1. Offer-Answer Model Considerations
6.1. 申し出答えモデル問題
No special considerations are needed for using the SDP Offer/Answer model [5] with the BV16 and BV32 RTP payload formats.
どんな特別な問題もBV16とBV32 RTPペイロード形式と共にSDP Offer/答えモデル[5]を使用するのに必要ではありません。
7. Security Considerations
7. セキュリティ問題
RTP packets using the payload format defined in this specification are subject to the security considerations discussed in the RTP specification [1] and any appropriate profile (for example, [6]). This implies that confidentiality of the media streams is achieved by encryption.
この仕様に基づき定義されたペイロード書式を使用するRTPパケットがRTP仕様[1]とどんな適切なプロフィールでも議論したセキュリティ問題を条件としています。(例えば、[6])。 これは、メディアの流れの秘密性が暗号化で達成されるのを含意します。
A potential denial-of-service threat exists for data encoding using compression techniques that have non-uniform receiver-end computational load. The attacker can inject pathological datagrams into the stream that are complex to decode and cause the receiver to become overloaded. However, the encodings covered in this document do not exhibit any significant non-uniformity.
潜在的サービスの否定の脅威は、zデータの符号化のために不均等な受信端末コンピュータの負荷を持っている圧縮のテクニックを使用することで存在しています。 攻撃者によって、流れの中への解読するために複雑な病理学的なデータグラムを注入して、受信機は積みすぎられるようになることができます。 しかしながら、本書では覆われたencodingsは少しの重要な非の一様性も示しません。
8. Congestion Control
8. 輻輳制御
The general congestion control considerations for transporting RTP data apply to BV16 and BV32 audio over RTP as well (see RTP [1]) and any applicable RTP profile like AVP [6]. BV16 and BV32 do not have any built-in mechanism for reducing the bandwidth. Packing more frames in each RTP payload can reduce the number of packets sent, and hence the overhead from IP/UDP/RTP headers, at the expense of increased delay and reduced error robustness against packet losses.
RTPデータを輸送するための一般的な輻輳制御問題はまた、RTPの上でBV16とBV32にオーディオを当てはまります。(AVP[6]のようなRTP[1])とあらゆる適切なRTPプロフィールを見てください。 BV16とBV32には、帯域幅を減少させるためのどんな内蔵のメカニズムもありません。 それぞれのRTPペイロードで、より多くのフレームを梱包するのは、IP/UDP/RTPヘッダーから送られたパケットの数を減少させて、したがって、オーバーヘッドを減少させることができます、パケット損失に対する増加する遅れと減少している誤り丈夫さを犠牲にして。
9. Acknowledgements
9. 承認
The authors would like to thank Magnus Westerlund, Colin Perkins, Allison Mankin, and Jean-Francois Mule for their review of this document.
作者は彼らのこのドキュメントのレビューについてマグヌスWesterlund、コリン・パーキンス、アリソン・マンキン、およびジャン・フランソワMuleに感謝したがっています。
Chen, et al. Standards Track [Page 11] RFC 4298 RTP Payload Format for BroadVoice December 2005
チェン、他 規格は2005年12月にBroadVoiceのためにRFC4298RTP有効搭載量形式を追跡します[11ページ]。
10. References
10. 参照
10.1. Normative References
10.1. 引用規格
[1] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson,
"RTP: A Transport Protocol for Real-Time Applications", STD 64,
RFC 3550, July 2003.
[1]Schulzrinne、H.、Casner、S.、フレディリック、R.、およびV.ジェーコブソン、「RTP:」 「リアルタイムのアプリケーションのためのトランスポート・プロトコル」、STD64、RFC3550、2003年7月。
[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] Cable Television Laboratories, Inc., BroadVoice(TM)16 Speech
Codec Specification, Revision 1.2, October 30, 2003.
[3]ケーブルテレビ研究所Inc.、BroadVoice(TM)16スピーチコーデック仕様、改正1.2、2003年10月30日。
[4] Handley, M. and V. Jacobson, "SDP: Session Description Protocol",
RFC 2327, April 1998.
[4] ハンドレー、M.、およびV.ジェーコブソン、「SDP:」 「セッション記述プロトコル」、RFC2327、1998年4月。
[5] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with
Session Description Protocol (SDP)", RFC 3264, June 2002.
[5] ローゼンバーグとJ.とH.Schulzrinne、「セッション記述プロトコル(SDP)がある申し出/答えモデル」、RFC3264、2002年6月。
[6] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video
Conferences with Minimal Control", STD 65, RFC 3551, July 2003.
[6] Schulzrinne、H.、およびS.Casner、「オーディオのためのRTPプロフィールと最小量があるテレビ会議システムは制御します」、STD65、RFC3551、2003年7月。
[7] Sjoberg, J., Westerlund, M., Lakaniemi, A., and Q. Xie, "Real-
Time Transport Protocol (RTP) Payload Format and File Storage
Format for the Adaptive Multi-Rate (AMR) and Adaptive Multi-Rate
Wideband (AMR-WB) Audio Codecs", RFC 3267, June 2002.
[7] シェーベリ、J.、Westerlund、M.、Lakaniemi、A.、およびQ.シェ、「本当の時間トランスポート・プロトコル(RTP)有効搭載量形式とファイル記憶装置は適応型のマルチレート(AMR)の、そして、適応型のマルチレート広帯域(AMR-WB)にオーディオコーデックをフォーマットします」、RFC3267、2002年6月。
10.2. Informative References
10.2. 有益な参照
[8] Cable Television Laboratories, Inc., PacketCable(TM) 1.5
Audio/Video Codecs Specification, PKT-SP-CODEC1.5-I01-050128,
January 28, 2005.
http://www.cablelabs.com/specifications/archives/
[8] . ケーブルテレビ研究所Inc.、PacketCable(TM)1.5オーディオ/ビデオコーデック仕様、PKT-SP-CODEC1.5-I01-050128、2005年1月28日 http://www.cablelabs.com/specifications/archives/
Chen, et al. Standards Track [Page 12] RFC 4298 RTP Payload Format for BroadVoice December 2005
チェン、他 規格は2005年12月にBroadVoiceのためにRFC4298RTP有効搭載量形式を追跡します[12ページ]。
Authors' Addresses
作者のアドレス
Juin-Hwey (Raymond) Chen Broadcom Corporation Room A3020 16215 Alton Parkway Irvine, CA 92618 USA
ジュアン-Hwey(レイモンド)チェンBroadcom社の余地のA3020 16215オールトンParkwayカリフォルニア92618アーバイン(米国)
Phone: +1 949 926 6288 EMail: rchen@broadcom.com
以下に電話をしてください。 +1 6288年の949 926メール: rchen@broadcom.com
Winnie Lee Broadcom Corporation Room A2012E 200-13711 International Place Richmond, British Columbia V6V 2Z8 Canada
ウィニーリーBroadcom社の余地のA2012E200-13711の国際ブリティッシュコロンビアPlace V6V 2Z8リッチモンド(カナダ)
Phone: +1 604 233 8605 EMail: wlee@broadcom.com
以下に電話をしてください。 +1 8605年の604 233メール: wlee@broadcom.com
Jes Thyssen Broadcom Corporation Room A3018 16215 Alton Parkway Irvine, CA 92618 USA
Jesテュッセン・Broadcom社の余地のA3018 16215オールトンParkwayカリフォルニア92618アーバイン(米国)
Phone: +1 949 926 5768 EMail: jthyssen@broadcom.com
以下に電話をしてください。 +1 5768年の949 926メール: jthyssen@broadcom.com
Chen, et al. Standards Track [Page 13] RFC 4298 RTP Payload Format for BroadVoice December 2005
チェン、他 規格は2005年12月にBroadVoiceのためにRFC4298RTP有効搭載量形式を追跡します[13ページ]。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2005).
Copyright(C)インターネット協会(2005)。
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 procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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機能のための基金は現在、インターネット協会によって提供されます。
Chen, et al. Standards Track [Page 14]
チェン、他 標準化過程[14ページ]
一覧
スポンサーリンク
