[要約] RFC 5577は、ITU-T勧告G.722.1のRTPペイロード形式に関する仕様です。このRFCの目的は、G.722.1コーデックを使用して音声をRTPパケットにエンコードするための標準化を提供することです。
Network Working Group P. Luthi
Request for Comments: 5577 Tandberg
Obsoletes: 3047 R. Even
Category: Standards Track Gesher Erove Ltd
July 2009
RTP Payload Format for ITU-T Recommendation G.722.1
ITU-T推奨のRTPペイロード形式G.722.1
Abstract
概要
International Telecommunication Union (ITU-T) Recommendation G.722.1 is a wide-band audio codec. This document describes the payload format for including G.722.1-generated bit streams within an RTP packet. The document also describes the syntax and semantics of the Session Description Protocol (SDP) parameters needed to support G.722.1 audio codec.
International Telecommunication Union（ITU-T）推奨G.722.1は、ワイドバンドオーディオコーデックです。このドキュメントでは、RTPパケット内にG.722.1が生成したビットストリームを含めるためのペイロード形式について説明します。このドキュメントでは、G.722.1オーディオコーデックをサポートするために必要なセッション説明プロトコル（SDP）パラメーターの構文とセマンティクスについても説明しています。
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) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2009 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
このドキュメントは、BCP 78およびこのドキュメントの公開日（http://trustee.ietf.org/license-info）に有効なIETFドキュメントに関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
このドキュメントには、2008年11月10日までに公開または公開されたIETFドキュメントまたはIETFの貢献からの資料が含まれている場合があります。IETF標準プロセスの外。そのような資料の著作権を制御する人から適切なライセンスを取得しないと、このドキュメントはIETF標準プロセスの外側に変更されない場合があり、その派生作業は、ITF標準プロセスの外側で作成されない場合があります。RFCとしての出版または英語以外の言語に翻訳する。
Table of Contents
目次
1. Introduction ....................................................2
2. Terminology .....................................................3
3. RTP Usage for G.722.1 ...........................................3
3.1. RTP G.722.1 Header Fields ..................................3
3.2. RTP Payload Format for G.722.1 .............................3
3.3. Multiple G.722.1 Frames in an RTP Packet ...................5
3.4. Computing the Number of G.722.1 Frames .....................6
4. IANA Considerations .............................................6
4.1. Media Type Registration ....................................6
4.1.1. Registration of Media Type audio/G7221 ..............6
5. SDP Parameters ..................................................8
5.1. Usage with the SDP Offer/Answer Model ......................8
6. Security Considerations .........................................8
7. Changes from RFC 3047 ...........................................9
8. Acknowledgments .................................................9
9. References ......................................................9
9.1. Normative References .......................................9
9.2. Informative References ....................................10
ITU-T G.722.1 [ITU.G7221] is a low-complexity coder; it compresses 50 Hz - 14 kHz audio signals into one of the following bit rates: 24 kbit/s, 32 kbit/s, or 48 kbit/s.
ITU-T G.722.1 [ITU.G7221]は低複合コーダーです。50 Hz -14 kHzオーディオ信号を次のビットレートのいずれかのいずれかに圧縮します：24 kbit/s、32 kbit/s、または48 kbit/s。
The coder may be used 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 videoconferencing and telephony
o ビデオ会議やテレフォニーなどのリアルタイムコミュニケーション
o Streaming audio
o ストリーミングオーディオ
o Archival and messaging
o アーカイブとメッセージング
ITU-T G.722.1 [ITU.G7221] uses 20-ms frames and a sampling rate clock of 16 kHz or 32kHz. The encoding and decoding algorithm can change the bit rate at any 20-ms frame boundary, but no bit rate change notification is provided in-band with the bit stream.
ITU-T G.722.1 [ITU.G7221]は、20 msフレームと16 kHzまたは32kHzのサンプリングレートクロックを使用します。エンコードおよびデコードアルゴリズムは、20 msのフレーム境界でビットレートを変更できますが、ビットストリームでバンド内のビットレート変更通知は提供されません。
For any given bit rate, the number of bits in a frame is a constant. Within this fixed frame, G.722.1 uses variable-length coding (e.g., Huffman coding) to represent most of the encoded parameters. All variable-length codes are transmitted in order from the leftmost bit (most significant bit -- MSB) to the rightmost bit (least significant bit -- LSB), see [ITU.G7221] for more details.
任意のビットレートの場合、フレーム内のビット数は定数です。この固定フレーム内で、g.722.1は可変長さのコーディング（ハフマンコーディングなど）を使用して、ほとんどのエンコードされたパラメーターを表します。すべての可変長さのコードは、左端ビット（最も重要なビット - MSB）から右端ビット（最小重要なビット-LSB）に順番に送信されます。詳細については、[itu.g7221]を参照してください。
The ITU-T standardized bit rates for G.722.1 are 24 kbit/s or 32kbit/s at 16 Khz sample rate, and 24 kbit/s, 32 kbit/s, or 48 kbit/s at 32 Khz sample rate. However, the coding algorithm itself has the capability to run at any user-specified bit rate (not just 24, 32, and 48 kbit/s) while maintaining an audio bandwidth of 50 Hz to 14 kHz. This rate change is accomplished by a linear scaling of the codec operation, resulting in frames with size in bits equal to 1/50 of the corresponding bit rate.
G.722.1のITU-T標準ビットレートは、16 kHzのサンプルレートで24 kbit/sまたは32kbit/s、24 kbit/s、32 kbit/s、または32 kHzのサンプルレートで48 kbit/sです。ただし、コーディングアルゴリズム自体には、50 Hzから14 kHzのオーディオ帯域幅を維持しながら、ユーザー指定のビットレート（24、32、および48 kbit/sだけでなく）で実行する機能があります。このレートの変化は、コーデック操作の線形スケーリングによって達成され、その結果、ビットのサイズのフレームが対応するビットレートの1/50に等しくなります。
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] and indicate requirement levels for compliant RTP implementations.
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「optional」は、RFC 2119 [RFC2119]で説明されているように解釈され、準拠したRTP実装の要件レベルを示します。
The RTP header is defined in the RTP specification [RFC3550]. This section defines how fields in the RTP header are used.
RTPヘッダーは、RTP仕様[RFC3550]で定義されています。このセクションでは、RTPヘッダーのフィールドの使用方法を定義します。
Payload Type (PT): The assignment of an RTP payload type for this packet format is outside the scope of this document; it is specified by the RTP profile under which this payload format is used, or it is signaled dynamically out-of-band (e.g., using SDP).
ペイロードタイプ（PT）：このパケット形式のRTPペイロードタイプの割り当ては、このドキュメントの範囲外です。これは、このペイロード形式が使用されるRTPプロファイルによって指定されているか、帯域外に動的に合図されます（例：SDPを使用）。
Marker (M) bit: The M bit is set to zero.
マーカー（m）ビット：mビットはゼロに設定されています。
Extension (X) bit: Defined by the RTP profile used.
拡張機能（x）ビット：使用されるRTPプロファイルによって定義されています。
Timestamp: A 32-bit word that corresponds to the sampling instant for the first frame in the RTP packet. The sampling frequency can be 16 Khz or 32 Khz. The RTP timestamp clock frequency of 32 Khz SHOULD be used unless only an RTP stream sampled at 16 Khz is going to be sent.
タイムスタンプ：RTPパケットの最初のフレームのサンプリングインスタントに対応する32ビットワード。サンプリング周波数は16 kHzまたは32 kHzになります。16 kHzでサンプリングされたRTPストリームのみが送信されない限り、32 kHzのRTPタイムスタンプクロック周波数を使用する必要があります。
The RTP payload for G.722.1 has the format shown in Figure 1. No additional header fields specific to this payload format are required.
G.722.1のRTPペイロードには、図1に示す形式があります。このペイロード形式に固有の追加のヘッダーフィールドは必要ありません。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RTP Header |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| |
+ one or more frames of G.722.1 |
| .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: RTP payload for G.722.1.
図1：G.722.1のRTPペイロード。
Because bit rate is not signaled in-band, a separate out-of-band method is REQUIRED to indicate the bit rate (see Section 5 for an example of signaling bit rate information using SDP). For the payload format specified here, the bit rate MUST remain constant for a particular payload type value. An application MAY switch bit rates and clock rates from packet to packet by defining different payload type values and switching between them.
ビットレートは帯域内に信号を送られていないため、ビットレートを示すために別のバンド外の方法が必要です（SDPを使用したシグナルビットレート情報の例については、セクション5を参照）。ここで指定されているペイロード形式の場合、ビットレートは特定のペイロードタイプの値に対して一定のままでなければなりません。アプリケーションは、異なるペイロードタイプの値を定義し、それらを切り替えることにより、パケットからパケットへのビットレートとクロックレートを切り替えることができます。
The use of Huffman coding means that it is not possible to identify the various encoded parameters/fields contained within the bit stream without first completely decoding the entire frame. For the purposes of packetizing the bit stream in RTP, it is only necessary to consider the sequence of bits as output by the G.722.1 encoder and to present the same sequence to the decoder. The payload format described here maintains this sequence.
Huffmanコーディングの使用は、最初にフレーム全体を完全にデコードすることなく、ビットストリーム内に含まれるさまざまなエンコードされたパラメーター/フィールドを識別することができないことを意味します。RTPのビットストリームをパケット化するために、G.722.1エンコーダーによる出力としてビットのシーケンスを考慮し、デコーダーに同じシーケンスを提示することのみが必要です。ここで説明するペイロード形式は、このシーケンスを維持しています。
When operating at 24 kbit/s, 480 bits (60 octets) are produced per frame. When operating at 32 kbit/s, 640 bits (80 octets) are produced per frame. When operating at 48 kbit/s, 960 bits (120 octets) are produced per frame. Thus, all three bit rates allow for octet alignment without the need for padding bits.
24 kbit/sで動作する場合、フレームごとに480ビット（60オクテット）が生成されます。32 kbit/sで動作する場合、フレームごとに640ビット（80オクテット）が生成されます。48 kbit/sで動作する場合、フレームごとに960ビット（120オクテット）が生成されます。したがって、3つのビットレートはすべて、パディングビットを必要とせずにオクテットアライメントを可能にします。
Figure 2 illustrates how the G.722.1 bit stream MUST be mapped into an octet-aligned RTP payload.
図2は、G.722.1ビットストリームをオクテットに並べられたRTPペイロードにマッピングする方法を示しています。
first bit last bit
transmitted transmitted
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ sequence of bits (480, 640, or 960) generated by the |
| G.722.1 encoder for transmission |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | |
| | | ... | |
| | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... +-+-+-+-+-+-+-+-+-+-+-+-+
|MSB... LSB|MSB... LSB| |MSB... LSB|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... +-+-+-+-+-+-+-+-+-+-+-+-+
RTP RTP RTP
octet 1 octet 2 octet
60, 80, 120
Figure 2: The G.722.1 encoder bit stream is split into a sequence of octets (60, 80, or 120 depending on the bit rate), and each octet is in turn mapped into an RTP octet.
図2：G.722.1エンコーダービットストリームは、オクテットのシーケンス（ビットレートに応じて60、80、または120）に分割され、各オクテットはRTPオクテットにマッピングされます。
When operating at non-standard rates, the payload format MUST follow the guidelines illustrated in Figure 2. It is RECOMMENDED that values in the range 16000 to 48000 be used. Non-standard rates MUST have a value that is a multiple of 400 (this maintains octet alignment and does not then require (undefined) padding bits for each frame if not octet aligned). For example, a bit rate of 16.4 kbit/s will result in a frame of size 328 bits or 41 octets, which is mapped into RTP per Figure 2.
非標準料金で動作する場合、ペイロード形式は図2に示すガイドラインに従う必要があります。16000〜48000の範囲の値を使用することをお勧めします。非標準のレートには、400の倍数の値が必要です（これにより、オクテットのアライメントが維持され、オクテットが揃っていない場合、各フレームに（未定義の）パディングビットを必要としません）。たとえば、16.4 kbit/sのビットレートにより、サイズ328ビットまたは41オクテットのフレームが発生し、図2ごとにRTPにマッピングされます。
A sender may include more than one consecutive G.722.1 frame in a single RTP packet.
送信者には、単一のRTPパケットに複数の連続したG.722.1フレームを含めることができます。
Senders have the following additional restrictions:
送信者には、次の追加の制限があります。
o Sender SHOULD NOT include more G.722.1 frames in a single RTP packet than will fit in the MTU of the RTP transport protocol.
o 送信者は、RTPトランスポートプロトコルのMTUに収まるよりも、単一のRTPパケットにG.722.1フレームを追加するべきではありません。
o All frames contained in a single RTP packet MUST be of the same length and sampled at the same clock rate. They MUST have the same bit rate (octets per frame).
o 単一のRTPパケットに含まれるすべてのフレームは、同じ長さで、同じクロックレートでサンプリングされている必要があります。同じビットレート（フレームあたりのオクテット）が必要です。
o Frames MUST NOT be split between RTP packets.
o フレームをRTPパケット間で分割してはなりません。
It is RECOMMENDED that the number of frames contained within an RTP packet be consistent with the application. For example, in a telephony application where delay is important, the fewer frames per packet, the lower the delay; whereas for a delay-insensitive streaming or messaging application, many frames per packet would be acceptable.
RTPパケットに含まれるフレームの数をアプリケーションと一致させることをお勧めします。たとえば、遅延が重要なテレフォニーアプリケーションでは、パケットあたりのフレームが少ないほど、遅延が低くなります。一方、遅延非感受性ストリーミングまたはメッセージングアプリケーションの場合、パケットあたりの多くのフレームは受け入れられます。
Information describing the number of frames contained in an RTP packet is not transmitted as part of the RTP payload. The only way to determine the number of G.722.1 frames is to count the total number of octets within the RTP packet and divide the octet count by the number of expected octets per frame. This expected octet-per-frame count is derived from the bit rate and is therefore a function of the payload type.
RTPパケットに含まれるフレームの数を説明する情報は、RTPペイロードの一部として送信されません。G.722.1フレームの数を判断する唯一の方法は、RTPパケット内のオクテットの総数をカウントし、オクテット数をフレームあたりの予想オクテットの数で除算することです。この予想されるオクテットあたりのフレームカウントは、ビットレートから派生しているため、ペイロードタイプの関数です。
This document updates the G7221 media type described in RFC 3047.
このドキュメントは、RFC 3047で説明されているG7221メディアタイプを更新します。
This section describes the media types and names associated with this payload format. The section registers the media types, as per RFC 4288 [RFC4288]
このセクションでは、このペイロード形式に関連付けられたメディアの種類と名前について説明します。このセクションは、RFC 4288 [RFC4288]に従って、メディアタイプを登録します
Media type name: audio
メディアタイプ名：オーディオ
Media subtype name: G7221
メディアサブタイプ名：G7221
Required parameters:
必要なパラメーター：
bitrate: the data rate for the audio bit stream. This parameter is mandatory because the bit rate is not signaled within the G.722.1 bit stream. At the standard G.722.1 bit rates, the value MUST be either 24000 or 32000 at 16 Khz sample rate, and 24000, 32000, or 48000 at 32 Khz sample rate. If using the non-standard bit rates, then it is RECOMMENDED that values in the range 16000 to 48000 be used. Non-standard rates MUST have a value that is a multiple of 400 (this maintains octet alignment and does not then require (undefined) padding bits for each frame if not octet aligned).
Bitrate：オーディオビットストリームのデータレート。このパラメーターは、ビットレートがG.722.1ビットストリーム内で通知されないため、必須です。標準G.722.1ビットレートでは、値は16 kHzのサンプルレートで24000または32000、32 kHzのサンプルレートで24000、32000、または48000でなければなりません。標準以外のビットレートを使用する場合は、16000〜48000の範囲の値を使用することをお勧めします。非標準のレートには、400の倍数の値が必要です（これにより、オクテットのアライメントが維持され、オクテットが揃っていない場合、各フレームに（未定義の）パディングビットを必要としません）。
Optional parameters:
オプションのパラメーター：
rate: RTP timestamp clock rate, which is equal to the sampling rate. If the parameter is not specified, a clock rate of 16 Khz is assumed.
レート：RTPタイムスタンプ時計レート。これはサンプリングレートに等しい。パラメーターが指定されていない場合、16 kHzのクロックレートが想定されます。
ptime: see RFC 4566. SHOULD be a multiple of 20 ms.
PTIME：RFC 4566を参照してください。20msの倍数である必要があります。
maxptime: see RFC 4566. SHOULD be a multiple of 20 ms.
Maxptime：RFC 4566を参照してください。20msの倍数である必要があります。
Encoding considerations:
考慮事項のエンコード：
This media type is framed and binary, see Section 4.8 in [RFC4288].
このメディアタイプはフレームとバイナリです。[RFC4288]のセクション4.8を参照してください。
Security considerations: See Section 6
セキュリティ上の考慮事項：セクション6を参照してください
Interoperability considerations:
相互運用性の考慮事項：
Terminals SHOULD offer a media type at 16 Khz sample rate in order to interoperate with terminals that do not support the new 32 Khz sample rate.
端子は、新しい32 kHzのサンプルレートをサポートしていない端子と相互操作するために、16 kHzのサンプルレートでメディアタイプを提供する必要があります。
Published specification: RFC 5577.
公開された仕様：RFC 5577。
Applications that use this media type:
このメディアタイプを使用するアプリケーション：
Audio and Video streaming and conferencing applications.
オーディオおよびビデオストリーミングおよび会議アプリケーション。
Additional information: none
追加情報：なし
Person and email address to contact for further information :
詳細については、人とメールアドレスをお問い合わせください。
Roni Even: ron.even.tlv@gmail.com
roni vert：ron.even.tlv@gmail.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: Roni Even
著者：ロニ偶数
Change controller:
Change Controller：
IETF Audio/Video Transport working group delegated from the IESG.
IETFオーディオ/ビデオトランスポートワーキンググループは、IESGから委任されました。
The media types audio/G7221 are mapped to fields in the Session Description Protocol (SDP) [RFC4566] as follows:
メディアタイプのオーディオ/G7221は、次のように、セッション説明プロトコル（SDP）[RFC4566]のフィールドにマッピングされます。
o The media name in the "m=" line of SDP MUST be audio.
o SDPの「m =」行のメディア名は音声でなければなりません。
o The encoding name in the "a=rtpmap" line of SDP MUST be G7221 (the media subtype).
o SDPの「a = rtpmap」行のエンコーディング名は、g7221（メディアサブタイプ）でなければなりません。
o The parameter "rate" goes in "a=rtpmap" as clock rate parameter.
o パラメーター「レート」は、「a = rtpmap」に入ります。
o Only one bitrate SHALL be defined (using the "bitrate=" parameter in the a=fmtp line) for each payload type.
o 各ペイロードタイプに1つのビットレートのみが定義されます（a = fmtp行の「bitrate =」パラメーターを使用）。
When offering G.722.1 over RTP using SDP in an Offer/Answer model [RFC3264], the following considerations are necessary.
オファー/回答モデル[RFC3264]でSDPを使用してRTPを介してG.722.1を提供する場合、次の考慮事項が必要です。
The combination of the clock rate in the rtpmap and the bitrate parameter defines the configuration of each payload type. Each configuration intended to be used MUST be declared.
RTPMAPとBitRateパラメーターのクロックレートの組み合わせは、各ペイロードタイプの構成を定義します。使用することを目的とした各構成は宣言する必要があります。
There are two sampling clock rates defined for G.722.1 in this document. RFC 3047 [RFC3047] supports only the 16 Khz clock rate. Therefore, a system that wants to use G.722.1 SHOULD offer a payload type with clock rate of 16000 for backward interoperability.
このドキュメントには、G.722.1について定義されている2つのサンプリングクロックレートがあります。RFC 3047 [RFC3047]は、16 kHzのクロックレートのみをサポートします。したがって、G.722.1を使用したいシステムは、後方相互運用性のために16000のクロックレートのペイロードタイプを提供する必要があります。
An example of an offer that includes a 16000 and 32000 clock rate is:
16000および32000クロックレートを含むオファーの例は次のとおりです。
m=audio 49000 RTP/AVP 121 122
a=rtpmap:121 G7221/16000
a=fmtp:121 bitrate=24000
a=rtpmap:122 G7221/32000
a=fmtp:122 bitrate=48000
RTP packets using the payload format defined in this specification are subject to the security considerations discussed in the RTP specification [RFC3550] and any appropriate 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) is [RFC3711] recommended. Another mechanism that may be used is IPsec [RFC4301] Transport Layer Security (TLS) [RFC5246] (RTP over TCP); other alternatives may exist.
このメモに従ってRTPとペイロードにセキュリティを提供する適切なメカニズムは異なる場合があることに注意してください。アプリケーション、輸送、および採用されたシグナルプロトコルに依存します。したがって、単一のメカニズムでは十分ではありません。ただし、適切な場合は、安全なリアルタイムトランスポートプロトコル（SRTP）の使用が推奨されます。使用できるもう1つのメカニズムは、IPSEC [RFC4301]輸送層セキュリティ（TLS）[RFC5246]（TCPを介したRTP）です。他の選択肢が存在する場合があります。
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ペイロード形式にはアクティブなコンテンツが含まれていません。
This specification obsoletes RFC 3047, adding the support for the Superwideband (14 Khz) audio support defined in annex C of the new revision of ITU-T G.722.1.
この仕様はRFC 3047を廃止し、ITU-T G.722.1の新しい改訂の付録Cで定義されたスーパーワイドバンド（14 kHz）オーディオサポートのサポートを追加します。
Other changes:
その他の変更：
Updated the text to be in line with the current rules for RFCs and with media type registration conforming to RFC 4288.
テキストを更新して、RFCの現在のルールと、RFC 4288に準拠したメディアタイプの登録と一致しました。
The authors would like to thank Tom Taylor for his contribution to this work.
著者は、この仕事への貢献についてトム・テイラーに感謝したいと思います。
[ITU.G7221] International Telecommunications Union, "Low-complexity coding at 24 and 32 kbit/s for hands-free operation in systems with low frame loss", ITU-T Recommendation G.722.1, 2005.
[ITU.G7221] International Telecommunications Union、「低いフレーム損失のあるシステムでのハンズフリー操作のための24および32 KBIT/sでの低複雑度コーディング」、ITU-T推奨G.722.1、2005。
[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月。
[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月。
[RFC3047] Luthi, P., "RTP Payload Format for ITU-T Recommendation G.722.1", RFC 3047, January 2001.
[RFC3047] Luthi、P。、「ITU-T推奨G.722.1のRTPペイロード形式」、RFC 3047、2001年1月。
[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月。
[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月。
[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
著者のアドレス
Patrick Luthi Tandberg Philip Pedersens vei 22 1366 Lysaker Norway
Patrick Luthi Tandberg Philip Pedersens Vei 22 1366 Lysaker Norway
EMail: patrick.luthi@tandberg.no
Roni Even Gesher Erove Ltd 14 David Hamelech Tel Aviv 64953 Israel
Roni Even Gesher Erove Ltd 14 David Hamelech Tel Aviv 64953イスラエル
EMail: ron.even.tlv@gmail.com