[要約] 要約：RFC 4184は、AC-3オーディオのRTPペイロード形式に関する仕様です。この仕様は、AC-3オーディオをRTPパケットにエンコードする方法を定義しています。目的：RFC 4184の目的は、AC-3オーディオをネットワーク上で効率的に転送するための標準化された形式を提供することです。
Network Working Group B. Link
Request for Comments: 4184 T. Hager
Category: Standards Track Dolby Laboratories
J. Flaks
Microsoft Corporation
October 2005
RTP Payload Format for AC-3 Audio
AC-3オーディオ用の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 an RTP payload format for transporting audio data using the AC-3 audio compression standard. AC-3 is a high quality, multichannel audio coding system that is used for United States HDTV, DVD, cable television, satellite television and other media. The RTP payload format presented in this document includes support for data fragmentation.
このドキュメントでは、AC-3オーディオ圧縮標準を使用してオーディオデータを輸送するためのRTPペイロード形式について説明します。AC-3は、米国HDTV、DVD、ケーブルテレビ、衛星テレビ、その他のメディアに使用される高品質のマルチチャネルオーディオコーディングシステムです。このドキュメントに示されているRTPペイロード形式には、データの断片化のサポートが含まれています。
AC-3 [ATSC] is a high-quality audio codec (audio coding format) designed to encode multiple channels of audio into a low bit-rate format. AC-3 achieves its large compression ratios via encoding a multiplicity of channels as a single entity. Dolby Digital, which is a branded version of AC-3, encodes up to 5.1 channels of audio.
AC-3 [ATSC]は、複数の音声チャネルを低ビットレート形式にエンコードするように設計された高品質のオーディオコーデック（オーディオコーディング形式）です。AC-3は、単一のエンティティとして多数のチャネルをエンコードすることにより、大きな圧縮率を達成します。AC-3のブランドバージョンであるDolby Digitalは、最大5.1チャネルのオーディオをエンコードしています。
AC-3 has been adopted as an audio compression scheme for many consumer and professional applications. It is a mandatory audio codec for DVD-video, Advanced Television Standards Committee (ATSC) digital terrestrial television and Digital Living Network Alliance (DLNA) home networking, as well as an optional multichannel audio format for DVD-audio.
AC-3は、多くの消費者および専門的なアプリケーションのオーディオ圧縮スキームとして採用されています。これは、DVD-Video、Advanced Television Standards Committee（ATSC）デジタルテレビテレビおよびデジタルリビングネットワークアライアンス（DLNA）ホームネットワーキングのための必須のオーディオコーデックと、DVD-Audioのオプションのマルチチャネルオーディオ形式です。
There is a need to stream AC-3 data over IP networks. The Internet Real Time Protocol (RTP) provides a mechanism for stream synchronization and hence serves as the best transport solution for AC-3, which is primarily used in audio-for-video applications. Applications for streaming AC-3 include streaming movies from a home media server to a display, video on demand, and multichannel Internet radio.
IPネットワークを介してAC-3データをストリーミングする必要があります。インターネットリアルタイムプロトコル（RTP）は、ストリーム同期のメカニズムを提供するため、主にAudio-for-Videoアプリケーションで使用されるAC-3の最適な輸送ソリューションとして機能します。AC-3のストリーミングのアプリケーションには、ホームメディアサーバーからディスプレイ、ビデオオンデマンド、マルチチャネルインターネットラジオへのストリーミング映画が含まれます。
Section 2 gives a brief overview of the AC-3 algorithm. Section 3 specifies values for fields in the RTP header, while Section 4 specifies the AC-3 payload format. Section 5 discusses media types and SDP usage. Security considerations are covered in Section 6, congestion control in Section 7, and IANA considerations in Section 8. References are given in Sections 9 and 10.
セクション2では、AC-3アルゴリズムの概要を説明します。セクション3は、RTPヘッダーのフィールドの値を指定し、セクション4はAC-3ペイロード形式を指定します。セクション5では、メディアの種類とSDPの使用について説明します。セキュリティ上の考慮事項は、セクション6で、セクション7の混雑制御、セクション8のIANAの考慮事項で説明されています。参考文献はセクション9および10に記載されています。
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 [RFC2119].
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はRFC 2119 [RFC2119]で説明されているように解釈されます。
AC-3 can deliver up to 5.1 channels of audio at data rates approximately equal to half of one PCM channel [ATSC], [1994AC3], [1996AC3]. The ".1" refers to a band-limited, optional, low-frequency effects (LFE) channel. AC-3 was designed for signals sampled at rates of 32, 44.1, or 48 kHz. Data rates can vary between 32 kbps and 640 kbps, depending on the number of channels and the desired quality.
AC-3は、1つのPCMチャネル[ATSC]、[1994AC3]、[1996AC3]のほぼ半分に等しいデータレートで最大5.1チャネルのオーディオを配信できます。「.1」とは、バンド制限されたオプションの低周波効果（LFE）チャネルを指します。AC-3は、32、44.1、または48 kHzのレートでサンプリングされた信号用に設計されました。データレートは、チャネルの数と目的の品質に応じて、32 kbpsから640 kbpsの間で異なります。
AC-3 exploits psycho-acoustic phenomena that cause a significant fraction of the information contained in a typical audio signal to be inaudible. Substantial data reduction occurs via the removal of inaudible information contained in an audio stream. Source coding techniques are further used to reduce the data rate.
AC-3は、典型的なオーディオ信号に含まれる情報のかなりの部分を聞くことができないように、精神音響現象を悪用します。大幅なデータ削減は、オーディオストリームに含まれる聞き取れない情報を削除することにより発生します。ソースコーディング手法は、データレートを下げるためにさらに使用されます。
Like most perceptual coders, AC-3 operates in the frequency domain. A 512-point TDAC transform is taken with 50% overlap, providing 256 new frequency samples. Frequency samples are then converted to exponents and mantissas. Exponents are differentially encoded. Mantissas are allocated a varying number of bits depending on the audibility of the associated spectral components. Audibility is determined via a masking curve. Bits for mantissas are allocated from a global bit pool.
ほとんどの知覚コーダーと同様に、AC-3は周波数領域で動作します。512ポイントのTDAC変換が50％のオーバーラップで採取され、256個の新しい周波数サンプルが提供されます。その後、周波数サンプルは指数およびマンティッサに変換されます。指数は差別的にエンコードされます。マンティサには、関連するスペクトルコンポーネントの可聴性に応じて、さまざまな数のビットが割り当てられます。可聴性はマスキング曲線を介して決定されます。Mantissasのビットは、グローバルなビットプールから割り当てられています。
AC-3 bit streams are organized into synchronization frames. Each AC-3 frame contains a Synchronization Information (SI) field, a Bit Stream Information (BSI) field, and 6 audio blocks (ABs) that each represent 256 PCM samples for all channels. The frame ends with an optional auxiliary data field (AUX) and an error correction field (CRC). The entire frame represents the time duration of 1536 PCM samples across all coded channels [ATSC]. AC-3 encodes audio sampled at 32 kHz, 44.1 kHz, and 48 kHz. From Annex A, Part 2, of [ATSC], the time duration of an AC-3 frame varies with the sampling rate as follows:
AC-3ビットストリームは、同期フレームに編成されます。各AC-3フレームには、同期情報（SI）フィールド、ビットストリーム情報（BSI）フィールド、およびそれぞれがすべてのチャネルの256 PCMサンプルを表す6つのオーディオブロック（ABS）が含まれています。フレームは、オプションの補助データフィールド（AUX）とエラー修正フィールド（CRC）で終了します。フレーム全体は、すべてのコード化されたチャネル[ATSC]にわたる1536 PCMサンプルの期間を表します。AC-3は、32 kHz、44.1 kHz、および48 kHzでサンプリングされたオーディオをエンコードします。[ATSC]のパート2の付録Aから、AC-3フレームの期間はサンプリングレートによって次のように変化します。
Sampling rate Frame duration
_____________________________________
48 kHz 32 ms
44.1 kHz approx. 34.83 ms
32 kHz 48 ms
Figure 1 shows the AC-3 frame format.
図1は、AC-3フレーム形式を示しています。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|SI |BSI| AB0 | AB1 | AB2 | AB3 | AB4 | AB5 |AUX|CRC|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1. AC-3 Frame Format
図1. AC-3フレーム形式
The Synchronization Information field contains information needed to acquire and maintain codec synchronization. The Bit Stream Information field contains parameters that describe the coded audio service [ATSC]. Each audio block contains fields that indicate the use of various coding tools: block switching, dither, coupling, and exponent strategy. They also contain metadata, optionally used to enhance the playback, such as dynamic range control. Finally, the exponents and bit allocation data needed to decode the mantissas into audio data, and the mantissas themselves, are included. The placement of these fields in an AC-3 audio block is shown in Figure 2. The fields shown in this figure are described in detail in [ATSC]. Note that field sizes vary depending on the coded data.
同期情報フィールドには、コーデック同期を取得および維持するために必要な情報が含まれています。ビットストリーム情報フィールドには、コード化されたオーディオサービス[ATSC]を記述するパラメーターが含まれています。各オーディオブロックには、さまざまなコーディングツールの使用を示すフィールドが含まれています：ブロックスイッチング、ディザ、カップリング、および指数戦略が含まれています。また、ダイナミックレンジコントロールなどの再生を強化するためにオプションで使用されるメタデータも含まれています。最後に、マンティサをオーディオデータにデコードするために必要な指数とビット割り当てデータ、およびマンティッサ自体が含まれています。これらのフィールドのAC-3オーディオブロックへの配置を図2に示します。この図に示すフィールドは、[ATSC]で詳細に説明されています。フィールドサイズは、コード化されたデータによって異なることに注意してください。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Block |Dither |Dynamic |Coupling |Coupling |Exponent |
| Switch |Flags |Range Ctrl |Strategy |Coordinates |Strategy |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Exponents | Bit Allocation | Mantissas |
| | Parameters | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2. AC-3 Audio Block Format
図2. AC-3オーディオブロック形式
o Payload Type (PT): The assignment of an RTP payload type for this packet format is outside the scope of this document. It is specified by the RTP profile under which this payload format is used, or signaled dynamically out-of-band (e.g., using SDP).
o ペイロードタイプ（PT）：このパケット形式のRTPペイロードタイプの割り当ては、このドキュメントの範囲外です。これは、このペイロード形式が使用されるRTPプロファイルによって指定されているか、動的に帯域外に合図されます（例：SDPを使用）。
o Marker (M) bit: The M bit is set to one to indicate that the RTP packet payload contains at least one complete AC-3 frame or contains the final fragment of an AC-3 frame.
o マーカー（M）ビット：Mビットは1に設定されており、RTPパケットペイロードに少なくとも1つの完全なAC-3フレームが含まれているか、AC-3フレームの最終フラグメントが含まれていることを示します。
o Extension (X) bit: Defined by the RTP profile used.
o 拡張機能（x）ビット：使用されるRTPプロファイルによって定義されています。
o Timestamp: A 32-bit word that corresponds to the sampling instant for the first AC-3 frame in the RTP packet. Packets containing fragments of the same frame MUST have the same time stamp. The timestamp of the first RTP packet sent SHOULD be selected at random. Thereafter, the timestamp increases linearly with the number of samples included in each frame (i.e., by 1536 for each frame).
o タイムスタンプ：RTPパケットの最初のAC-3フレームのサンプリングインスタントに対応する32ビットワード。同じフレームのフラグメントを含むパケットには、同じタイムスタンプが必要です。送信された最初のRTPパケットのタイムスタンプは、ランダムに選択する必要があります。その後、タイムスタンプは、各フレームに含まれるサンプルの数（つまり、各フレームの1536）とともに直線的に増加します。
This payload format is defined for AC-3, as defined in the main part and Annex D of [ATSC]. It is not defined for E-AC-3, as defined in Annex E of [ATSC], and it MUST NOT be used to carry E-AC-3.
このペイロード形式は、[ATSC]のメイン部分と付属書Dで定義されているように、AC-3に対して定義されます。[ATSC]の付録Eで定義されているE-AC-3では定義されておらず、E-AC-3を運ぶために使用してはなりません。
According to [RFC2736], RTP payload formats should contain an integral number of application data units (ADUs). The AC-3 frame corresponds to an ADU, in the context of this payload format. Each RTP payload MUST start with the two-byte payload header followed by an integral number of complete AC-3 frames or by a single fragment of an AC-3 frame.
[RFC2736]によると、RTPペイロード形式には、積分数のアプリケーションデータユニット（ADU）が含まれている必要があります。AC-3フレームは、このペイロード形式のコンテキストでADUに対応します。各RTPペイロードは、2バイトのペイロードヘッダーから開始する必要があります。その後、積分数の完全なAC-3フレーム、またはAC-3フレームの単一のフラグメントが必要です。
If an AC-3 frame exceeds the MTU for a network, it SHOULD be fragmented for transmission within an RTP packet. Section 4.2 provides guidelines for creating frame fragments.
AC-3フレームがネットワークのMTUを超える場合、RTPパケット内の送信のために断片化する必要があります。セクション4.2では、フレームフラグメントを作成するためのガイドラインを示します。
There is a two-octet Payload Header at the beginning of each payload.
各ペイロードの開始時には、2オクテットのペイロードヘッダーがあります。
Each AC-3 RTP payload MUST begin with the payload header shown in Figure 3.
各AC-3 RTPペイロードは、図3に示すペイロードヘッダーから開始する必要があります。
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MBZ | FT| NF |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3. AC-3 RTP Payload Header
図3. AC-3 RTPペイロードヘッダー
o MBZ (Must Be Zero): Bits marked MBZ SHALL be set to the value zero and SHALL be ignored by receivers. The bits are reserved for future extensions.
o MBZ（ゼロである必要があります）：マークされたMBZのマークされたビットは、値ゼロに設定され、受信機は無視するものとします。ビットは、将来の拡張のために予約されています。
o FT (Frame Type): This two-bit field indicates the type of frame(s) present in the payload. It takes the following values:
o ft（フレームタイプ）：この2ビットフィールドは、ペイロードに存在するフレームのタイプを示します。次の値が必要です。
0 - One or more complete frames. 1 - Initial fragment of frame which includes the first 5/8ths of the frame. (See Section 4.2.) 2 - Initial fragment of frame, which does not include the first 5/8ths of the frame. 3 - Fragment of frame other than initial fragment. (Note that M bit in RTP header is set for final fragment).
0- 1つ以上の完全なフレーム。1-フレームの最初の5/8を含むフレームの初期フラグメント。（セクション4.2を参照してください。）2-フレームの最初の5/8番目は含まれていないフレームの初期フラグメント。3-初期フラグメント以外のフレームのフラグメント。（RTPヘッダーのMビットは、最終的なフラグメントに設定されていることに注意してください）。
o NF (Number of frames/fragments): An 8-bit field whose meaning depends on the Frame Type (FT) in this payload. For complete frames (FT of 0), it is used to indicate the number of AC-3 frames in the RTP payload. For frame fragments (FT of 1, 2, or 3), it is used to indicate the number fragments (and therefore packets) that make up the current frame. NF MUST be identical for packets containing fragments of the same frame.
o NF（フレーム/フラグメント数）：このペイロードのフレームタイプ（ft）に意味が依存する8ビットフィールド。完全なフレーム（0のFT）の場合、RTPペイロードのAC-3フレームの数を示すために使用されます。フレームフラグメント（1、2、または3のft）の場合、現在のフレームを構成する数値フラグメント（したがってパケット）を示すために使用されます。NFは、同じフレームのフラグメントを含むパケットについて同一でなければなりません。
Figure 4 shows the full AC-3 RTP payload format.
図4は、完全なAC-3 RTPペイロード形式を示しています。
+-+-+-+-+-+-+-+-+-+-+-+-+-+- .. +-+-+-+-+
| Payload | Frame | Frame | | Frame |
| Header | (1) | (2) | | (n) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+- .. +-+-+-+-+
Figure 4. Full AC-3 RTP payload
図4.完全なAC-3 RTPペイロード
When receiving AC-3 payloads with FT = 0 and more than a single frame (NF > 1), a receiver needs to use the "frmsizecod" field in the Synchronization Information (syncinfo) block in each AC-3 frame to determine the frame's length. That way a receiver can determine the boundary of the next frame. Note that the frame length may vary from frame to frame.
ft = 0および単一のフレーム（nf> 1）を超えるAC-3ペイロードを受信する場合、受信者は各AC-3フレームの同期情報（syncinfo）ブロックで「frmsizecod」フィールドを使用してフレームを決定する必要があります。長さ。そうすれば、レシーバーは次のフレームの境界を決定できます。フレームの長さはフレームごとに異なる場合があることに注意してください。
The size of an AC-3 frame depends on the sample rate of the audio and the data rate used by the encoder (which are indicated in the "Synchronization Information" header in the AC-3 frame). The size of a frame, for a given sample rate and data rate, is specified in Table 5.18 ("Frame Size Code Table") of [ATSC]. This table shows that AC-3 frames range in size from a minimum of 128 bytes to a maximum of 3840 bytes. If the size of an AC-3 frame exceeds the MTU size, the frame SHOULD be fragmented at the RTP level. The fragmentation MAY be performed at any byte boundary in the frame. RTP packets containing fragments of the same AC-3 frame SHALL be sent in consecutive order, from first to last fragment. This enables a receiver to assemble the fragments in correct order.
AC-3フレームのサイズは、オーディオのサンプルレートとエンコーダで使用されるデータレート（AC-3フレームの「同期情報」ヘッダーに示されている）に依存します。特定のサンプルレートとデータレートのフレームのサイズは、[ATSC]の表5.18（「フレームサイズコードテーブル」）に指定されています。この表は、AC-3フレームのサイズの範囲が最低128バイトから最大3840バイトまでの範囲であることを示しています。AC-3フレームのサイズがMTUサイズを超える場合、フレームはRTPレベルで断片化する必要があります。断片化は、フレーム内の任意のバイト境界で実行できます。同じAC-3フレームのフラグメントを含むRTPパケットは、最初から最後のフラグメントまで、連続して順序で送信するものとします。これにより、受信者はフラグメントを正しい順序で組み立てることができます。
When an AC-3 frame is fragmented, it MAY be fragmented such that at least the first 5/8ths of the frame data is in the first fragment. This provides greater resilience to packet loss. This initial portion of any frame is guaranteed to contain the data necessary to decode the first two blocks of the frame. Any frame fragments other than those containing the first 5/8ths of frame data are only decodable once the complete frame is received. The 5/8ths point of the frame is defined in Table 7.34 ("5/8_frame Size Table") of [ATSC].
AC-3フレームが断片化されている場合、少なくともフレームデータの最初の5/8分の1が最初のフラグメントにあるように断片化される可能性があります。これにより、パケット損失に対する回復力が高まります。フレームのこの最初の部分は、フレームの最初の2つのブロックをデコードするために必要なデータを含めることが保証されています。フレームデータの最初の5/8分の8を含むもの以外のフレームフラグメントは、完全なフレームが受信された場合にのみ解読できます。フレームの5/8のポイントは、[ATSC]の表7.34（ "5/8_Frameサイズテーブル"）に定義されています。
This registration uses the template defined in [DRAFT-FREED] and follows RFC 3555 [RFC3555].
この登録は、[ドラフトフリード]で定義されたテンプレートを使用し、RFC 3555 [RFC3555]に従います。
o Type name: audio
o タイプ名：オーディオ
o Subtype name: ac3
o サブタイプ名：AC3
o Required parameters:
o 必要なパラメーター：
rate: The RTP timestamp clock rate that is equal to the audio sampling rate. Permitted rates are 32000, 44100, and 48000.
レート：オーディオサンプリングレートに等しいRTPタイムスタンプクロックレート。許可された料金は32000、44100、および48000です。
o Optional parameters:
o オプションのパラメーター：
channels: From a sender, the maximum number of channels present in the AC3 stream. From a receiver, the maximum number of output channels the receiver will deliver. This MUST be a number between 1 and 6. The LFE (".1") channel MUST be counted as one channel. Note that the channel order used in AC-3 differs from the channel order scheme in [RFC3551]. The AC-3 channel order scheme can be found in Table 5.8 of [ATSC].
チャネル：送信者から、AC3ストリームに存在するチャネルの最大数。受信機から、レシーバーが配信する出力チャネルの最大数。これは1〜6の数でなければなりません。LFE（ ".1"）チャネルは1つのチャネルとしてカウントする必要があります。AC-3で使用されるチャネル順序は、[RFC3551]のチャネル順序スキームとは異なることに注意してください。AC-3チャネルの順序スキームは、[ATSC]の表5.8にあります。
ptime: See RFC 2327 [RFC2327].
PTIME：RFC 2327 [RFC2327]を参照してください。
maxptime: See RFC 3267 [RFC3267].
Maxptime：RFC 3267 [RFC3267]を参照してください。
o Encoding considerations:
o 考慮事項のエンコード：
This media type is framed (see section 4.8 in [DRAFT-FREED]) and contains binary data.
このメディアタイプはフレーム（[ドラフトフリード]のセクション4.8を参照）で、バイナリデータが含まれています。
o Security considerations:
o セキュリティ上の考慮事項：
See Section 6 of this document.
このドキュメントのセクション6を参照してください。
o Interoperability considerations:
o 相互運用性の考慮事項：
None
なし
o Published specification:
o 公開された仕様：
This payload format specification and see [ATSC].
このペイロード形式の仕様と[ATSC]を参照してください。
o Applications that use this media type:
o このメディアタイプを使用するアプリケーション：
Multichannel audio compression of audio and audio for video.
ビデオ用のオーディオとオーディオのマルチチャネルオーディオ圧縮。
o Additional Information:
o 追加情報：
Magic number(s): The first two octets of an AC-3 frame are always the synchronization word, which has the hex value 0x0B77.
マジック番号：AC-3フレームの最初の2オクテットは、常に同期単語であり、HEX値0x0B77です。
o Person & email address to contact for further information:
o 詳細については、連絡先への個人およびメールアドレス：
Brian Link <bdl@dolby.com> IETF AVT working group.
ブライアンリンク<bdl@dolby.com> ietf avtワーキンググループ。
o Intended Usage:
o 意図された使用法：
COMMON
一般
o Restrictions on usage:
o 使用に関する制限：
This media type depends on RTP framing, and hence is only defined for transfer via RTP [RFC3550]. Transport within other framing protocols is not defined at this time.
このメディアタイプはRTPフレーミングに依存するため、RTP [RFC3550]を介した転送に対してのみ定義されます。この時点では、他のフレーミングプロトコル内の輸送は定義されていません。
Author/Change controller:
著者/変更コントローラー：
IETF Audio/Video Transport Working Group delegated from the IESG.
IETFオーディオ/ビデオトランスポートワーキンググループは、IESGから委任されました。
The information carried in the MIME media type specification has a specific mapping to fields in the Session Description Protocol (SDP) [RFC2327], which is commonly used to describe RTP sessions. When SDP is used to specify sessions employing AC-3, the mapping is as follows:
MIMEメディアタイプの仕様に掲載されている情報には、セッション説明プロトコル（SDP）[RFC2327]のフィールドへの特定のマッピングがあります。これは、RTPセッションを説明するために一般的に使用されます。SDPがAC-3を使用するセッションを指定するために使用される場合、マッピングは次のとおりです。
o The Media type ("audio") goes in SDP "m=" as the media name.
o メディアタイプ（ "Audio"）は、メディア名としてSDP "m ="になります。
o The Media subtype ("ac3") goes in SDP "a=rtpmap" as the encoding name.
o メディアサブタイプ（ "AC3"）は、エンコーディング名としてSDP "a = rtpmap"になります。
o The required parameter "rate" also goes in "a=rtpmap" as the clock rate, optionally followed by the parameter "channel".
o 必要なパラメーター「レート」は、クロックレートとして「a = rtpmap」にも含まれ、オプションでパラメーター「チャネル」が続きます。
o The optional parameters "ptime" and "maxptime" go in the SDP "a=ptime" and "a=maxptime" attributes, respectively.
o オプションのパラメーター「PTIME」と「MAXPTIME」は、それぞれSDP「A = PTIME」および「A = MaxPtime」属性に移動します。
An example of the SDP data for AC-3:
AC-3のSDPデータの例：
m=audio 49111 RTP/AVP 100 a=rtpmap:100 ac3/48000/6
M =オーディオ49111 RTP/AVP 100 A = RTPMAP：100 AC3/48000/6
Certain considerations are needed when SDP is used to perform offer/answer exchanges [RFC3264].
SDPを使用してオファー/回答交換[RFC3264]を実行する場合は、特定の考慮事項が必要です。
o The "rate" is a symmetric parameter, and the answer MUST use the same value or remove the payload type.
o 「レート」は対称パラメーターであり、答えは同じ値を使用するか、ペイロードタイプを削除する必要があります。
o The "channels" parameter is declarative and indicates, for recvonly or sendrecv, the desired channel configuration to receive, and for sendonly, the intended channel configuration to transmit. All receivers are capable of receiving any of the defined channel configurations, and the parameter exchange might be used to help optimize the transmission to the number of channels the receiver requests. If the "channels" parameter is omitted, a default maximum value of 6 is implied.
o 「チャネル」パラメーターは宣言的であり、RecvonlyまたはSendRecvの場合、受信する目的のチャネル構成、および送信する意図したチャネル構成を示します。すべての受信機は、定義されたチャネル構成を受信することができ、パラメーター交換を使用して、受信機要求のチャネル数への伝送を最適化するのに役立ちます。「チャネル」パラメーターが省略されている場合、デフォルトの最大値6が暗示されます。
o The "ptime" and "maxptime" parameters are negotiated as defined for "ptime" in RFC 3264 [RFC3264].
o 「PTIME」および「MAXPTIME」パラメーターは、RFC 3264 [RFC3264]の「PTIME」に対して定義されていると交渉されます。
The payload format described in this document is subject to the security considerations defined in the RTP specification [RFC3550] and in any applicable RTP profile (e.g., [RFC3551]). To protect the user's privacy and any copyrighted material, confidentiality protection would have to be applied. To also protect against modification by intermediate entities and ensure the authenticity of the stream, integrity protection and authentication would be required. Confidentiality, integrity protection, and authentication have to be provided by a mechanism external to this payload format, e.g., SRTP [RFC3711].
このドキュメントで説明されているペイロード形式は、RTP仕様[RFC3550]および該当するRTPプロファイル（[RFC3551]など）で定義されているセキュリティ上の考慮事項の対象となります。ユーザーのプライバシーと著作権で保護された資料を保護するには、機密保護を適用する必要があります。また、中間エンティティによる変更から保護し、ストリーム、整合性の保護、および認証の信頼性を確保するために必要です。機密性、整合性保護、および認証は、このペイロード形式の外部のメカニズム、たとえばSRTP [RFC3711]によって提供する必要があります。
The AC-3 format is designed so that the validity of data frames can determined by decoders. A decoder that encounters a malformed frame discards the malformed data and conceals the errors in the audio output until a valid frame is detected and decoded. This is expected to prevent crashes and other abnormal decoder behavior in response to errors or attacks.
AC-3形式は、データフレームの有効性がデコーダーによって決定できるように設計されています。奇形のフレームに遭遇するデコーダーは、不正なデータを破棄し、有効なフレームが検出されてデコードされるまでオーディオ出力のエラーを隠します。これは、エラーや攻撃に応じて、クラッシュやその他の異常なデコーダーの動作を防ぐことが期待されています。
The general congestion control considerations for transporting RTP data apply to AC-3 audio over RTP as well. See the RTP specification [RFC3550] and any applicable RTP profile (e.g., [RFC3551]).
RTPデータを輸送するための一般的な混雑制御の考慮事項は、RTPよりもAC-3オーディオにも適用されます。RTP仕様[RFC3550]および該当するRTPプロファイル（[RFC3551]など）を参照してください。
AC-3 encoders may use a range of bit rates to encode audio data, so it is possible to adapt network bandwidth by adjusting the encoder bit rate in real time or by having multiple copies of content encoded at different bit rates. Additionally, 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 robustness against packet losses.
AC-3エンコーダーは、オーディオデータをエンコードするためにさまざまなビットレートを使用する場合があるため、エンコーダービットレートをリアルタイムで調整するか、異なるビットレートでエンコードされたコンテンツの複数のコピーを使用することで、ネットワーク帯域幅を適合させることができます。さらに、各RTPペイロードでより多くのフレームを梱包すると、送信されるパケットの数を減らすことができ、したがって、パケット損失に対する遅延の増加と堅牢性の低下を犠牲にして、IP/UDP/RTPヘッダーからのオーバーヘッドを減らすことができます。
A new media subtype has been assigned for AC-3; see Section 5.1.
AC-3に新しいメディアサブタイプが割り当てられています。セクション5.1を参照してください。
[RFC2119] Bradner, S., "Key Words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、RFC 2119、1997年3月。
[ATSC] U.S. Advanced Television Systems Committee (ATSC), "ATSC Standard: Digital Audio Compression (AC-3), Revision B," Doc A/52B, June 2005.
[ATSC]米国先進テレビシステム委員会（ATSC）、「ATSC標準：デジタルオーディオ圧縮（AC-3）、リビジョンB」、Doc A/52B、2005年6月。
[RFC2327] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998.
[RFC2327] Handley、M。and V. Jacobson、「SDP：セッション説明プロトコル」、RFC 2327、1998年4月。
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
[RFC3550] Schulzrinne、H.、Casner、S.、Frederick、R。、およびV. Jacobson、「RTP：リアルタイムアプリケーション用の輸送プロトコル」、STD 64、RFC 3550、2003年7月。
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.
[RFC3264] Rosenberg、J。およびH. Schulzrinne、「セッション説明プロトコル（SDP）のオファー/回答モデル」、RFC 3264、2002年6月。
[RFC3267] 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.
[RFC3267] Sjoberg、J.、Westerlund、M.、Lakaniemi、A。、およびQ. Xie、 "リアルタイム輸送プロトコル（RTP）ペイロード形式とファイルストレージ形式（AMR）および適応型マルチマルチ - レートワイドバンド（AMR-WB）オーディオコーデック "、RFC 3267、2002年6月。
[RFC3555] Casner, S. and P. Hoschka, "MIME Type Registration of RTP Payload Formats", RFC 3555, July 2003.
[RFC3555] Casner、S。およびP. Hoschka、「RTPペイロードフォーマットのMIMEタイプ登録」、RFC 3555、2003年7月。
[RFC2736] Handley, M. and C. Perkins, "Guidelines for Writers of RTP Payload Format Specifications", BCP 36, RFC 2736, December 1999.
[RFC2736] Handley、M。およびC. Perkins、「RTPペイロード形式の仕様の作家のためのガイドライン」、BCP 36、RFC 2736、1999年12月。
[RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video Conferences with Minimal Control", STD 65, RFC 3551, July 2003.
[RFC3551] Schulzrinne、H。およびS. Casner、「最小限のコントロールを備えたオーディオおよびビデオ会議のRTPプロファイル」、STD 65、RFC 3551、2003年7月。
[1994AC3] Todd, C., et al., "AC-3: Flexible Perceptual Coding for Audio Transmission and Storage," Preprint 3796, Presented at the 96th Convention of the Audio Engineering Society, May 1994.
[1994AC3] Todd、C.、et al。、「AC-3：オーディオ送信とストレージの柔軟な知覚コーディング」、Preprint 3796は、1994年5月にオーディオエンジニアリング協会の第96条約で発表されました。
[1996AC3] Fielder, L., et al., "AC-2 and AC-3: Low-Complexity Transform-Based Audio Coding," Collected Papers on Digital Audio Bit-Rate Reduction, pp. 54-72, Audio Engineering Society, September 1996.
[1996AC3] Fielder、L.、et al。、「AC-2およびAC-3：低複雑度変換ベースのオーディオコーディング」、デジタルオーディオビットレート削減に関する論文の収集、54-72ページ、オーディオエンジニアリングソサエティ、1996年9月。
[RFC3711] Baugher, M., et al., "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004.
[RFC3711] Baugher、M.、et al。、「The Secure Real-Time Transport Protocol（SRTP）」、RFC 3711、2004年3月。
[DRAFT-FREED] Freed, N. and Klensin, J., "Media Type Specifications and Registration Procedures", Work in Progress, April 2005.
[Draft-Freed] Freed、N。およびKlensin、J。、「メディアタイプの仕様と登録手順」、2005年4月、進行中の作業。
Authors' Addresses
著者のアドレス
Brian Link Dolby Laboratories 100 Potrero Ave San Francisco, CA 94103
ブライアンリンクドルビーラボラトリーズ100ポトレロアベニューサンフランシスコ、カリフォルニア94103
Phone: +1 415 558 0200
EMail: bdl@dolby.com
Todd Hager Dolby Laboratories 100 Potrero Ave San Francisco, CA 94103
トッド・ヘイガー・ドルビー研究所100ポトレロ・アベニュー・サンフランシスコ、カリフォルニア94103
Phone: +1 415 558 0136
EMail: thh@dolby.com
Jason Flaks Microsoft Corporation 1 Microsoft Way Redmond, WA 98052
ジェイソンフラックスマイクロソフトコーポレーション1マイクロソフトウェイレドモンド、ワシントン州98052
Phone: +1 425 722 2543
EMail: jasonfl@microsoft.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エディター機能の資金は現在、インターネット協会によって提供されています。