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
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.
国際電気通信連合（ITU-T）勧告G.722.1は、ワイドバンドオーディオコーデックです。この文書では、RTPパケット内G.722.1、生成されたビットストリームを含めるためのペイロード・フォーマットを記述する。文書はまた、セッション記述プロトコル（SDP）G.722.1オーディオコーデックをサポートするために必要なパラメータの構文と意味を説明しています。
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.
著作権（C）2009 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
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トラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。
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.
この材料の一部がIETFトラストにこのような材料の変更を許可する権利を与えられていない可能性がありますにこの文書は、2008年、IETFドキュメントまたは11月10日以前に発行または公開さIETF貢献から著作権を支配する者（複数可）材料を含んでいてもよいですIETF標準化プロセスの外。そのような材料の著作権を管理者（単数または複数）から適切なライセンスを取得することなく、この文書は、IETF標準化過程の外側修正されないかもしれません、そして、それの派生物は、IETF標準化過程の外側に作成されない場合があり、それをフォーマットする以外出版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】低複雑度の符号化器です。 24キロビット/秒、32キロビット/秒、または48キロビット/秒以下のビットレートのうちの1つに14 kHzのオーディオ信号 - それは50ヘルツを圧縮します。
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 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ミリ秒のフレームと16キロヘルツまたは32kHzのサンプリングレートクロックを使用します。符号化及び復号化アルゴリズムは、任意の20ミリ秒のフレーム境界でビットレートを変更することができるが、何ビットレート変更通知は、ビットストリームと帯域内で提供されていません。
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は、符号化パラメータの大部分を表すために（例えば、ハフマン符号化）可変長符号化を使用します。右端のビット（最下位ビット - LSB）に - （MSB最上位ビット）は、全ての可変長符号は左端のビットから順に送信され、詳細については、[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標準化されたビットレートは、32 kHzのサンプリングレートで24キロビット/秒または32Kビット/ sの16 kHzのサンプリングレートで、24キロビット/秒、32キロビット/秒、または48キロビット/秒です。しかしながら、符号化アルゴリズム自体は、14 kHzの50ヘルツのオーディオ帯域幅を維持しながら、任意のユーザ指定のビットレート（だけでなく、24、32、および48キロビット/秒）で動作する能力を有しています。この速度変化は、対応するビットレートの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.
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "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ビット・ワード。サンプリング周波数は16kHzで、または32kHzのであってもよいです。 16kHzでサンプリングされた唯一の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.
ハフマン符号化の使用は、最初に完全にフレーム全体を復号することなく、ビットストリーム内に含まれる様々な符号化されたパラメータ/フィールドを識別することができないことを意味します。 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キロビット/秒で動作する場合、480ビット（60オクテット）がフレームごとに生成されます。 32キロビット/秒で動作する場合、640ビット（80オクテット）がフレームごとに生成されます。 48キロビット/秒で動作する場合、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.
非標準の速度で動作するとき、ペイロード・フォーマットは、範囲16000から48000までの値を使用することを推奨されている図2に示したガイドラインに従わなければなりません。非標準速度（これはオクテット整列を維持し、整列オクテットではないならば、フレーム毎に（未定義の）パディングビットを必要としない）、400の倍数である値を有しなければなりません。たとえば、16.4キロビットのビットレート/ Sは、図2当たりRTPにマッピングされているサイズ328ビットまたは41オクテットのフレームをもたらすであろう。
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).
ビットレート：オーディオのビットストリームのデータ・レート。ビットレートがG.722.1ビットストリーム内合図されていないため、このパラメータは必須です。標準G.722.1のビットレートで、値は、32 kHzのサンプリングレートで16 kHzのサンプリングレート、および24000、32000または48000で24000または32000のいずれかでなければなりません。非標準的なビットレートを使用している場合、範囲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.が20ミリ秒の倍数でなければなりません参照してください。
maxptime: see RFC 4566. SHOULD be a multiple of 20 ms.
maxptime：RFC 4566.が20ミリ秒の倍数でなければなりません参照してください。
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 :
詳細のために連絡する人とEメールアドレス：
Roni Even: ron.even.tlv@gmail.com
ロニさえ：ron.even.tlv@gmail.com
Intended usage: COMMON
意図している用法：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:
コントローラを変更します。
IETF Audio/Video Transport working group delegated from the IESG.
IESGから委任IETFオーディオ/ビデオ輸送ワーキンググループ。
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中のメディア名「Mは=」SDPのラインがオーディオでなければなりません。
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つだけのビットレートは、各ペイロード・タイプの（A =のfmtp線の「ビットレート=」パラメータを使用して）定義されなければなりません。
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におけるクロックレート及びビットレートパラメータの組み合わせは、各ペイロードタイプの設定を定義します。使用されることを意図した各構成は宣言する必要があります。
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）の使用量は[RFC3711]である、がお勧め。使用できる別のメカニズムは、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ペイロードフォーマットとメディアデコーダは、パケット処理のために受信側計算の複雑さの有意な不均一性を示し、したがってによる病理学的データを受信すると、サービス拒否の脅威をもたらす可能性が低いものではありません。 NOR 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.
この仕様は、ITU-T G.722.1の新しいリビジョンの附属書Cに定義されSuperwideband（14キロヘルツ）オーディオサポートするためのサポートを追加、RFC 3047を時代遅れ。
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】国際電気通信連合、ITU-T勧告G.722.1 2005「低フレーム損失がシステムにおけるハンズフリー操作のための24および32キロビット/秒で符号化低複雑」。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、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]ローゼンバーグ、J.とH. Schulzrinneと、RFC 3264、2002年6月 "セッション記述プロトコル（SDP）とのオファー/アンサーモデル"。
[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.、フレデリック、R.、およびV.ヤコブソン、 "RTP：リアルタイムアプリケーションのためのトランスポートプロトコル"、STD 64、RFC 3550、2003年7月。
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
[RFC4566]ハンドリー、M.、ヤコブソン、V.、およびC.パーキンス、 "SDP：セッション記述プロトコル"、RFC 4566、2006年7月。
[RFC3047] Luthi, P., "RTP Payload Format for ITU-T Recommendation G.722.1", RFC 3047, January 2001.
[RFC3047]ルティ、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.、マグリュー、D.、Naslund、M.、カララ、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]解放され、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]ケント、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]ダークス、T.およびE.レスコラ、 "トランスポート層セキュリティ（TLS）プロトコルバージョン1.2"、RFC 5246、2008年8月。
Authors' Addresses
著者のアドレス
Patrick Luthi Tandberg Philip Pedersens vei 22 1366 Lysaker Norway
パトリック・ルティTandbergのフィリップ・ペダーセン道22 1366リサーカーノルウェー
EMail: patrick.luthi@tandberg.no
メールアドレス：patrick.luthi@tandberg.no
Roni Even Gesher Erove Ltd 14 David Hamelech Tel Aviv 64953 Israel
ロニでもGesher Erove株式会社14デイビッドHamelechテルアビブ64953イスラエル
EMail: ron.even.tlv@gmail.com
メールアドレス：ron.even.tlv@gmail.com