[要約] RFC 5404は、G.719のRTPペイロード形式に関する仕様です。このRFCの目的は、G.719オーディオコーデックのRTPストリーミングをサポートするためのペイロード形式を定義することです。
Network Working Group M. Westerlund
Request for Comments: 5404 I. Johansson
Category: Standards Track Ericsson AB
January 2009
RTP Payload Format for G.719
G.719の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) 2008 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2008 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
このドキュメントは、BCP 78およびIETFドキュメント（http://trustee.ietf.org/ license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。
Abstract
概要
This document specifies the payload format for packetization of the G.719 full-band codec encoded audio signals into the Real-time Transport Protocol (RTP). The payload format supports transmission of multiple channels, multiple frames per payload, and interleaving.
このドキュメントは、G.719フルバンドコーデックエンコードオーディオ信号をリアルタイムトランスポートプロトコル（RTP）にパケット化するためのペイロード形式を指定します。ペイロード形式は、複数のチャネルの送信、ペイロードあたりの複数のフレーム、およびインターリーブをサポートします。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Definitions and Conventions . . . . . . . . . . . . . . . . . 3
3. G.719 Description . . . . . . . . . . . . . . . . . . . . . . 3
4. Payload Format Capabilities . . . . . . . . . . . . . . . . . 4
4.1. Multi-Rate Encoding and Rate Adaptation . . . . . . . . . 4
4.2. Support for Multi-Channel Sessions . . . . . . . . . . . . 5
4.3. Robustness against Packet Loss . . . . . . . . . . . . . . 5
4.3.1. Use of Forward Error Correction (FEC) . . . . . . . . 5
4.3.2. Use of Frame Interleaving . . . . . . . . . . . . . . 6
5. Payload Format . . . . . . . . . . . . . . . . . . . . . . . . 7
5.1. RTP Header Usage . . . . . . . . . . . . . . . . . . . . . 8
5.2. Payload Structure . . . . . . . . . . . . . . . . . . . . 8
5.2.1. Basic ToC Element . . . . . . . . . . . . . . . . . . 9
5.3. Basic Mode . . . . . . . . . . . . . . . . . . . . . . . . 10
5.4. Interleaved Mode . . . . . . . . . . . . . . . . . . . . . 10
5.5. Audio Data . . . . . . . . . . . . . . . . . . . . . . . . 11
5.6. Implementation Considerations . . . . . . . . . . . . . . 12
5.6.1. Receiving Redundant Frames . . . . . . . . . . . . . . 12
5.6.2. Interleaving . . . . . . . . . . . . . . . . . . . . . 12
5.6.3. Decoding Validation . . . . . . . . . . . . . . . . . 13
6. Payload Examples . . . . . . . . . . . . . . . . . . . . . . . 13
6.1. 3 Mono Frames with 2 Different Bitrates . . . . . . . . . 13
6.2. 2 Stereo Frame-Blocks of the Same Bitrate . . . . . . . . 14
6.3. 4 Mono Frames Interleaved . . . . . . . . . . . . . . . . 15
7. Payload Format Parameters . . . . . . . . . . . . . . . . . . 16
7.1. Media Type Definition . . . . . . . . . . . . . . . . . . 16
7.2. Mapping to SDP . . . . . . . . . . . . . . . . . . . . . . 19
7.2.1. Offer/Answer Considerations . . . . . . . . . . . . . 19
7.2.2. Declarative SDP Considerations . . . . . . . . . . . . 22
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
9. Congestion Control . . . . . . . . . . . . . . . . . . . . . . 23
10. Security Considerations . . . . . . . . . . . . . . . . . . . 24
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 25
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25
12.1. Normative References . . . . . . . . . . . . . . . . . . . 25
12.2. Informative References . . . . . . . . . . . . . . . . . . 26
This document specifies the payload format for packetization of the G.719 full-band (FB) codec encoded audio signals into the Real-time Transport Protocol (RTP) [RFC3550]. The payload format supports transmission of multiple channels, multiple frames per payload, and packet loss robustness methods using redundancy or interleaving.
このドキュメントは、G.719フルバンド（FB）コーデックエンコードオーディオ信号をリアルタイムトランスポートプロトコル（RTP）[RFC3550]にパケット化するためのペイロード形式を指定します。ペイロード形式は、複数のチャネルの送信、ペイロードあたりの複数のフレーム、および冗長性またはインターリーブを使用したパケット損失の堅牢性方法をサポートします。
This document starts with conventions, a brief description of the codec, and the payload format's capabilities. The payload format is specified in Section 5. Examples can be found in Section 6. The media type and its mappings to the Session Description Protocol (SDP) and usage in SDP offer/answer are then specified. The document ends with considerations regarding congestion control and security.
このドキュメントは、コンベンション、コーデックの簡単な説明、ペイロード形式の機能から始まります。ペイロード形式はセクション5で指定されています。例はセクション6にあります。メディアタイプとセッション説明プロトコル（SDP）へのマッピングとSDPのオファー/回答の使用法が指定されています。このドキュメントは、混雑制御とセキュリティに関する考慮事項で終わります。
The term "frame-block" is used in this document to describe the time-synchronized set of audio frames in a multi-channel audio session. In particular, in an N-channel session, a frame-block will contain N audio frames, one from each of the channels, and all N speech frames represent exactly the same time period.
「フレームブロック」という用語は、このドキュメントで使用されて、マルチチャネルオーディオセッションでの時間同期されたオーディオフレームのセットを説明しています。特に、nチャネルセッションでは、フレームブロックにはnオーディオフレームが含まれます。各チャネルからのオーディオフレームが含まれ、すべてのn音声フレームはまったく同じ期間を表します。
This document contains depictions of bit fields. The most significant bit is always leftmost in the figure on each row and has the lowest enumeration. For fields that are depicted over multiple rows, the upper row is more significant than the next.
このドキュメントには、ビットフィールドの描写が含まれています。最も重要なビットは、各行の図の常に左端であり、列挙が最も低くなっています。複数の行に描かれているフィールドの場合、上の列は次の行よりも重要です。
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]で説明されているように解釈されます。
The ITU-T G.719 full-band codec is a transform coder based on Modulated Lapped Transform (MLT). G.719 is a low-complexity full-bandwidth codec for conversational speech and audio coding. The encoder input and decoder output are sampled at 48 kHz. The codec enables full-bandwidth from 20 Hz to 20 kHz, encoding of speech, music, and general audio content at rates from 32 kbit/s up to 128 kbit/s. The codec operates on 20-ms frames and has an algorithmic delay of 40 ms.
ITU-T G.719フルバンドコーデックは、変調されたラップ変換（MLT）に基づく変換コーダーです。G.719は、会話のスピーチとオーディオコーディングのための低複合性フルバンド幅コーデックです。エンコーダー入力とデコーダー出力は48 kHzでサンプリングされます。コーデックは、20 Hzから20 kHzまでのフルバンド幅を可能にし、32 kbit/sまでのレートで音声、音楽、一般的なオーディオコンテンツをエンコードします。コーデックは20 msフレームで動作し、40ミリ秒のアルゴリズム遅延があります。
The codec provides excellent quality for speech, music, and other types of audio. Some of the applications for which this coder is suitable are: o Real-time communications such as video conferencing and telephony
コーデックは、音声、音楽、その他の種類のオーディオに優れた品質を提供します。このコーダーが適しているアプリケーションの一部は次のとおりです。Oビデオ会議やテレフォニーなどのリアルタイムコミュニケーション
o Streaming audio
o ストリーミングオーディオ
o Archival and messaging
o アーカイブとメッセージング
The encoding and decoding algorithm can change the bitrate at any 20-ms frame boundary. The encoder receives the audio sampled at 48 kHz. The support of other sampling rates is possible by re-sampling the input signal to the codec's sampling rate, i.e., 48 kHz; however, this functionality is not part of the standard.
エンコードおよびデコードアルゴリズムは、20 msフレームの境界でビットレートを変更できます。エンコーダーは、48 kHzでサンプリングされたオーディオを受信します。他のサンプリングレートのサポートは、入力信号をコーデックのサンプリングレート、つまり48 kHzに再サンプリングすることで可能です。ただし、この機能は標準の一部ではありません。
The encoding is performed on equally sized frames. For each frame, the encoder decides between two encoding modes, a transient mode and a stationary mode. The decision is based on statistics derived from the input signal. The stationary mode uses a long MLT that leads to a spectrum of 960 coefficients, while the transient encoding mode uses a short MLT (higher time resolution transform) that results in 4 spectra (4 x 240 = 960 coefficients). The encoding of the spectrum is done in two steps. First, the spectral envelope is computed, quantized, and Huffman encoded. The envelope is computed on a non-uniform frequency subdivision. From the coded spectral envelope, a weighted spectral envelope is derived and is used for bit allocation; this process is also repeated at the decoder. Thus, only the spectral envelope is transmitted. The output of the bit allocation is used in order to quantize the spectra. In addition, for stationary frames, the encoder estimates the amount of noise level. The decoder applies the reverse operation upon reception of the bit stream. The non-coded coefficients (i.e., no bits allocated) are replaced by entries of a noise codebook that is built based on the decoded coefficients.
エンコードは、同様にサイズのフレームで実行されます。各フレームについて、エンコーダは2つのエンコーディングモード、過渡モードと固定モードの間を決定します。この決定は、入力信号から派生した統計に基づいています。固定モードは、960係数のスペクトルを引き起こす長いMLTを使用しますが、過渡エンコードモードでは短いMLT（より高い時間分解能変換）を使用して4スペクトル（4 x 240 = 960係数）になります。スペクトルのエンコードは2つのステップで行われます。まず、スペクトルエンベロープが計算され、量子化され、ハフマンがエンコードされます。エンベロープは、不均一な周波数区画で計算されます。コード化されたスペクトルエンベロープから、加重スペクトルエンベロープが導出され、ビット割り当てに使用されます。このプロセスは、デコーダーでも繰り返されます。したがって、スペクトルエンベロープのみが送信されます。ビット割り当ての出力は、スペクトルを量子化するために使用されます。さらに、固定フレームの場合、エンコーダーはノイズレベルの量を推定します。デコーダーは、ビットストリームを受信すると逆操作を適用します。非コード化された係数（つまり、ビットが割り当てられていない）は、デコードされた係数に基づいて構築されたノイズコードブックのエントリに置き換えられます。
This payload format has a number of capabilities, and this section discusses them in some detail.
このペイロード形式には多くの機能があり、このセクションでは詳細について説明します。
G.719 supports a multi-rate encoding capability that enables on a per-frame basis variation of the encoding rate. This enables support for bitrate adaptation and congestion control. The possibility to aggregate multiple audio frames into a single RTP payload is another dimension of adaptation. The RTP and payload format overhead can thus be reduced by the aggregation at the cost of increased delay and reduced packet-loss robustness.
G.719は、エンコーディングレートのフレームごとのバリエーションを有効にするマルチレートエンコーディング機能をサポートしています。これにより、ビットレートの適応と輻輳制御のサポートが可能になります。複数のオーディオフレームを単一のRTPペイロードに集約する可能性は、適応の別の次元です。したがって、RTPおよびペイロード形式のオーバーヘッドは、遅延の増加とパケット損失の堅牢性の低下の犠牲を払って集約により削減できます。
The RTP payload format defined in this document supports multi-channel audio content (e.g., stereophonic or surround audio sessions). Although the G.719 codec itself does not support encoding of multi-channel audio content into a single bit stream, it can be used to separately encode and decode each of the individual channels. To transport (or store) the separately encoded multi-channel content, the audio frames for all channels that are framed and encoded for the same 20-ms period are logically collected in a "frame-block".
このドキュメントで定義されているRTPペイロード形式は、マルチチャネルオーディオコンテンツ（ステレオフォニックまたはサラウンドオーディオセッションなど）をサポートしています。G.719コーデック自体は、マルチチャネルオーディオコンテンツのエンコードを単一のビットストリームにサポートしていませんが、個々のチャネルを個別にエンコードおよびデコードするために使用できます。個別にエンコードされたマルチチャネルコンテンツを輸送（または保存）するには、同じ20 msの期間にわたってフレーム化およびエンコードされたすべてのチャネルのオーディオフレームが「フレームブロック」で論理的に収集されます。
At the session setup, out-of-band signaling must be used to indicate the number of channels in the payload type. The order of the audio frames within the frame-block depends on the number of the channels and follows the definition in Section 4.1 of the RTP/AVP profile [RFC3551]. When using SDP for signaling, the number of channels is specified in the rtpmap attribute.
セッションのセットアップでは、ペイロードタイプのチャネルの数を示すために、バンド外シグナリングを使用する必要があります。フレームブロック内のオーディオフレームの順序は、チャネルの数に依存し、RTP/AVPプロファイル[RFC3551]のセクション4.1の定義に従います。シグナリングにSDPを使用する場合、チャネルの数はRTPMAP属性で指定されます。
The payload format supports several means, including forward error correction (FEC) and frame interleaving, to increase robustness against packet loss.
ペイロード形式は、パケット損失に対する堅牢性を高めるために、フォワードエラー補正（FEC）やフレームインターリーブなど、いくつかの手段をサポートしています。
Generic forward error correction within RTP is defined, for example, in RFC 5109 [RFC5109]. Audio redundancy coding is defined in RFC 2198 [RFC2198]. Either scheme can be used to add redundant information to the RTP packet stream and make it more resilient to packet losses, at the expense of a higher bitrate. Please see either of the RFCs for a discussion of the implications of the higher bitrate to network congestion.
たとえば、RFC 5109 [RFC5109]で、RTP内の汎用フォワードエラー補正が定義されています。オーディオ冗長コーディングは、RFC 2198 [RFC2198]で定義されています。いずれのスキームを使用して、RTPパケットストリームに冗長な情報を追加し、より高いビットレートを犠牲にしてパケット損失により回復力を向けることができます。ネットワークの輻輳に対するより高いビットレートの影響についての議論については、RFCのいずれかを参照してください。
In addition to these media-unaware mechanisms, this memo specifies a G.719-specific form of audio redundancy coding, which may be beneficial in terms of packetization overhead. Conceptually, previously transmitted transport frames are aggregated together with new ones. A sliding window can be used to group the frames to be sent in each payload. However, irregular or non-consecutive patterns are also possible by inserting NO_DATA frames between primary and redundant transmissions. Figure 1 below shows an example.
これらのメディアに不在のメカニズムに加えて、このメモは、梱包オーバーヘッドの点で有益である可能性のあるオーディオ冗長性コーディングのG.719固有の形式を指定します。概念的には、以前に送信されたトランスポートフレームが新しいものと集約されています。スライディングウィンドウを使用して、各ペイロードで送信されるフレームをグループ化できます。ただし、プライマリトランスミッションと冗長なトランスミッションの間にNO_DATAフレームを挿入することにより、不規則または非継続的なパターンも可能です。以下の図1は、例を示しています。
--+--------+--------+--------+--------+--------+--------+--------+--
| f(n-2) | f(n-1) | f(n) | f(n+1) | f(n+2) | f(n+3) | f(n+4) |
--+--------+--------+--------+--------+--------+--------+--------+--
<---- p(n-1) ---->
<----- p(n) ----->
<---- p(n+1) ---->
<---- p(n+2) ---->
<---- p(n+3) ---->
<---- p(n+4) ---->
Figure 1: An example of redundant transmission
図1：冗長伝送の例
Here, each frame is retransmitted once in the following RTP payload packet. f(n-2)...f(n+4) denote a sequence of audio frames, and p(n-1)...p(n+4) a sequence of payload packets.
ここでは、各フレームが次のRTPペイロードパケットで1回再送信されます。f（n-2）... f（n 4）は、オーディオフレームのシーケンスとp（n-1）... p（n 4）のペイロードパケットのシーケンスを示します。
The mechanism described does not really require signaling at the session setup. However, signaling has been defined to allow for the sender to voluntarily bind the buffering and delay requirements. If nothing is signaled, the use of this mechanism is allowed and unbounded. For a certain timestamp, the receiver may receive multiple copies of a frame containing encoded audio data, even at different encoding rates. The cost of this scheme is bandwidth and the receiver delay necessary to allow the redundant copy to arrive.
記載されているメカニズムは、セッションのセットアップで実際にシグナリングを必要としません。ただし、送信者がバッファリング要件と遅延要件を自発的に結合できるように、シグナル伝達が定義されています。何も知られていない場合、このメカニズムの使用は許可され、束縛されていません。特定のタイムスタンプの場合、レシーバーは、異なるエンコードレートであっても、エンコードされたオーディオデータを含むフレームの複数のコピーを受け取ることができます。このスキームのコストは帯域幅であり、冗長コピーを到着するために必要なレシーバー遅延が必要です。
This redundancy scheme provides a functionality similar to the one described in RFC 2198, but it works only if both original frames and redundant representations are G.719 frames. When the use of other media coding schemes is desirable, one has to resort to RFC 2198.
この冗長性スキームは、RFC 2198で説明されている機能と同様の機能を提供しますが、元のフレームと冗長表現の両方がG.719フレームである場合にのみ機能します。他のメディアコーディングスキームの使用が望ましい場合、RFC 2198に頼らなければなりません。
The sender is responsible for selecting an appropriate amount of redundancy based on feedback about the channel conditions, e.g., in the RTP Control Protocol (RTCP) [RFC3550] receiver reports. The sender is also responsible for avoiding congestion, which may be exacerbated by redundancy (see Section 9 for more details).
送信者は、チャネル条件に関するフィードバック、たとえばRTPコントロールプロトコル（RTCP）[RFC3550]レシーバーレポートでのフィードバックに基づいて、適切な量の冗長性を選択する責任があります。送信者はまた、冗長性によって悪化する可能性のある輻輳を回避する責任があります（詳細についてはセクション9を参照）。
To decrease protocol overhead, the payload design allows several audio transport frames to be encapsulated into a single RTP packet. One of the drawbacks of such an approach is that in the case of packet loss, several consecutive frames are lost. Consecutive frame loss normally renders error concealment less efficient and usually causes clearly audible and annoying distortions in the reconstructed audio. Interleaving of transport frames can improve the audio quality in such cases by distributing the consecutive losses into a number of isolated frame losses, which are easier to conceal.
プロトコルオーバーヘッドを減らすために、ペイロード設計により、いくつかのオーディオトランスポートフレームを単一のRTPパケットにカプセル化できます。このようなアプローチの欠点の1つは、パケット損失の場合、いくつかの連続したフレームが失われることです。連続したフレームの損失は通常、エラーの隠蔽を効率が低下し、通常、再構築されたオーディオではっきりと聞こえる厄介な歪みを引き起こします。輸送フレームのインターリーブは、連続した損失を多くの孤立したフレーム損失に分配することにより、そのような場合にオーディオの品質を改善することができます。
However, interleaving and bundling several frames per payload also increases end-to-end delay and sets higher buffering requirements. Therefore, interleaving is not appropriate for all use cases or devices. Streaming applications should most likely be able to exploit interleaving to improve audio quality in lossy transmission conditions.
ただし、ペイロードあたりの複数のフレームをインターリーブしてバンドルすると、エンドツーエンドの遅延が増加し、より高いバッファリング要件が設定されます。したがって、インターリーブはすべてのユースケースまたはデバイスに適していません。ストリーミングアプリケーションは、インテリアを活用して、損失のある伝送条件のオーディオ品質を向上させることができるはずです。
Note that this payload design supports the use of frame interleaving as an option. The usage of this feature needs to be negotiated in the session setup.
このペイロード設計は、オプションとしてフレームインターリーブの使用をサポートしていることに注意してください。この機能の使用は、セッションのセットアップで交渉する必要があります。
The interleaving supported by this format is rather flexible. For example, a continuous pattern can be defined, as depicted in Figure 2.
この形式でサポートされているインターリーブは、かなり柔軟です。たとえば、図2に示すように、連続パターンを定義できます。
--+--------+--------+--------+--------+--------+--------+--------+--
| f(n-2) | f(n-1) | f(n) | f(n+1) | f(n+2) | f(n+3) | f(n+4) |
--+--------+--------+--------+--------+--------+--------+--------+--
[ p(n) ]
[ p(n+1) ] [ p(n+1) ]
[ p(n+2) ] [ p(n+2) ]
[ p(n+3) ]
[ p(n+4) ]
Figure 2: An example of interleaving pattern that has constant delay
図2：一定の遅延があるインテリアパターンの例
In Figure 2, the consecutive frames, denoted f(n-2) to f(n+4), are aggregated into packets p(n) to p(n+4), each packet carrying two frames. This approach provides an interleaving pattern that allows for constant delay in both the interleaving and de-interleaving processes. The de-interleaving buffer needs to have room for at least three frames, including the one that is ready to be consumed. The storage space for three frames is needed, for example, when f(n) is the next frame to be decoded: since frame f(n) was received in packet p(n+2), which also carried frame f(n+3), both these frames are stored in the buffer. Furthermore, frame f(n+1) received in the previous packet, p(n+1), is also in the de-interleaving buffer. Note also that in this example the buffer occupancy varies: when frame f(n+1) is the next one to be decoded, there are only two frames, f(n+1) and f(n+3), in the buffer.
図2では、F（n-2）からF（n 4）と表示されている連続したフレームは、2つのフレームを搭載した各パケットをパケットする各パケットをパケットp（n）からp（n 4）に集約します。このアプローチは、インテリアとインテリアの両方のプロセスの両方で一定の遅延を可能にするインテリアパターンを提供します。インターレービングバッファーには、消費される準備ができているものを含め、少なくとも3つのフレームのスペースが必要です。たとえば、f（n）がデコードされる次のフレームである場合、3つのフレームのストレージスペースが必要です。フレームf（n 2）でフレームf（n）が受信されたため、フレームf（n 3）も運ばれました。、これらの両方のフレームはバッファーに保存されます。さらに、以前のパケットであるP（n 1）で受信したフレームF（n 1）も、非介入バッファーにあります。また、この例では、バッファの占有率は異なることに注意してください。フレームF（n 1）が次のデコードされる場合、バッファーには2つのフレーム、F（n 1）とF（n 3）のみが2つのフレームしかありません。
The main purpose of the payload design for G.719 is to maximize the potential of the codec to its fullest degree with as minimal overhead as possible. In the design, both basic and interleaved modes have been included, as the codec is suitable both for conversational and other low-delay applications as well as streaming, where more delay is acceptable.
G.719のペイロード設計の主な目的は、可能な限り最小限のオーバーヘッドでコーデックの可能性を最大限に最大化することです。設計では、コーデックは会話型アプリケーションと他の低遅延アプリケーションの両方に適しているため、より多くの遅延が許容されるストリーミングの両方に適しているため、基本モードとインターリーブモードの両方が含まれています。
The main structural difference between the basic and interleaved modes is the extension of the table of contents entries with frame displacement fields in the interleaved mode. The basic mode supports aggregation of multiple consecutive frames in a payload. The interleaved mode supports aggregation of multiple frames that are non-consecutive in time. In both modes, it is possible to have frames encoded with different frame types in the same payload.
基本モードとインターリーブモードの主な構造の違いは、インターリーブモードのフレーム変位フィールドを使用した目次エントリの拡張です。基本モードは、ペイロード内の複数の連続したフレームの集約をサポートします。インターリーブモードは、時間内にはない複数のフレームの集約をサポートします。両方のモードで、同じペイロード内の異なるフレームタイプでフレームをエンコードすることができます。
The payload format also supports the usage of G.719 for carrying multi-channel content using one discrete encoder per channel all using the same bitrate. In this case, a complete frame-block with data from all channels is included in the RTP payload. The data is the concatenation of all the encoded audio frames in the order specified for that number of included channels. Also, interleaving is done on complete frame-blocks rather than on individual audio frames.
ペイロード形式は、同じビットレートを使用して、チャネルごとに1つの離散エンコーダーを使用してマルチチャネルコンテンツを運ぶためのG.719の使用もサポートしています。この場合、すべてのチャネルからのデータを含む完全なフレームブロックがRTPペイロードに含まれています。データは、含まれるチャネルの数に指定された順序で、すべてのエンコードされたオーディオフレームを連結することです。また、インターリーブは、個々のオーディオフレームではなく、完全なフレームブロックで行われます。
The RTP timestamp corresponds to the sampling instant of the first sample encoded for the first frame-block in the packet. The timestamp clock frequency SHALL be 48000 Hz. The timestamp is also used to recover the correct decoding order of the frame-blocks.
RTPタイムスタンプは、パケット内の最初のフレームブロックにエンコードされた最初のサンプルのサンプリングインスタントに対応します。タイムスタンプクロック周波数は48000 Hzでなければなりません。タイムスタンプは、フレームブロックの正しいデコード順序を回復するためにも使用されます。
The RTP header marker bit (M) SHALL be set to 1 whenever the first frame-block carried in the packet is the first frame-block in a talkspurt (see definition of the talkspurt in Section 4.1 of [RFC3551]). For all other packets, the marker bit SHALL be set to zero (M=0).
RTPヘッダーマーカービット（M）は、パケットに掲載された最初のフレームブロックがTalkspurtの最初のフレームブロックである場合は1に設定されます（[RFC3551]のセクション4.1のTalkspurtの定義を参照）。他のすべてのパケットについては、マーカービットをゼロ（m = 0）に設定する必要があります。
The assignment of an RTP payload type for the format defined in this memo is outside the scope of this document. The RTP profiles in use currently mandate binding the payload type dynamically for this payload format. This is basically necessary because the payload type expresses the configuration of the payload itself, i.e., basic or interleaved mode, and the number of channels carried.
このメモで定義されている形式のRTPペイロードタイプの割り当ては、このドキュメントの範囲外です。現在使用されているRTPプロファイルは、このペイロード形式のペイロードタイプを動的に拘束するマンデートを義務付けています。これは、ペイロードタイプがペイロード自体、つまり基本モードまたはインターリーブモードの構成、および運ばれるチャネルの数を表現するため、基本的に必要です。
The remaining RTP header fields are used as specified in [RFC3550].
残りのRTPヘッダーフィールドは、[RFC3550]で指定されているように使用されます。
The payload consists of one or more table of contents (ToC) entries followed by the audio data corresponding to the ToC entries. The following sections describe both the basic mode and the interleaved mode. Each ToC entry MUST be padded to a byte boundary to ensure octet alignment. The rules regarding maximum payload size given in Section 3.2 of [RFC5405] SHOULD be followed.
ペイロードは、1つ以上の目次（TOC）エントリで構成され、その後にTOCエントリに対応するオーディオデータが続きます。次のセクションでは、基本モードとインターリーブモードの両方について説明します。各TOCエントリは、オクテットのアライメントを確保するために、バイト境界にパッドでパッドで入れる必要があります。[RFC5405]のセクション3.2に記載されている最大ペイロードサイズに関するルールに従う必要があります。
All the different formats and modes in this document use a common basic ToC that may be extended in the different options described below.
このドキュメントのさまざまな形式とモードはすべて、以下で説明するさまざまなオプションに拡張できる一般的な基本TOCを使用します。
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|F| L |R|R|
+-+-+-+-+-+-+-+-+
Figure 3: Basic TOC element
図3：基本的なTOC要素
F (1 bit): If set to 1, indicates that this ToC entry is followed by another ToC entry; if set to zero, indicates that this ToC entry is the last one in the ToC.
F（1ビット）：1に設定されている場合、このTOCエントリの後に別のTOCエントリが続くことを示します。ゼロに設定されている場合、このTOCエントリがTOCの最後のエントリであることを示します。
L (5 bits): A field that gives the frame length of each individual frame within the frame-block.
L（5ビット）：フレームブロック内の各フレームのフレーム長を与えるフィールド。
L length(bytes)
============================
0 0 NO_DATA
1-7 N/A (reserved)
8-22 80+10*(L-8)
23-27 240+20*(L-23)
28-31 N/A (reserved)
Figure 4: How to map L values to frame lengths
図4：L値をフレームの長さにマッピングする方法
L=0 (NO_DATA) is used to indicate an empty frame, which is useful if frames are missing (e.g., at re-packetization), or to insert gaps when sending redundant frames together with primary frames in the same payload. The value range [1..7] and [28..31] inclusive is reserved for future use in this document version; if these values occur in a ToC, the entire packet SHOULD be treated as invalid and discarded. A few examples are given below where the frame size and the corresponding codec bitrate is computed based on the value L.
l = 0（no_data）は、空のフレームを示すために使用されます。これは、フレームが欠落している場合（たとえば、再パケット化）、または同じペイロードのプライマリフレームと一緒に冗長フレームを送信するときにギャップを挿入します。値範囲[1..7]および[28..31] Inclusiveは、このドキュメントバージョンで将来使用するために予約されています。これらの値がTOCで発生する場合、パケット全体を無効で破棄したものとして扱う必要があります。フレームサイズと対応するコーデックビットレートが値lに基づいて計算される場所の以下の例を示します。
L Bytes Codec Bitrate(kbps)
===================================
8 80 32
9 90 36
10 100 40
12 120 48
16 160 64
22 220 88
23 240 96
25 280 112
27 320 128
Figure 5: Examples of L values and corresponding frame lengths
図5：L値と対応するフレーム長の例
This encoding yields a granularity of 4 kbps between 32 and 88 kbps and a granularity of 8 kbps between 88 and 128 kbps with a defined range of 32-128 kbps for the codec data.
このエンコードは、32〜88 kbpsの4 kbpsの粒度と、88〜128 kbpsの8 kbpsの粒度が得られ、コーデックデータの32〜128 kbpsの範囲が定義されています。
R (2 bits): Reserved bits. SHALL be set to zero on sending and SHALL be ignored on reception.
R（2ビット）：予約ビット。送信時にゼロに設定され、レセプションで無視されます。
The basic ToC element shown in Figure 3 is followed by a 1-octet field for the number of frame-blocks (#frames) to form the ToC entry. The frame-blocks field tells how many frame-blocks of the same length the ToC entry relates to.
図3に示す基本的なTOC要素の後に、Frameブロックの数（＃frames）の1オクセットフィールドが続き、TOCエントリを形成します。フレームブロックフィールドは、TOCエントリが関連する同じ長さのフレームブロックの数を示しています。
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| #frames |
+-+-+-+-+-+-+-+-+
Figure 6: Number of frame-blocks field
図6：フレームブロックフィールドの数
The basic ToC is followed by a 1-octet field for the number of frame-blocks (#frames) and then the DIS fields to form a ToC entry in interleaved mode. The frame-blocks field tells how many frame-blocks of the same length the ToC relates to. The DIS fields, one for each frame-block indicated by the #frames field, express the interleaving distance between audio frames carried in the payload. If necessary to achieve octet alignment, a 4-bit padding is added.
基本的なTOCの後には、フレームブロックの数（#Frames）の1オクテットフィールドが続き、次にDISフィールドがインターリーブモードでTOCエントリを形成します。フレームブロックフィールドは、TOCが関連する同じ長さのフレームブロックの数を示しています。#Framesフィールドで示される各フレームブロックに1つのDISフィールドは、ペイロードに掲載されたオーディオフレーム間のインターリーブ距離を表します。必要に応じて、Octetアライメントを達成するために、4ビットパディングが追加されます。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| #frames | DIS1 | ... | DISi | ... | DISn | Padd |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: Number of frame-block + interleave fields
図7：フレームブロックインターリーブフィールドの数
DIS1...DISn (4 bits): A list of n (n=#frames) displacement fields indicating the displacement of the i:th (i=1..n) audio frame-block relative to the preceding frame-block in the payload, in units of 20-ms long audio frame-blocks). The 4-bit unsigned integer displacement values may be between zero and 15 indicating the number of audio frame-blocks in decoding order between the (i-1):th and the i:th frame in the payload. Note that for the first ToC entry of the payload, the value of DIS1 is meaningless. It SHALL be set to zero by a sender and SHALL be ignored by a receiver. This frame-block's location in the decoding order is uniquely defined by the RTP timestamp. Note that for subsequent ToC entries DIS1 indicates the number of frames between the last frame of the previous group and the first frame of this group.
dis1 ... disn（4ビット）：n（n =＃frames）変位フィールドのリストは、前述のフレームブロックに対するi：th（i = 1..n）オーディオフレームブロックの変位を示しています。ペイロード、20 msの長さのオーディオフレームブロックの単位）。4ビットの署名されていない整数変位値は、ゼロから15の間である可能性があり、（I-1）：THとI：THフレームの間のデコード順序のオーディオフレームブロックの数を示します。ペイロードの最初のTOCエントリでは、DIS1の値は無意味であることに注意してください。それは送信者によってゼロに設定され、レシーバーによって無視されるものとします。デコード順にあるこのフレームブロックの位置は、RTPタイムスタンプによって一意に定義されています。後続のTOCエントリの場合、DIS1は、前のグループの最後のフレームとこのグループの最初のフレーム間のフレームの数を示していることに注意してください。
Padd (4 bits): To ensure octet alignment, 4 padding bits SHALL be included at the end of the ToC entry in case there is an odd number of frame-blocks in the group referenced by this ToC entry. These bits SHALL be set to zero and SHALL be ignored by the receiver. If a group containing an even number of frames is referenced by this ToC entry, these padding bits SHALL NOT be included in the payload.
PADD（4ビット）：Octetアライメントを確保するために、このTOCエントリで参照されるグループに奇数のフレームブロックがある場合、TOCエントリの最後に4つのパディングビットを含めるものとします。これらのビットはゼロに設定され、受信機によって無視されます。偶数のフレームを含むグループがこのTOCエントリによって参照される場合、これらのパディングビットはペイロードに含まれてはなりません。
The audio data part follows the table of contents. All the octets comprising an audio frame SHALL be appended to the payload as a unit. For each frame-block, the audio frames are concatenated in the order indicated by the table in Section 4.1 of [RFC3551] for the number of channels configured for the payload type in use. So the first channel (leftmost) indicated comes first followed by the next channel. The audio frame-blocks are packetized in increasing timestamp order within each group of frame-blocks (per ToC entry), i.e., oldest frame-block first. The groups of frame-blocks are packetized in the same order as their corresponding ToC entries.
オーディオデータの部分は、目次に従います。オーディオフレームを含むすべてのオクテットは、ユニットとしてペイロードに追加されるものとします。フレームブロックごとに、使用中のペイロードタイプ用に構成されたチャネルの数について、[RFC3551]のセクション4.1のテーブルで示される順序でオーディオフレームが連結されます。したがって、最初のチャンネル（左端）が最初に次に次のチャンネルが続きます。オーディオフレームブロックは、フレームブロックの各グループ内（TOCエントリごと）内でタイムスタンプの順序を増やすことでパケット化されます。つまり、最初に最古のフレームブロックです。フレームブロックのグループは、対応するTOCエントリと同じ順序でパケット化されます。
The audio frames are specified in ITU recommendation [ITU-T-G719].
オーディオフレームは、ITUの推奨[ITU-T-G719]で指定されています。
The G.719 bit stream is split into a sequence of octets and transmitted in order from the leftmost (most significant (MSB)) bit to the rightmost (least significant (LSB)) bit.
G.719ビットストリームはオクテットのシーケンスに分割され、左端（最も重要な（MSB））ビットから右端（最も重要な（LSB））ビットに順番に送信されます。
An application implementing this payload format MUST understand all the payload parameters specified in this specification. Any mapping of the parameters to a signaling protocol MUST support all parameters. So an implementation of this payload format in an application using SDP is required to understand all the payload parameters in their SDP-mapped form. This requirement ensures that an implementation always can decide whether it is capable of communicating when the communicating entities support this version of the specification.
このペイロード形式を実装するアプリケーションは、この仕様で指定されたすべてのペイロードパラメーターを理解する必要があります。シグナリングプロトコルへのパラメーターのマッピングは、すべてのパラメーターをサポートする必要があります。したがって、SDPマップフォームのすべてのペイロードパラメーターを理解するには、SDPを使用したアプリケーションでのこのペイロード形式の実装が必要です。この要件により、実装は、通信エンティティがこのバージョンの仕様をサポートするときに通信できるかどうかを常に決定できるようになります。
Basic mode SHALL be implemented and the interleaved mode SHOULD be implemented. The implementation burden of both is rather small, and supporting both ensures interoperability. However, interleaving is not mandated as it has limited applicability for conversational applications that require tight delay boundaries.
基本モードを実装し、インターリーブモードを実装する必要があります。両方の実装の負担はかなり小さく、両方をサポートすることで相互運用性が保証されます。ただし、緊密な遅延境界を必要とする会話型アプリケーションへの適用性が限られているため、インターリーブは義務付けられていません。
The reception of redundant audio frames, i.e., more than one audio frame from the same source for the same time slot, MUST be supported by the implementation. In the case that the receiver gets multiple audio frames in different bitrates for the same time slot, it is RECOMMENDED that the receiver keeps the one with the highest bitrate.
冗長なオーディオフレーム、つまり、同じ時間スロットで同じソースから複数のオーディオフレームを受信することは、実装によってサポートする必要があります。レシーバーが同じタイムスロットで異なるビットレートで複数のオーディオフレームを取得する場合、受信機が最高のビットレートを持つものを保持することをお勧めします。
The use of interleaving requires further considerations. As presented in the example in Section 4.3.2, a given interleaving pattern requires a certain amount of the de-interleaving buffer. This buffer space, expressed in a number of transport frame slots, is indicated by the "interleaving" media type parameter. The number of frame slots needed can be converted into actual memory requirements by considering the 320 bytes per frame used by the highest bitrate of G.719.
インターリーブの使用には、さらなる考慮事項が必要です。セクション4.3.2の例で示されているように、特定のインターリーブパターンには、一定量のinterleaingバッファーが必要です。多くのトランスポートフレームスロットで表されるこのバッファースペースは、「インターリーブ」メディアタイプパラメーターで示されています。必要なフレームスロットの数は、G.719の最高ビットレートで使用されるフレームごとに320バイトを考慮することにより、実際のメモリ要件に変換できます。
The information about the frame buffer size is not always sufficient to determine when it is appropriate to start consuming frames from the interleaving buffer. Additional information is needed when the interleaving pattern changes. The "int-delay" media type parameter is defined to convey this information. It allows a sender to indicate the minimal media time that needs to be present in the buffer before the decoder can start consuming frames from the buffer. Because the sender has full control over the interleaving pattern, it can calculate this value. In certain cases (for example, if joining a multicast session with interleaving mid-session), a receiver may initially receive only part of the packets in the interleaving pattern. This initial partial reception (in frame sequence order) of frames can yield too few frames for acceptable quality from the audio decoding. This problem also arises when using encryption for access control, and the receiver does not have the previous key. Although the G.719 is robust and thus tolerant to a high random frame erasure rate, it would have difficulties handling consecutive frame losses at startup. Thus, some special implementation considerations are described.
フレームバッファーサイズに関する情報は、インターリーブバッファーからフレームを消費することがいつ適切であるかを決定するのに必ずしも十分ではありません。インターリーブパターンが変化する場合は、追加情報が必要です。「int-delay」メディアタイプパラメーターは、この情報を伝えるために定義されています。これにより、送信者は、デコーダーがバッファからフレームの消費を開始する前に、バッファーに存在する必要がある最小限のメディア時間を示すことができます。送信者はインターリーブパターンを完全に制御できるため、この値を計算できます。特定の場合（たとえば、インターリーブ中間セッションとマルチキャストセッションに参加する場合）、受信者は最初にインターリーブパターンのパケットの一部のみを受け取る場合があります。この最初の部分的な受信（フレームシーケンスの順序で）フレームは、オーディオデコードから許容できる品質にはフレームが少なすぎる可能性があります。この問題は、アクセス制御に暗号化を使用する場合にも発生し、受信機には以前のキーがありません。G.719は堅牢であるため、ランダムなフレームの消去率が高いことに耐性がありますが、起動時に連続したフレーム損失を処理するのが困難です。したがって、いくつかの特別な実装に関する考慮事項について説明します。
In order to handle this type of startup efficiently, decoding can start provided that:
このタイプのスタートアップを効率的に処理するために、次のことを条件に解読を開始できます。
1. There are at least two consecutive frames available.
1. 少なくとも2つの連続したフレームがあります。
2. More than or equal to half the frames are available in the time period from where decoding was planned to start and the most forward received decoding.
2. フレームの半分以上が、デコードが開始される予定であり、最もフォワード受信されたデコードが計画されていた期間に利用可能です。
After receiving a number of packets, in the worst case as many packets as the interleaving pattern covers, the previously described effects disappear and normal decoding is resumed. Similar issues arise when a receiver leaves a session or has lost access to the stream. If the receiver leaves the session, this would be a minor issue since playout is normally stopped. The sender can avoid this type of problem in many sessions by starting and ending interleaving patterns correctly when risks of losses occur. One such example is a key-change done for access control to encrypted streams. If only some keys are provided to clients and there is a risk they will receive content for which they do not have the key, it is recommended that interleaving patterns do not overlap key changes.
多数のパケットを受け取った後、最悪の場合、インターリーブパターンがカバーするのと同じくらい多くのパケットが、前述の効果が消え、通常のデコードが再開されます。レシーバーがセッションを離れるか、ストリームへのアクセスを失った場合、同様の問題が発生します。受信者がセッションを離れる場合、プレイアウトが通常停止されているため、これは小さな問題になります。送信者は、損失のリスクが発生したときにインターリーブパターンを正しく開始および終了することにより、多くのセッションでこのタイプの問題を回避できます。そのような例の1つは、暗号化されたストリームへのアクセス制御のために行われたキー変更です。クライアントにいくつかのキーのみが提供され、キーがないコンテンツを受け取るリスクがある場合、インターリーブパターンがキーの変更を重複させないことをお勧めします。
If the receiver finds a mismatch between the size of a received payload and the size indicated by the ToC of the payload, the receiver SHOULD discard the packet. This is recommended because decoding a frame parsed from a payload based on erroneous ToC data could severely degrade the audio quality.
受信したペイロードのサイズとペイロードのTOCで示されるサイズの間の不一致を受信者が見つけた場合、受信機はパケットを廃棄する必要があります。これは、誤ったTOCデータに基づいてペイロードから解析されたフレームをデコードすると、オーディオの品質を著しく分解する可能性があるためです。
A few examples to highlight the payload format follow.
ペイロード形式を強調するためのいくつかの例が続きます。
The first example is a payload consisting of 3 mono frames where the first 2 frames correspond to a bitrate of 32 kbps (80 bytes/frame) and the last is 48 kbps (120 bytes/frame).
最初の例は、最初の2つのフレームが32 kbps（80バイト/フレーム）のビットレートに対応する3つのモノフレームで構成されるペイロードで、最後は48 kbps（120バイト/フレーム）です。
The first 32 bits are ToC fields. Bit 0 is '1' as another ToC field follows. Bits 1..5 are '01000' = 80 bytes/frame. Bits 8..15 are '00000010' = 2 frame-blocks with 80 bytes/frame. Bit 16 is '0', no more ToC follows. Bits 17..21 are '01100' = 120 bytes/frame. Bits 24..31 are '00000001' = 1 frame-block with 120 bytes/frame.
最初の32ビットはTOCフィールドです。別のTOCフィールドが続くように、ビット0は「1」です。ビット1..5は「01000」= 80バイト/フレームです。ビット8..15は、80バイト/フレームの「00000010」= 2フレームブロックです。ビット16は「0」ですが、TOCは続きません。ビット17..21は「01100」= 120バイト/フレームです。ビット24..31は「00000001」= 1フレームブロック120バイト/フレームです。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|0 1 0 0 0|0 0|0 0 0 0 0 0 1 0|0|0 1 1 0 0|0 0|0 0 0 0 0 0 0 1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|d(0) frame 1 |
. .
| d(639)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|d(0) frame 2 |
. .
| d(639)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|d(0) frame 3 |
. .
| d(959)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The second example is a payload consisting of 2 stereo frames that correspond to a bitrate of 32 kbps (80 bytes/frame) per channel. The receiver calculates the number of frames in the audio block by multiplying the value of the "channels" parameter (2) with the #frames field value (2) to derive that there are 4 audio frames in the payload.
2番目の例は、チャネルあたり32 kbps（80バイト/フレーム）のビットレートに対応する2つのステレオフレームで構成されるペイロードです。レシーバーは、「チャネル」パラメーター（2）の値を＃フレームフィールド値（2）に掛けて、ペイロードに4つのオーディオフレームがあることを導出することにより、オーディオブロック内のフレームの数を計算します。
The first 16 bits is the ToC field. Bit 0 is '0' as no ToC field follows. Bits 1..5 are '01000' = 80 bytes/frame. Bits 8..15 are '00000010' = 2 frame-blocks with 80 bytes/frame.
最初の16ビットはTOCフィールドです。TOCフィールドが続くと、ビット0は「0」です。ビット1..5は「01000」= 80バイト/フレームです。ビット8..15は、80バイト/フレームの「00000010」= 2フレームブロックです。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0 1 0 0 0|0 0|0 0 0 0 0 0 1 0| d(0) frame 1 left ch. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
| d(639)| d(0) frame 1 right ch. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
| d(639)| d(0) frame 2 left ch. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
| d(639)| d(0) frame 2 right ch. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| d(639)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The third example is a payload consisting of 4 mono frames that correspond to a bitrate of 32 kbps (80 bytes/frame) interleaved. A pattern of interleaving for constant delay when aggregating 4 frames is used in the example below. The actual packet illustrated is packet n, while the previous and following packets' frame-block content is shown to illustrate the pattern.
3番目の例は、32 kbps（80バイト/フレーム）インターリーブのビットレートに対応する4つのモノフレームで構成されるペイロードです。以下の例では、4つのフレームを集約する場合の一定の遅延のためのインターリーブのパターンを使用します。実際のパケット図はパケットnですが、前後のパケットのフレームブロックコンテンツはパターンを示すように示されています。
Packet n-3: 1, 6, 11, 16
Packet n-2: 5, 10, 15, 20
Packet n-1: 9, 14, 19, 24
Packet n: 13, 18, 23, 28
Packet n+1: 17, 22, 27, 32
Packet n+2: 21, 26, 31, 36
The first 32 bits are the ToC field. Bit 0 is '0' as there is no ToC field following. Bits 1..5 are '01000' = 80 bytes/frame. Bits 8..15 are '00000100' = 4 frame-blocks with 80 bytes/frame. Bits 16..19 are '0000' = DIS1 (0). Bits 20..23 are '0100' = DIS2 (4). Bits 24..27 are '0100' = DIS3 (4). Bits 28..31 are '0100' = DIS4 (4).
最初の32ビットはTOCフィールドです。TOCフィールドフォローがないため、ビット0は「0」です。ビット1..5は「01000」= 80バイト/フレームです。ビット8..15は、80バイト/フレームの「00000100」= 4フレームブロックです。ビット16..19は「0000」= dis1（0）です。ビット20..23は '0100' = dis2（4）です。ビット24..27は '0100' = dis3（4）です。ビット28..31は「0100」= dis4（4）です。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0 1 0 0 0|0 0|0 0 0 0 0 1 0 0|0 0 0 0|0 1 0 0|0 1 0 0|0 1 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| d(0) frame 13 |
. .
| d(639)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| d(0) frame 18 |
. .
| d(639)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| d(0) frame 23 |
. .
| d(639)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| d(0) frame 28 |
. .
| d(639)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This RTP payload format is identified using the media type audio/ G719, which is registered in accordance with [RFC4855] and uses the template of [RFC4288].
このRTPペイロード形式は、[RFC4855]に従って登録され、[RFC4288]のテンプレートを使用しているメディアタイプオーディオ/ G719を使用して識別されます。
The media type for the G.719 codec is allocated from the IETF tree since G.719 has the potential to become a widely used audio codec in general Voice over IP (VoIP), teleconferencing, and streaming applications. This media type registration covers real-time transfer via RTP.
G.719は、ITFツリーからIETFツリーから割り当てられているG.719は、一般的な音声（VOIP）、テレコンファレンス、およびストリーミングアプリケーションで広く使用されているオーディオコーデックになる可能性があります。このメディアタイプの登録は、RTP経由のリアルタイム転送をカバーしています。
Note, any unspecified parameter MUST be ignored by the receiver to ensure that additional parameters can be added in any future revision of this specification.
注意していないパラメーターは、この仕様の将来の改訂で追加のパラメーターを追加できることを確認するために、受信機によって無視する必要があります。
Type name: audio
タイプ名：オーディオ
Subtype name: G719
サブタイプ名：G719
Required parameters: none
必要なパラメーター：なし
Optional parameters: interleaving: Indicates that interleaved mode SHALL be used for the payload. The parameter specifies the number of frame-block slots available in a de-interleaving buffer (including the frame that is ready to be consumed) for each source. Its value is equal to one plus the maximum number of frames that can precede any frame in transmission order and follow the frame in RTP timestamp order. The value MUST be greater than zero. If this parameter is not present, interleaved mode SHALL NOT be used.
オプションのパラメーター：インターリーブ：ペイロードにインターリーブモードが使用されることを示します。このパラメーターは、各ソースのインターレービングバッファー（消費する準備ができているフレームを含む）で利用可能なフレームブロックスロットの数を指定します。その値は、1つのフレームに任意のフレームに先行し、RTPタイムスタンプの順序でフレームに従うことができる最大フレームの数に等しくなります。値はゼロより大きくなければなりません。このパラメーターが存在しない場合、インターリーブモードを使用してはなりません。
int-delay: The minimal media time delay in milliseconds that is needed to avoid underrun in the de-interleaving buffer before starting decoding, i.e., the difference in RTP timestamp ticks between the earliest and latest audio frame present in the de-interleaving buffer expressed in milliseconds. The value is a stream property and provided per source. The allowed values are zero to the largest value expressible by an unsigned 16-bit integer (65535). Please note that in practice, the largest value that can be used is equal to the declared size of the interleaving buffer of the receiver. If the value for some reason is larger than the receiver buffer declared by or for the receiver, this value defaults to the size of the receiver buffer. For sources for which this value hasn't been provided, the value defaults to the size of the receiver buffer. The format is a comma-separated list of synchronization source (SSRC) ":" delay in ms pairs, which in ABNF [RFC5234] is expressed as:
int-delay：デコードを開始する前に、interleaingバッファーのアンダーランを避けるために必要なミリ秒の最小メディア時間遅延、つまり、発現した脱毛バッファーに存在する初期と最新のオーディオフレームの間のRTPタイムスタンプのティックの差ミリ秒単位。値はストリームプロパティであり、ソースごとに提供されます。許可された値は、署名されていない16ビット整数（65535）によって表現可能な最大値までゼロです。実際には、使用できる最大の値は、レシーバーのインターリーブバッファーの宣言されたサイズに等しいことに注意してください。何らかの理由で値がレシーバーによって宣言されたレシーバーバッファーよりも大きい場合、この値はレシーバーバッファーのサイズにデフォルトです。この値が提供されていないソースの場合、値はレシーバーバッファーのサイズにデフォルトです。この形式は、同期ソース（SSRC）のコンマ区切りリストです」：「ABNF [RFC5234]では次のように表されるMSペアの遅延は次のとおりです。
int-delay = "int-delay:" source-delay *("," source-delay)
source-delay = SSRC ":" delay-value
source-delay = ssrc "："遅延値
SSRC = 1*8HEXDIG ; The 32-bit SSRC encoded in hex format
delay-value = 1*5DIGIT ; The delay value in milliseconds
Example: int-delay=ABCD1234:1000,4321DCB:640
NOTE: No white space allowed in the parameter before the end of all the value pairs
注：すべての値ペアが終了する前にパラメーターに空白が許可されていません
max-red: The maximum duration in milliseconds that elapses between the primary (first) transmission of a frame and any redundant transmission that the sender will use. This parameter allows a receiver to have a bounded delay when redundancy is used. Allowed values are between zero (no redundancy will be used) and 65535. If the parameter is omitted, no limitation on the use of redundancy is present.
Max-Red：フレームの一次（最初の）送信と、送信者が使用する冗長トランスミッションの間で経過するミリ秒単位での最大期間。このパラメーターにより、冗長性を使用すると、レシーバーが境界遅延を持つことができます。許可された値はゼロ（冗長性は使用されません）と65535の間にあります。パラメーターが省略されている場合、冗長性の使用に関する制限はありません。
channels: The number of audio channels. The possible values (1-6) and their respective channel order is specified in Section 4.1 of [RFC3551]. If omitted, it has the default value of 1.
チャネル：オーディオチャネルの数。可能な値（1-6）とそれぞれのチャネル順序は、[RFC3551]のセクション4.1で指定されています。省略した場合、デフォルト値は1です。
CBR: Constant Bitrate (CBR) indicates the exact codec bitrate in bits per second (not including the overhead from packetization, RTP header, or lower layers) that the codec MUST use. "CBR" is to be used when the dynamic rate cannot be supported (one case is, e.g., gateway to H.320). "CBR" is mostly used for gateways to circuit switch networks. Therefore, the "CBR" is the rate not including any FEC as specified in Section 4.3.1. If FEC is to be used, the "b=" parameter MUST be used to allow the extra bitrate needed to send the redundant information. It is RECOMMENDED that this parameter is only used when necessary to establish a working communication. The usage of this parameter has implications for congestion control that need to be considered; see Section 9.
CBR：定数ビットレート（CBR）は、コーデックが使用する必要がある1秒あたりのビットでの正確なコーデックビットレート（パケット化、RTPヘッダー、または下層層からのオーバーヘッドを含めない）を示します。「CBR」は、動的レートをサポートできない場合に使用されます（たとえば、H.320へのゲートウェイ）。「CBR」は、主に回路スイッチネットワークへのゲートウェイに使用されます。したがって、「CBR」は、セクション4.3.1で指定されているFECを含めないレートです。FECを使用する場合、「b =」パラメーターを使用して、冗長な情報を送信するために必要な追加のビットレートを許可する必要があります。このパラメーターは、必要な場合にのみ使用される場合にのみ使用されることをお勧めします。このパラメーターの使用は、考慮する必要がある混雑制御に影響を与えます。セクション9を参照してください。
ptime: see [RFC4566].
PTIME：[RFC4566]を参照してください。
maxptime: see [RFC4566].
Maxptime：[RFC4566]を参照してください。
Encoding considerations: This media type is framed and binary; see Section 4.8 of [RFC4288].
考慮事項のエンコーディング：このメディアタイプはフレームとバイナリです。[RFC4288]のセクション4.8を参照してください。
Security considerations: See Section 10 of RFC 5404.
セキュリティ上の考慮事項：RFC 5404のセクション10を参照してください。
Interoperability considerations: The support of the Interleaving mode is not mandatory and needs to be negotiated. See Section 7.2 for how to do that for SDP-based protocols.
相互運用性の考慮事項：インターリーブモードのサポートは必須ではなく、交渉する必要があります。SDPベースのプロトコルの方法については、セクション7.2を参照してください。
Published specification: RFC 5404
公開された仕様：RFC 5404
Applications that use this media type: Real-time audio applications like Voice over IP and teleconference, and multi-media streaming.
このメディアタイプを使用するアプリケーション：Voice over IPやTeleconference、Multi-Mediaストリーミングなどのリアルタイムオーディオアプリケーション。
Additional information: none
追加情報：なし
Person & email address to contact for further information: Ingemar Johansson <ingemar.s.johansson@ericsson.com>
詳細については、個人とメールアドレスをお問い合わせください：Ingemar Johansson <Gemar.s.s.johansson@ericsson.com>
Intended usage: COMMON
意図された使用法：共通
Restrictions on usage: 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:
Ingemar Johansson <ingemar.s.johansson@ericsson.com>
Magnus Westerlund <magnus.westerlund@ericsson.com>
Change controller: IETF Audio/Video Transport working group delegated from the IESG.
Change Controller：IETFオーディオ/ビデオトランスポートワーキンググループは、IESGから委任されました。
Additionally, note that file storage of G.719-encoded audio in ISO base media file format is specified in Annex A of [ITU-T-G719]. Thus, media file formats such as MP4 (audio/mp4 or video/mp4) [RFC4337] and 3GP (audio/3GPP and video/3GPP) [RFC3839] can contain G.719-encoded audio.
さらに、ISOベースメディアファイル形式のG.719エンコードオーディオのファイルストレージは、[ITU-T-G719]の付録Aで指定されていることに注意してください。したがって、MP4（オーディオ/MP4またはビデオ/MP4）[RFC4337]や3GP（Audio/3GPPおよびVideo/3GPP）[RFC3839]などのメディアファイル形式は、G.719エンコードオーディオを含めることができます。
The information carried in the media type specification has a specific mapping to fields in the Session Description Protocol (SDP) [RFC4566], which is commonly used to describe RTP sessions. When SDP is used to specify sessions employing the G.719 codec, the mapping is as follows:
メディアタイプの仕様に掲載されている情報には、セッション説明プロトコル（SDP）[RFC4566]のフィールドへの特定のマッピングがあります。これは、RTPセッションを記述するために一般的に使用されます。SDPを使用してG.719コーデックを使用するセッションを指定する場合、マッピングは次のとおりです。
o The media type ("audio") goes in SDP "m=" as the media name.
o メディアタイプ（ "Audio"）は、メディア名としてSDP "m ="になります。
o The media subtype (payload format name) goes in SDP "a=rtpmap" as the encoding name. The RTP clock rate in "a=rtpmap" MUST be 48000, and the encoding parameter "channels" (Section 7.1) MUST either be explicitly set to N or omitted, implying a default value of 1. The values of N that are allowed are specified in Section 4.1 in [RFC3551].
o メディアサブタイプ（ペイロード形式名）は、エンコーディング名としてSDP "a = rtpmap"になります。「a = rtpmap」のrtpクロックレートは48000でなければならず、エンコードパラメーター「チャネル」（セクション7.1）はnに明示的に設定するか、省略する必要があり、1のデフォルト値を意味します。[RFC3551]のセクション4.1で指定されています。
o The parameters "ptime" and "maxptime" go in the SDP "a=ptime" and "a=maxptime" attributes, respectively.
o パラメーター「PTIME」と「MAXPTIME」は、それぞれSDP「A = PTIME」と「A = MaxPtime」属性に移動します。
o Any remaining parameters go in the SDP "a=fmtp" attribute by copying them directly from the media type parameter string as a semicolon-separated list of parameter=value pairs.
o 残りのパラメーターは、Parameter = valueペアのセミコロン分離リストとしてメディアタイプパラメーター文字列から直接コピーすることにより、SDP "a = fmtp"属性になります。
The following considerations apply when using SDP offer/answer procedures to negotiate the use of G.719 payload in RTP:
SDPオファー/回答手順を使用してG.719ペイロードをRTPで交渉する場合、以下の考慮事項が適用されます。
o Each combination of the RTP payload transport format configuration parameters ("interleaving" and "channels") is unique in its bit pattern and not compatible with any other combination. When creating an offer in an application desiring to use the more advanced features (interleaving or more than one channel), the offerer is RECOMMENDED to also offer a payload type containing only the configuration with a single channel. If multiple configurations are of interest to the application, they may all be offered; however, care should be taken not to offer too many payload types. An SDP answerer MUST include, in the SDP answer for a payload type, the following parameters unmodified from the SDP offer (unless it removes the payload type): "interleaving" and "channels". However, the value of the "interleaving" parameter MAY be changed. The SDP offerer and answerer MUST generate G.719 packets as described by these parameters.
o RTPペイロードトランスポートフォーマット構成パラメーター（「インターリーブ」と「チャネル」）の各組み合わせは、そのビットパターンで一意であり、他の組み合わせと互換性がありません。より高度な機能（インターリーブまたは複数のチャネル）を使用したいアプリケーションでオファーを作成する場合、オファーは、単一チャネルの構成のみを含むペイロードタイプも提供することをお勧めします。複数の構成がアプリケーションにとって興味深い場合、それらはすべて提供される場合があります。ただし、あまりにも多くのペイロードタイプを提供しないように注意する必要があります。SDP回答者には、ペイロードタイプのSDP回答に、SDPオファーから変更されていない次のパラメーター（ペイロードタイプを削除しない限り）を含める必要があります：「インターリーブ」および「チャネル」。ただし、「インターリーブ」パラメーターの値を変更する場合があります。SDP提供者と回答者は、これらのパラメーターで説明されているようにG.719パケットを生成する必要があります。
o The "interleaving" and "int-delay" parameters' values have a specific relationship that needs to be considered. It also depends on the directionality of the streams and their delivery method. The high-level explanation that can be understood from the definition is that the value of "interleaving" declares the size of the receiver buffer, while "int-delay" is a stream property provided by the sender to inform how much buffer space it in practice is using for the stream it sends.
o 「インターリービング」および「int-delay」パラメーターの値には、考慮する必要がある特定の関係があります。また、ストリームの方向性とその配信方法にも依存します。定義から理解できる高レベルの説明は、「インターリーブ」の値は受信バッファーのサイズを宣言し、「int-delay」は送信者が提供するストリームプロパティであり、バッファースペースの量を通知することです。練習は、送信するストリームに使用しています。
* For media streams that are sent over multicast, the value of "interleaving" SHALL NOT be changed by the answerer. It shall either be accepted or the payload type deleted. The value of the "int-delay" parameter is a stream property and provided by the offer/answer agent that intends to send media with this payload type, and for each stream coming from that agent (one or more). The value MUST be between zero and what corresponds to the buffer size declared by the value of the "interleaving" parameter.
* マルチキャストを介して送信されるメディアストリームの場合、「インターリービング」の価値は、回答者によって変更されてはなりません。受け入れられるか、ペイロードタイプが削除されます。「int-delay」パラメーターの値は、ストリームプロパティであり、このペイロードタイプを使用してメディアを送信する予定のオファー/回答エージェントによって提供され、そのエージェント（1つ以上）から来る各ストリームに対して提供されます。値はゼロと、「インターリーブ」パラメーターの値によって宣言されたバッファサイズに対応するものの間でなければなりません。
* For unicast streams that the offerer declares as send-only, the value of the "interleaving" parameter is the size that the answerer is RECOMMENDED to use by the offerer. The answerer MAY change it to any allowed value. The "int-delay" parameter value will be the one the offerer intends to use unless the answerer reduces the value of the "interleaving" parameter below what is needed for that "int-delay" value. If the "interleaving" value in the answer is smaller than the offer's "int-delay" value, the "int-delay" value is per default reduced to be corresponding to the "interleaving" value. If the offerer is not satisfied with this, he will need to perform another round of offer/answer. As the answerer will not send any media, it doesn't include any "int-delay" in the answer.
* オファーが送信専用と宣言するユニキャストストリームの場合、「インターリーブ」パラメーターの値は、応募者が使用することを推奨するサイズです。応答者は、許可された価値に変更する場合があります。「int-delay」パラメーター値は、応答者が「インターリービング」パラメーターの値をその「int-delay」値に必要なもの以下の値を下げない限り、提供者が使用する意図したものです。答えの「インターリーブ」値がオファーの「int-delay」値よりも小さい場合、「int-delay」値は、デフォルトごとに「インターリーブ」値に対応するように削減されます。オファーがこれに満足していない場合、彼は別のラウンドのオファー/回答を実行する必要があります。応答者はメディアを送信しないため、回答には「イントレイ」は含まれていません。
* For unicast streams that the offerer declares as recvonly, the value of "interleaving" in the offer will be the offerer's size of the interleaving buffer. The answerer indicates its preferred size of the interleaving buffer for any future round of offer/answer. The offerer will not provide any "int-delay" parameter as it is not sending any media. The answerer is recommended to include in its answer an "int-delay" parameter to declare what the property is for the stream it is going to send. The answer is expected to be capable of selecting a valid parameter value that is between zero and the declared maximum number of slots in the de-interleaving buffer.
* オファーがrecvonlyと宣言するユニキャストストリームの場合、オファーの「インターリーブ」の価値は、オファーの潜水バッファーのサイズになります。回答者は、将来のオファー/回答のラウンドに合わせて、インテリアバッファーの好ましいサイズを示しています。オファーは、メディアを送信していないため、「int-delay」パラメーターを提供しません。回答者は、回答に「int-delay」パラメーターを含めることをお勧めします。答えは、ゼロと宣言されたinterleavingバッファーで宣言された最大スロットの間の有効なパラメーター値を選択できることが期待されています。
* For unicast streams that the offer declares as sendrecv streams, the value of the "interleaving" parameter in the offer will be the offerer's size of the interleaving buffer. The answerer will in the answer indicate the size of its actual interleaving buffer. It is recommended that this value is at least as big as the offer's. The offerer is recommended to include an "int-delay" parameter that is selected based on the answerer having at least as much interleaving space as the offerer unless nothing else is known. As the offerer's interleaving buffer size is not yet known, this may fail, in which case the default rule is to downgrade the value of the "int-delay" to correspond to the full size of the answerer's interleaving buffer. If the offerer isn't satisfied with this, it will need to initiate another round of offer/answer. The answerer is recommended in its answer to include an "int-delay" parameter to declare what the property is for the stream(s) it is going to send. The answer is expected to be capable of selecting a valid parameter value that is between zero and the declared maximum number of slots in the de-interleaving buffer.
* オファーがSendRecvストリームとして宣言するユニキャストストリームの場合、オファーの「インターリーブ」パラメーターの値は、オファーのサイズのインターリーブバッファーになります。回答者は、実際のインテリアバッファーのサイズを示しています。この値は、少なくともオファーと同じくらい大きいことをお勧めします。オファーは、他に何も知られていない限り、少なくとも提供者と同じくらい多くのインターリービングスペースを持つ回答者に基づいて選択される「int-delay」パラメーターを含めることをお勧めします。オファーのインターリーブバッファーサイズがまだわからないため、これは失敗する可能性があります。その場合、デフォルトのルールは、「int-delay」の値を、回答者のインターリービングバッファーのフルサイズに対応するように格下げすることです。オファーがこれに満足していない場合、別のラウンドのオファー/回答を開始する必要があります。回答者は、その回答で、送信するストリームのプロパティが何であるかを宣言する「int-delay」パラメーターを含めるように推奨されます。答えは、ゼロと宣言されたinterleavingバッファーで宣言された最大スロットの間の有効なパラメーター値を選択できることが期待されています。
o In most cases, the parameters "maxptime" and "ptime" will not affect interoperability; however, the setting of the parameters can affect the performance of the application. The SDP offer/ answer handling of the "ptime" parameter is described in [RFC3264]. The "maxptime" parameter MUST be handled in the same way.
o ほとんどの場合、パラメーター「maxptime」と「ptime」は相互運用性に影響しません。ただし、パラメーターの設定は、アプリケーションのパフォーマンスに影響を与える可能性があります。「PTIME」パラメーターのSDPオファー/回答処理は、[RFC3264]で説明されています。「MaxPtime」パラメーターも同じ方法で処理する必要があります。
o The parameter "max-red" is a stream property parameter. For sendonly or sendrecv unicast media streams, the parameter declares the limitation on redundancy that the stream sender will use. For recvonly streams, it indicates the desired value for the stream sent to the receiver. The answerer MAY change the value, but is RECOMMENDED to use the same limitation as the offer declares. In the case of multicast, the offerer MAY declare a limitation; this SHALL be answered using the same value. A media sender using this payload format is RECOMMENDED to always include the "max-red" parameter. This information is likely to simplify the media stream handling in the receiver. This is especially true if no redundancy will be used, in which case "max-red" is set to zero.
o パラメーター「max-red」は、ストリームプロパティパラメーターです。SendonlyまたはSendRecv Unicast Media Streamsの場合、パラメーターは、ストリーム送信者が使用する冗長性の制限を宣言します。Recvonlyストリームの場合、レシーバーに送信されたストリームの望ましい値を示します。応答者は値を変更する場合がありますが、オファーが宣言するのと同じ制限を使用することをお勧めします。マルチキャストの場合、提供者は制限を宣言することができます。これは、同じ値を使用して回答するものとします。このペイロード形式を使用するメディア送信者は、常に「最大レッド」パラメーターを含めるようにお勧めします。この情報は、受信機のメディアストリームの処理を簡素化する可能性があります。これは、冗長性が使用されない場合に特に当てはまります。その場合、「最大赤」がゼロに設定されています。
o Any unknown parameter in an offer SHALL be removed in the answer.
o オファー内の未知のパラメーターは、回答で削除されるものとします。
o The "b=" SDP parameter SHOULD be used to negotiate the maximum bandwidth to be used for the audio stream. The offerer may offer a maximum rate and the answer may contain a lower rate. If no "b=" parameter is present in the offer or answer, it implies a rate up to 128 kbps.
o 「B =」SDPパラメーターを使用して、オーディオストリームに使用する最大帯域幅をネゴシエートする必要があります。オファーは最大レートを提供する場合があり、答えには低いレートが含まれる場合があります。「b =」パラメーターがオファーまたは回答に存在しない場合、最大128 kbpsのレートを意味します。
o The parameter "CBR" is a receiver capability; i.e., only receivers that really require a constant bitrate should use it. Usage of this parameter has a negative impact on the possibility to perform congestion control; see Section 9. For recvonly and sendrecv streams, it indicates the desired constant bitrate that the receiver wants to accept. A sender MUST be able to send a constant bitrate stream since it is a subset of the variable bitrate capability. If the offer includes this parameter, the answerer MUST send G.719 audio at the constant bitrate if it is within the allowed session bitrate ("b=" parameter). If the answerer cannot support the stated CBR, this payload type must be refused in the answer. The answerer SHOULD only include this parameter if the answerer itself requires to receive at a constant bitrate, even if the offer did not include the "CBR" parameter. In this case, the offerer SHALL send at the constant bitrate, but SHALL be able to accept media at a variable bitrate. An answerer is RECOMMEND to use the same CBR as in the offer, as symmetric usage is more likely to work. If both sides require a particular CBR, there is the possibility of communication failure when one or both sides can't transmit the requested rate. In this case, the agent detecting this issue will have to perform a second round of offer/answer to try to find another working configuration or end the established session. In case the offer contained a "CBR" parameter but the answer does not, then the offerer is free to transmit at any rate to the answerer, but the answerer is restricted to the declared rate.
o パラメーター「CBR」はレシーバー機能です。つまり、一定のビットレートを本当に必要とするレシーバーのみがそれを使用する必要があります。このパラメーターの使用は、混雑制御を実行する可能性に悪影響を及ぼします。セクション9を参照してください。RecvonlyおよびSendRecvストリームについては、受信者が受け入れたいという望ましい定数ビットレートを示します。送信者は、可変ビットレート機能のサブセットであるため、一定のビットレートストリームを送信できる必要があります。オファーにこのパラメーターが含まれている場合、回答者は許可されたセッションビットレート（ "b ="パラメーター）内にある場合、constant bitrateでG.719オーディオを送信する必要があります。応答者が指定されたCBRをサポートできない場合、このペイロードタイプは回答で拒否されなければなりません。応募者自体が「CBR」パラメーターが含まれていない場合でも、回答者自体が一定のビットレートで受信する必要がある場合にのみ、このパラメーターを含める必要があります。この場合、提供者は一定のビットレートで送信するものとしますが、可変ビットレートでメディアを受け入れることができます。対称的な使用が機能する可能性が高いため、応答者はオファーと同じCBRを使用することをお勧めします。双方が特定のCBRを必要とする場合、一方または両側が要求されたレートを送信できない場合、通信障害の可能性があります。この場合、この問題を検出するエージェントは、別の作業構成を見つけたり、確立されたセッションを終了しようとするために、オファー/回答の2回目のラウンドを実行する必要があります。オファーに「CBR」パラメーターが含まれていたが答えが含まれていない場合、提供者はとにかく自由に応答者に送信できますが、回答者は宣言されたレートに制限されています。
In declarative usage, like SDP in the Real Time Streaming Protocol (RTSP) [RFC2326] or the Session Announcement Protocol (SAP) [RFC2974], the parameters SHALL be interpreted as follows:
リアルタイムストリーミングプロトコル（RTSP）[RFC2326]またはセッションアナウンスプロトコル（SAP）[RFC2974]のSDPのように、宣言的使用法では、パラメーターは次のように解釈されます。
o The payload format configuration parameters ("interleaving" and "channels") are all declarative, and a participant MUST use the configuration(s) that is provided for the session. More than one configuration may be provided if necessary by declaring multiple RTP payload types; however, the number of types should be kept small.
o ペイロード形式の構成パラメーター（「インターリーブ」と「チャネル」）はすべて宣言的であり、参加者はセッションに提供される構成を使用する必要があります。複数のRTPペイロードタイプを宣言することにより、必要に応じて複数の構成を提供できます。ただし、タイプの数は小さくする必要があります。
o It might not be possible to know the SSRC values that are going to be used by the sources at the time of sending the SDP. This is not a major issue as the size of the interleaving buffer can be tailored towards the values that are actually going to be used, thus ensuring that the default values for "int-delay" are not resulting in too much extra buffering.
o SDPの送信時にソースが使用するSSRC値を知ることはできないかもしれません。インターリーブバッファーのサイズは、実際に使用される値に合わせて調整できるため、これは大きな問題ではありません。したがって、「int-delay」のデフォルト値があまり余分なバッファリングにならないようにします。
o Any "maxptime" and "ptime" values should be selected with care to ensure that the session's participants can achieve reasonable performance.
o セッションの参加者が合理的なパフォーマンスを達成できるようにするために、「最大」および「PTIME」値を注意して選択する必要があります。
o The parameter "CBR" if included applies to all RTP streams using that payload type for which a particular CBR is declared. Usage of this parameter has a negative impact on the possibility to perform congestion control; see Section 9.
o パラメーター「CBR」が含まれている場合、特定のCBRが宣言されているペイロードタイプを使用してすべてのRTPストリームに適用されます。このパラメーターの使用は、混雑制御を実行する可能性に悪影響を及ぼします。セクション9を参照してください。
One media type (audio/G719) has been defined and registered in the media types registry; see Section 7.1.
1つのメディアタイプ（Audio/G719）が定義され、メディアタイプレジストリに登録されています。セクション7.1を参照してください。
The general congestion control considerations for transporting RTP data apply; see RTP [RFC3550] and any applicable RTP profile like AVP [RFC3551]. However, the multi-rate capability of G.719 audio coding provides a mechanism that may help to control congestion, since the bandwidth demand can be adjusted (within the limits of the codec) by selecting a different encoding bitrate.
RTPデータを輸送するための一般的な混雑制御の考慮事項が適用されます。RTP [RFC3550]およびAVP [RFC3551]のような該当するRTPプロファイルを参照してください。ただし、G.719オーディオコーディングのマルチレート機能は、異なるエンコーディングビットレートを選択することで帯域幅の需要を調整できるため、混雑を制御するのに役立つメカニズムを提供します。
The number of frames encapsulated in each RTP payload highly influences the overall bandwidth of the RTP stream due to header overhead constraints. Packetizing more frames in each RTP payload can reduce the number of packets sent and hence the header overhead, at the expense of increased delay and reduced error robustness. If forward error correction (FEC) is used, the amount of FEC-induced redundancy needs to be regulated such that the use of FEC itself does not cause a congestion problem. In other words, a sender SHALL NOT increase the total bitrate when adding redundancy in response to packet loss, and needs instead to adjust it down in accordance to the congestion control algorithm being run. Thus, when adding redundancy, the media bitrate will need to be reduced to provide room for the redundancy.
各RTPペイロードにカプセル化されたフレームの数は、ヘッダーオーバーヘッドの制約により、RTPストリームの全体的な帯域幅に大きく影響します。各RTPペイロードでより多くのフレームをパケット化すると、遅延の増加とエラーの堅牢性の低下を犠牲にして、送信されるパケットの数を減らすことができ、ヘッダーのオーバーヘッドを減らすことができます。フォワードエラー補正（FEC）を使用する場合、FEC自体の使用がうっ血の問題を引き起こさないように、FEC誘導冗長性の量を調整する必要があります。言い換えれば、送信者は、パケットの損失に応じて冗長性を追加するときに総ビットレートを増やすことはできません。代わりに、実行中の混雑制御アルゴリズムに従って調整する必要があります。したがって、冗長性を追加する場合、メディアビットレートを縮小する必要があります。
The "CBR" signaling parameter allows a receiver to lock down an RTP payload type to use a single encoding rate. As this prevents the codec rate from being lowered when congestion is experienced, the sender is constrained to either change the packetization or abort the transmission. Since these responses to congestion are severely limited, implementations SHOULD NOT use the "CBR" parameter unless they are interacting with a device that cannot support a variable bitrate (e.g., a gateway to H.320 systems). When using CBR mode, a receiver MUST monitor the packet loss rate to ensure congestion is not caused, following the guidelines in Section 2 of RFC 3551.
「CBR」シグナリングパラメーターを使用すると、レシーバーはRTPペイロードタイプをロックダウンして単一のエンコーディングレートを使用できます。これにより、混雑が発生したときにコーデックレートが低下するのを防ぐため、送信者はパケット化を変更するか、伝送を中止するように制約されます。輻輳に対するこれらの応答は厳しく制限されているため、実装は、可変ビットレート（たとえば、H.320システムへのゲートウェイ）をサポートできないデバイスと相互作用していない限り、「CBR」パラメーターを使用しないでください。CBRモードを使用する場合、受信者はRFC 3551のセクション2のガイドラインに従って、混雑が発生しないようにパケット損失率を監視する必要があります。
RTP packets using the payload format defined in this specification are subject to the security considerations discussed in the RTP specification [RFC3550] and in any applicable RTP profile. The main security considerations for the RTP packet carrying the RTP payload format defined within this memo are confidentiality, integrity, and source authenticity. Confidentiality is achieved by encryption of the RTP payload. Integrity of the RTP packets is achieved through a suitable cryptographic integrity protection mechanism. Such a cryptographic system may also allow the authentication of the source of the payload. A suitable security mechanism for this RTP payload format should provide confidentiality, integrity protection, and at least source authentication capable of determining if an RTP packet is from a member of the RTP session.
この仕様で定義されたペイロード形式を使用したRTPパケットは、RTP仕様[RFC3550]および該当するRTPプロファイルで説明されているセキュリティ上の考慮事項の対象となります。このメモ内で定義されているRTPペイロード形式を運ぶRTPパケットの主なセキュリティ上の考慮事項は、機密性、整合性、およびソースの信頼性です。機密性は、RTPペイロードの暗号化によって達成されます。RTPパケットの整合性は、適切な暗号化整合性保護メカニズムを通じて達成されます。このような暗号化システムは、ペイロードのソースの認証を可能にする場合もあります。このRTPペイロード形式の適切なセキュリティメカニズムは、機密性、整合性保護、および少なくともRTPパケットがRTPセッションのメンバーからのものであるかどうかを判断できるソース認証を提供する必要があります。
Note that the appropriate mechanism to provide security to RTP and payloads following this memo may vary. It is dependent on the application, the transport, and the signaling protocol employed. Therefore, a single mechanism is not sufficient, although if suitable, usage of the Secure Real-time Transport Protocol (SRTP) [RFC3711] is recommended. Other mechanisms that may be used are IPsec [RFC4301] and Transport Layer Security (TLS) [RFC5246] (RTP over TCP); other alternatives may exist.
このメモに従ってRTPとペイロードにセキュリティを提供する適切なメカニズムは異なる場合があることに注意してください。アプリケーション、輸送、および採用されたシグナルプロトコルに依存します。したがって、単一のメカニズムは十分ではありませんが、適切な場合は安全なリアルタイムトランスポートプロトコル（SRTP）[RFC3711]の使用法が推奨されます。使用できる他のメカニズムは、IPSEC [RFC4301]および輸送層セキュリティ（TLS）[RFC5246]（TCPを介したRTP）です。他の選択肢が存在する場合があります。
The use of interleaving in conjunction with encryption can have a negative impact on confidentiality for a short period of time. Consider the following packets (in brackets) containing frame numbers as indicated: {10, 14, 18}, {13, 17, 21}, {16, 20, 24} (a popular continuous diagonal interleaving pattern). The originator wishes to deny some participants the ability to hear material starting at time 16. Simply changing the key on the packet with the timestamp at or after 16, and denying that new key to those participants, does not achieve this; frames 17, 18, and 21 have been supplied in prior packets under the prior key, and error concealment may make the audio intelligible at least as far as frame 18 or 19, and possibly further.
暗号化と組み合わせてインターリーブを使用すると、短期間の機密性にマイナスの影響を与える可能性があります。示されているようにフレーム番号を含む次のパケット（括弧内）を考えてみましょう：{10、14、18}、{13、17、21}、{16、20、24}（一般的な連続した対角線インターリーブパターン）。オリジネーターは、時間16からの資料を聞く能力を参加者に否定したいと考えています。16時以降にタイムスタンプでパケットのキーを変更するだけで、それらの参加者の新しいキーを否定してもこれは達成されません。フレーム17、18、および21は、以前のキーの下で以前のパケットに提供されており、エラーの隠蔽により、少なくともフレーム18または19まで、オーディオはわかりやすくなる可能性があります。
This RTP payload format and its media decoder do not exhibit any significant non-uniformity in the receiver-side computational complexity for packet processing, and thus are unlikely to pose a denial-of-service threat due to the receipt of pathological data. Nor does the RTP payload format contain any active content.
このRTPペイロード形式とそのメディアデコーダーは、パケット処理のためにレシーバー側の計算の複雑さに有意な不均一性を示さないため、病理学的データの受領によりサービス拒否の脅威をもたらすことはほとんどありません。また、RTPペイロード形式にはアクティブなコンテンツが含まれていません。
The authors would like to thank Roni Even and Anisse Taleb for their help with this document. We would also like to thank the people who have provided feedback: Colin Perkins, Mark Baker, and Stephen Botzko.
著者は、この文書の支援をしてくれたRoni EvenとAnisse Talebに感謝したいと思います。また、フィードバックを提供してくれた人々、コリンパーキンス、マークベイカー、スティーブンボッツコに感謝したいと思います。
[ITU-T-G719] ITU-T, "Specification : ITU-T G.719 extension for 20 kHz fullband audio", April 2008.
[ITU-T-G719] ITU-T、「仕様：20 kHzフルバンドオーディオのITU-T G.719拡張」、2008年4月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[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月。
[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月。
[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月。
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
[RFC4566] Handley、M.、Jacobson、V。、およびC. Perkins、「SDP：セッション説明プロトコル」、RFC 4566、2006年7月。
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5234] Crocker、D。およびP. Overell、「構文仕様のためのBNFの増強」、STD 68、RFC 5234、2008年1月。
[RFC5405] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines for Application Designers", BCP 145, RFC 5405, November 2008.
[RFC5405] Eggert、L。およびG. Fairhurst、「アプリケーションデザイナーのユニキャストUDP使用ガイドライン」、BCP 145、RFC 5405、2008年11月。
[RFC2198] Perkins, C., Kouvelas, I., Hodson, O., Hardman, V., Handley, M., Bolot, J., Vega-Garcia, A., and S. Fosse-Parisis, "RTP Payload for Redundant Audio Data", RFC 2198, September 1997.
[RFC2198] Perkins、C.、Kouvelas、I.、Hodson、O.、Hardman、V.、Handley、M.、Bolot、J.、Vega-Garcia、A。、およびS. Fosse-Parisis、 "RTPペイロード冗長なオーディオデータの場合」、RFC 2198、1997年9月。
[RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time Streaming Protocol (RTSP)", RFC 2326, April 1998.
[RFC2326] Schulzrinne、H.、Rao、A。、およびR. Lanphier、「リアルタイムストリーミングプロトコル（RTSP）」、RFC 2326、1998年4月。
[RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session Announcement Protocol", RFC 2974, October 2000.
[RFC2974] Handley、M.、Perkins、C。、およびE. Whelan、「セッションアナウンスプロトコル」、RFC 2974、2000年10月。
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004.
[RFC3711] Baugher、M.、McGrew、D.、Naslund、M.、Carrara、E。、およびK. Norrman、「安全なリアルタイム輸送プロトコル（SRTP）」、RFC 3711、2004年3月。
[RFC3839] Castagno, R. and D. Singer, "MIME Type Registrations for 3rd Generation Partnership Project (3GPP) Multimedia files", RFC 3839, July 2004.
[RFC3839] Castagno、R。およびD. Singer、「第3世代パートナーシッププロジェクト（3GPP）マルチメディアファイルのMIMEタイプ登録」、RFC 3839、2004年7月。
[RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and Registration Procedures", BCP 13, RFC 4288, December 2005.
[RFC4288] Freed、N。およびJ. Klensin、「メディアタイプの仕様と登録手順」、BCP 13、RFC 4288、2005年12月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301] Kent、S。およびK. SEO、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 4301、2005年12月。
[RFC4337] Y Lim and D. Singer, "MIME Type Registration for MPEG-4", RFC 4337, March 2006.
[RFC4337] Y LIMおよびD.シンガー、「MPEG-4のMIMEタイプ登録」、RFC 4337、2006年3月。
[RFC4855] Casner, S., "Media Type Registration of RTP Payload Formats", RFC 4855, February 2007.
[RFC4855] Casner、S。、「RTPペイロードフォーマットのメディアタイプ登録」、RFC 4855、2007年2月。
[RFC5109] Li, A., "RTP Payload Format for Generic Forward Error Correction", RFC 5109, December 2007.
[RFC5109] Li、A。、「ジェネリックフォワードエラー補正のRTPペイロード形式」、RFC 5109、2007年12月。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5246] Dierks、T。およびE. Rescorla、「The Transport Layer Security（TLS）Protocolバージョン1.2」、RFC 5246、2008年8月。
Authors' Addresses
著者のアドレス
Magnus Westerlund Ericsson AB Torshamnsgatan 21-23 SE-164 83 Stockholm SWEDEN
マグナスウェスターランドエリクソンAB TORSHAMNSGATAN 21-23 SE-164 83ストックホルムスウェーデン
Phone: +46 10 7190000
EMail: magnus.westerlund@ericsson.com
Ingemar Johansson Ericsson AB Laboratoriegrand 11 SE-971 28 Lulea SWEDEN
Ingemar Johansson Ericsson AB LaboratorieGrand 11 SE-971 28 Lulea Sweden
Phone: +46 10 7190000
EMail: ingemar.s.johansson@ericsson.com