Network Working Group J.-H. Chen
Request for Comments: 4298 W. Lee
Category: Standards Track J. Thyssen
Broadcom Corporation
December 2005
RTP Payload Format for BroadVoice Speech Codecs
Status of This Memo
このメモのステータス
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2005).
著作権（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と呼ばれる狭帯域コーデックは、PacketCableの1.5で必須コーデックとしてのCableLabsによって選択され、CableLabsの仕様を有しています。文書はまた、MIMEとBroadVoiceの使用およびセッション記述プロトコル（SDP）の仕様を提供します。
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
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.
この文書は、リアルタイムトランスポートプロトコル（RTP）[1]を用いてBroadVoice符号化された音声又はオーディオ信号を送信するためのペイロード・フォーマットを指定します。送信者は、ネットワークの状態、帯域幅可用性、遅延要件、およびパケット損失許容度に基づいて、アプリケーションシナリオに応じて、パケットごとに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"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますRFC 2119に記載されるように解釈される[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はDSLオーバーケーブル、音声ボイスオーバー、およびIP電話アプリケーションなどのVoIP（ボイス・オーバー・インターネット・プロトコル）アプリケーション用に開発された音声コーデックファミリーです。 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 very similar (but not identical) coding algorithms; they share most of their algorithm modules.
BroadVoiceコーデックファミリは2つのコーデックのバージョンが含まれています。狭帯域BroadVoice16呼ばBroadVoiceのバージョン、[3]、または略してBV16は、8kHzのサンプリング狭帯域第16キロビット/のビットレートで音声、または16キロビット/秒をコードします。 BroadVoice32呼ばBroadVoice、またはBV32の広帯域バージョンは、32キロビット/秒のビットレートで16 kHzのサンプリング広帯域音声を符号化します。 BV16とBV32コーディング非常に類似（しかし同一ではない）アルゴリズムを使用します。彼らは、アルゴリズム・モジュールのほとんどを共有しています。
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.
いずれかを先に見て使用しなくても、5ミリの非常に小さなフレームサイズとBV16とBV32エンコード音声の両方をリアルタイム双方向通信の遅延を最小限に抑えるために。必要に応じて5ミリ秒と小さいパケットサイズを使用することによって、これは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.
例えばG.728、G.729、G.723.1、及びG.722.2としてCELP（符号化励振線形予測）に基づいて、ITU-T標準の音声コーデックと比較した場合BroadVoiceはまた、比較的低いコーデック複雑性を有します。 BV16の全二重実装とBV32汎用16ビット固定小数点デジタルシグナルプロセッサ（DSP）上で、それぞれ、約12および17 MIPSを取ります。プログラムサイズ、データテーブル、及びデータRAMを含むBV16とBV32の総メモリフットプリントは、約12 Kワード毎、又は24バイトです。
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.
ケーブルテレビラボラトリーズ社（CableLabsの（R））のPacketCableの（TM）プロジェクトは、ケーブル事業者が提供するVoIP電話サービスで使用するためBV16コーデックを選択しました。より具体的には、BV16コーデックのPacketCable（TM）1.5オーディオ/ビデオコーデック仕様の必須のオーディオコーデックの一つとして選択された[8]と複数のベンダによって実装されています。広帯域バージョン（BV32）は、ブロードコムが開発したが、まだ公開された仕様には現れていません。それは技術的にBV16と非常によく似ていることから、そのペイロードフォーマットも、この文書で定義されています。
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ミリ秒フレームおよび8kHzのサンプリング周波数を使用するため、RTPタイムスタンプは、第二の1/8000単位でなければなりません。 RTPタイムスタンプはペイロードに存在するフレーム（S）で表される最も古いオーディオサンプルのサンプリング時点を示します。 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 |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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パケットが1に設定された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.
この新しいパケットフォーマットのためのRTPペイロードタイプの課題は、この文書の範囲外であり、ここで指定されることはありません。アプリケーションの特定のクラスのためのRTPプロファイルは、この符号化のためのペイロードタイプを割り当てることが予想される、またはそれが行われない場合には、ダイナミックレンジのペイロードタイプを選択しなければなりません。
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エンコーダは、毎秒8000個のサンプルのサンプリングレートで40個のサンプルに対応する5ミリ秒の音声フレームで動作します。すべての5ミリ秒のフレームについて、エンコーダは、80ビット、または10個のオクテットに40個の連続する音声サンプルを符号化します。このように、各5msのフレームについてBroadVoice16によって生成さ80ビットのビットストリームはオクテット整列され、パディングビットが必要とされません。 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
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番号が付けられています。各符号化パラメータのデータフィールドのビットは、左の最上位ビットと、同じ順序で番号が付けられています。
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|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: BroadVoice16 bit packing
図1：BroadVoice16ビットパッキング
More than one BroadVoice16 frame MAY be included in a single RTP packet by a sender. Senders have the following additional restrictions:
複数のBroadVoice16フレームは、送信者が、単一のRTPパケットに含まれるかもしれません。送信者は、次の追加の制限があります。
o SHOULD NOT include more BroadVoice16 frames in a single RTP packet than will fit in the MTU of the RTP.
oはRTPのMTUに収まるよりも、単一のRTPパケットに、よりBroadVoice16フレームを含むべきではありません。
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パケット内のすべてのフレームのタイムスタンプを回収する5ミリ秒の固定フレームサイズを有するので容易でなければならないからです。上述のように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パケット内に含まれるフレームの数は、アプリケーションと一致することが推奨されます。遅延例えば、遅延が重要な電話アプリケーションで、パケットあたり少ないフレーム、低級。一方、遅延鈍感なストリーミングやメッセージングアプリケーションのために、パケットごとに多数のフレームが許容可能です。
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によってオクテット数を分割することです。
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ミリ秒フレーム及び16kHzのサンプリング周波数を使用するため、RTPタイムスタンプは、第二の16000分の1の単位でなければなりません。 RTPタイムスタンプはペイロードに存在するフレーム（S）で表される最も古いオーディオサンプルのサンプリング時点を示します。 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 |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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パケットが1に設定された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.
この新しいパケットフォーマットのためのRTPペイロードタイプの課題は、この文書の範囲外であり、ここで指定されることはありません。アプリケーションの特定のクラスのためのRTPプロファイルは、この符号化のためのペイロードタイプを割り当てることが予想される、またはそれが行われない場合には、ダイナミックレンジのペイロードタイプを選択しなければなりません。
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 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
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|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: BroadVoice32 bit packing
図2：BroadVoice32ビットパッキング
More than one BroadVoice32 frame MAY be included in a single RTP packet by a sender. Senders have the following additional restrictions:
複数のBroadVoice32フレームは、送信者が、単一のRTPパケットに含まれるかもしれません。送信者は、次の追加の制限があります。
o SHOULD NOT include more BroadVoice32 frames in a single RTP packet than will fit in the MTU of the RTP.
oはRTPのMTUに収まるよりも、単一のRTPパケットに、よりBroadVoice32フレームを含むべきではありません。
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パケット内のすべてのフレームのタイムスタンプを回収する5ミリ秒の固定フレームサイズを有するので容易でなければならないからです。上述のように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パケット内に含まれるフレームの数は、アプリケーションと一致することが推奨されます。遅延例えば、遅延が重要な電話アプリケーションで、パケットあたり少ないフレーム、低級。一方、遅延鈍感なストリーミングやメッセージングアプリケーションのために、パケットごとに多数のフレームが許容可能です。
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によってオクテット数を分割することです。
Two new MIME sub-types, as described in this section, have been registered.
二つの新しい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.
これら二つのコーデックが広くボイスオーバーIPアプリケーションのために使用されることが期待されているのでBV16とBV32コーデックのMIME名は、ケーブルのアプリケーション上で特に声に、IETF木から割り当てられています。
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オーディオ用に通常通り定義され（[4] RFC 2327を参照）。
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：その定義については、RFC 3267 [7]を参照してください。 maxptimeは、単一のコーデックデータフレーム（5ミリ秒）の持続時間の倍数でなければなりません。
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.
符号化の考慮事項：このタイプは、RFCの第3節4298.オーディオデータで指定されたペイロードフォーマットを使用して、RTPを介しBV16エンコードされたデータを転送するために定義されたバイナリデータであり、非バイナリー輸送のために符号化されなければなりません。 Base64エンコーディングは、電子メールに適しています。
Security considerations: See Section 7 "Security Considerations" of RFC 4298.
セキュリティに関する考慮事項：RFC 4298のセクション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.
意図している用法：COMMON。多くのVoIPアプリケーション、ケーブルアプリケーション経由特に声は、このタイプを使用することが期待されます。
Person & email address to contact for further information: Juin-Hwey (Raymond) Chen rchen@broadcom.com
人とEメールアドレスは、詳細のために連絡する：JUIN-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
著者/変更コントローラ：著者：JUIN-Hwey（レイモンド）チェン、rchen@broadcom.com変更コントローラ：IETFオーディオ/ビデオ輸送ワーキンググループIESGから委任
MIME media type name: audio
MIMEメディアタイプ名：オーディオ
MIME media subtype name: BV32
MIMEメディアサブタイプ名：BV32
Required parameter: none
必要なパラメータ：なし
Optional parameters: ptime: Defined as usual for RTP audio (see RFC 2327 [4]).
オプションのパラメータ：PTIME：RTPオーディオ用に通常通り定義され（[4] RFC 2327を参照）。
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：その定義については、RFC 3267 [7]を参照してください。 maxptimeは、単一のコーデックデータフレーム（5ミリ秒）の持続時間の倍数でなければなりません。
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.
符号化の考慮事項：このタイプは、RFCの第4 4298.オーディオデータで指定されたペイロードフォーマットを使用して、RTPを介しBV32エンコードされたデータを転送するために定義されたバイナリデータであり、非バイナリー輸送のために符号化されなければなりません。 Base64エンコーディングは、電子メールに適しています。
Security considerations: See Section 7 "Security Considerations" of RFC 4298.
セキュリティに関する考慮事項：RFC 4298のセクション7「セキュリティの考慮事項」を参照してください。
Intended usage: COMMON. It is expected that many VoIP applications, especially Voice over Cable applications, will use this type.
意図している用法：COMMON。多くのVoIPアプリケーション、ケーブルアプリケーション経由特に声は、このタイプを使用することが期待されます。
Person & email address to contact for further information: Juin-Hwey (Raymond) Chen rchen@broadcom.com
人とEメールアドレスは、詳細のために連絡する：JUIN-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
著者/変更コントローラ：著者：JUIN-Hwey（レイモンド）チェン、rchen@broadcom.com変更コントローラ：IETFオーディオ/ビデオ輸送ワーキンググループIESGから委任
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メディアタイプの仕様で搬送される情報は、[4]、一般にRTPセッションを記述するために使用されるセッション記述プロトコル（SDP）内のフィールドに特定のマッピングを有します。 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クロックレートはBV16とBV32のための16000のために8000でなければなりません。
- The parameters "ptime" and "maxptime" go in the SDP "a=ptime" and "a=maxptime" attributes, respectively.
- パラメータ "PTIME" と "maxptime" SDPに "= PTIME" を行って、 "A = maxptime" は、それぞれの属性。
An example of the media representation in SDP for describing BV16 might be:
BV16を説明するためのSDP内のメディア表現の例があるかもしれません。
m=audio 49120 RTP/AVP 97 a=rtpmap:97 BV16/8000
97 BV16 / 8000：= rtpmapメートル=オーディオ49120 RTP / AVP 97
An example of the media representation in SDP for describing BV32 might be:
BV32を説明するためのSDP内のメディア表現の例があるかもしれません。
m=audio 49122 RTP/AVP 99 a=rtpmap:99 BV32/16000
M =オーディオ49122 RTP / AVP 99 = rtpmap：99 BV32 / 16000
No special considerations are needed for using the SDP Offer/Answer model [5] with the BV16 and BV32 RTP payload formats.
特別な配慮はBV16とBV32 RTPペイロードフォーマットを[5] SDPオファー/アンサーモデルを使用するために必要ではありません。
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パケットが（例えば、[6]）RTP仕様[1]と、任意の適切なプロファイルで議論したセキュリティ問題を受けることです。これは、メディアストリームの機密性は、暗号化によって達成されることを意味します。
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.
潜在的なサービス拒否の脅威は、不均一な受信端計算負荷を有する圧縮技術を用いて、データ符号化のために存在します。攻撃者が復号及び過負荷になるために受信機を引き起こすのに複雑であるストリームに病理学的なデータグラムを注入することができます。しかし、本書で取り上げエンコーディングは、有意な不均一性を示しません。
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オーディオに適用される（RTP参照[1]）とAVP等該当RTPプロファイル[6]。 BV16とBV32は、帯域幅を削減するための任意の組み込みのメカニズムを持っていません。各RTPペイロードに複数のフレームを充填するパケット損失に対する増加遅延および減少エラー耐性を犠牲にして、IP / UDP / RTPヘッダから送信されたパケットの数、したがってオーバーヘッドを低減することができます。
The authors would like to thank Magnus Westerlund, Colin Perkins, Allison Mankin, and Jean-Francois Mule for their review of this document.
作者はこのドキュメントの彼らのレビューのためにマグヌスウェスター、コリンパーキンス、アリソンマンキン、とジャン・フランソワ・ミュールに感謝したいと思います。
[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：リアルタイムアプリケーションのためのトランスポートプロトコル"、STD 64、RFC 3550、2003年7月。
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[2]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[3] Cable Television Laboratories, Inc., BroadVoice(TM)16 Speech Codec Specification, Revision 1.2, October 30, 2003.
[3]ケーブルテレビラボラトリーズ社、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. Jacobsonの "SDP：セッション記述プロトコル"、RFC 2327、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と、RFC 3264 "セッション記述プロトコル（SDP）とのオファー/アンサーモデル"、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プロフィール"、STD 65、RFC 3551、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] Sjoberg、J.、ウェスター、M.、Lakaniemi、A.、およびQ.謝、「リアルタイムトランスポートプロトコル（RTP）ペイロードフォーマットと適応マルチレート（AMR）と適応マルチ用ストレージファイル形式を-rate広帯域（AMR-WB）オーディオコーデック」、RFC 3267、2002年6月。
[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]ケーブルテレビラボラトリーズ社、PacketCableの（TM）1.5オーディオ/ビデオコーデック仕様、PKT-SP-CODEC1.5-I01-050128、1月28日、2005年http://www.cablelabs.com/specifications/アーカイブ/
Authors' Addresses
著者のアドレス
Juin-Hwey (Raymond) Chen Broadcom Corporation Room A3020 16215 Alton Parkway Irvine, CA 92618 USA
JUIN-Hwey（レイモンド）チェンブロードコム・コーポレーションルームA3020 16215アルトンパークウェイアーバイン、CA 92618 USA
Phone: +1 949 926 6288 EMail: rchen@broadcom.com
電話：+1 949 926 6288 Eメール：rchen@broadcom.com
Winnie Lee Broadcom Corporation Room A2012E 200-13711 International Place Richmond, British Columbia V6V 2Z8 Canada
ウィニーリーブロードコム・コーポレーションルームA2012E 200から13711国際プレースリッチモンド、ブリティッシュコロンビア州V6V 2Z8カナダ
Phone: +1 604 233 8605 EMail: wlee@broadcom.com
電話：+1 604 233 8605 Eメール：wlee@broadcom.com
Jes Thyssen Broadcom Corporation Room A3018 16215 Alton Parkway Irvine, CA 92618 USA
ジェスティッセンブロードコム・コーポレーションルームA3018 16215アルトンパークウェイアーバイン、CA 92618 USA
Phone: +1 949 926 5768 EMail: jthyssen@broadcom.com
電話：+1 949 926 5768 Eメール：jthyssen@broadcom.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
著作権（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.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。