[要約] RFC 3190は、12ビットDATオーディオと20ビットおよび24ビットのリニアサンプルオーディオのためのRTPペイロード形式を定義しています。このRFCの目的は、これらのオーディオ形式をRTPパケットにエンコードするための標準化と相互運用性を提供することです。
Network Working Group K. Kobayashi
Request for Comments: 3190 Communication Research Laboratory
Category: Standards Track A. Ogawa
Keio University
S. Casner
Packet Design
C. Bormann
Universitaet Bremen TZI
January 2002
RTP Payload Format for 12-bit DAT Audio and 20- and 24-bit Linear Sampled Audio
12ビットデータオーディオおよび20および24ビットの線形サンプリングオーディオ用の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 (2002). All Rights Reserved.
Copyright（c）The Internet Society（2002）。無断転載を禁じます。
Abstract
概要
This document specifies a packetization scheme for encapsulating 12-bit nonlinear, 20-bit linear, and 24-bit linear audio data streams using the Real-time Transport Protocol (RTP). This document also specifies the format of a Session Description Protocol (SDP) parameter to indicate when audio data is preemphasized before sampling. The parameter may be used with other audio payload formats, in particular L16 (16-bit linear).
このドキュメントは、リアルタイムトランスポートプロトコル（RTP）を使用して、12ビットの非線形、20ビット線形、および24ビットの線形オーディオデータストリームをカプセル化するためのパケット化スキームを指定します。このドキュメントは、セッション説明プロトコル（SDP）パラメーターの形式を指定して、サンプリング前にオーディオデータが事前に強調されていることを示します。このパラメーターは、他のオーディオペイロード形式、特にL16（16ビット線形）で使用できます。
This document describes the sampling of audio data in 12-bit nonlinear, 20-bit linear, and 24-bit linear encodings, and specifies the encapsulation of the audio data into the Real-time Transport Protocol (RTP), version 2 [1,2]. DAT (digital audio tape) and DV (digital video) devices [3,4] use these audio encodings in addition to 16-bit linear encoding. The packetization scheme for 16-bit linear audio (L16) is already specified [2,5]. This document specifies the packetization scheme for the other encodings following that for L16; in particular, when used with the RTP profile [2], these payload formats follow the encoding-independent rules for sample ordering and channel interleaving specified in [2] plus extensions specified here. This document also specifies out-of-band negotiation methods for the extended channel interleaving rules and for use when an analog preemphasis technique is applied to the audio data.
このドキュメントでは、12ビットの非線形、20ビット線形、および24ビットの線形エンコーディングでのオーディオデータのサンプリングについて説明し、オーディオデータのリアルタイムトランスポートプロトコル（RTP）、バージョン2へのカプセル化を指定します[1、2]。DAT（デジタルオーディオテープ）とDV（デジタルビデオ）デバイス[3,4]は、16ビット線形エンコードに加えて、これらのオーディオエンコーディングを使用します。16ビット線形オーディオ（L16）のパケット化スキームはすでに指定されています[2,5]。このドキュメントは、L16に続く他のエンコーディングのパケット化スキームを指定します。特に、RTPプロファイル[2]で使用する場合、これらのペイロード形式は、[2]で指定されたサンプルの順序とチャネルインターリーブのエンコーディング非依存ルールと、ここで指定された拡張機能に従います。このドキュメントは、拡張チャネルインターリーブルールの帯域外交渉方法と、アナログ前の強調技術がオーディオデータに適用される場合に使用するための帯域外交渉方法も指定しています。
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 [6]
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「optional」は、RFC 2119 [6]に記載されていると解釈される
Many high-quality digital audio and visual systems, such as DAT and DV, adopt sample-based audio encodings. Different audio formats are used in various situations. To transport the audio data using RTP, an encapsulation needs to be defined for each specific format. Only 16-bit linear audio encapsulation (L16) has thus far been defined. Other encoding formats have already appeared, such as the 12-bit nonlinear, 20-bit linear and 24-bit linear encodings used in the DAT and DV video world. This specification defines the RTP payload encapsulation format in order to use the new encodings in the RTP environment.
DATやDVなどの多くの高品質のデジタルオーディオおよびビジュアルシステムは、サンプルベースのオーディオエンコーディングを採用しています。さまざまな状況でさまざまなオーディオ形式が使用されています。RTPを使用してオーディオデータを輸送するには、特定の形式ごとにカプセル化を定義する必要があります。これまでに定義されているのは、16ビットの線形オーディオカプセル化（L16）のみです。DATおよびDV Video Worldで使用される12ビットの非線形、20ビット線形、24ビットの線形エンコードなど、他のエンコード形式が既に表示されています。この仕様では、RTP環境で新しいエンコーディングを使用するために、RTPペイロードカプセル化形式を定義します。
IEC 61119 [3] specifies the 12-bit nonlinear audio format in DAT and DV, called LP (Long Play) audio. It would be easy to convert 12-bit nonlinear audio into 16-bit linear form at the RTP sender and transmit it using the L16 audio format already defined. However, this would consume 33% more network bandwidth than necessary. This payload format is specified as a more efficient alternative.
IEC 61119 [3]は、LP（Long Play）オーディオと呼ばれるDATおよびDVで12ビットの非線形オーディオ形式を指定します。RTP送信者で12ビットの非線形オーディオを16ビット線形フォームに変換し、すでに定義されているL16オーディオ形式を使用して送信するのは簡単です。ただし、これにより、必要以上に33％のネットワーク帯域幅が消費されます。このペイロード形式は、より効率的な代替品として指定されています。
The 12-bit nonlinear encoding is the same as for 16-bit linear audio except for the packing of each sampled data element. Each sample of 12-bit nonlinear audio is derived from a single sample of 16-bit linear audio by a nonlinear compression. Table 1 shows the details of the conversion from 16 to 12 bits. The result is a 12-bit signed value ranging from -2048 to 2047 and it is represented in two's complement notation. The 12-bit samples are packed contiguously into payload octets starting with the most significant bit. When the payload contains an odd number of samples, the four LSBs of the last octet are unused. Parameters other than quantization, e.g., sampling frequency and audio channel assignment, are the same as in the L16 payload format. In particular, samples are packed into the packet in time sequence beginning with the oldest sample.
12ビットの非線形エンコードは、各サンプリングされたデータ要素の梱包を除き、16ビットの線形オーディオの場合と同じです。12ビットの非線形オーディオの各サンプルは、非線形圧縮により16ビット線形オーディオの単一サンプルから導出されます。表1は、16〜12ビットの変換の詳細を示しています。その結果、-2048から2047の範囲の12ビットの署名値があり、2つの補数表記に表されます。12ビットサンプルは、最も重要なビットから始まるペイロードオクテットに連続的に詰め込まれています。ペイロードに奇数のサンプルが含まれている場合、最後のオクテットの4つのLSBが使用されていません。量子化以外のパラメーター、例えばサンプリング周波数およびオーディオチャネルの割り当ては、L16ペイロード形式と同じです。特に、サンプルは、最も古いサンプルから始まる時間シーケンスでパケットに詰め込まれます。
------------------------------------------------------------
32,767 (7FFFh) Y = INT(X/64) + (600h) 2,047 (7FFh)
16,384 (4000h) 1,792 (700h)
------------------------------------------------------------
16,383 (3FFFh) Y = INT(X/32) + (500h) 1,791 (6FFh)
8,192 (2000h) 1,536 (600h)
------------------------------------------------------------
8,191 (1FFFh) Y = INT(X/16) + (400h) 1,535 (5FFh)
4,096 (1000h) 1,280 (500h)
------------------------------------------------------------
4,095 (0FFFh) Y = INT(X/8) + (300h) 1,279 (4FFh)
2,048 (0800h) 1,024 (400h)
------------------------------------------------------------
2,047 (07FFh) Y = INT(X/4) + (200h) 1,023 (3FFh)
1,024 (0400h) 768 (300h)
------------------------------------------------------------
1,023 (03FFh) Y = INT(X/2) + (100h) 767 (2FFh)
512 (0200h) 512 (200h)
------------------------------------------------------------
511 (01FFh) Y = X 511 (1FFh)
0 (0000h) 0 (000h)
------------------------------------------------------------
-1 (FFFFh) Y = X -1 (FFFh)
-512 (FE00h) -512 (E00h)
------------------------------------------------------------
-513 (FFFFh) Y = INT((X + 1)/2) - (101h) -513 (DFFh)
-1,024 (FE00h) -768 (D00h)
------------------------------------------------------------
-1,025 (FBFFh) Y = INT((X + 1)/4) - (201h) -769 (CFFh)
-2,048 (F800h) -1,024 (C00h)
------------------------------------------------------------
-2,049 (F7FFh) Y = INT((X + 1)/8) - (301h) -1,025 (BFFh)
-4,096 (F000h) -1,280 (B00h)
------------------------------------------------------------
-4,097 (EFFFh) Y = INT((X + 1)/16) - (401h) -1,281 (AFFh)
-8,192 (E000h) -1,536 (A00h)
------------------------------------------------------------
-8,193 (DFFFh) Y = INT((X + 1)/32) - (501h) -1,537 (9FFh)
-16,384 (C000h) -1,792 (900h)
------------------------------------------------------------
-16,385 (BFFFh) Y = INT((X + 1)/64) - (601h) -1,793 (8FFh)
-32,768 (8000h) -2,048 (800h)
------------------------------------------------------------
Table 1. Conversion from 16-bit linear values (X) to 12-bit nonlinear values (Y) [3]
表1. 16ビット線形値（x）から12ビットの非線形値（y）への変換[3]
When conveying encoding information in an SDP [7] session description, the 12-bit nonlinear audio payload format specified here is given the encoding name "DAT12". Thus, the media format representation might be:
SDP [7]セッションの説明でエンコード情報を伝えるとき、ここで指定された12ビットの非線形オーディオペイロード形式には、エンコード名「DAT12」が与えられます。したがって、メディア形式の表現は次のとおりです。
m=audio 49230 RTP/AVP 97 98
a=rtpmap:97 DAT12/32000/2
a=rtpmap:98 L16/48000/2
The 20- and 24-bit linear audio encodings are simply an extension of the L16 linear audio encoding [2]. The 20- or 24-bit uncompressed audio data samples are represented as signed values in two's complement notation. The samples are packed contiguously into payload octets starting with the most significant bit. For the 20-bit encoding, when the payload contains an odd number of samples, the four LSBs of the last octet are unused. Samples are packed into the packet in time sequence beginning with the oldest sample.
20および24ビットの線形オーディオエンコーディングは、単にL16線形オーディオエンコードの拡張です[2]。20または24ビットの非圧縮オーディオデータサンプルは、2つの補数表記で署名された値として表されます。サンプルは、最も重要なビットから始まるペイロードオクテットに連続的に詰め込まれています。20ビットエンコーディングの場合、ペイロードに奇数のサンプルが含まれている場合、最後のオクテットの4つのLSBが使用されません。サンプルは、最も古いサンプルから始まる時間シーケンスでパケットに詰め込まれています。
When conveying encoding information in an SDP session description, the 20- and 24-bit linear audio payload formats specified here are given the encoding names "L20" and "L24", respectively. An example SDP audio media description would be:
SDPセッションの説明でエンコード情報を伝える場合、ここで指定されている20および24ビットの線形オーディオペイロード形式は、それぞれエンコード名「L20」と「L24」が与えられます。SDPオーディオメディアの説明の例は次のとおりです。
m=audio 49230 RTP/AVP 99 100
a=rtpmap:99 L20/48000/2
a=rtpmap:100 L24/48000
In order to improve the higher frequency characteristics of audio signals, analog preemphasis is often applied to the signal before quantization. If analog preemphasis was applied before the payload data was sampled, the type of the preemphasis SHOULD be conveyed with out-of-band signaling. An "emphasis" parameter is defined for this purpose and may be conveyed either as a MIME optional parameter or using the SDP format-specific attribute (a=fmtp line) as below:
オーディオ信号のより高い周波数特性を改善するために、類似物前のエンペナスは、量子化前に信号に適用されることがよくあります。ペイロードデータがサンプリングされる前にアナログの事前増強が適用された場合、エンペセス前のシグナリングで具体的なタイプを伝える必要があります。「強調」パラメーターはこの目的のために定義され、MIMEオプションパラメーターとして、または以下のようにSDP形式固有の属性（a = fmtp行）を使用して伝えることができます。
a=fmtp:<payload type> emphasis=<emphasis type>
Only one <emphasis type> value is defined for the parameter at this point:
この時点でパラメーターに対して定義されているのは、1つの<Emphasis Type>値のみが定義されています。
50-15 <50/15 microsecond CD-type emphasis>
50-15 <50/15マイクロ秒CDタイプの強調>
The emphasis attribute MUST NOT be included in the SDP record if preemphasis was not applied. This rule allows the emphasis attribute to be used with other audio formats, in particular L16 [2], while retaining backward compatibility with existing implementations so long as preemphasis is not applied. If an existing application that does not implement preemphasis accepts a session description with an emphasis attribute but ignores that attribute, the only penalty is that the sound will be too "bright" when receiving or "dull" when sending.
強調前の属性は、事前の強調が適用されなかった場合、SDPレコードに含めるべきではありません。このルールにより、他のオーディオ形式、特にL16 [2]で強調属性を使用することができ、既存の実装との逆互換性を維持し、既存の実装が適用されない限り。事前強調を実装しない既存のアプリケーションが、強調属性を持つセッションの説明を受け入れるが、その属性を無視する場合、唯一のペナルティは、送信時に受信または「鈍い」音が「明るく」あまりにも「明るく」ことです。
A sample SDP record showing preemphasis applied only to payload type 99 might be as follows:
ペイロードタイプ99にのみ適用されるエンファシス前のサンプルSDPレコードは次のとおりかもしれません。
m=audio 49230 RTP/AVP 99 100
a=rtpmap:99 L20/48000/2
a=fmtp:99 emphasis=50-15
a=rtpmap:100 L24/48000
The DV video specification IEC 61834-4 [4] defines the negative full-scale audio sample value to be an audio error code indicating that no valid audio sample is available for that sample period. Such an error might occur due to a failure while reading audio data from magnetic tape. The audio error code values for each of the DV audio encodings are (in hexadecimal):
DVビデオ仕様IEC 61834-4 [4]は、ネガティブフルスケールのオーディオサンプル値を、そのサンプル期間に有効なオーディオサンプルが利用できないことを示すオーディオエラーコードであると定義しています。このようなエラーは、磁気テープからオーディオデータを読み取る際に障害のために発生する可能性があります。DVオーディオエンコーディングのそれぞれのオーディオエラーコード値は（16進数）です。
12-bit nonlinear: 800h 16-bit linear: 8000h 20-bit linear: 80000h
12ビット非線形：800h 16ビット線形：8000h 20ビット線形：80000h
For the payload formats defined in this document, as well as for the L16 payload format defined in [2], no such error code is defined. That is, all possible sample values are valid. When an RTP sender accepts audio samples from a DV video system and encapsulates those samples according to one of these payload formats, the RTP sender SHOULD perform some error concealment algorithm which may depend upon whether a single sample error or multiple sample errors have occurred. The error concealment algorithm is not specified here and is left to the implementation. The RTP sender MAY treat the error code as if it were a valid audio sample, but this is likely to cause undesirable audio output.
このドキュメントで定義されているペイロード形式と[2]で定義されているL16ペイロード形式の場合、そのようなエラーコードは定義されていません。つまり、考えられるすべてのサンプル値は有効です。RTP送信者がDVビデオシステムからオーディオサンプルを受け入れ、これらのペイロード形式のいずれかに従ってそれらのサンプルをカプセル化する場合、RTP送信者は、単一のサンプルエラーまたは複数のサンプルエラーが発生したかどうかに依存する可能性のあるエラー隠蔽アルゴリズムを実行する必要があります。エラー隠蔽アルゴリズムはここでは指定されておらず、実装に任されています。RTP送信者は、エラーコードを有効なオーディオサンプルであるかのように扱う場合がありますが、これは望ましくないオーディオ出力を引き起こす可能性があります。
Conversely, an RTP receiver that accepts audio packets in one of these payload formats and delivers the audio samples to a DV video system SHOULD translate the audio samples that would be interpreted as error codes into the next smaller negative audio value. Such audio samples may be present because the audio packets may have come from a source other than a DV video system. The DV video specification [4] gives the following translations for the defined audio encodings:
逆に、これらのペイロード形式のいずれかでオーディオパケットを受け入れ、オーディオサンプルをDVビデオシステムに配信するRTPレシーバーは、エラーコードとして解釈されるオーディオサンプルを次の小さなネガティブオーディオ値に変換する必要があります。オーディオパケットは、DVビデオシステム以外のソースから来た可能性があるため、このようなオーディオサンプルが存在する可能性があります。DVビデオ仕様[4]は、定義されたオーディオエンコーディングの次の翻訳を示しています。
12-bit nonlinear: 800h -> 801h
16-bit linear: 8000h -> 8001h
20-bit linear: 80000h - 8000Fh -> 80010h
For the 20-bit linear encoding, note that multiple audio sample values are translated in order to allow a 16-bit system to play 20- bit audio data by ignoring the least significant four bits. Note also that no translation is specified for 24-bit linear audio because that encoding is not included in the DV video specification.
20ビット線形エンコードの場合、16ビットシステムが最小の重要な4ビットを無視して20ビットオーディオデータを再生できるようにするために、複数のオーディオサンプル値が翻訳されることに注意してください。また、そのエンコードはDVビデオ仕様に含まれていないため、24ビット線形オーディオに翻訳が指定されていないことに注意してください。
When multiple channels of audio, such as in a stereo program, are multiplexed into a single RTP stream, the audio samples from each channel are interleaved according to the rules specified in [2] to be consistent with the L16 payload format. That is, samples from different channels taken at the same sampling instant are packed into consecutive octets. For example, for a two-channel encoding, the sample sequence is (left channel, first sample), (right channel, first sample), (left channel, second sample), (right channel, second sample). Samples for all channels belonging to a single sampling instant MUST be contained in the same packet.
ステレオプログラムなどの複数のオーディオチャネルが単一のRTPストリームに多重化されると、各チャネルのオーディオサンプルは、[2]で指定されたルールに従ってL16ペイロード形式と一致するように相互にリードされます。つまり、同じサンプリングインスタントで撮影した異なるチャネルのサンプルは、連続したオクテットに詰め込まれています。たとえば、2チャンネルエンコードの場合、サンプルシーケンスは（左チャネル、最初のサンプル）、（右チャネル、最初のサンプル）、（左チャネル、2番目のサンプル）、（右チャネル、2番目のサンプル）です。単一のサンプリングインスタントに属するすべてのチャネルのサンプルは、同じパケットに含める必要があります。
This sample order differs from the packing of samples into blocks in a native DV audio stream. Therefore, applications transmitting DV audio using the payload formats defined in this document MUST reshuffle the samples into the order specified here. This requirement is intended to enable interworking between DV systems and other digital audio systems. Applications choosing to send bundled DV audio/video streams using the native DV block structure may use the payload format defined in [8] instead.
このサンプル順序は、ネイティブDVオーディオストリームのサンプルの梱包とは異なります。したがって、このドキュメントで定義されているペイロードフォーマットを使用してDVオーディオを送信するアプリケーションは、ここで指定された順序にサンプルを変更する必要があります。この要件は、DVシステムと他のデジタルオーディオシステム間の相互作用を可能にすることを目的としています。ネイティブDVブロック構造を使用してバンドルされたDVオーディオ/ビデオストリームを送信することを選択するアプリケーションは、代わりに[8]で定義されているペイロード形式を使用する場合があります。
Most of the existing RTP audio payload formats follow the AIFF-C convention for channel ordering as specified in [2] when sending more than two audio channels within a single RTP stream. However, this convention does not cover some applications. For example, some DV audio formats define a "woofer" channel, but AIFF-C does not include this frequency-dependent channel. Thus, it is necessary to specify the audio channel allocation information explicitly when the contents of the audio stream are beyond the scope of AIFF-C.
既存のRTPオーディオペイロードフォーマットのほとんどは、単一のRTPストリーム内で3つ以上のオーディオチャネルを送信する場合、[2]で指定されたチャネル注文のAIFF-Cコンベンションに従います。ただし、この条約はいくつかのアプリケーションをカバーしていません。たとえば、一部のDVオーディオフォーマットは「ウーファー」チャネルを定義しますが、AIFF-Cにはこの周波数依存チャネルは含まれていません。したがって、オーディオストリームの内容がAIFF-Cの範囲を超えている場合、オーディオチャネル割り当て情報を明示的に指定する必要があります。
For DV audio streams of 4 or more channels, the channel order MUST be specified out-of-band. This applies both to the payload formats defined in this document and to the L16 payload format. A "channel- order" parameter is defined here for this purpose and may be conveyed either as a MIME optional parameter or with the SDP a=fmtp attribute using the following syntax:
4つ以上のチャネルのDVオーディオストリームの場合、チャネルの順序を帯域外に指定する必要があります。これは、このドキュメントで定義されているペイロード形式とL16ペイロード形式の両方に適用されます。この目的のために「チャネル順」パラメーターはここで定義され、MIMEオプションパラメーターとして、または次の構文を使用してSDP A = FMTP属性として伝達できます。
a=fmtp:<payload type> channel-order=<convention>.<order>
The first component of the value, <convention>, specifies the type of channel assignment convention used. This allows for conventions other than AIFF-C and DV to be defined in the future. This document defines only one convention for use in the channel-order parameter:
値の最初のコンポーネント<コンベンション>は、使用するチャネル割り当て規則のタイプを指定します。これにより、AIFF-CおよびDV以外の規則が将来定義されます。このドキュメントでは、チャネルオーダーパラメーターで使用するための1つの慣習のみを定義しています。
DV
DV
The second component of the value, <order>, indicates the arrangement of channels within the stream. The DV video specification [4] defines the types of audio channels that may be present and in what order. The symbols used to denote the channel types are reproduced in the Appendix at the end of this document. For the DV convention, the following values, which were formed from the concatenation of the individual channel symbols in the allowed channel orders, are defined for the <order> component:
値の2番目のコンポーネント<Order>は、ストリーム内のチャネルの配置を示します。DVビデオ仕様[4]は、存在する可能性のあるオーディオチャネルの種類とどの順序で定義されています。チャネルタイプを示すために使用されるシンボルは、このドキュメントの最後にある付録に再現されています。DV条約の場合、許可されたチャネル順序で個々のチャネルシンボルの連結から形成された次の値は、<dorder>コンポーネントに対して定義されています。
4 channels: LRLsRs, LRCS, LRCWo 5 channels: LRLsRsC 6 channels: LRLsRsCS, LmixRmixTWoQ1Q2 8 channels: LRCWoLsRsLmixRmix, LRCWoLs1Rs1Ls2Rs2, LRCWoLsRsLcRc
4チャネル：LRLSRS、LRCS、LRCWO 5チャンネル：LRLSRSC 6チャネル：LRLSRSCS、LMIXRMIXTWOQ1Q2 8チャンネル：LRCWOLSLMIXRMIX、LRCWOLS1RS1LS2、LRCWOLSRSRSLCRCRCC
The <convention> and <order> symbols are case-insensitive, but are shown here in mixed case to make the individual channel symbols more apparent. These concatenated symbols were deliberately constructed without separators to make clear the fact that the channels MUST NOT be assembled in other, arbitrary orders.
<コンベンション>および<dorder>シンボルはケース非感受性ですが、個々のチャネルシンボルをより明確にするために混合ケースでここに示されています。これらの連結されたシンボルは、セパレーターなしで意図的に構築され、チャネルを他の任意の順序で組み立ててはならないという事実を明確にしました。
For interworking with DV video systems, some of the audio encodings are defined only for a subset of the channel combinations listed above. The DV video specification lists the channel combinations that are allowed for each encoding.
DVビデオシステムとの相互作用のために、一部のオーディオエンコーディングは、上記のチャネル組み合わせのサブセットに対してのみ定義されます。DVビデオ仕様には、各エンコードに許可されているチャネルの組み合わせがリストされています。
The channel-order parameter MUST be consistent with the number of channels specified in the MIME optional parameter "channels" or in the a=rtpmap attribute of SDP. For RTP audio streams of 1, 2 or 3 channels, the AIFF-C channel order is used and is implicit in the number of audio channels specified. To allow backward compatibility, the channel-order parameter MUST NOT be included in this case.
チャネルオーダーパラメーターは、MIMEオプションパラメーター「チャネル」またはSDPのa = rtpmap属性で指定されたチャネルの数と一致する必要があります。1、2、または3チャネルのRTPオーディオストリームの場合、AIFF-Cチャネルの順序が使用され、指定されたオーディオチャネルの数に暗黙的です。後方互換性を可能にするには、この場合にチャネル順序パラメーターを含めてはなりません。
Note that for the DV convention with 5 channels only one channel order is allowed, but for consistency the channel-order parameter MUST be included nonetheless.
5チャネルのDVコンベンションでは、1つのチャネル順序のみが許可されていることに注意してください。ただし、一貫性のためには、チャネル順のパラメーターを含める必要があります。
An example of an SDP session description using the channel-order parameter is:
チャネルオーダーパラメーターを使用したSDPセッション説明の例は次のとおりです。
v=0
o=ikob 2890844526 2890842807 IN IP4 126.16.64.4
s=POI (Audio only)
i=A Seminar on making Presentations on the Internet
u=http://www.koganei.wide.ad.jp/~ikob/POI/index.html
e=ikob@koganei.wide.ad.jp (Katsushi Kobayashi)
c=IN IP4 224.2.17.12/127
t=2873397496 2873404696
m=audio 49170 RTP/AVP 112 113
a=rtpmap:112 L16/48000/2
a=rtpmap:113 DAT12/32000/4
a=fmtp:113 emphasis=50-15; channel-order=DV.LRCWO
This session description shows the audio medium being transmitted in two formats, L16 and DAT12, using payload type numbers 112 and 113, respectively. For the L16 format, the audio data contains 2-channel stereo following the implicit, default AIFF-C convention for left channel first and right channel second. For the DAT12 format, the audio data contains 4 channels following the DV audio convention for the channels left, right, center, and woofer.
このセッションの説明には、それぞれペイロードタイプ番号112と113を使用して、2つの形式の2つの形式で送信されているオーディオメディアが2つの形式で送信されています。L16形式の場合、オーディオデータには、左チャンネルの最初と右チャンネルの暗黙のデフォルトAIFF-Cコンベンションに続く2チャンネルステレオが含まれています。DAT12形式の場合、オーディオデータには、左、右、中央、ウーファーのチャネルのDVオーディオコンベンションに続く4つのチャネルが含まれています。
This example also shows how multiple MIME optional parameters ("emphasis" and "channel-order") for these payload formats are mapped to a single a=fmtp attribute as a semicolon separated list of parameter=value pairs.
この例は、これらのペイロード形式の複数のMIMEオプションパラメーター（「強調」と「チャネルオーダー」）が、パラメーター=値ペアのセミコロン分離リストとして単一のa = fmtp属性にマッピングされる方法を示しています。
The channel-order parameter described here provides a generic out-of-band mechanism to define alternatives to the AIFF-C channel order. However, if multi-channel audio data could be sent following the AIFF-C channel convention after simple processing, such as a data shuffling on the sender side, the alternative channel order SHOULD NOT be defined and instead the AIFF-C order SHOULD be employed to maximize interoperability.
ここで説明するチャネルオーダーパラメーターは、AIFF-Cチャネルの順序の代替を定義するための一般的なバンド外のメカニズムを提供します。ただし、送信者側でのデータシャッフルなどの簡単な処理後にAIFF-Cチャネルコンベンションに続いてマルチチャネルオーディオデータを送信できる場合、代替チャネルの順序を定義しないでください。相互運用性を最大化するため。
Moreover, multiple channels of audio data should only be multiplexed within a single RTP stream when all of the audio channels are intended to be reproduced together, such as the left and right channels in a stereo program. Independent audio channels, such as multiple language translations, SHOULD be sent in separate RTP sessions. This reduces bandwidth requirements by allowing receivers to tune in to only those channels which are desired.
さらに、オーディオデータの複数のチャネルは、すべてのオーディオチャネルがステレオプログラムの左右のチャネルなど、一緒に再現されることを目的としている場合にのみ、単一のRTPストリーム内でのみ多重化する必要があります。複数の言語翻訳などの独立したオーディオチャネルは、個別のRTPセッションで送信する必要があります。これにより、受信機が必要なチャネルのみにチューニングできるようにすることにより、帯域幅の要件が削減されます。
This document defines some new RTP payload format names which are also registered as MIME subtypes: DAT12, L20 and L24. The registration forms for these MIME subtypes are provided in the next sections.
このドキュメントでは、MIMEサブタイプとしても登録されているいくつかの新しいRTPペイロード形式名を定義します：DAT12、L20、L24。これらのMIMEサブタイプの登録フォームは、次のセクションで提供されます。
MIME media type name: audio
MIMEメディアタイプ名：オーディオ
MIME subtype name: DAT12
MIMEサブタイプ名：dat12
Required parameters: rate: number of samples per second -- RECOMMENDED values for rate are 8000, 11025, 16000, 22050, 24000, 32000, 44100 and 48000 samples per second. Other values are permissible.
必要なパラメーター：レート：毎秒サンプル数 - レートの推奨値は8000、11025、16000、22050、24000、32000、44100、および48000サンプルです。他の値は許容されます。
Optional parameters: channels: how many audio streams are interleaved -- defaults to 1; stereo would be 2, etc. Interleaving takes place between individual 12-bit samples.
オプションのパラメーター：チャネル：インターリーブされるオーディオストリームの数 - デフォルトは1になります。ステレオは2などになります。個々の12ビットサンプル間でインターリーブが行われます。
emphasis: analog preemphasis applied to the data before quantization. The only emphasis value defined here is emphasis=50-15 to indicate 50/15 microsecond preemphasis. This parameter MUST be omitted if no analog preemphasis was applied.
強調：アナログ前のエンファシスは、量子化前にデータに適用されます。ここで定義されている唯一の強調値は、50/15マイクロ秒前の段階を示すための強調= 50-15です。アナログの事前強調が適用されなかった場合、このパラメーターは省略する必要があります。
channel-order: specifies the sample interleaving order for multiple-channel audio streams (see RFC 3190 Section 7). Permissible values are DV.LRLsRs, DV.LRCS, DV.LRCWo, DV.LRLsRsC, DV.LRLsRsCS, DV.LmixRmixTWoQ1Q2, DV.LRCWoLsRsLmixRmix, DV.LRCWoLs1Rs1Ls2Rs2, DV.LRCWoLsRsLcRc. For interoperation with DV video systems, only a subset of these channel combinations is specified for use with 12-bit nonlinear encoding in the DV video specification [4]; that subset is all of the above except DV.LmixRmixTWoQ1Q2. This parameter MUST be omitted when the AIFF-C channel order convention is in use.
チャネルオーダー：マルチチャネルオーディオストリームのサンプルインターリーブ順序を指定します（RFC 3190セクション7を参照）。Permissible values are DV.LRLsRs, DV.LRCS, DV.LRCWo, DV.LRLsRsC, DV.LRLsRsCS, DV.LmixRmixTWoQ1Q2, DV.LRCWoLsRsLmixRmix, DV.LRCWoLs1Rs1Ls2Rs2, DV.LRCWoLsRsLcRc.DVビデオシステムとの相互操作のために、これらのチャネルの組み合わせのサブセットのみが、DVビデオ仕様[4]で12ビットの非線形エンコードで使用するために指定されています。そのサブセットは、dv.lmixrmixtwoq1q2を除く上記のすべてです。このパラメーターは、AIFF-Cチャネルの注文規則が使用されている場合に省略する必要があります。
Encoding considerations: DAT12 audio can be transmitted with RTP as specified in RFC 3190.
考慮事項のエンコード：DAT12オーディオは、RFC 3190で指定されているようにRTPで送信できます。
Security considerations: See Section 9.
セキュリティ上の考慮事項：セクション9を参照してください。
Interoperability considerations: NONE Published specification: IEC 61119 Standard [4] and RFC 3190.
相互運用性の考慮事項：公開されていない仕様：IEC 61119標準[4]およびRFC 3190。
Applications which use this media type: Audio communication.
このメディアタイプを使用するアプリケーション：オーディオ通信。
Additional information:
Magic number(s): None
File extension(s): None
Macintosh File Type Code(s): None
Person & email address to contact for further information: Katsushi Kobayashi e-mail: ikob@koganei.wide.ad.jp
詳細については、人と電子メールアドレスをお問い合わせください：Katsushi Kobayashi E-mail：ikob@koganei.wide.ad.jp
Intended usage: COMMON
意図された使用法：共通
Author/Change controller: Katsushi Kobayashi e-mail: ikob@koganei.wide.ad.jp
著者/変更コントローラー：katsushi kobayashi電子メール：ikob@koganei.wide.ad.jp
MIME media type name: audio
MIMEメディアタイプ名：オーディオ
MIME subtype name: L20
MIMEサブタイプ名：L20
Required parameters: rate: number of samples per second -- RECOMMENDED values for rate are 8000, 11025, 16000, 22050, 24000, 32000, 44100 and 48000 samples per second. Other values are permissible.
必要なパラメーター：レート：毎秒サンプル数 - レートの推奨値は8000、11025、16000、22050、24000、32000、44100、および48000サンプルです。他の値は許容されます。
Optional parameters: channels: how many audio streams are interleaved -- defaults to 1; stereo would be 2, etc. Interleaving takes place between individual 20-bit samples.
オプションのパラメーター：チャネル：インターリーブされるオーディオストリームの数 - デフォルトは1になります。ステレオは2などになります。個々の20ビットサンプル間でインターリーブが行われます。
emphasis: analog preemphasis applied to the data before quantization. The only emphasis value defined here is emphasis=50-15 to indicate 50/15 microsecond preemphasis. This parameter MUST be omitted if no analog preemphasis was applied.
強調：アナログ前のエンファシスは、量子化前にデータに適用されます。ここで定義されている唯一の強調値は、50/15マイクロ秒前の段階を示すための強調= 50-15です。アナログの事前強調が適用されなかった場合、このパラメーターは省略する必要があります。
channel-order: specifies the sample interleaving order for multiple-channel audio streams (see RFC 3190 Section 7). Permissible values are DV.LRLsRs, DV.LRCS, DV.LRCWo, DV.LRLsRsC, DV.LRLsRsCS, DV.LmixRmixTWoQ1Q2, DV.LRCWoLsRsLmixRmix, DV.LRCWoLs1Rs1Ls2Rs2, DV.LRCWoLsRsLcRc. For interoperation with DV video systems, none of these channel combinations is specified for use with 20-bit linear encoding in the DV video specification [4]; only mono and stereo are allowed. This parameter MUST be omitted when the AIFF-C channel order convention is in use.
チャネルオーダー：マルチチャネルオーディオストリームのサンプルインターリーブ順序を指定します（RFC 3190セクション7を参照）。Permissible values are DV.LRLsRs, DV.LRCS, DV.LRCWo, DV.LRLsRsC, DV.LRLsRsCS, DV.LmixRmixTWoQ1Q2, DV.LRCWoLsRsLmixRmix, DV.LRCWoLs1Rs1Ls2Rs2, DV.LRCWoLsRsLcRc.DVビデオシステムとの相互操作のために、これらのチャネルの組み合わせは、DVビデオ仕様[4]で20ビット線形エンコードを使用して使用するために指定されていません。モノとステレオのみが許可されています。このパラメーターは、AIFF-Cチャネルの注文規則が使用されている場合に省略する必要があります。
Encoding considerations: L20 audio can be transmitted with RTP as specified in RFC 3190.
考慮事項のエンコード：L20オーディオは、RFC 3190で指定されているようにRTPで送信できます。
Security considerations: See Section 9.
セキュリティ上の考慮事項：セクション9を参照してください。
Interoperability considerations: NONE
相互運用性の考慮事項：なし
Published specification: RFC 3190.
公開された仕様：RFC 3190。
Applications which use this media type: Audio communication.
このメディアタイプを使用するアプリケーション：オーディオ通信。
Additional information:
Magic number(s): None
File extension(s): None
Macintosh File Type Code(s): None
Person & email address to contact for further information: Katsushi Kobayashi e-mail: ikob@koganei.wide.ad.jp
詳細については、人と電子メールアドレスをお問い合わせください：Katsushi Kobayashi E-mail：ikob@koganei.wide.ad.jp
Intended usage: COMMON
意図された使用法：共通
Author/Change controller: Katsushi Kobayashi e-mail: ikob@koganei.wide.ad.jp
著者/変更コントローラー：katsushi kobayashi電子メール：ikob@koganei.wide.ad.jp
MIME media type name: audio
MIMEメディアタイプ名：オーディオ
MIME subtype name: L24
MIMEサブタイプ名：L24
Required parameters: rate: number of samples per second -- RECOMMENDED values for rate are 8000, 11025, 16000, 22050, 24000, 32000, 44100 and 48000 samples per second. Other values are permissible.
必要なパラメーター：レート：毎秒サンプル数 - レートの推奨値は8000、11025、16000、22050、24000、32000、44100、および48000サンプルです。他の値は許容されます。
Optional parameters: channels: how many audio streams are interleaved -- defaults to 1; stereo would be 2, etc. Interleaving takes place between individual 24-bit samples.
オプションのパラメーター：チャネル：インターリーブされるオーディオストリームの数 - デフォルトは1になります。ステレオは2などになります。個々の24ビットサンプル間でインターリーブが行われます。
emphasis: analog preemphasis applied to the data before quantization. The only emphasis value defined here is emphasis=50-15 to indicate 50/15 microsecond preemphasis. This parameter MUST be omitted if no analog preemphasis was applied.
強調：アナログ前のエンファシスは、量子化前にデータに適用されます。ここで定義されている唯一の強調値は、50/15マイクロ秒前の段階を示すための強調= 50-15です。アナログの事前強調が適用されなかった場合、このパラメーターは省略する必要があります。
channel-order: specifies the sample interleaving order for multiple-channel audio streams (see Section 7). Permissible values are DV.LRLsRs, DV.LRCS, DV.LRCWo, DV.LRLsRsC, DV.LRLsRsCS, DV.LmixRmixTWoQ1Q2, DV.LRCWoLsRsLmixRmix, DV.LRCWoLs1Rs1Ls2Rs2, DV.LRCWoLsRsLcRc. This parameter MUST be omitted when the AIFF-C channel order convention is in use.
チャネルオーダー：マルチチャネルオーディオストリームのサンプルインターリーブ順序を指定します（セクション7を参照）。Permissible values are DV.LRLsRs, DV.LRCS, DV.LRCWo, DV.LRLsRsC, DV.LRLsRsCS, DV.LmixRmixTWoQ1Q2, DV.LRCWoLsRsLmixRmix, DV.LRCWoLs1Rs1Ls2Rs2, DV.LRCWoLsRsLcRc.このパラメーターは、AIFF-Cチャネルの注文規則が使用されている場合に省略する必要があります。
Encoding considerations: L24 audio can be transmitted with RTP as specified in RFC 3190.
考慮事項のエンコード：L24オーディオは、RFC 3190で指定されているようにRTPで送信できます。
Security considerations: See Section 9.
セキュリティ上の考慮事項：セクション9を参照してください。
Interoperability considerations: NONE
相互運用性の考慮事項：なし
Published specification: RFC 3190.
公開された仕様：RFC 3190。
Applications which use this media type: Audio communication.
このメディアタイプを使用するアプリケーション：オーディオ通信。
Additional information:
Magic number(s): None
File extension(s): None
Macintosh File Type Code(s): None
Person & email address to contact for further information: Katsushi Kobayashi e-mail: ikob@koganei.wide.ad.jp
詳細については、人と電子メールアドレスをお問い合わせください：Katsushi Kobayashi E-mail：ikob@koganei.wide.ad.jp
Intended usage: COMMON
意図された使用法：共通
Author/Change controller: Katsushi Kobayashi e-mail: ikob@koganei.wide.ad.jp
著者/変更コントローラー：katsushi kobayashi電子メール：ikob@koganei.wide.ad.jp
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 RTP profile [2]. This implies that confidentiality of the media streams is achieved by encryption. Because the data compression used along with this payload format is applied end-to-end, encryption may be performed after compression so there is no conflict between the two operations.
この仕様で定義されたペイロード形式を使用したRTPパケットは、RTP仕様[1]で説明されているセキュリティ上の考慮事項と、適切なRTPプロファイル[2]の対象となります。これは、メディアストリームの機密性が暗号化によって達成されることを意味します。このペイロード形式とともに使用されるデータ圧縮がエンドツーエンドで適用されるため、圧縮後に暗号化が実行される可能性があるため、2つの操作間に競合がありません。
A potential denial-of-service threat exists for data encodings using compression techniques that have non-uniform receiver-end computational load. The attacker can inject pathological datagrams into the stream which are complex to decode and cause the receiver to be overloaded. However, this encoding does not exhibit any significant non-uniformity.
不均一なレシーバーエンドの計算負荷を備えた圧縮技術を使用したデータエンコーディングには、潜在的なサービス拒否脅威が存在します。攻撃者は、デコードしてレシーバーを過負荷にするために複雑なストリームに病理学的データグラムを注入できます。ただし、このエンコーディングは、有意な不均一性を示すものではありません。
As with any IP-based protocol, in some circumstances a receiver may be overloaded simply by the receipt of too many packets, either desired or undesired. Network-layer authentication may be used to discard packets from undesired sources, but the processing cost of the authentication itself may be too high. In a multicast environment, pruning of specific sources may be implemented in future versions of IGMP [9] and in multicast routing protocols to allow a receiver to select which sources are allowed to reach it.
他のIPベースのプロトコルと同様に、状況によっては、受信者が、望ましいまたは望ましくないあまりにも多くのパケットを受け取るだけで過負荷になる場合があります。ネットワーク層認証は、望ましくないソースからパケットを破棄するために使用できますが、認証自体の処理コストが高すぎる場合があります。マルチキャスト環境では、特定のソースの剪定がIGMPの将来のバージョン[9]およびマルチキャストルーティングプロトコルで実装され、受信者がどのソースに到達できるかを選択できるようにすることができます。
This document defines two new MIME subtype-specific optional parameters "emphasis" and "channel-order", which are specified with the sets of permissible values for those parameters in Sections 5 and 7, respectively. Section 8 includes registrations for three new MIME subtypes that use those optional parameters. These registrations define the subset of the optional parameter values allowed for each subtype. It is expected that the number of additional values that will need to be defined for these optional parameters is small. Therefore, anyone wishing to define new values is required to produce a revision of this document to be vetted through the normal Internet Standards process.
このドキュメントでは、セクション5および7のパラメーターの許容値のセットで指定された2つの新しいMIMEサブタイプ固有のオプションパラメーター「強調」と「チャネルオーダー」を定義します。セクション8には、これらのオプションのパラメーターを使用する3つの新しいMIMEサブタイプの登録が含まれています。これらの登録は、各サブタイプで許可されるオプションのパラメーター値のサブセットを定義します。これらのオプションのパラメーターに対して定義する必要がある追加値の数が小さいことが予想されます。したがって、通常のインターネット標準プロセスを通じてこのドキュメントの改訂を検討するために、新しい値を定義したい人は誰でも必要です。
[1] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, "RTP: A Transport Protocol for real-time applications," RFC 1889, January 1996.
[1] Schulzrinne、H.、Casner、S.、Frederick、R。、およびV. Jacobson、「RTP：リアルタイムアプリケーション用の輸送プロトコル」、RFC 1889、1996年1月。
[2] H. Schulzrinne, "RTP profile for audio and video conferences with minimal control", RFC 1890, January 1996.
[2] H. Schulzrinne、「最小限のコントロールを備えたオーディオおよびビデオ会議のRTPプロファイル」、RFC 1890、1996年1月。
[3] IEC 61119, Digital audio tape cassette system (DAT), November 1992.
[3] IEC 61119、デジタルオーディオテープカセットシステム（DAT）、1992年11月。
[4] IEC 61834, Helical-scan digital video cassette recording system using 6,35 mm magnetic tape for consumer use (525-60, 625-50, 1125-60 and 1250-50 systems), August 1998.
[4] IEC 61834, Helical-scan digital video cassette recording system using 6,35 mm magnetic tape for consumer use (525-60, 625-50, 1125-60 and 1250-50 systems), August 1998.
[5] Salsman, J., "The Audio/L16 MIME content type", RFC 2586, May 1999.
[5] Salsman、J。、「オーディオ/L16 MIMEコンテンツタイプ」、RFC 2586、1999年5月。
[6] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[6] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[7] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998.
[7] Handley、M。and V. Jacobson、「SDP：セッション説明プロトコル」、RFC 2327、1998年4月。
[8] Kobayashi, K., Ogawa, A., Casner, S. and C. Bormann, "RTP Payload Format for DV (IEC 61834) Video", RFC 3189, January 2002.
[8] Kobayashi、K.、Ogawa、A.、Casner、S。、およびC. Bormann、「DV（IEC 61834）ビデオのRTPペイロード形式」、RFC 3189、2002年1月。
[9] Deering, S., "Host Extensions for IP Multicasting", STD 5, RFC 1112, August 1989.
[9] Deering、S。、「IPマルチキャストのホスト拡張」、STD 5、RFC 1112、1989年8月。
Appendix
付録
The DV audio channel symbols are specified in Table 2. These symbols are taken from the notation used in the DV video specification IEC 61834-4 [4], chapter 8.1. For the exact meaning of each symbol, the original DV video specification should be consulted.
DVオーディオチャネルシンボルを表2に指定します。これらのシンボルは、DVビデオ仕様IEC 61834-4 [4]、第8.1章で使用されている表記から取得されます。各シンボルの正確な意味については、元のDVビデオ仕様に相談する必要があります。
L: Left channel of stereo
R: Right channel of stereo
M: Monaural signal
C: Center channel of 3,4,6 or 8 channel audio
S: Surround channel of 4 channel audio
Ls, Ls1, Ls2: Left surround channel
Rs, Rs1, Rs2: Right surround channel
Lc: Left center channel of 8 channel audio
Rc: Right center channel of 8 channel audio
Wo: Woofer channel
Lmix: L + 0.7071C + 0.7071LS
Rmix: R + 0.7071C + 0.7071RS
T: 0.7071C
Q1: 0.7071LS + 0.7071RS
Q2: 0.7071LS - 0.7071RS
Table 2. Channel symbols for audio channels in DV video [4]
表2. DVビデオのオーディオチャネルのチャネル記号[4]
Authors' Addresses
著者のアドレス
Katsushi Kobayashi Communication Research Laboratory 4-2-1 Nukii-kita machi, Koganei Tokyo 184-8795 JAPAN
Katsushi Kobayashi Communication Research Laboratory 4-2-1 Nukii-Kita Machi、Koganei Tokyo 184-8795 Japan
Phone: +81 42 327 6174
EMail: ikob@koganei.wide.ad.jp
Akimichi Ogawa Keio University 5322 Endo, Fujisawa Kanagawa 252 JAPAN
小川keio大学5322エンド、藤沢川子川252日本
EMail: akimichi@sfc.wide.ad.jp
Stephen L. Casner Packet Design 2465 Latham Street Mountain View, CA 94040 United States
スティーブンL.キャスナーパケットデザイン2465レイサムストリートマウンテンビュー、カリフォルニア94040アメリカ合衆国
Phone: +1 650-943-1843
EMail: casner@acm.org
Carsten Bormann Universitaet Bremen TZI Postfach 330440 D-28334 Bremen, Germany
Carsten Bormann Universitaet Bremen Tzi Postfach 330440 D-28334ブレーメン、ドイツ
Phone: +49 421 218 7024
Fax: +49 421 218 7000
EMail: cabo@tzi.org
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright（c）The Internet Society（2002）。無断転載を禁じます。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
このドキュメントと翻訳は他の人にコピーされて提供される場合があります。また、それについてコメントまたは説明する派生作品、またはその実装を支援することは、いかなる種類の制限なしに、準備、コピー、公開、および部分的に配布される場合があります。、上記の著作権通知とこの段落がそのようなすべてのコピーとデリバティブ作品に含まれている場合。ただし、このドキュメント自体は、インターネット協会や他のインターネット組織への著作権通知や参照を削除するなど、いかなる方法でも変更できない場合があります。インターネット標準プロセスに従うか、英語以外の言語に翻訳するために必要な場合に従う必要があります。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の限られた許可は永続的であり、インターネット社会またはその後継者または譲受人によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
このドキュメントと本書に含まれる情報は、「現状」に基づいて提供されており、インターネット社会とインターネットエンジニアリングタスクフォースは、ここにある情報の使用が行われないという保証を含むがこれらに限定されないすべての保証を否認します。特定の目的に対する商品性または適合性の権利または黙示的な保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。