[要約] RFC 4298は、BroadVoice音声コーデックのためのRTPペイロード形式に関する仕様です。このRFCの目的は、BroadVoiceコーデックを使用して音声データをRTPパケットにエンコードする方法を定義することです。
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
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.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2005).
Copyright（c）The Internet Society（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とセッション説明プロトコル（SDP）を使用したBroadVoiceを使用するための仕様も提供しています。
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 Codecデータフレームを送信できます。
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].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、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は、VoIP（Voice over Internet Protocol）アプリケーション用に開発されたスピーチコーデックファミリーです。BroadVoiceは、コーディング遅延が低く、Codecの複雑さが比較的低い音声品質が高くなります。
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 Codecファミリーには、2つのコーデックバージョンが含まれています。BroadVoice16 [3]、またはBV16と呼ばれるBroadVoiceの狭帯域バージョンは、16キロビット/秒または16 kbit/sのビットレートで8 kHzサンプリングされた狭帯域発話をエンコードします。BroadVoice32またはBV32と呼ばれるBroadVoiceのワイドバンドバージョンは、32 kbit/sのビットレートで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.
リアルタイムの双方向通信の遅延を最小限に抑えるために、BV16とBV32の両方が、5ミリ秒の非常に小さなフレームサイズでスピーチをエンコードして、先を見てください。必要に応じて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.
BroadVoiceは、G.728、G.729、G.723.1、G.722.2などのCELP（コード化された励起線形予測）に基づくITU-T標準音声コーデックと比較すると、比較的低いコーデックの複雑さもあります。BV16およびBV32の全二重実装は、それぞれ汎用16ビット固定ポイントデジタル信号プロセッサ（DSP）で約12および17回のMIPSを使用します。プログラムのサイズ、データテーブル、データRAMを含むBV16およびBV32のメモリフットプリントの合計は、それぞれ約12 kワード、または24 kバイトです。
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.
Cable Television Laboratories、Inc。（CableLabs（R））のPacketCable（TM）プロジェクトは、ケーブルオペレーターが提供するVoIP電話サービスで使用するためにBV16コーデックを選択しました。より具体的には、BV16コーデックは、PacketCable（TM）1.5 Audio/Video Codecs仕様[8]の必須のオーディオコーデックの1つとして選択され、複数のベンダーによって実装されています。ワイドバンドバージョン（BV32）はBroadcomによって開発されていますが、公開仕様にはまだ登場していません。技術的には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ミリ秒のフレームと8 kHzのサンプリング周波数を使用するため、RTPタイムスタンプは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 |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
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エンコーダーは、5ミリ秒の音声フレームで動作し、1秒あたり8000サンプルのサンプリングレートで40サンプルに対応します。5ミリ秒のフレームごとに、エンコーダは40の連続したオーディオサンプルを80ビット、または10オクテットにエンコードします。したがって、5ミリ秒のフレームごとにBroadVoice16によって生成された80ビットビットストリームはOctet-Alignedであり、パディングビットは必要ありません。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 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:
送信者による単一のRTPパケットに複数のBroadVoice16フレームを含めることができます。送信者には、次の追加の制限があります。
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フレームを1つ以上含めるべきではありません。
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ミリ秒のフレームと16 kHzのサンプリング周波数を使用するため、RTPタイムスタンプは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 |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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パケットは、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プロファイルが、このエンコードのペイロードタイプを割り当てるか、それが完了していない場合、ダイナミックレンジのペイロードタイプを選択することが期待されます。
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 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:
送信者による単一のRTPパケットに複数のBroadVoice32フレームを含めることができます。送信者には、次の追加の制限があります。
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フレームを1つ以上含めるべきではありません。
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.
このセクションで説明されているように、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.
BV16およびBV32コーデックのMIME名は、特にVoice Over Cable ApplicationsでボイスオーバーIPアプリケーションに広く使用されると予想されるため、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オーディオの場合は通常どおり定義されています（RFC 2327 [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：その定義については、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 4298のセクション3で指定されたペイロード形式を使用して、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.
意図された使用法：共通。多くのVoIPアプリケーション、特にVoice over Cable Applicationsがこのタイプを使用することが予想されます。
Person & email address to contact for further information: Juin-Hwey (Raymond) Chen rchen@broadcom.com
詳細については、人とメールアドレスをお問い合わせ：Juin-Hwey（Raymond）Chen 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（Raymond）Chen、rchen@broadcom.com Change Controller：IETF Audio/Video Transport Working Group 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オーディオの場合は通常どおり定義されています（RFC 2327 [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：その定義については、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 4298のセクション4で指定されたペイロード形式を使用して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.
意図された使用法：共通。多くのVoIPアプリケーション、特にVoice over Cable Applicationsがこのタイプを使用することが予想されます。
Person & email address to contact for further information: Juin-Hwey (Raymond) Chen rchen@broadcom.com
詳細については、人とメールアドレスをお問い合わせ：Juin-Hwey（Raymond）Chen 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（Raymond）Chen、rchen@broadcom.com Change Controller：IETF Audio/Video Transport Working Group 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メディアタイプの仕様に掲載されている情報には、セッション説明プロトコル（SDP）[4]のフィールドへの特定のマッピングがあり、これは一般的にRTPセッションを説明するために使用されます。SDPがBroadVoice16またはBroadVoice32 Codecを採用するセッションを指定するために使用される場合、マッピングは次のとおりです。
- The MIME type ("audio") goes in SDP "m=" as the media name.
- MIMEタイプ（ "Audio"）は、メディア名として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で8000、BV32で16000でなければなりません。
- The parameters "ptime" and "maxptime" go in the SDP "a=ptime" and "a=maxptime" attributes, respectively.
- パラメーター「PTIME」と「MAXPTIME」は、それぞれSDP「A = 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
M =オーディオ49120 RTP/AVP 97 A = RTPMAP：97 BV16/8000
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 A = 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ペイロード形式でSDPオファー/回答モデル[5]を使用するために特別な考慮事項は必要ありません。
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.
不均一なレシーバーエンドの計算負荷を備えた圧縮技術を使用したデータエンコードのデータには、潜在的なサービス拒否脅威が存在します。攻撃者は、デコードしてレシーバーが過負荷になるように複雑なストリームに病理学的データグラムを注入できます。ただし、このドキュメントで取り上げられているエンコーディングは、有意な不均一性を示しません。
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 [6]のような該当するRTPプロファイル。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.、Frederick、R。、およびV. Jacobson、「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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[3] Cable Television Laboratories, Inc., BroadVoice(TM)16 Speech Codec Specification, Revision 1.2, October 30, 2003.
[3] Cable Television Laboratories、Inc.、Broadvoice（TM）16 Speech Codec仕様、改訂1.2、2003年10月30日。
[4] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998.
[4] Handley、M。and 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] Rosenberg、J。およびH. Schulzrinne、「セッション説明プロトコル（SDP）を備えたオファー/回答モデル」、RFC 3264、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.、Westerlund、M.、Lakaniemi、A。、およびQ. Xie、「リアルタイムトランスポートプロトコル（RTP）ペイロード形式とファイルストレージ形式（AMR）および適応型マルチレートワイドバンドのファイルストレージ形式（AMR-WB）Audio Codecs "、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] Cable Television Laboratories、Inc.、PacketCable（TM）1.5オーディオ/ビデオコーデック仕様、PKT-SP-CODEC1.5-I01-050128、2005年1月28日
Authors' Addresses
著者のアドレス
Juin-Hwey (Raymond) Chen Broadcom Corporation Room A3020 16215 Alton Parkway Irvine, CA 92618 USA
Juin-Hwey（Raymond）Chen Broadcom Corporation Room A3020 16215 Alton Parkway Irvine、CA 92618 USA
Phone: +1 949 926 6288
EMail: rchen@broadcom.com
Winnie Lee Broadcom Corporation Room A2012E 200-13711 International Place Richmond, British Columbia V6V 2Z8 Canada
Winnie Lee Broadcom Corporation Room A2012E 200-13711 International Placeリッチモンド、ブリティッシュコロンビアV6V 2Z8カナダ
Phone: +1 604 233 8605
EMail: wlee@broadcom.com
Jes Thyssen Broadcom Corporation Room A3018 16215 Alton Parkway Irvine, CA 92618 USA
Jes Thyssen Broadcom Corporation Room A3018 16215 Alton Parkway Irvine、CA 92618 USA
Phone: +1 949 926 5768
EMail: jthyssen@broadcom.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
Copyright（c）The Internet Society（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
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.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。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エディター機能の資金は現在、インターネット協会によって提供されています。