Network Working Group H. Schulzrinne
Request for Comments: 3551 Columbia University
Obsoletes: 1890 S. Casner
Category: Standards Track Packet Design
July 2003
RTP Profile for Audio and Video Conferences
with Minimal Control
Status of this Memo
このメモの位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2003). All Rights Reserved.
著作権（C）インターネット協会（2003）。全著作権所有。
Abstract
抽象
This document describes a profile called "RTP/AVP" for the use of the real-time transport protocol (RTP), version 2, and the associated control protocol, RTCP, within audio and video multiparticipant conferences with minimal control. It provides interpretations of generic fields within the RTP specification suitable for audio and video conferences. In particular, this document defines a set of default mappings from payload type numbers to encodings.
この文書は、最小限のコントロールとオーディオおよびビデオmultiparticipant会議内のリアルタイム転送プロトコル（RTP）、バージョン2、及び関連する制御プロトコルRTCPの使用のための「RTP / AVP」と呼ばれるプロファイルを記述する。これは、オーディオおよびビデオ会議に適したRTP仕様内の汎用フィールドの解釈を提供します。特に、この文書は、ペイロードタイプ番号からエンコーディングへのデフォルトマッピングのセットを定義します。
This document also describes how audio and video data may be carried within RTP. It defines a set of standard encodings and their names when used within RTP. The descriptions provide pointers to reference implementations and the detailed standards. This document is meant as an aid for implementors of audio, video and other real-time multimedia applications.
この文書では、オーディオおよびビデオデータをRTP内で搬送することができる方法を説明します。 RTP内で使用されるときには、標準のエンコーディングとその名前のセットを定義します。説明は、実装と詳細な基準を参照するためのポインタを提供します。この文書は、オーディオ、ビデオ、およびその他のリアルタイムマルチメディアアプリケーションの実装のための補助として意味しています。
This memorandum obsoletes RFC 1890. It is mostly backwards-compatible except for functions removed because two interoperable implementations were not found. The additions to RFC 1890 codify existing practice in the use of payload formats under this profile and include new payload formats defined since RFC 1890 was published.
このメモは、二つの相互運用可能な実装が見つからなかったので、それが除去機能を除いて大部分が後方互換であるRFC 1890を時代遅れ。 RFC 1890への追加は、このプロファイルの下のペイロードフォーマットの使用中の既存の慣行を成文化し、RFC 1890が発行されましたので、定義された新しいペイロードフォーマットが含まれます。
Table of Contents
目次
1. Introduction ................................................. 3
1.1 Terminology ............................................. 3
2. RTP and RTCP Packet Forms and Protocol Behavior .............. 4
3. Registering Additional Encodings ............................. 6
4. Audio ........................................................ 8
4.1 Encoding-Independent Rules .............................. 8
4.2 Operating Recommendations ............................... 9
4.3 Guidelines for Sample-Based Audio Encodings ............. 10
4.4 Guidelines for Frame-Based Audio Encodings .............. 11
4.5 Audio Encodings ......................................... 12
4.5.1 DVI4 ............................................ 13
4.5.2 G722 ............................................ 14
4.5.3 G723 ............................................ 14
4.5.4 G726-40, G726-32, G726-24, and G726-16 .......... 18
4.5.5 G728 ............................................ 19
4.5.6 G729 ............................................ 20
4.5.7 G729D and G729E ................................. 22
4.5.8 GSM ............................................. 24
4.5.9 GSM-EFR ......................................... 27
4.5.10 L8 .............................................. 27
4.5.11 L16 ............................................. 27
4.5.12 LPC ............................................. 27
4.5.13 MPA ............................................. 28
4.5.14 PCMA and PCMU ................................... 28
4.5.15 QCELP ........................................... 28
4.5.16 RED ............................................. 29
4.5.17 VDVI ............................................ 29
5. Video ........................................................ 30
5.1 CelB .................................................... 30
5.2 JPEG .................................................... 30
5.3 H261 .................................................... 30
5.4 H263 .................................................... 31
5.5 H263-1998 ............................................... 31
5.6 MPV ..................................................... 31
5.7 MP2T .................................................... 31
5.8 nv ...................................................... 32
6. Payload Type Definitions ..................................... 32
7. RTP over TCP and Similar Byte Stream Protocols ............... 34
8. Port Assignment .............................................. 34
9. Changes from RFC 1890 ........................................ 35
10. Security Considerations ...................................... 38
11. IANA Considerations .......................................... 39
12. References ................................................... 39
12.1 Normative References .................................... 39
12.2 Informative References .................................. 39
13. Current Locations of Related Resources ....................... 41
14. Acknowledgments .............................................. 42
15. Intellectual Property Rights Statement ....................... 43
16. Authors' Addresses ........................................... 43
17. Full Copyright Statement ..................................... 44
This profile defines aspects of RTP left unspecified in the RTP Version 2 protocol definition (RFC 3550) [1]. This profile is intended for the use within audio and video conferences with minimal session control. In particular, no support for the negotiation of parameters or membership control is provided. The profile is expected to be useful in sessions where no negotiation or membership control are used (e.g., using the static payload types and the membership indications provided by RTCP), but this profile may also be useful in conjunction with a higher-level control protocol.
このプロファイルは、RTPの態様[1] RTPバージョン2プロトコル定義（RFC 3550）で指定しない定義します。このプロファイルは、最小限のセッション制御と、オーディオおよびビデオ会議内での使用を目的としています。具体的には、パラメータや会員管理の交渉のためのサポートが提供されていません。プロファイルは、（静的ペイロードタイプとRTCPによって提供メンバーシップ指示を使用して、例えば）は、交渉又は会員制御が使用されていないセッションに有用であると期待されるが、このプロファイルは、より高いレベルの制御プロトコルと組み合わせて有用であり得ます。
Use of this profile may be implicit in the use of the appropriate applications; there may be no explicit indication by port number, protocol identifier or the like. Applications such as session directories may use the name for this profile specified in Section 11.
このプロファイルを使用すると、適切なアプリケーションを使用することで暗黙的にであってもよく、ポート番号、プロトコル識別子等によって明示的指示がなくてもよいです。そのようなセッションディレクトリなどのアプリケーションは、セクション11で指定されたこのプロファイルの名前を使用することができます。
Other profiles may make different choices for the items specified here.
他のプロファイルは、ここで指定した項目のための異なった選択を行うことがあります。
This document also defines a set of encodings and payload formats for audio and video. These payload format descriptions are included here only as a matter of convenience since they are too small to warrant separate documents. Use of these payload formats is NOT REQUIRED to use this profile. Only the binding of some of the payload formats to static payload type numbers in Tables 4 and 5 is normative.
この文書では、オーディオとビデオのエンコーディングとペイロードフォーマットのセットを定義します。彼らは別のドキュメントを保証するには小さすぎるため、これらのペイロードフォーマットの説明は便宜上の問題としてここに含まれています。これらのペイロードフォーマットの使用は、このプロファイルを使用する必要はありません。表4における静的ペイロードタイプ番号にペイロードフォーマットのいくつかの結合および5のみが規範です。
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 [2] and indicate requirement levels for implementations compliant with this RTP profile.
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますRFC 2119 [2]で説明し、このRTPプロファイルに準拠した実装の要求レベルを示すものと解釈されます。
This document defines the term media type as dividing encodings of audio and video content into three classes: audio, video and audio/video (interleaved).
オーディオ、ビデオ、およびオーディオ/ビデオ（インターリーブ）：この文書では、3つのクラスにオーディオおよびビデオコンテンツのエンコーディングを分割する用語メディアタイプを定義します。
The section "RTP Profiles and Payload Format Specifications" of RFC 3550 enumerates a number of items that can be specified or modified in a profile. This section addresses these items. Generally, this profile follows the default and/or recommended aspects of the RTP specification.
RFC 3550のセクション「RTPプロファイルとペイロードフォーマットの仕様は、」プロファイルで指定または変更することができるアイテムの数を列挙します。このセクションでは、これらの項目に取り組みます。一般的に、このプロファイルは、デフォルトの次および/またはRTP仕様の側面をお勧めします。
RTP data header: The standard format of the fixed RTP data header is used (one marker bit).
RTPデータヘッダ：固定RTPデータヘッダの標準フォーマットが使用されている（一つのマーカービット）。
Payload types: Static payload types are defined in Section 6.
ペイロードタイプ：静的なペイロードタイプは、セクション6で定義されています。
RTP data header additions: No additional fixed fields are appended to the RTP data header.
RTPデータヘッダの追加：追加の固定フィールドがRTPデータヘッダに付加されています。
RTP data header extensions: No RTP header extensions are defined, but applications operating under this profile MAY use such extensions. Thus, applications SHOULD NOT assume that the RTP header X bit is always zero and SHOULD be prepared to ignore the header extension. If a header extension is defined in the future, that definition MUST specify the contents of the first 16 bits in such a way that multiple different extensions can be identified.
RTPデータヘッダの拡張：いいえRTPヘッダの拡張が定義されていますが、このプロファイルの下で動作するアプリケーションは、このような拡張機能を使用するかもしれません。したがって、アプリケーションは、RTPヘッダのXビットは常にゼロであり、ヘッダ拡張子を無視するように準備されるべきであると仮定すべきではありません。ヘッダ拡張が、将来的に定義されている場合、その定義は、複数の異なる拡張子を識別することができるように、最初の16ビットの内容を指定しなければなりません。
RTCP packet types: No additional RTCP packet types are defined by this profile specification.
RTCPパケットタイプ：追加のRTCPパケットタイプは、このプロファイル仕様で定義されていません。
RTCP report interval: The suggested constants are to be used for the RTCP report interval calculation. Sessions operating under this profile MAY specify a separate parameter for the RTCP traffic bandwidth rather than using the default fraction of the session bandwidth. The RTCP traffic bandwidth MAY be divided into two separate session parameters for those participants which are active data senders and those which are not. Following the recommendation in the RTP specification [1] that 1/4 of the RTCP bandwidth be dedicated to data senders, the RECOMMENDED default values for these two parameters would be 1.25% and 3.75%, respectively. For a particular session, the RTCP bandwidth for non-data-senders MAY be set to zero when operating on unidirectional links or for sessions that don't require feedback on the quality of reception. The RTCP bandwidth for data senders SHOULD be kept non-zero so that sender reports can still be sent for inter-media synchronization and to identify the source by CNAME. The means by which the one or two session parameters for RTCP bandwidth are specified is beyond the scope of this memo.
RTCPのレポート間隔：提案定数はRTCPレポート間隔の計算に使用されるべきです。このプロファイルの下で作動するセッションがRTCPトラフィックの帯域幅ではなく、セッション帯域幅のデフォルトの割合を使用するための別のパラメータを指定するかもしれません。 RTCPトラフィックの帯域幅は、アクティブなデータの送信者とそうでないものであるこれらの参加者のための2つの別々のセッションパラメータに分けることができます。 RTCP帯域幅の1/4がデータ送信者に専用されていることがRTP仕様の推奨[1]以下、これらの2つのパラメータのために推奨されるデフォルト値は、それぞれ、1.25％3.75％となります。単方向リンク上または受信の品質に関するフィードバックを必要としないセッションのために動作しているときに、特定のセッションのために、非データ送信者のためのRTCP帯域幅がゼロに設定されてもよいです。データの送信者のためのRTCP帯域幅は、その送信者のレポートは、まだメディア間同期のために送信することができますし、CNAMEでソースを識別するために、非ゼロので、維持されなければなりません。 RTCP帯域幅の1つのまたは2つのセッションパラメータが指定される手段は、このメモの範囲を超えています。
SR/RR extension: No extension section is defined for the RTCP SR or RR packet.
SR / RR拡張：いいえ延長部分がRTCP SRやRRパケットのために定義されていません。
SDES use: Applications MAY use any of the SDES items described in the RTP specification. While CNAME information MUST be sent every reporting interval, other items SHOULD only be sent every third reporting interval, with NAME sent seven out of eight times within that slot and the remaining SDES items cyclically taking up the eighth slot, as defined in Section 6.2.2 of the RTP specification. In other words, NAME is sent in RTCP packets 1, 4, 7, 10, 13, 16, 19, while, say, EMAIL is used in RTCP packet 22.
SDESは使用：アプリケーションは、RTP仕様で説明SDES項目のいずれかを使用することができます。 CNAME情報は、すべての報告間隔を送信しなければならないが、他のアイテムのみつおき報告間隔を送信されるべきであり、NAMEで8そのスロット内の時間およびセクション6.2で定義されるように周期的に、第スロットを占め、残りのSDESアイテムのうち7を送りました。 RTP仕様の2。換言すれば、NAMEは、RTCPパケットで送信される1、4、7、10、13、16、19、一方、たとえば、電子メールがRTCPパケット22に使用されます。
Security: The RTP default security services are also the default under this profile.
セキュリティ：RTPデフォルトのセキュリティサービスも、このプロファイルの下のデフォルトです。
String-to-key mapping: No mapping is specified by this profile.
文字列からキーへのマッピング：マッピングが、このプロファイルで指定されていません。
Congestion: RTP and this profile may be used in the context of enhanced network service, for example, through Integrated Services (RFC 1633) [4] or Differentiated Services (RFC 2475) [5], or they may be used with best effort service.
混雑：RTPとこのプロファイルは、統合サービスを介して、例えば、強化されたネットワークサービスのコンテキストで使用することができる（RFC 1633）[4]または差別化サービス（RFC 2475）[5]、またはそれらはベストエフォート型サービスで使用することができます。
If enhanced service is being used, RTP receivers SHOULD monitor packet loss to ensure that the service that was requested is actually being delivered. If it is not, then they SHOULD assume that they are receiving best-effort service and behave accordingly.
拡張サービスが使用されている場合は、RTP受信機は、要求されたサービスが実際に配信されていることを保証するために、パケット損失を監視する必要があります。それがない場合、彼らはベストエフォート型のサービスを受けていることを前提とすべきであり、それに応じて動作します。
If best-effort service is being used, RTP receivers SHOULD monitor packet loss to ensure that the packet loss rate is within acceptable parameters. Packet loss is considered acceptable if a TCP flow across the same network path and experiencing the same network conditions would achieve an average throughput, measured on a reasonable timescale, that is not less than the RTP flow is achieving. This condition can be satisfied by implementing congestion control mechanisms to adapt the transmission rate (or the number of layers subscribed for a layered multicast session), or by arranging for a receiver to leave the session if the loss rate is unacceptably high.
ベストエフォート型のサービスが使用されている場合は、RTP受信機は、パケット損失率が許容パラメータの範囲内であることを保証するために、パケット損失を監視する必要があります。 TCPの同じネットワーク・パスを横切る流れと同じネットワーク条件を経験するが、合理的なタイムスケールで測定した平均スループットを達成する場合は、パケット損失が許容されると考えられる、すなわち、RTPフローが達成さ以上です。この条件は、伝送速度（又は層状マルチキャストセッションのために加入層数）を適合させるために、輻輳制御メカニズムを実装することで、または損失率が許容できないほど高い場合にセッションを終了するための受信機のために配置することによって満たすことができます。
The comparison to TCP cannot be specified exactly, but is intended as an "order-of-magnitude" comparison in timescale and throughput. The timescale on which TCP throughput is measured is the round-trip time of the connection. In essence, this requirement states that it is not acceptable to deploy an application (using RTP or any other transport protocol) on the best-effort Internet which consumes bandwidth arbitrarily and does not compete fairly with TCP within an order of magnitude.
TCPとの比較を正確に特定することはできないが、タイムスケールとスループットの「桁違い」の比較として意図されています。 TCPのスループットが測定されているタイムスケールは、接続のラウンドトリップ時間です。本質的には、この要件は、任意の帯域幅を消費し、桁以内TCPと公平に競合しないベストエフォート型のインターネット上（RTPまたは任意の他のトランスポートプロトコルを使用して）アプリケーションをデプロイすることは受け入れられないと述べています。
Underlying protocol: The profile specifies the use of RTP over unicast and multicast UDP as well as TCP. (This does not preclude the use of these definitions when RTP is carried by other lower-layer protocols.)
基本的なプロトコル：プロファイルはユニキャストとマルチキャストUDPだけでなく、TCP上のRTPの使用を指定します。 （これは、RTPは、他の下位層プロトコルによって運ばれるこれらの定義の使用を排除するものではありません。）
Transport mapping: The standard mapping of RTP and RTCP to transport-level addresses is used.
トランスポートマッピング：アドレスレベルの輸送するRTPとRTCPの標準マッピングが使用されています。
Encapsulation: This profile leaves to applications the specification of RTP encapsulation in protocols other than UDP.
カプセル化：このプロファイルは、アプリケーションにUDP以外のプロトコルでRTPのカプセル化の仕様を残します。
This profile lists a set of encodings, each of which is comprised of a particular media data compression or representation plus a payload format for encapsulation within RTP. Some of those payload formats are specified here, while others are specified in separate RFCs. It is expected that additional encodings beyond the set listed here will be created in the future and specified in additional payload format RFCs.
このプロファイルは、特定のメディアデータ圧縮または表現プラスRTP内のカプセル化のためのペイロード・フォーマットで構成されてそれぞれが符号化方式のセットを一覧表示します。他の人が別のRFCで指定されている一方で、それらのペイロードフォーマットのいくつかは、ここで指定されています。ここに記載されたセットを超える追加のエンコーディングは、将来的に作成され、追加のペイロード形式のRFCで指定されることが期待されます。
This profile also assigns to each encoding a short name which MAY be used by higher-level control protocols, such as the Session Description Protocol (SDP), RFC 2327 [6], to identify encodings selected for a particular RTP session.
このプロファイルは、[6]は、特定のRTPセッションのために選択された符号化方式を識別するために、セッション記述プロトコル（SDP）のような、より高いレベルの制御プロトコル、RFC 2327によって使用されるかもしれ短い名前をコードそれぞれに割り当てます。
In some contexts it may be useful to refer to these encodings in the form of a MIME content-type. To facilitate this, RFC 3555 [7] provides registrations for all of the encodings names listed here as MIME subtype names under the "audio" and "video" MIME types through the MIME registration procedure as specified in RFC 2048 [8].
いくつかの状況では、MIMEコンテンツタイプの形でこれらのエンコーディングを参照することが有用であり得ます。これを容易にするために、RFC 3555は、RFC 2048に指定されている[7] MIME登録手続きを通じて「オーディオ」と「映像」MIMEタイプの下MIMEサブタイプ名としてここに記載されているエンコーディング名のすべてのための登録を提供[8]。
Any additional encodings specified for use under this profile (or others) may also be assigned names registered as MIME subtypes with the Internet Assigned Numbers Authority (IANA). This registry provides a means to insure that the names assigned to the additional encodings are kept unique. RFC 3555 specifies the information that is required for the registration of RTP encodings.
任意の追加このプロファイル下での使用のために指定されたエンコーディング（またはその他）も、インターネット割り当て番号機関（IANA）とMIMEサブタイプとして登録名を割り当てることができます。このレジストリは、追加のエンコーディングに割り当てられた名前がユニーク保たれていることを保証するための手段を提供します。 RFC 3555は、RTPエンコーディングの登録に必要な情報を指定します。
In addition to assigning names to encodings, this profile also assigns static RTP payload type numbers to some of them. However, the payload type number space is relatively small and cannot accommodate assignments for all existing and future encodings. During the early stages of RTP development, it was necessary to use statically assigned payload types because no other mechanism had been specified to bind encodings to payload types. It was anticipated that non-RTP means beyond the scope of this memo (such as directory services or invitation protocols) would be specified to establish a dynamic mapping between a payload type and an encoding. Now, mechanisms for defining dynamic payload type bindings have been specified in the Session Description Protocol (SDP) and in other protocols such as ITU-T Recommendation H.323/H.245. These mechanisms associate the registered name of the encoding/payload format, along with any additional required parameters, such as the RTP timestamp clock rate and number of channels, with a payload type number. This association is effective only for the duration of the RTP session in which the dynamic payload type binding is made. This association applies only to the RTP session for which it is made, thus the numbers can be re-used for different encodings in different sessions so the number space limitation is avoided.
エンコーディングに名前を割り当てることに加えて、このプロファイルはまた、それらのいくつかの静的なRTPペイロードタイプ番号を割り当てます。しかし、ペイロードタイプ番号スペースは比較的小さく、すべての既存および将来のエンコーディングの割り当てを受け入れることはできません。 RTP開発の初期段階では、他のメカニズムは、ペイロードタイプへのエンコーディングをバインドするために指定されていなかったので、静的に割り当てられたペイロードタイプを使用する必要がありました。これは、非RTPは、（例えば、ディレクトリサービスまたは招待プロトコルなど）は、このメモの範囲を超えて意味ペイロードタイプと符号化との間の動的マッピングを確立するために指定されるであろうことが予想されました。今、ダイナミックペイロードタイプバインディングを定義するためのメカニズムは、セッション記述プロトコル（SDP）に、そのようなITU-T勧告H.323 / H.245のような他のプロトコルで指定されています。これらの機構は、ペイロードタイプ番号と、そのようなRTPタイムスタンプクロックレートとチャネルの数として任意の追加の必要なパラメータとともに、符号化/ペイロードフォーマットの登録名を関連付けます。この会合は、結合ダイナミックペイロードタイプがなされたRTPセッションの間有効です。この関連付けは番号空間の制限が回避されるので、このようにして番号が異なるセッションで異なるエンコーディングのために再使用することができる、唯一それが作られているRTPセッションに適用されます。
This profile reserves payload type numbers in the range 96-127 exclusively for dynamic assignment. Applications SHOULD first use values in this range for dynamic payload types. Those applications which need to define more than 32 dynamic payload types MAY bind codes below 96, in which case it is RECOMMENDED that unassigned payload type numbers be used first. However, the statically assigned payload types are default bindings and MAY be dynamically bound to new encodings if needed. Redefining payload types below 96 may cause incorrect operation if an attempt is made to join a session without obtaining session description information that defines the dynamic payload types.
動的割り当てのために排他的に96から127の範囲でこのプロファイル準備ペイロードタイプ番号。アプリケーションは、最初のダイナミックペイロードタイプは、この範囲内の値を使用すべきです。 32の以上のダイナミックペイロードタイプを定義する必要がこれらのアプリケーションは、割り当てられていないペイロードタイプ番号を最初に使用することを推奨している場合には96以下のコードを結合することができます。しかし、静的に割り当てられたペイロードタイプは、デフォルトのバインディングであり、必要に応じて動的に新しいエンコーディングに結合させることができます。試みがダイナミックペイロードタイプを定義するセッション記述情報を取得することなく、セッションに参加するために行われた場合96の下方にペイロードタイプを再定義すると、誤動作を引き起こす可能性があります。
Dynamic payload types SHOULD NOT be used without a well-defined mechanism to indicate the mapping. Systems that expect to interoperate with others operating under this profile SHOULD NOT make their own assignments of proprietary encodings to particular, fixed payload types.
ダイナミックペイロードタイプは、マッピングを示すために、明確に定義されたメカニズムなしで使用されるべきではありません。このプロファイルの下で作動する他の人と相互運用することを期待するシステムは特に、固定ペイロードタイプに独自の符号化の独自の割り当てを行うべきではありません。
This specification establishes the policy that no additional static payload types will be assigned beyond the ones defined in this document. Establishing this policy avoids the problem of trying to create a set of criteria for accepting static assignments and encourages the implementation and deployment of the dynamic payload type mechanisms.
この仕様は、追加の静的なペイロードタイプは、この文書で定義されたものを超えて割り当てられませんポリシーを確立します。このポリシーを確立することは、静的な割り当てを受け入れるための基準のセットを作成しようとしているの問題を回避し、ダイナミックなペイロードタイプのメカニズムの実装と展開を奨励しています。
The final set of static payload type assignments is provided in Tables 4 and 5.
静的ペイロードタイプの割り当ての最終セットは、表4及び表5に設けられています。
Since the ability to suppress silence is one of the primary motivations for using packets to transmit voice, the RTP header carries both a sequence number and a timestamp to allow a receiver to distinguish between lost packets and periods of time when no data was transmitted. Discontiguous transmission (silence suppression) MAY be used with any audio payload format. Receivers MUST assume that senders may suppress silence unless this is restricted by signaling specified elsewhere. (Even if the transmitter does not suppress silence, the receiver should be prepared to handle periods when no data is present since packets may be lost.)
沈黙を抑制する能力は、音声を送信するためにパケットを使用するための主要な動機の一つであるので、RTPヘッダは、シーケンス番号とはデータが送信されなかった場合、受信機は、時間の損失パケットと期間とを区別できるように、タイムスタンプの両方を運びます。不連続送信（無音抑制）は、任意のオーディオペイロードフォーマットと共に使用することができます。受信機は、これは他の場所で指定されたシグナル伝達によって制限されない限り、送信者が無音を抑制することができると仮定しなければなりません。 （送信機は沈黙を抑制しない場合でも、受信機は、パケットが失われる可能性があるので、データが存在しない場合の期間を処理するために用意されるべきです。）
Some payload formats (see Sections 4.5.3 and 4.5.6) define a "silence insertion descriptor" or "comfort noise" frame to specify parameters for artificial noise that may be generated during a period of silence to approximate the background noise at the source. For other payload formats, a generic Comfort Noise (CN) payload format is specified in RFC 3389 [9]. When the CN payload format is used with another payload format, different values in the RTP payload type field distinguish comfort-noise packets from those of the selected payload format.
いくつかのペイロード形式（セクション4.5.3および4.5.6を参照）ソースにバックグラウンドノイズを近似するために沈黙の期間に発生することができる人工的なノイズのパラメータを指定するために「無音挿入記述子」または「コンフォートノイズ」フレームを規定。他のペイロード・フォーマットのために、一般的なコンフォートノイズ（CN）ペイロードフォーマットは、RFC 3389で指定されている[9]。 CNペイロードフォーマットを別のペイロードフォーマットと共に使用される場合、RTPペイロードタイプフィールドに異なる値が選択されたペイロード形式のものからコンフォート・ノイズ・パケットを区別する。
For applications which send either no packets or occasional comfort-noise packets during silence, the first packet of a talkspurt, that is, the first packet after a silence period during which packets have not been transmitted contiguously, SHOULD be distinguished by setting the marker bit in the RTP data header to one. The marker bit in all other packets is zero. The beginning of a talkspurt MAY be used to adjust the playout delay to reflect changing network delays. Applications without silence suppression MUST set the marker bit to zero.
沈黙中にないパケットまたは時折快適ノイズパケットいずれかを送信していないアプリケーションのために、ある有音部の第一パケット、パケットが連続的に送信されていない時に無音期間の後の最初のパケットは、マーカービットを設定することによって区別されるべきですいずれかのRTPデータヘッダです。他のすべてのパケットでマーカービットはゼロです。有音部の先頭には、変化するネットワークの遅延を反映するために、プレイアウト遅延を調整するために使用されるかもしれません。無音抑止のないアプリケーションはゼロにマーカービットを設定しなければなりません。
The RTP clock rate used for generating the RTP timestamp is independent of the number of channels and the encoding; it usually equals the number of sampling periods per second. For N-channel encodings, each sampling period (say, 1/8,000 of a second) generates N samples. (This terminology is standard, but somewhat confusing, as the total number of samples generated per second is then the sampling rate times the channel count.)
RTPタイムスタンプを生成するために使用されるRTPクロックレートは、チャンネルの数及び符号化とは無関係です。それは、通常毎秒サンプリング周期の数に等しいです。 Nチャネル符号化のために、各サンプリング周期（例えば、第二の1 / 8,000）は、N個のサンプルを生成します。 （毎秒生成されたサンプルの総数は、その後サンプリングレート回チャンネル数であり、この用語は、標準的な、しかし幾分混乱です。）
If multiple audio channels are used, channels are numbered left-to-right, starting at one. In RTP audio packets, information from lower-numbered channels precedes that from higher-numbered channels.
複数のオーディオチャンネルが使用されている場合は、チャンネルは1から始まり、左から右に番号が付けられています。 RTP音声パケットに、低い番号のチャネルからの情報は、先行するより高い番号のチャネルから。
For more than two channels, the convention followed by the AIFF-C audio interchange format SHOULD be followed [3], using the following notation, unless some other convention is specified for a particular encoding or payload format:
二つ以上のチャネルに対して、AIFF-Cオーディオ交換フォーマットに続く規則に従う必要があり[3]、いくつかの他の規則は、特定の符号化又はペイロードフォーマットのために指定されない限り、以下の表記法を使用して：
l left r right c center S surround F front R rear
Lは、r右CセンターSサラウンドFフロントR、リアの左
channels description channel
1 2 3 4 5 6
_________________________________________________
2 stereo l r
3 l r c
4 l c r S
5 Fl Fr Fc Sl Sr
6 l lc c r rc S
Note: RFC 1890 defined two conventions for the ordering of four audio channels. Since the ordering is indicated implicitly by the number of channels, this was ambiguous. In this revision, the order described as "quadrophonic" has been eliminated to remove the ambiguity. This choice was based on the observation that quadrophonic consumer audio format did not become popular whereas surround-sound subsequently has.
注意：RFC 1890には、4つのオーディオチャンネルの順序付けのために2つの規則を定義しました。順序はチャンネル数によって暗黙的に示されているので、これはあいまいでした。この改正では、「quadrophonic」として記載された順序は、曖昧さを除去するために除去されています。この選択は、サラウンドサウンドがその後持っているのに対し、quadrophonic民生用オーディオ・フォーマットが一般的になっていなかったという観察に基づいていました。
Samples for all channels belonging to a single sampling instant MUST be within the same packet. The interleaving of samples from different channels depends on the encoding. General guidelines are given in Section 4.3 and 4.4.
単一のサンプリングの瞬間に属するすべてのチャンネルのサンプルは、同じパケット内でなければなりません。異なるチャネルからのサンプルのインターリーブは、符号化に依存します。一般的なガイドラインは、セクション4.3および4.4に記載されています。
The sampling frequency SHOULD be drawn from the set: 8,000, 11,025, 16,000, 22,050, 24,000, 32,000, 44,100 and 48,000 Hz. (Older Apple Macintosh computers had a native sample rate of 22,254.54 Hz, which can be converted to 22,050 with acceptable quality by dropping 4 samples in a 20 ms frame.) However, most audio encodings are defined for a more restricted set of sampling frequencies. Receivers SHOULD be prepared to accept multi-channel audio, but MAY choose to only play a single channel.
8,000、11,025、16,000、22,050、24,000、32,000、44,100および48,000ヘルツ：サンプリング周波数セットから引き出されるべきです。 （古いApple Macintoshコンピュータは、20ミリ秒のフレームに4つのサンプルをドロップすることにより、許容可能な品質で22050に変換することができ22,254.54ヘルツのネイティブサンプルレートを、持っていた。）しかし、ほとんどのオーディオエンコーディングは、サンプリング周波数のより制限されたセットのために定義されています。レシーバは、マルチチャンネルオーディオを受け入れるように準備されるべきですが、唯一つのチャンネルを再生することもできます。
The following recommendations are default operating parameters. Applications SHOULD be prepared to handle other values. The ranges given are meant to give guidance to application writers, allowing a set of applications conforming to these guidelines to interoperate without additional negotiation. These guidelines are not intended to restrict operating parameters for applications that can negotiate a set of interoperable parameters, e.g., through a conference control protocol.
次の推奨事項は、デフォルトの動作パラメータです。アプリケーションは、他の値を処理するために準備する必要があります。与えられた範囲は、追加交渉なしで相互運用するために、これらのガイドラインに準拠したアプリケーションのセットが可能、アプリケーション作成者に指導を与えることを意味しています。これらのガイドラインは、会議制御プロトコルを介して、例えば、相互運用可能なパラメータのセットをネゴシエートすることができるアプリケーションのための動作パラメータを制限することを意図していません。
For packetized audio, the default packetization interval SHOULD have a duration of 20 ms or one frame, whichever is longer, unless otherwise noted in Table 1 (column "ms/packet"). The packetization interval determines the minimum end-to-end delay; longer packets introduce less header overhead but higher delay and make packet loss more noticeable. For non-interactive applications such as lectures or for links with severe bandwidth constraints, a higher packetization delay MAY be used. A receiver SHOULD accept packets representing between 0 and 200 ms of audio data. (For framed audio encodings, a receiver SHOULD accept packets with a number of frames equal to 200 ms divided by the frame duration, rounded up.) This restriction allows reasonable buffer sizing for the receiver.
パケット化されたオーディオのために、デフォルトのパケット化間隔は20ミリ秒または他の方法で表1（カラム「MS /パケット」）に記載がない限り、いずれか長い方1つのフレームの持続時間を有するべきです。パケット化インターバルは、最小のエンドツーエンド遅延を決定します。長いパケットは、以下のヘッダのオーバーヘッドが、より高い遅延を導入し、パケットロスがより顕著になります。などの講義として、あるいは深刻な帯域幅の制約とのリンクのための非対話型アプリケーションでは、高いパケット化遅延を使用することができます。受信機は、音声データの0〜200ミリ秒を表すパケットを受け入れるべきです。 （フレーム化オーディオ符号化のために、受信機は、フレーム持続時間で割った200ミリ秒に等しいフレーム数を有するパケットを受け入れる必要があり、切り上げ。）この制限は、合理的なバッファが受信機のためにサイジング可能にします。
In sample-based encodings, each audio sample is represented by a fixed number of bits. Within the compressed audio data, codes for individual samples may span octet boundaries. An RTP audio packet may contain any number of audio samples, subject to the constraint that the number of bits per sample times the number of samples per packet yields an integral octet count. Fractional encodings produce less than one octet per sample.
サンプルベースの符号化では、各オーディオサンプルは固定ビット数で表されます。圧縮オーディオデータ内の、個々のサンプルのためのコードはオクテット境界にまたがることができます。 RTPオーディオパケットは、パケット当たりのサンプルのサンプル時間数当たりのビットの数は、積分オクテットカウントを生じる制約を受けるオーディオサンプルの任意の数を含んでいてもよいです。フラクショナルエンコーディングは、サンプルあたり未満1つのオクテットを作り出します。
The duration of an audio packet is determined by the number of samples in the packet.
オーディオパケットの持続時間は、パケット内のサンプル数によって決定されます。
For sample-based encodings producing one or more octets per sample, samples from different channels sampled at the same sampling instant SHOULD be packed in consecutive octets. For example, for a two-channel encoding, the octet sequence is (left channel, first sample), (right channel, first sample), (left channel, second sample), (right channel, second sample), .... For multi-octet encodings, octets SHOULD be transmitted in network byte order (i.e., most significant octet first).
サンプルあたり一つ以上のオクテットを産生するサンプルベースの符号化のために、同一のサンプリング時点でサンプリングされた異なるチャネルからのサンプルは、連続オクテットに充填されるべきです。例えば、2チャネル符号化、オクテットシーケンスは（左チャンネル、最初のサンプル）、（右チャンネル、最初のサンプル）、（左チャンネル、第二の試料）、（右チャンネル、第二の試料）であり、....マルチオクテットのエンコーディングについては、オクテットは、ネットワークバイトオーダー（すなわち、最も重要なオクテット最初）で送信されるべきである（SHOULD）。
The packing of sample-based encodings producing less than one octet per sample is encoding-specific.
サンプルあたり未満のオクテットを生成するサンプルベースの符号化のパッキングは、エンコーディング固有です。
The RTP timestamp reflects the instant at which the first sample in the packet was sampled, that is, the oldest information in the packet.
RTPタイムスタンプは、パケットの最初のサンプルは、つまり、パケット内の最も古い情報をサンプリングした瞬間を反映しています。
Frame-based encodings encode a fixed-length block of audio into another block of compressed data, typically also of fixed length. For frame-based encodings, the sender MAY choose to combine several such frames into a single RTP packet. The receiver can tell the number of frames contained in an RTP packet, if all the frames have the same length, by dividing the RTP payload length by the audio frame size which is defined as part of the encoding. This does not work when carrying frames of different sizes unless the frame sizes are relatively prime. If not, the frames MUST indicate their size.
フレームベースの符号化は、典型的には固定長の、圧縮されたデータの別のブロックへのオーディオの固定長ブロックを符号化します。フレームベースの符号化のために、送信者は、単一のRTPパケットにいくつかのようなフレームを組み合わせることを選ぶかもしれません。全てのフレームは、符号化の一部として定義されているオーディオフレームサイズによりRTPペイロード長を分割して、同じ長さを有する場合、受信機は、RTPパケットに含まれるフレームの数を伝えることができます。異なるサイズのフレームを運ぶ際に、フレームサイズが互いに素でない限り、これは動作しません。そうでない場合、フレームはそのサイズを指定する必要があります。
For frame-based codecs, the channel order is defined for the whole block. That is, for two-channel audio, right and left samples SHOULD be coded independently, with the encoded frame for the left channel preceding that for the right channel.
フレームベースのコーデックのために、チャネル順序はブロック全体のために定義されています。すなわち、2チャンネルオーディオのため、左右のサンプルを右チャンネル用こと先行左チャンネル用の符号化されたフレームと、独立して符号化されるべきであるています。
All frame-oriented audio codecs SHOULD be able to encode and decode several consecutive frames within a single packet. Since the frame size for the frame-oriented codecs is given, there is no need to use a separate designation for the same encoding, but with different number of frames per packet.
すべてのフレーム指向のオーディオコーデックは、単一のパケット内の複数の連続するフレームを符号化し、復号化することができるべきです。フレーム指向のコーデックのためのフレームのサイズが与えられているので、しかし、パケットあたりのフレーム数が異なる、同じ符号化のために別個の指定を使用する必要はありません。
RTP packets SHALL contain a whole number of frames, with frames inserted according to age within a packet, so that the oldest frame (to be played first) occurs immediately after the RTP packet header. The RTP timestamp reflects the instant at which the first sample in the first frame was sampled, that is, the oldest information in the packet.
（最初に再生される）最も古いフレームが直ちにRTPパケットヘッダの後に発生するようにRTPパケットは、パケット内の年齢に応じて挿入されたフレームと、フレームの全体の数を含まなければなりません。 RTPタイムスタンプは、第1のフレームの最初のサンプルは、つまり、パケット内の最も古い情報をサンプリングした瞬間を反映しています。
name of sampling default
encoding sample/frame bits/sample rate ms/frame ms/packet
__________________________________________________________________
DVI4 sample 4 var. 20
G722 sample 8 16,000 20
G723 frame N/A 8,000 30 30
G726-40 sample 5 8,000 20
G726-32 sample 4 8,000 20
G726-24 sample 3 8,000 20
G726-16 sample 2 8,000 20
G728 frame N/A 8,000 2.5 20
G729 frame N/A 8,000 10 20
G729D frame N/A 8,000 10 20
G729E frame N/A 8,000 10 20
GSM frame N/A 8,000 20 20
GSM-EFR frame N/A 8,000 20 20
L8 sample 8 var. 20
L16 sample 16 var. 20
LPC frame N/A 8,000 20 20
MPA frame N/A var. var.
PCMA sample 8 var. 20
PCMU sample 8 var. 20
QCELP frame N/A 8,000 20 20
VDVI sample var. var. 20
Table 1: Properties of Audio Encodings (N/A: not applicable; var.: variable)
表1：オーディオエンコーディングのプロパティ（N / A：該当なし; VAR：変数）
The characteristics of the audio encodings described in this document are shown in Table 1; they are listed in order of their payload type in Table 4. While most audio codecs are only specified for a fixed sampling rate, some sample-based algorithms (indicated by an entry of "var." in the sampling rate column of Table 1) may be used with different sampling rates, resulting in different coded bit rates. When used with a sampling rate other than that for which a static payload type is defined, non-RTP means beyond the scope of this memo MUST be used to define a dynamic payload type and MUST indicate the selected RTP timestamp clock rate, which is usually the same as the sampling rate for audio.
この文書に記載されたオーディオ符号化の特性を表1に示します。ほとんどのオーディオコーデックのみ固定サンプリング・レートのために指定されているが、それらは表4に、それらのペイロードタイプの順にリストされ、（のエントリによって示される「VAR」表1のサンプリングレートの列に）いくつかのサンプルベースのアルゴリズム異なる符号化ビットレートをもたらす、異なるサンプリングレートで使用することができます。静的ペイロードタイプが定義されているもの以外のサンプリングレートで使用される場合、非RTPは、このメモの範囲を超え手段ダイナミックペイロードタイプを定義するために使用する必要があり、通常、選択されたRTPタイムスタンプクロックレートを、示さなければなりませんオーディオのサンプリングレートと同じ。
DVI4 uses an adaptive delta pulse code modulation (ADPCM) encoding scheme that was specified by the Interactive Multimedia Association (IMA) as the "IMA ADPCM wave type". However, the encoding defined here as DVI4 differs in three respects from the IMA specification:
DVI4は、「IMA ADPCM波型」とインタラクティブ・マルチメディア協会（IMA）によって指定された適応差分パルス符号変調（ADPCM）符号化方式を使用します。しかし、DVI4としてここで定義されたエンコーディングは、IMA仕様の3点で異なります。
o The RTP DVI4 header contains the predicted value rather than the first sample value contained the IMA ADPCM block header.
O RTP DVI4ヘッダは、最初のサンプル値は、IMA ADPCMブロックヘッダを含んでいたのではなく、予測値を含みます。
o IMA ADPCM blocks contain an odd number of samples, since the first sample of a block is contained just in the header (uncompressed), followed by an even number of compressed samples. DVI4 has an even number of compressed samples only, using the `predict' word from the header to decode the first sample.
ブロックの最初のサンプルが圧縮サンプルの偶数続いて、単にヘッダ（圧縮されていない）に含まれているためO IMA ADPCMブロックは、サンプルの奇数を含みます。 DVI4は、最初のサンプルを復号するヘッダから `予測」の単語を使用して、唯一の圧縮サンプルの偶数を有します。
o For DVI4, the 4-bit samples are packed with the first sample in the four most significant bits and the second sample in the four least significant bits. In the IMA ADPCM codec, the samples are packed in the opposite order.
O DVI4ために、4ビットのサンプルは、4つの最上位ビットの最初のサンプルと4つの最下位ビットにおける第二のサンプルで充填されています。 IMA ADPCMコーデックでは、サンプルは逆の順番でパックされています。
Each packet contains a single DVI block. This profile only defines the 4-bit-per-sample version, while IMA also specified a 3-bit-per-sample encoding.
各パケットは、単一のDVIブロックが含まれています。 IMAはまた、3ビットあたりのサンプル符号化を指定しながら、このプロファイルは、4ビットあたりのサンプルバージョンを定義します。
The "header" word for each channel has the following structure:
各チャンネルの「ヘッダ」という単語は、以下の構造を有します。
int16 predict; /* predicted value of first sample
from the previous block (L16 format) */
u_int8 index; /* current index into stepsize table */
u_int8 reserved; /* set to zero by sender, ignored by receiver */
Each octet following the header contains two 4-bit samples, thus the number of samples per packet MUST be even because there is no means to indicate a partially filled last octet.
ヘッダに続く各オクテットは、2つの4ビットサンプル、部分的に充填された最後のオクテットを示すための手段がないので、このように、パケットあたりのサンプルの数は偶数でなければなりませんが含まれています。
Packing of samples for multiple channels is for further study.
複数のチャネルのためのサンプルの包装は、今後の検討課題です。
The IMA ADPCM algorithm was described in the document IMA Recommended Practices for Enhancing Digital Audio Compatibility in Multimedia Systems (version 3.0). However, the Interactive Multimedia Association ceased operations in 1997. Resources for an archived copy of that document and a software implementation of the RTP DVI4 encoding are listed in Section 13.
IMA ADPCMアルゴリズムは、文書に記載されたマルチメディアシステムにおける強化デジタルオーディオ互換（バージョン3.0）のためのIMAの推奨プラクティス。しかし、インタラクティブマルチメディア協会は、その文書およびRTP DVI4エンコーディングのソフトウェア実装のアーカイブされたコピーのために1997年リソースの操作は、セクション13に記載されていなくなりました。
G722 is specified in ITU-T Recommendation G.722, "7 kHz audio-coding within 64 kbit/s". The G.722 encoder produces a stream of octets, each of which SHALL be octet-aligned in an RTP packet. The first bit transmitted in the G.722 octet, which is the most significant bit of the higher sub-band sample, SHALL correspond to the most significant bit of the octet in the RTP packet.
G722 "が7 kHzの64キロビット/秒内のオーディオ符号化"、ITU-T勧告G.722で規定されています。 G.722エンコーダは、RTPパケットにオクテット整列されなければならない各々がオクテットのストリームを生成します。より高いサブバンドサンプルの最上位ビットであるG.722オクテットで送信最初のビットは、RTPパケット内のオクテットの最上位ビットに対応しなければなりません。
Even though the actual sampling rate for G.722 audio is 16,000 Hz, the RTP clock rate for the G722 payload format is 8,000 Hz because that value was erroneously assigned in RFC 1890 and must remain unchanged for backward compatibility. The octet rate or sample-pair rate is 8,000 Hz.
G.722オーディオの実際のサンプリングレートは、16,000ヘルツであっても、その値が誤ってRFC 1890年に割り当てられたとの下位互換性のために不変のままでなければならないので、G722ペイロード形式のためのRTPクロックレートは、8,000ヘルツです。オクテットレートまたはサンプル対速度は8,000ヘルツです。
G723 is specified in ITU Recommendation G.723.1, "Dual-rate speech coder for multimedia communications transmitting at 5.3 and 6.3 kbit/s". The G.723.1 5.3/6.3 kbit/s codec was defined by the ITU-T as a mandatory codec for ITU-T H.324 GSTN videophone terminal applications. The algorithm has a floating point specification in Annex B to G.723.1, a silence compression algorithm in Annex A to G.723.1 and a scalable channel coding scheme for wireless applications in G.723.1 Annex C.
G723は、ITU勧告G.723.1、「5.3及び6.3キロビット/秒で伝送するマルチメディア通信用のデュアルレート音声コーダ」で指定されています。 G.723.1 5.3 / 6.3キロビット/秒コーデックは、ITU-T H.324 GSTNテレビ電話端末のアプリケーションのために必須コーデックとしてITU-Tによって定義されました。アルゴリズムはG.723.1、G.723.1に附属書Aに無音圧縮アルゴリズムとG.723.1附属書Cのワイヤレス・アプリケーションのためのスケーラブルチャンネル符号化方式に附属書Bにおける浮動小数点仕様を有しています
This Recommendation specifies a coded representation that can be used for compressing the speech signal component of multi-media services at a very low bit rate. Audio is encoded in 30 ms frames, with an additional delay of 7.5 ms due to look-ahead. A G.723.1 frame can be one of three sizes: 24 octets (6.3 kb/s frame), 20 octets (5.3 kb/s frame), or 4 octets. These 4-octet frames are called SID frames (Silence Insertion Descriptor) and are used to specify comfort noise parameters. There is no restriction on how 4, 20, and 24 octet frames are intermixed. The least significant two bits of the first octet in the frame determine the frame size and codec type:
この勧告は、非常に低いビットレートでマルチメディア・サービスの音声信号成分を圧縮するために使用することができる符号化表現を指定します。オーディオは、先読みによる7.5ミリ秒の付加的な遅延と、30ミリ秒のフレームで符号化されます。 24個のオクテット（6.3キロバイト/秒フレーム）、20個のオクテット（5.3キロバイト/秒のフレーム）、または4つのオクテット：G.723.1フレームは、三のサイズのいずれかであることができます。これら4オクテットのフレームがSIDフレーム（無音挿入記述子）と呼ばれ、快適雑音パラメータを指定するために使用されます。 4、20、および24オクテットのフレームが混在している方法に制限はありません。フレーム内の最初のオクテットの最下位の2ビットはフレームサイズとコーデックタイプを決定します。
bits content octets/frame
00 high-rate speech (6.3 kb/s) 24
01 low-rate speech (5.3 kb/s) 20
10 SID frame 4
11 reserved
It is possible to switch between the two rates at any 30 ms frame boundary. Both (5.3 kb/s and 6.3 kb/s) rates are a mandatory part of the encoder and decoder. Receivers MUST accept both data rates and MUST accept SID frames unless restriction of these capabilities has been signaled. The MIME registration for G723 in RFC 3555 [7] specifies parameters that MAY be used with MIME or SDP to restrict to a single data rate or to restrict the use of SID frames. This coder was optimized to represent speech with near-toll quality at the above rates using a limited amount of complexity.
任意の30ミリ秒のフレーム境界で2つのレート間で切り替えることが可能です。両方（5.3キロバイト/秒6.3 KB /秒）速度は、エンコーダとデコーダの必須部分です。レシーバは、両方のデータ・レートを受け入れなければならないし、これらの機能の制限が合図されていない限り、SIDフレームを受け入れなければなりません。 RFC 3555におけるG723のためのMIME登録[7]単一データレートに制限するか、SIDフレームの使用を制限するMIMEまたはSDPと共に使用することができるパラメータを指定します。このコーダは、複雑さの限られた量を使用して上記料金に近いトール品質のスピーチを表現するために最適化しました。
The packing of the encoded bit stream into octets and the transmission order of the octets is specified in Rec. G.723.1 and is the same as that produced by the G.723 C code reference implementation. For the 6.3 kb/s data rate, this packing is illustrated as follows, where the header (HDR) bits are always "0 0" as shown in Fig. 1 to indicate operation at 6.3 kb/s, and the Z bit is always set to zero. The diagrams show the bit packing in "network byte order", also known as big-endian order. The bits of each 32-bit word are numbered 0 to 31, with the most significant bit on the left and numbered 0. The octets (bytes) of each word are transmitted most significant octet first. The bits of each data field are numbered in the order of the bit stream representation of the encoding (least significant bit first). The vertical bars indicate the boundaries between field fragments.
オクテットに符号化ビットストリームの充填及びオクテットの送信順序は、撮影に指定されています。 G.723.1とG.723 Cコードリファレンス実装によって生成されたものと同じです。次のように6.3キロバイト/ sのデータレートのために、このパッキングは、ヘッダ（HDR）ビットが1 6.3キロバイト/ sで動作を指示する。常に図2に示すように、「0」であり、そしてZビットが常にある場合、図示されていますゼロに設定します。図は、「ネットワークバイトオーダー」でビットパッキング、また、ビッグエンディアン順序として知られているを示しています。各32ビット・ワードのビットは、左の最上位ビットと、0〜31の番号を付け、各ワードのオクテット（バイト）が最初の最も重要なオクテット送信される0番号が付けられています。各データフィールドのビット（最下位ビット）符号化のビットストリーム表現の順に番号が付けられています。垂直バーは、フィールドの断片間の境界を示しています。
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LPC |HDR| LPC | LPC | ACL0 |LPC| | | | | | | | |0 0 0 0 0 0|0 0|1 1 1 1 0 0 0 0|2 2 1 1 1 1 1 1|0 0 0 0 0 0|2 2| |5 4 3 2 1 0| |3 2 1 0 9 8 7 6|1 0 9 8 7 6 5 4|5 4 3 2 1 0|3 2| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ACL2 |ACL|A| GAIN0 |ACL|ACL| GAIN0 | GAIN1 | | | 1 |C| | 3 | 2 | | | |0 0 0 0 0|0 0|0|0 0 0 0|0 0|0 0|1 1 0 0 0 0 0 0|0 0 0 0 0 0 0 0| |4 3 2 1 0|1 0|6|3 2 1 0|1 0|6 5|1 0 9 8 7 6 5 4|7 6 5 4 3 2 1 0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | GAIN2 | GAIN1 | GAIN2 | GAIN3 | GRID | GAIN3 | | | | | | | | |0 0 0 0|1 1 0 0|1 1 0 0 0 0 0 0|0 0 0 0 0 0 0 0|0 0 0 0|1 1 0 0| |3 2 1 0|1 0 9 8|1 0 9 8 7 6 5 4|7 6 5 4 3 2 1 0|3 2 1 0|1 0 9 8| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MSBPOS |Z|POS| MSBPOS | POS0 |POS| POS0 | | | | 0 | | | 1 | | |0 0 0 0 0 0 0|0|0 0|1 1 1 0 0 0|0 0 0 0 0 0 0 0|0 0|1 1 1 1 1 1| |6 5 4 3 2 1 0| |1 0|2 1 0 9 8 7|9 8 7 6 5 4 3 2|1 0|5 4 3 2 1 0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | POS1 | POS2 | POS1 | POS2 | POS3 | POS2 | | | | | | | | |0 0 0 0 0 0 0 0|0 0 0 0|1 1 1 1|1 1 0 0 0 0 0 0|0 0 0 0|1 1 1 1| |9 8 7 6 5 4 3 2|3 2 1 0|3 2 1 0|1 0 9 8 7 6 5 4|3 2 1 0|5 4 3 2| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | POS3 | PSIG0 |POS|PSIG2| PSIG1 | PSIG3 |PSIG2| | | | 3 | | | | | |1 1 0 0 0 0 0 0|0 0 0 0 0 0|1 1|0 0 0|0 0 0 0 0|0 0 0 0 0|0 0 0| |1 0 9 8 7 6 5 4|5 4 3 2 1 0|3 2|2 1 0|4 3 2 1 0|4 3 2 1 0|5 4 3| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + | LPC | HDR | LPC | LPC | ACL0 | LPC | | | | | | | | | 0 0 0 0 0 0 | 0 | 1 1 1 1 0 0 0 0 | 2 2 1 1 1 1 1 1 | 0 0 0 0 0 0 | 2 2 | | 5 4 3 2 1 0 | | 3 2 1 0 9 8 7 6 | 1 0 9 8 7 6 5 4 | 5 4 3 2 1 0 | 3 2 | + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + | ACL2 | ACL | A | GAIN0 | ACL | ACL | GAIN0 | GAIN1 | | | 1 | C | | 3 | 2 | | | | 0 0 0 0 0 | 0 | 0 | 0 0 0 0 | 0 0 | 0 0 | 1 1 0 0 0 0 0 0 | 0 0 0 0 0 0 0 0 | | 4 3 2 1 0 | 1 0 | 6 | 3 2 1 0 | 1 0 | 6 5 | 1 0 9 8 7 6 5 4 | 7 6 5 4 3 2 1 0 | + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + | GAIN2 | GAIN1 | GAIN2 | GAIN3 | GRID | GAIN3 | | | | | | | | | 0 0 0 0 | 1 1 0 0 | 1 1 0 0 0 0 0 0 | 0 0 0 0 0 0 0 0 | 0 0 0 0 | 1 1 0 0 | | 3 2 1 0 | 1 0 9 8 | 1 0 9 8 7 6 5 4 | 7 6 5 4 3 2 1 0 | 3 2 1 0 | 1 0 9 8 | + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + | MSBPOS | Z | POS | MSBPOS | POS0 | POS | POS0 | | | | 0 | | | 1 | | | 0 0 0 0 0 0 0 | 0 | 0 | 1 1 1 0 0 0 | 0 0 0 0 0 0 0 0 | 0 0 | 1 1 1 1 1 1 | | 6 5 4 3 2 1 0 | | 1 0 | 2 1 0 9 8 7 | 9 8 7 6 5 4 3 2 | 1 0 | 5 4 3 2 1 0 | + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + | POS1 | POS2 | POS1 | POS2 | POS3 | POS2 | | | | | | | | | 0 0 0 0 0 0 0 0 | 0 0 0 0 | 1 1 1 1 | 1 1 0 0 0 0 0 0 | 0 0 0 0 | 1 1 1 1 | | 9 8 7 6 5 4 3 2 | 3 2 1 0 | 3 2 1 0 | 1 0 9 8 7 6 5 4 | 3 2 1 0 | 5 4 3 2 | + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + | POS3 | PSIG0 | POS | PSIG2 | PSIG1 | PSIG3 | PSIG2 | | | | 3 | | | | | | 1 1 0 0 0 0 0 0 | 0 0 0 0 0 0 | 1 | 0 0 0 | 0 0 0 0 0 | 0 0 0 0 0 | 0 0 0 | | 1 0 9 8 7 6 5 4 | 5 4 3 2 1 0 | 3 2 | 2 1 0 | 4 3 2 1 0 | 4 3 2 1 0 | 5 4 3 | + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
Figure 1: G.723 (6.3 kb/s) bit packing
図1：G.723（6.3キロバイト/秒）ビットパッキング
For the 5.3 kb/s data rate, the header (HDR) bits are always "0 1", as shown in Fig. 2, to indicate operation at 5.3 kb/s.
/ sの5.3キロバイトでの動作を示すために、図2に示すように、5.3キロバイト/ sのデータレートのために、ヘッダ（HDR）ビットは、常に「0 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LPC |HDR| LPC | LPC | ACL0 |LPC| | | | | | | | |0 0 0 0 0 0|0 1|1 1 1 1 0 0 0 0|2 2 1 1 1 1 1 1|0 0 0 0 0 0|2 2| |5 4 3 2 1 0| |3 2 1 0 9 8 7 6|1 0 9 8 7 6 5 4|5 4 3 2 1 0|3 2| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ACL2 |ACL|A| GAIN0 |ACL|ACL| GAIN0 | GAIN1 | | | 1 |C| | 3 | 2 | | | |0 0 0 0 0|0 0|0|0 0 0 0|0 0|0 0|1 1 0 0 0 0 0 0|0 0 0 0 0 0 0 0| |4 3 2 1 0|1 0|6|3 2 1 0|1 0|6 5|1 0 9 8 7 6 5 4|7 6 5 4 3 2 1 0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | GAIN2 | GAIN1 | GAIN2 | GAIN3 | GRID | GAIN3 | | | | | | | | |0 0 0 0|1 1 0 0|1 1 0 0 0 0 0 0|0 0 0 0 0 0 0 0|0 0 0 0|1 1 0 0| |3 2 1 0|1 0 9 8|1 0 9 8 7 6 5 4|7 6 5 4 3 2 1 0|4 3 2 1|1 0 9 8| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | POS0 | POS1 | POS0 | POS1 | POS2 | | | | | | | |0 0 0 0 0 0 0 0|0 0 0 0|1 1 0 0|1 1 0 0 0 0 0 0|0 0 0 0 0 0 0 0| |7 6 5 4 3 2 1 0|3 2 1 0|1 0 9 8|1 0 9 8 7 6 5 4|7 6 5 4 3 2 1 0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | POS3 | POS2 | POS3 | PSIG1 | PSIG0 | PSIG3 | PSIG2 | | | | | | | | | |0 0 0 0|1 1 0 0|1 1 0 0 0 0 0 0|0 0 0 0|0 0 0 0|0 0 0 0|0 0 0 0| |3 2 1 0|1 0 9 8|1 0 9 8 7 6 5 4|3 2 1 0|3 2 1 0|3 2 1 0|3 2 1 0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + | LPC | HDR | LPC | LPC | ACL0 | LPC | | | | | | | | | 0 0 0 0 0 0 | 0 1 | 1 1 1 1 0 0 0 0 | 2 2 1 1 1 1 1 1 | 0 0 0 0 0 0 | 2 2 | | 5 4 3 2 1 0 | | 3 2 1 0 9 8 7 6 | 1 0 9 8 7 6 5 4 | 5 4 3 2 1 0 | 3 2 | + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + | ACL2 | ACL | A | GAIN0 | ACL | ACL | GAIN0 | GAIN1 | | | 1 | C | | 3 | 2 | | | | 0 0 0 0 0 | 0 | 0 | 0 0 0 0 | 0 0 | 0 0 | 1 1 0 0 0 0 0 0 | 0 0 0 0 0 0 0 0 | | 4 3 2 1 0 | 1 0 | 6 | 3 2 1 0 | 1 0 | 6 5 | 1 0 9 8 7 6 5 4 | 7 6 5 4 3 2 1 0 | + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + | GAIN2 | GAIN1 | GAIN2 | GAIN3 | GRID | GAIN3 | | | | | | | | | 0 0 0 0 | 1 1 0 0 | 1 1 0 0 0 0 0 0 | 0 0 0 0 0 0 0 0 | 0 0 0 0 | 1 1 0 0 | | 3 2 1 0 | 1 0 9 8 | 1 0 9 8 7 6 5 4 | 7 6 5 4 3 2 1 0 | 4 3 2 1 | 1 0 9 8 | + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + | POS0 | POS1 | POS0 | POS1 | POS2 | | | | | | | | 0 0 0 0 0 0 0 0 | 0 0 0 0 | 1 1 0 0 | 1 1 0 0 0 0 0 0 | 0 0 0 0 0 0 0 0 | | 7 6 5 4 3 2 1 0 | 3 2 1 0 | 1 0 9 8 | 1 0 9 8 7 6 5 4 | 7 6 5 4 3 2 1 0 | + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + | POS3 | POS2 | POS3 | PSIG1 | PSIG0 | PSIG3 | PSIG2 | | | | | | | | | | 0 0 0 0 | 1 1 0 0 | 1 1 0 0 0 0 0 0 | 0 0 0 0 | 0 0 0 0 | 0 0 0 0 | 0 0 0 0 | | 3 2 1 0 | 1 0 9 8 | 1 0 9 8 7 6 5 4 | 3 2 1 0 | 3 2 1 0 | 3 2 1 0 | 3 2 1 0 | + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
Figure 2: G.723 (5.3 kb/s) bit packing
図2：G.723（5.3キロバイト/秒）ビットパッキング
The packing of G.723.1 SID (silence) frames, which are indicated by the header (HDR) bits having the pattern "1 0", is depicted in Fig. 3.
パターン「1 0」を有するヘッダ（HDR）ビットによって示されるG.723.1 SID（無音）フレームのパッキングは、図2に示されている。3。
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LPC |HDR| LPC | LPC | GAIN |LPC| | | | | | | | |0 0 0 0 0 0|1 0|1 1 1 1 0 0 0 0|2 2 1 1 1 1 1 1|0 0 0 0 0 0|2 2| |5 4 3 2 1 0| |3 2 1 0 9 8 7 6|1 0 9 8 7 6 5 4|5 4 3 2 1 0|3 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 + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + | LPC | HDR | LPC | LPC | GAIN | LPC | | | | | | | | | 0 0 0 0 0 0 | 1 0 | 1 1 1 1 0 0 0 0 | 2 2 1 1 1 1 1 1 | 0 0 0 0 0 0 | 2 2 | | 5 4 3 2 1 0 | | 3 2 1 0 9 8 7 6 | 1 0 9 8 7 6 5 4 | 5 4 3 2 1 0 | 3 2 | + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
Figure 3: G.723 SID mode bit packing
図3：G.723 SIDモードビットパッキング
ITU-T Recommendation G.726 describes, among others, the algorithm recommended for conversion of a single 64 kbit/s A-law or mu-law PCM channel encoded at 8,000 samples/sec to and from a 40, 32, 24, or 16 kbit/s channel. The conversion is applied to the PCM stream using an Adaptive Differential Pulse Code Modulation (ADPCM) transcoding technique. The ADPCM representation consists of a series of codewords with a one-to-one correspondence to the samples in the PCM stream. The G726 data rates of 40, 32, 24, and 16 kbit/s have codewords of 5, 4, 3, and 2 bits, respectively.
ITU-T勧告G.726は、とりわけ、およびから40、32、24、または8,000サンプル/秒で符号化された単一の64キロビット/秒のA-lawまたはμ則PCMチャンネルの変換のために推奨されるアルゴリズムを説明します16キロビット/秒のチャンネル。変換は、適応差分パルス符号変調（ADPCM）トランスコーディング技術を用いてPCMストリームに適用されます。 ADPCM表現はPCMストリーム内のサンプルに1対1の対応を有する符号語の系列から成ります。 40、32、24、16キロビットのG726データレート/ Sは、それぞれ、5、4、3、2ビットのコードワードを有しています。
The 16 and 24 kbit/s encodings do not provide toll quality speech. They are designed for used in overloaded Digital Circuit Multiplication Equipment (DCME). ITU-T G.726 recommends that the 16 and 24 kbit/s encodings should be alternated with higher data rate encodings to provide an average sample size of between 3.5 and 3.7 bits per sample.
16および24キロビット/秒のエンコーディングは、トール品質な音声を提供していません。オーバーロードされたデジタル回路の乗算装置（DCME）で使用するために彼らは設計されています。 ITU-T G.726は、16と24キロビット/秒のエンコーディングは、サンプルあたり3.5〜3.7ビットの平均サンプルサイズを提供するために、より高いデータレートエンコーディングと交互にされるべきであることをお勧めします。
The encodings of G.726 are here denoted as G726-40, G726-32, G726-24, and G726-16. Prior to 1990, G721 described the 32 kbit/s ADPCM encoding, and G723 described the 40, 32, and 16 kbit/s encodings. Thus, G726-32 designates the same algorithm as G721 in RFC 1890.
G.726の符号化方式は、ここでG726-40、G726-32、G726-24、およびG726-16と表記されています。 1990年前に、G721は32キロビット/秒のADPCM符号化を説明し、そしてG723は40、32、16キロビット/秒のエンコーディングを記述しました。したがって、G726-32は、RFC 1890年G721と同じアルゴリズムを指定します。
A stream of G726 codewords contains no information on the encoding being used, therefore transitions between G726 encoding types are not permitted within a sequence of packed codewords. Applications MUST determine the encoding type of packed codewords from the RTP payload identifier.
G726コードワードのストリームは、従って、使用される符号化に関する情報が含まれていないパックされたコードワードの配列内に許可されていないG726の符号化タイプとの間で遷移します。アプリケーションは、RTPペイロード識別子から充填コードワードの符号化タイプを決定しなければなりません。
No payload-specific header information SHALL be included as part of the audio data. A stream of G726 codewords MUST be packed into octets as follows: the first codeword is placed into the first octet such that the least significant bit of the codeword aligns with the least significant bit in the octet, the second codeword is then packed so that its least significant bit coincides with the least significant unoccupied bit in the octet. When a complete codeword cannot be placed into an octet, the bits overlapping the octet boundary are placed into the least significant bits of the next octet. Packing MUST end with a completely packed final octet. The number of codewords packed will therefore be a multiple of 8, 2, 8, and 4 for G726-40, G726-32, G726-24, and G726-16, respectively. An example of the packing scheme for G726-32 codewords is as shown, where bit 7 is the least significant bit of the first octet, and bit A3 is the least significant bit of the first codeword:
いいえペイロード特有のヘッダ情報は、オーディオデータの一部として含まれてはなりません。次のようにG726コードワードのストリームは、オクテットに詰め込まなければならない：最初のコードワードは、コードワードの最下位ビットがオクテットの最下位ビットと整列するように最初のオクテットの中に配置され、そのように、第2の符号語は、次いで、充填されています最下位ビットは、オクテットの最下位空きビットと一致します。完全なコードワードはオクテット内に配置することができない場合、オクテット境界を重複ビットは、次のオクテットの最下位ビットに配置されます。梱包は完全に詰まっ最終オクテットで終わらなければなりません。パックされたコードワードの数は、従って、それぞれ、G726-40、G726-32、G726-24、およびG726-16 8の倍数、2,8、および4です。 G726-32符号語のパッキング方式の一例を示すようにビット7が最初のオクテットの最下位ビットであり、であり、A3は、最初のコードワードの最下位ビットであるビット。
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
|B B B B|A A A A|D D D D|C C C C| ...
|0 1 2 3|0 1 2 3|0 1 2 3|0 1 2 3|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
An example of the packing scheme for G726-24 codewords follows, where again bit 7 is the least significant bit of the first octet, and bit A2 is the least significant bit of the first codeword:
再び図7は、最初のオクテットの最下位ビット、ビット、ビットA2は、最初のコードワードの最下位ビットであるG726-24符号語のパッキング方式の一例は、以下：
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
|C C|B B B|A A A|F|E E E|D D D|C|H H H|G G G|F F| ...
|1 2|0 1 2|0 1 2|2|0 1 2|0 1 2|0|0 1 2|0 1 2|0 1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Note that the "little-endian" direction in which samples are packed into octets in the G726-16, -24, -32 and -40 payload formats specified here is consistent with ITU-T Recommendation X.420, but is the opposite of what is specified in ITU-T Recommendation I.366.2 Annex E for ATM AAL2 transport. A second set of RTP payload formats matching the packetization of I.366.2 Annex E and identified by MIME subtypes AAL2-G726-16, -24, -32 and -40 will be specified in a separate document.
ここで指定されたサンプルはG726-16、-24のオクテットにパックされた「リトルエンディアン」方向、-32および-40ペイロードフォーマットはITU-T勧告X.420と一致しているが、の反対であることに注意してください何がATM AAL2輸送のためのITU-T勧告I.366.2の附属書Eに指定されています。 RTPペイロードフォーマットの第2のセットはI.366.2付属書Eのパケットを照合し、MIMEによって識別AAL2-G726-16、-24を、サブタイプ-32および-40は、別の文書で指定されるであろう。
G728 is specified in ITU-T Recommendation G.728, "Coding of speech at 16 kbit/s using low-delay code excited linear prediction".
G728「は16キロビットにおける音声の符号化/低遅延符号励起線形予測を用いてS」、ITU-T勧告G.728で規定されています。
A G.278 encoder translates 5 consecutive audio samples into a 10-bit codebook index, resulting in a bit rate of 16 kb/s for audio sampled at 8,000 samples per second. The group of five consecutive samples is called a vector. Four consecutive vectors, labeled V1 to V4 (where V1 is to be played first by the receiver), build one G.728 frame. The four vectors of 40 bits are packed into 5 octets, labeled B1 through B5. B1 SHALL be placed first in the RTP packet.
G.278エンコーダは、毎秒8,000サンプルでサンプリングされたオーディオの場合は16 KB / sのビットレートで、その結果、10ビットのコードブックインデックスに連続5個のオーディオサンプルを変換します。 5つの連続したサンプルのグループは、ベクトルと呼ばれています。 （V1は、受信機によって最初に再生される）V4にV1を標識した4つの連続するベクトルは、1つのG.728フレームを構築します。 40ビットの4つのベクトルは、B5を介して5つのオクテット、標識B1に充填されています。 B1は、RTPパケットの最初置きます。
Referring to the figure below, the principle for bit order is "maintenance of bit significance". Bits from an older vector are more significant than bits from newer vectors. The MSB of the frame goes to the MSB of B1 and the LSB of the frame goes to LSB of B5.
下の図を参照すると、ビット順序のための原則は、「ビット意義のメンテナンス」です。古いベクトルからのビットは、新しいベクトルからのビットよりも重要です。フレームのMSBはB1のMSBになり、LSBフレームのLSB B5のに行きます。
1 2 3 3
0 0 0 0 9
++++++++++++++++++++++++++++++++++++++++
<---V1---><---V2---><---V3---><---V4---> vectors
<--B1--><--B2--><--B3--><--B4--><--B5--> octets
<------------- frame 1 ---------------->
In particular, B1 contains the eight most significant bits of V1, with the MSB of V1 being the MSB of B1. B2 contains the two least significant bits of V1, the more significant of the two in its MSB, and the six most significant bits of V2. B1 SHALL be placed first in the RTP packet and B5 last.
特に、B1は、V1のMSBは、B1のMSBであると、V1の上位8ビットを含みます。 B2はV1の2つの最下位ビット、MSBその中の2つのより重要な、及びV2の上位6ビットを含みます。 B1は、RTPパケットとB5の最後に最初に設置しなければなりません。
G729 is specified in ITU-T Recommendation G.729, "Coding of speech at 8 kbit/s using conjugate structure-algebraic code excited linear prediction (CS-ACELP)". A reduced-complexity version of the G.729 algorithm is specified in Annex A to Rec. G.729. The speech coding algorithms in the main body of G.729 and in G.729 Annex A are fully interoperable with each other, so there is no need to further distinguish between them. An implementation that signals or accepts use of G729 payload format may implement either G.729 or G.729A unless restricted by additional signaling specified elsewhere related specifically to the encoding rather than the payload format. The G.729 and G.729 Annex A codecs were optimized to represent speech with high quality, where G.729 Annex A trades some speech quality for an approximate 50% complexity reduction [10]. See the next Section (4.5.7) for other data rates added in later G.729 Annexes. For all data rates, the sampling frequency (and RTP timestamp clock rate) is 8,000 Hz.
G729は、ITU-T勧告G.729で指定された「8キロビットでの音声の符号化/共役構造代数符号励振線形予測（CS-ACELP）を使用してS」。 G.729アルゴリズムの低減複雑バージョンが撮影に附属書Aに指定されています。 G.729。 G.729の本体およびG.729付属文書Aのアルゴリズム音声符号化は、互いに完全に相互運用可能であるので、さらにそれらを区別する必要はありません。他の場所で指定されたエンコーディングではなくペイロードフォーマットに特異的に関連する追加のシグナリングによって制限されない限り信号またはG729ペイロードフォーマットの使用を受け付ける実装では、G.729またはG.729Aのいずれかを実施することができます。 G.729およびG.729付属書AコーデックがG.729付属書Aは、約50％の複雑度の減少[10]のためのいくつかの音声品質を取引高品質で音声を表現するために最適化しました。 729附属書以降で追加されるその他のデータレートは、次のセクション（4.5.7）を参照してください。すべてのデータレートのために、サンプリング周波数（及びRTPタイムスタンプのクロックレート）が8,000ヘルツです。
A voice activity detector (VAD) and comfort noise generator (CNG) algorithm in Annex B of G.729 is RECOMMENDED for digital simultaneous voice and data applications and can be used in conjunction with G.729 or G.729 Annex A. A G.729 or G.729 Annex A frame contains 10 octets, while the G.729 Annex B comfort noise frame occupies 2 octets. Receivers MUST accept comfort noise frames if restriction of their use has not been signaled. The MIME registration for G729 in RFC 3555 [7] specifies a parameter that MAY be used with MIME or SDP to restrict the use of comfort noise frames.
G.729の付属書Bで音声アクティビティ検出器（VAD）およびコンフォート・ノイズ発生器（CNG）アルゴリズムは、デジタル同時音声およびデータアプリケーション用に推奨されており、G.729又はG.729付属書A. A Gと一緒に使用することができます729付属書B快適雑音フレームは2つのオクテットを占有しながら0.729又はG.729アネックスフレームは、10個のオクテットを含んでいます。これらの使用の制限が通知されていない場合、受信機は快適雑音フレームを受け入れなければなりません。 RFC 3555におけるG729のためのMIME登録[7]快適雑音フレームの使用を制限するMIMEまたはSDPと共に使用することができるパラメータを指定します。
A G729 RTP packet may consist of zero or more G.729 or G.729 Annex A frames, followed by zero or one G.729 Annex B frames. The presence of a comfort noise frame can be deduced from the length of the RTP payload. The default packetization interval is 20 ms (two frames), but in some situations it may be desirable to send 10 ms packets. An example would be a transition from speech to comfort noise in the first 10 ms of the packet. For some applications, a longer packetization interval may be required to reduce the packet rate.
G729 RTPパケットは、ゼロまたは1 G.729付録Bフレームに続くゼロ以上G.729又はG.729付属書Aフレーム、から構成されてもよいです。快適雑音フレームの存在は、RTPペイロードの長さから推定することができます。デフォルトのパケット化間隔は20ミリ秒（2つのフレーム）であるが、いくつかの状況では、10ミリ秒のパケットを送信することが望ましい場合があります。例では、パケットの最初の10ミリ秒でノイズを慰めるための音声からの遷移であろう。一部のアプリケーションでは、長いパケット間隔はパケットレートを減らすために必要な場合があります。
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |L| L1 | L2 | L3 | P1 |P| C1 | |0| | | | |0| | | |0 1 2 3 4 5 6|0 1 2 3 4|0 1 2 3 4|0 1 2 3 4 5 6 7| |0 1 2 3 4| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | C1 | S1 | GA1 | GB1 | P2 | C2 | | 1 1 1| | | | | | |5 6 7 8 9 0 1 2|0 1 2 3|0 1 2|0 1 2 3|0 1 2 3 4|0 1 2 3 4 5 6 7| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | C2 | S2 | GA2 | GB2 | | 1 1 1| | | | |8 9 0 1 2|0 1 2 3|0 1 2|0 1 2 3| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 + - + - + - + - + - + - - + + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - - + | L | L1 | L2 | L3 | P1 | P | C1 | | 0 | | | | | 0 | | | | 0 1 2 3 4 5 6 | 0 1 2 3 4 | 0 1 2 3 4 | 0 1 2 3 4 5 6 7 | | 0 1 2 3 4 | + + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - - + - + - + - + - + - + - + - + | C1 | S1 | GA1 | GB1 | P2 | C2 | | 1 1 1 | | | | | | | 5 6 7 8 9 0 1 2 | 0 1 2 3 | 0 1 2 | 0 1 2 3 | 0 1 2 3 4 | 0 1 2 3 4 5 6 7 | + + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - - + - + - + - + - + - + - + - + | C2 | S2 | GA2 | GB2 | | 1 1 1 | | | | | 8 9 0 1 2 | 0 1 2 3 | 0 1 2 | 0 1 2 3 | + + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + -
Figure 4: G.729 and G.729A bit packing
図4：G.729とG.729Aビットパッキング
The transmitted parameters of a G.729/G.729A 10-ms frame, consisting of 80 bits, are defined in Recommendation G.729, Table 8/G.729. The mapping of the these parameters is given below in Fig. 4. The diagrams show the bit packing in "network byte order", also known as big-endian order. The bits of each 32-bit word are numbered 0 to 31, with the most significant bit on the left and numbered 0. The octets (bytes) of each word are transmitted most significant octet first. The bits of each data field are numbered in the order as produced by the G.729 C code reference implementation.
G.729 / G.729Aの10msフレームの送信パラメータは、80ビットからなる、勧告G.729、表8 / G.729で定義されています。これらのパラメータのマッピングを図の下に与えられている。4.図は、「ネットワークバイト順序」に充填ビット、ビッグエンディアン順として知らを示します。各32ビット・ワードのビットは、左の最上位ビットと、0〜31の番号を付け、各ワードのオクテット（バイト）が最初の最も重要なオクテット送信される0番号が付けられています。 G.729 Cコードリファレンス実装によって生成される各データフィールドのビットが順に番号が付けられています。
The packing of the G.729 Annex B comfort noise frame is shown in Fig. 5.
729付属書Bの快適雑音フレームのパッキングは、図5に示されています。
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|L| LSF1 | LSF2 | GAIN |R|
|S| | | |E|
|F| | | |S|
|0|0 1 2 3 4|0 1 2 3|0 1 2 3 4|V| RESV = Reserved (zero)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: G.729 Annex B bit packing
図5：G.729附属書Bのビットパッキング
Annexes D and E to ITU-T Recommendation G.729 provide additional data rates. Because the data rate is not signaled in the bitstream, the different data rates are given distinct RTP encoding names which are mapped to distinct payload type numbers. G729D indicates a 6.4 kbit/s coding mode (G.729 Annex D, for momentary reduction in channel capacity), while G729E indicates an 11.8 kbit/s mode (G.729 Annex E, for improved performance with a wide range of narrow-band input signals, e.g., music and background noise). Annex E has two operating modes, backward adaptive and forward adaptive, which are signaled by the first two bits in each frame (the most significant two bits of the first octet).
ITU-T勧告G.729に附属書D及びEは、追加のデータレートを提供します。データレートは、ビットストリームにおいてシグナリングされていないため、異なるデータレートは異なるペイロードタイプ番号にマッピングされる別個のRTPエンコーディング名を与えられています。 G729Eは狭の広い範囲で改善された性能のために、11.8キロビット/秒モード（G.729付属書Eを示しているG729Dは、（チャネル容量の瞬間的還元のためのG.729付属書D）6.4キロビット/ sの符号化モードを示しますバンドの入力信号、例えば、音楽、バックグラウンドノイズ）。附属書Eは、各フレームの最初の2ビット（最初のオクテットの最上位2ビット）によってシグナリングされる2つの動作モード、後方適応フォワード適応を有しています。
The voice activity detector (VAD) and comfort noise generator (CNG) algorithm specified in Annex B of G.729 may be used with Annex D and Annex E frames in addition to G.729 and G.729 Annex A frames. The algorithm details for the operation of Annexes D and E with the Annex B CNG are specified in G.729 Annexes F and G. Note that Annexes F and G do not introduce any new encodings. Receivers MUST accept comfort noise frames if restriction of their use has not been signaled. The MIME registrations for G729D and G729E in RFC 3555 [7] specify a parameter that MAY be used with MIME or SDP to restrict the use of comfort noise frames.
G.729の付属書Bで指定された音声アクティビティ検出器（VAD）と快適ノイズ発生（CNG）アルゴリズムはG.729およびG.729付属書Aフレームに加えて、付属書D及び附属書Eフレームと共に使用することができます。付属書B CNGと附属書D及びEの動作のアルゴリズムの詳細はG.729付属書FとFとGは、任意の新しいエンコーディングを導入しない附属書G.ノートに指定されています。これらの使用の制限が通知されていない場合、受信機は快適雑音フレームを受け入れなければなりません。 RFC 3555にG729DとG729EのMIME登録[7]快適雑音フレームの使用を制限するMIMEまたはSDPと共に使用することができるパラメータを指定します。
For G729D, an RTP packet may consist of zero or more G.729 Annex D frames, followed by zero or one G.729 Annex B frame. Similarly, for G729E, an RTP packet may consist of zero or more G.729 Annex E frames, followed by zero or one G.729 Annex B frame. The presence of a comfort noise frame can be deduced from the length of the RTP payload.
G729Dため、RTPパケットは、ゼロまたは1 G.729の付属書Bフレームに続くゼロ以上G.729付属書Dフレーム、から構成されてもよいです。同様に、G729Eため、RTPパケットは、ゼロまたは1 G.729の付属書Bフレームに続くゼロ以上G.729付属書Eフレーム、から構成されてもよいです。快適雑音フレームの存在は、RTPペイロードの長さから推定することができます。
A single RTP packet must contain frames of only one data rate, optionally followed by one comfort noise frame. The data rate may be changed from packet to packet by changing the payload type number. G.729 Annexes D, E and H describe what the encoding and decoding algorithms must do to accommodate a change in data rate.
単一のRTPパケットは、必要に応じて1つの快適雑音フレームに続く一つだけのデータレートのフレームを含んでいなければなりません。データレートは、ペイロードタイプ番号を変更することにより、パケットにパケットから変更してもよいです。 729附属書D、E及びHは、符号化及び復号化アルゴリズムは、データレートの変化に適応するようにしなければならないものを記載しています。
For G729D, the bits of a G.729 Annex D frame are formatted as shown below in Fig. 6 (cf. Table D.1/G.729). The frame length is 64 bits.
図1に、以下に示すようG729Dため、G.729付属書Dフレームのビットは、フォーマットされています。6（参照表D.1 / G.729）。フレーム長が64ビットです。
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |L| L1 | L2 | L3 | P1 | C1 | |0| | | | | | | |0 1 2 3 4 5 6|0 1 2 3 4|0 1 2 3 4|0 1 2 3 4 5 6 7|0 1 2 3 4 5| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | C1 |S1 | GA1 | GB1 | P2 | C2 |S2 | GA2 | GB2 | | | | | | | | | | | |6 7 8|0 1|0 1 2|0 1 2|0 1 2 3|0 1 2 3 4 5 6 7 8|0 1|0 1 2|0 1 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 + - + - + - + - + - + - - + + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - - + | L | L1 | L2 | L3 | P1 | C1 | | 0 | | | | | | | | 0 1 2 3 4 5 6 | 0 1 2 3 4 | 0 1 2 3 4 | 0 1 2 3 4 5 6 7 | 0 1 2 3 4 5 | + + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - - + - + - + - + - + - + - + - + | C1 | S1 | GA1 | GB1 | P2 | C2 | S2 | GA2 | GB2 | | | | | | | | | | | | 6 7 8 | 0 1 | 0 1 2 | 0 1 2 | 0 1 2 3 | 0 1 2 3 4 5 6 7 8 | 0 1 | 0 1 2 | 0 1 2 | + + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - - + + - + - + - + - + - + - + -
Figure 6: G.729 Annex D bit packing
図6：G.729付属書Dビットパッキング
The net bit rate for the G.729 Annex E algorithm is 11.8 kbit/s and a total of 118 bits are used. Two bits are appended as "don't care" bits to complete an integer number of octets for the frame. For G729E, the bits of a data frame are formatted as shown in the next two diagrams (cf. Table E.1/G.729). The fields for the G729E forward adaptive mode are packed as shown in Fig. 7.
G.729付属書Eアルゴリズムの正味ビットレートは11.8キロビット/秒であり、118ビットの合計が使用されます。 2つのビットは、フレームのオクテットの整数を完了するために「気にしない」ビットとして付加されます。次の2つの図（参照表E.1 / G.729）に示すようにG729Eため、データフレームのビットは、フォーマットされています。図2に示すようにG729Eフォワード適応モードのフィールドがパックされる。7。
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|L| L1 | L2 | L3 | P1 |P| C0_1| | |0| | | | |0| | | | |0 1 2 3 4 5 6|0 1 2 3 4|0 1 2 3 4|0 1 2 3 4 5 6 7| |0 1 2| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | C1_1 | C2_1 | C3_1 | C4_1 | | | | | | | |3 4 5 6|0 1 2 3 4 5 6|0 1 2 3 4 5 6|0 1 2 3 4 5 6|0 1 2 3 4 5 6| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | GA1 | GB1 | P2 | C0_2 | C1_2 | C2_2 | | | | | | | | |0 1 2|0 1 2 3|0 1 2 3 4|0 1 2 3 4 5 6|0 1 2 3 4 5 6|0 1 2 3 4 5| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | C3_2 | C4_2 | GA2 | GB2 |DC | | | | | | | | |6|0 1 2 3 4 5 6|0 1 2 3 4 5 6|0 1 2|0 1 2 3|0 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 + - + - + - + - + - + - - + + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - - + | 0 0 | L | L1 | L2 | L3 | P1 | P | C0_1 | | | 0 | | | | | 0 | | | | | 0 1 2 3 4 5 6 | 0 1 2 3 4 | 0 1 2 3 4 | 0 1 2 3 4 5 6 7 | | 0 1 2 | + + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - - + - + - + - + - + - + - + - + | | C1_1 | C2_1 | C3_1 | C4_1 | | | | | | | | 3 4 5 6 | 0 1 2 3 4 5 6 | 0 1 2 3 4 5 6 | 0 1 2 3 4 5 6 | 0 1 2 3 4 5 6 | + + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - - + - + - + - + - + - + - + - + | GA1 | GB1 | P2 | C0_2 | C1_2 | C2_2 | | | | | | | | | 0 1 2 | 0 1 2 3 | 0 1 2 3 4 | 0 1 2 3 4 5 6 | 0 1 2 3 4 5 6 | 0 1 2 3 4 5 | + + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - - + - + - + - + - + - + - + - + | | C3_2 | C4_2 | GA2 | GB2 | DC | | | | | | | | | 6 | 0 1 2 3 4 5 6 | 0 1 2 3 4 5 6 | 0 1 2 | 0 1 2 3 | 0 1 | + + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + -
Figure 7: G.729 Annex E (forward adaptive mode) bit packing
図7：G.729の付属書E（前方適応モード）ビットパッキング
The fields for the G729E backward adaptive mode are packed as shown in Fig. 8.
図2に示すようにG729E後方適応モードのためのフィールドがパックされている。8。
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 1| P1 |P| C0_1 | C1_1 | | | |0| 1 1 1| | | |0 1 2 3 4 5 6 7|0|0 1 2 3 4 5 6 7 8 9 0 1 2|0 1 2 3 4 5 6 7| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | C2_1 | C3_1 | C4_1 |GA1 | GB1 |P2 | | | | | | | | | |8 9|0 1 2 3 4 5 6|0 1 2 3 4 5 6|0 1 2 3 4 5 6|0 1 2|0 1 2 3|0 1| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | C0_2 | C1_2 | C2_2 | | | 1 1 1| | | |2 3 4|0 1 2 3 4 5 6 7 8 9 0 1 2|0 1 2 3 4 5 6 7 8 9|0 1 2 3 4 5| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | C3_2 | C4_2 | GA2 | GB2 |DC | | | | | | | | |6|0 1 2 3 4 5 6|0 1 2 3 4 5 6|0 1 2|0 1 2 3|0 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 + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + | 1 | P1 | P | C0_1 | C1_1 | | | | 0 | 1 1 1 | | | | 0 1 2 3 4 5 6 7 | 0 | 0 1 2 3 4 5 6 7 8 9 0 1 2 | 0 1 2 3 4 5 6 7 | + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + | | C2_1 | C3_1 | C4_1 | GA1 | GB1 | P2 | | | | | | | | | | 8 9 | 0 1 2 3 4 5 6 | 0 1 2 3 4 5 6 | 0 1 2 3 4 5 6 | 0 1 2 | 0 1 2 3 | 0 1 | + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + | | C0_2 | C1_2 | C2_2 | | | 1 1 1 | | | | 2 3 4 | 0 1 2 3 4 5 6 7 8 9 0 1 2 | 0 1 2 3 4 5 6 7 8 9 | 0 1 2 3 4 5 | + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + | | C3_2 | C4_2 | GA2 | GB2 | DC | | | | | | | | | 6 | 0 1 2 3 4 5 6 | 0 1 2 3 4 5 6 | 0 1 2 | 0 1 2 3 | 0 1 | + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
Figure 8: G.729 Annex E (backward adaptive mode) bit packing
図8：G.729附属書E（後方適応モード）ビットパッキング
GSM (Group Speciale Mobile) denotes the European GSM 06.10 standard for full-rate speech transcoding, ETS 300 961, which is based on RPE/LTP (residual pulse excitation/long term prediction) coding at a rate of 13 kb/s [11,12,13]. The text of the standard can be obtained from:
GSM（グループSPECIALEモバイル）フルレート音声トランスコーディングのためのヨーロッパのGSM 06.10規格を示し、RPE / LTP（残留パルス励起/長期予測）に基づいているETS 300 961は、13キロバイト/秒の速度で符号化[11 、12,13]。標準のテキストは、から入手することができます。
ETSI (European Telecommunications Standards Institute) ETSI Secretariat: B.P.152 F-06561 Valbonne Cedex France Phone: +33 92 94 42 00 Fax: +33 93 65 47 16
ETSI（欧州電気通信標準化協会）ETSI事務局：B.P.152 F-06561ヴァルボンヌセデックスフランス電話：+33 92 94 42 00ファックス：+33 93 65 47 16
Blocks of 160 audio samples are compressed into 33 octets, for an effective data rate of 13,200 b/s.
160個のオーディオサンプルのブロックは、13,200 B / Sの実効データ・レートのために、33個のオクテットに圧縮されます。
The GSM standard (ETS 300 961) specifies the bit stream produced by the codec, but does not specify how these bits should be packed for transmission. The packetization specified here has subsequently been adopted in ETSI Technical Specification TS 101 318. Some software implementations of the GSM codec use a different packing than that specified here.
GSM規格（ETS 300 961）は、コーデックによって生成されたビットストリームを指定し、これらのビットは伝送のために充填されるべき方法を指定しません。ここで指定されたパケットは、その後、GSMコーデックの101の318一部のソフトウェア実装は、ここで指定したものとは異なる梱包を使用ETSI技術仕様書TSに採用されています。
field field name bits field field name bits
________________________________________________
1 LARc[0] 6 39 xmc[22] 3
2 LARc[1] 6 40 xmc[23] 3
3 LARc[2] 5 41 xmc[24] 3
4 LARc[3] 5 42 xmc[25] 3
5 LARc[4] 4 43 Nc[2] 7
6 LARc[5] 4 44 bc[2] 2
7 LARc[6] 3 45 Mc[2] 2
8 LARc[7] 3 46 xmaxc[2] 6
9 Nc[0] 7 47 xmc[26] 3
10 bc[0] 2 48 xmc[27] 3
11 Mc[0] 2 49 xmc[28] 3
12 xmaxc[0] 6 50 xmc[29] 3
13 xmc[0] 3 51 xmc[30] 3
14 xmc[1] 3 52 xmc[31] 3
15 xmc[2] 3 53 xmc[32] 3
16 xmc[3] 3 54 xmc[33] 3
17 xmc[4] 3 55 xmc[34] 3
18 xmc[5] 3 56 xmc[35] 3
19 xmc[6] 3 57 xmc[36] 3
20 xmc[7] 3 58 xmc[37] 3
21 xmc[8] 3 59 xmc[38] 3
22 xmc[9] 3 60 Nc[3] 7
23 xmc[10] 3 61 bc[3] 2
24 xmc[11] 3 62 Mc[3] 2
25 xmc[12] 3 63 xmaxc[3] 6
26 Nc[1] 7 64 xmc[39] 3
27 bc[1] 2 65 xmc[40] 3
28 Mc[1] 2 66 xmc[41] 3
29 xmaxc[1] 6 67 xmc[42] 3
30 xmc[13] 3 68 xmc[43] 3
31 xmc[14] 3 69 xmc[44] 3
32 xmc[15] 3 70 xmc[45] 3
33 xmc[16] 3 71 xmc[46] 3
34 xmc[17] 3 72 xmc[47] 3
35 xmc[18] 3 73 xmc[48] 3
36 xmc[19] 3 74 xmc[49] 3
37 xmc[20] 3 75 xmc[50] 3
38 xmc[21] 3 76 xmc[51] 3
Table 2: Ordering of GSM variables
表2：GSM変数の順序
Octet Bit 0 Bit 1 Bit 2 Bit 3 Bit 4 Bit 5 Bit 6 Bit 7
_____________________________________________________________________
0 1 1 0 1 LARc0.0 LARc0.1 LARc0.2 LARc0.3
1 LARc0.4 LARc0.5 LARc1.0 LARc1.1 LARc1.2 LARc1.3 LARc1.4 LARc1.5
2 LARc2.0 LARc2.1 LARc2.2 LARc2.3 LARc2.4 LARc3.0 LARc3.1 LARc3.2
3 LARc3.3 LARc3.4 LARc4.0 LARc4.1 LARc4.2 LARc4.3 LARc5.0 LARc5.1
4 LARc5.2 LARc5.3 LARc6.0 LARc6.1 LARc6.2 LARc7.0 LARc7.1 LARc7.2
5 Nc0.0 Nc0.1 Nc0.2 Nc0.3 Nc0.4 Nc0.5 Nc0.6 bc0.0
6 bc0.1 Mc0.0 Mc0.1 xmaxc00 xmaxc01 xmaxc02 xmaxc03 xmaxc04
7 xmaxc05 xmc0.0 xmc0.1 xmc0.2 xmc1.0 xmc1.1 xmc1.2 xmc2.0
8 xmc2.1 xmc2.2 xmc3.0 xmc3.1 xmc3.2 xmc4.0 xmc4.1 xmc4.2
9 xmc5.0 xmc5.1 xmc5.2 xmc6.0 xmc6.1 xmc6.2 xmc7.0 xmc7.1
10 xmc7.2 xmc8.0 xmc8.1 xmc8.2 xmc9.0 xmc9.1 xmc9.2 xmc10.0
11 xmc10.1 xmc10.2 xmc11.0 xmc11.1 xmc11.2 xmc12.0 xmc12.1 xcm12.2
12 Nc1.0 Nc1.1 Nc1.2 Nc1.3 Nc1.4 Nc1.5 Nc1.6 bc1.0
13 bc1.1 Mc1.0 Mc1.1 xmaxc10 xmaxc11 xmaxc12 xmaxc13 xmaxc14
14 xmax15 xmc13.0 xmc13.1 xmc13.2 xmc14.0 xmc14.1 xmc14.2 xmc15.0
15 xmc15.1 xmc15.2 xmc16.0 xmc16.1 xmc16.2 xmc17.0 xmc17.1 xmc17.2
16 xmc18.0 xmc18.1 xmc18.2 xmc19.0 xmc19.1 xmc19.2 xmc20.0 xmc20.1
17 xmc20.2 xmc21.0 xmc21.1 xmc21.2 xmc22.0 xmc22.1 xmc22.2 xmc23.0
18 xmc23.1 xmc23.2 xmc24.0 xmc24.1 xmc24.2 xmc25.0 xmc25.1 xmc25.2
19 Nc2.0 Nc2.1 Nc2.2 Nc2.3 Nc2.4 Nc2.5 Nc2.6 bc2.0
20 bc2.1 Mc2.0 Mc2.1 xmaxc20 xmaxc21 xmaxc22 xmaxc23 xmaxc24
21 xmaxc25 xmc26.0 xmc26.1 xmc26.2 xmc27.0 xmc27.1 xmc27.2 xmc28.0
22 xmc28.1 xmc28.2 xmc29.0 xmc29.1 xmc29.2 xmc30.0 xmc30.1 xmc30.2
23 xmc31.0 xmc31.1 xmc31.2 xmc32.0 xmc32.1 xmc32.2 xmc33.0 xmc33.1
24 xmc33.2 xmc34.0 xmc34.1 xmc34.2 xmc35.0 xmc35.1 xmc35.2 xmc36.0
25 Xmc36.1 xmc36.2 xmc37.0 xmc37.1 xmc37.2 xmc38.0 xmc38.1 xmc38.2
26 Nc3.0 Nc3.1 Nc3.2 Nc3.3 Nc3.4 Nc3.5 Nc3.6 bc3.0
27 bc3.1 Mc3.0 Mc3.1 xmaxc30 xmaxc31 xmaxc32 xmaxc33 xmaxc34
28 xmaxc35 xmc39.0 xmc39.1 xmc39.2 xmc40.0 xmc40.1 xmc40.2 xmc41.0
29 xmc41.1 xmc41.2 xmc42.0 xmc42.1 xmc42.2 xmc43.0 xmc43.1 xmc43.2
30 xmc44.0 xmc44.1 xmc44.2 xmc45.0 xmc45.1 xmc45.2 xmc46.0 xmc46.1
31 xmc46.2 xmc47.0 xmc47.1 xmc47.2 xmc48.0 xmc48.1 xmc48.2 xmc49.0
32 xmc49.1 xmc49.2 xmc50.0 xmc50.1 xmc50.2 xmc51.0 xmc51.1 xmc51.2
Table 3: GSM payload format
表3：GSMペイロードフォーマット
In the GSM packing used by RTP, the bits SHALL be packed beginning from the most significant bit. Every 160 sample GSM frame is coded into one 33 octet (264 bit) buffer. Every such buffer begins with a 4 bit signature (0xD), followed by the MSB encoding of the fields of the frame. The first octet thus contains 1101 in the 4 most significant bits (0-3) and the 4 most significant bits of F1 (0-3) in the 4 least significant bits (4-7). The second octet contains the 2 least significant bits of F1 in bits 0-1, and F2 in bits 2-7, and so on. The order of the fields in the frame is described in Table 2.
RTPで使用されるGSMのパッキングでは、ビットは、最上位ビットから始まるパックされるものとします。すべての160サンプルのGSMフレームは、一つ33オクテット（264ビット）のバッファに符号化されます。すべてのそのようなバッファは、フレームのフィールドのMSB符号化に続く4ビットの署名（0xDの）、始まります。最初のオクテットは、このように4つの最上位ビット（0-3）と4つの最下位ビット（4-7）でF1（0-3）の4つの最上位ビット1101を含んでいます。第2オクテットは、ようにビット2-7のビット0-1、およびF2におけるF1の2つの最下位ビットを含み、。フレーム内のフィールドの順序は、表2に記載されています。
In the RTP encoding we have the bit pattern described in Table 3, where F.i signifies the ith bit of the field F, bit 0 is the most significant bit, and the bits of every octet are numbered from 0 to 7 from most to least significant.
我々はFiはフィールドFのi番目のビットを意味し、表3に記載のビットパターンを有するRTP符号化では、ビット0が最上位ビットであり、すべてのオクテットのビットは最もから0から7まで番号が付けられている少なくともに対して有意な。
GSM-EFR denotes GSM 06.60 enhanced full rate speech transcoding, specified in ETS 300 726 which is available from ETSI at the address given in Section 4.5.8. This codec has a frame length of 244 bits. For transmission in RTP, each codec frame is packed into a 31 octet (248 bit) buffer beginning with a 4-bit signature 0xC in a manner similar to that specified here for the original GSM 06.10 codec. The packing is specified in ETSI Technical Specification TS 101 318.
GSM-EFRはセクション4.5.8で指定されたアドレスでETSIから入手可能であるETS 300 726に指定されたGSM 06.60拡張フルレート音声トランスコーディングを意味します。このコーデックは、244ビットのフレーム長を有しています。 RTPで送信のために、各コーデックフレームは、元のGSM 06.10コーデックのためにここで指定したのと同様に4ビットの署名から0xCから始まる31オクテット（248ビット）のバッファにパックされます。梱包は、ETSI技術仕様書TS 101 318で指定されています。
L8 denotes linear audio data samples, using 8-bits of precision with an offset of 128, that is, the most negative signal is encoded as zero.
L8は、128のオフセット、すなわち、最も負の信号がゼロとして符号化される精度の8ビットを使用して、リニアオーディオデータサンプルを表します。
L16 denotes uncompressed audio data samples, using 16-bit signed representation with 65,535 equally divided steps between minimum and maximum signal level, ranging from -32,768 to 32,767. The value is represented in two's complement notation and transmitted in network byte order (most significant byte first).
L16は-32,768から32,767の範囲の最小および最大信号レベルと65,535等分ステップ、と16ビットの符号付き表現を使用して、非圧縮のオーディオデータサンプルを表します。値は2の補数で表現し、ネットワークバイト順（最上位バイトが最初）に送信されます。
The MIME registration for L16 in RFC 3555 [7] specifies parameters that MAY be used with MIME or SDP to indicate that analog pre-emphasis was applied to the signal before quantization or to indicate that a multiple-channel audio stream follows a different channel ordering convention than is specified in Section 4.1.
RFC 3555にL16のためのMIME登録[7]アナログプリエンファシスは、量子化前の信号に適用されたことを示すために、またはマルチチャンネルオーディオストリームは、異なるチャネルの順序に従うことを示すために、MIMEまたはSDPと共に使用することができるパラメータを指定します4.1節で指定されているよりも大会。
LPC designates an experimental linear predictive encoding contributed by Ron Frederick, which is based on an implementation written by Ron Zuckerman posted to the Usenet group comp.dsp on June 26, 1992. The codec generates 14 octets for every frame. The framesize is set to 20 ms, resulting in a bit rate of 5,600 b/s.
LPCは、ロンズッカーマン6月26日にUsenetのグループcomp.dspにポストによって書かれた実装に基づいているロン・フレデリックが寄与する実験線形予測符号化を指定、1992年コーデックはフレーム毎に14個のオクテットを生成します。フレームサイズは5,600 B / sのビットレートで、その結果、20ミリ秒に設定されています。
MPA denotes MPEG-1 or MPEG-2 audio encapsulated as elementary streams. The encoding is defined in ISO standards ISO/IEC 11172-3 and 13818-3. The encapsulation is specified in RFC 2250 [14].
MPAは、エレメンタリストリームとしてカプセル化されたMPEG-1またはMPEG-2オーディオを表します。エンコードはISO規格ISO / IEC 11172-3と13818-3で定義されています。カプセル化は、RFC 2250 [14]で指定されています。
The encoding may be at any of three levels of complexity, called Layer I, II and III. The selected layer as well as the sampling rate and channel count are indicated in the payload. The RTP timestamp clock rate is always 90,000, independent of the sampling rate. MPEG-1 audio supports sampling rates of 32, 44.1, and 48 kHz (ISO/IEC 11172-3, section 1.1; "Scope"). MPEG-2 supports sampling rates of 16, 22.05 and 24 kHz. The number of samples per frame is fixed, but the frame size will vary with the sampling rate and bit rate.
符号化は、複雑さの三つのレベルのいずれかであっても呼ばれるレイヤI、II及びIIIできます。選択された層ならびにサンプリングレートとチャンネル数は、ペイロードに示されています。 RTPタイムスタンプのクロックレートは、サンプリングレートとは無関係に、常に90,000です。 MPEG-1オーディオは、32、44.1、48 kHzのサンプリングレートサポート（ISO / IEC 11172-3、セクション1.1、 "スコープ"）。 MPEG-2は16、22.05と24 kHzでのサンプリング・レートをサポートしています。フレームあたりのサンプル数が固定されているが、フレームサイズは、サンプリングレートとビットレートに応じて変化します。
The MIME registration for MPA in RFC 3555 [7] specifies parameters that MAY be used with MIME or SDP to restrict the selection of layer, channel count, sampling rate, and bit rate.
RFC 3555におけるMPAのためのMIME登録[7]層、チャンネル数、サンプリングレート、ビットレートの選択を制限するMIMEまたはSDPと共に使用することができるパラメータを指定します。
PCMA and PCMU are specified in ITU-T Recommendation G.711. Audio data is encoded as eight bits per sample, after logarithmic scaling. PCMU denotes mu-law scaling, PCMA A-law scaling. A detailed description is given by Jayant and Noll [15]. Each G.711 octet SHALL be octet-aligned in an RTP packet. The sign bit of each G.711 octet SHALL correspond to the most significant bit of the octet in the RTP packet (i.e., assuming the G.711 samples are handled as octets on the host machine, the sign bit SHALL be the most significant bit of the octet as defined by the host machine format). The 56 kb/s and 48 kb/s modes of G.711 are not applicable to RTP, since PCMA and PCMU MUST always be transmitted as 8-bit samples.
PCMAおよびPCMUは、ITU-T勧告G.711で規定されています。オーディオデータは対数スケーリングの後、サンプル当たり8ビットとして符号化されます。 PCMUがmu-法則スケーリング、PCMA A則のスケーリングを示しています。詳細な説明はジャヤント及びノル[15]によって与えられます。各G.711オクテットは、RTPパケット内のオクテット整列されなければなりません。各G.711オクテットの符号ビットがG.711サンプルはホストマシン上のオクテットとして扱われていると仮定すると、RTPパケット（すなわち、内オクテットの最上位ビットに対応するものと、符号ビットは最上位ビットでなければなりませんホストマシンフォーマットによって定義されるオクテット）の。 PCMAおよびPCMUが常に8ビットサンプルとして送信しなければならないのでG.711 56 KB /秒および48 KB / Sモードは、RTPには適用できません。
See Section 4.1 regarding silence suppression.
無音抑止に関するセクション4.1を参照してください。
The Electronic Industries Association (EIA) & Telecommunications Industry Association (TIA) standard IS-733, "TR45: High Rate Speech Service Option for Wideband Spread Spectrum Communications Systems", defines the QCELP audio compression algorithm for use in wireless CDMA applications. The QCELP CODEC compresses each 20 milliseconds of 8,000 Hz, 16-bit sampled input speech into one of four different size output frames: Rate 1 (266 bits), Rate 1/2 (124 bits), Rate 1/4 (54 bits) or Rate 1/8 (20 bits). For typical speech patterns, this results in an average output of 6.8 kb/s for normal mode and 4.7 kb/s for reduced rate mode. The packetization of the QCELP audio codec is described in [16].
電子工業会（EIA）＆電気通信工業会（TIA）規格は、IS-733、「TR45：広帯域スペクトル拡散通信システムのための高レート音声サービスオプション」、無線CDMA用途での使用にQCELP音声圧縮アルゴリズムを定義します。 、レート1（266ビット）、レート1/2（124ビット）レート1/4（54ビット）：QCELP CODECは、4つの異なるサイズの出力フレームのうちの1つに8,000ヘルツの各20ミリ秒、16ビットサンプリングされた入力音声を圧縮しますまたは1/8（20ビット）を評価します。典型的な音声パターンの場合、これは通常モードと低レートモード4.7 KB /秒6.8 KB /秒の平均出力を生じます。 QCELPオーディオコーデックのパケット化は[16]に記載されています。
The redundant audio payload format "RED" is specified by RFC 2198 [17]. It defines a means by which multiple redundant copies of an audio packet may be transmitted in a single RTP stream. Each packet in such a stream contains, in addition to the audio data for that packetization interval, a (more heavily compressed) copy of the data from a previous packetization interval. This allows an approximation of the data from lost packets to be recovered upon decoding of a subsequent packet, giving much improved sound quality when compared with silence substitution for lost packets.
冗長オーディオペイロード形式「RED」は、RFC 2198 [17]で指定されています。これは、音声パケットの複数の冗長コピーが単一のRTPストリームで送信することができる手段を定義します。そのようなストリーム内の各パケットは、そのパケット間隔のオーディオデータ、前回パケット化間隔からのデータ（より強く圧縮された）コピーに加えて、含まれています。これは、失われたパケットからのデータの近似は、失われたパケットのための沈黙置換と比較してはるかに改善された音質を与える、後続のパケットの復号の際に回収されることを可能にします。
VDVI is a variable-rate version of DVI4, yielding speech bit rates of between 10 and 25 kb/s. It is specified for single-channel operation only. Samples are packed into octets starting at the most-significant bit. The last octet is padded with 1 bits if the last sample does not fill the last octet. This padding is distinct from the valid codewords. The receiver needs to detect the padding because there is no explicit count of samples in the packet.
VDVIは10〜25 KB /秒の音声ビットレートを得DVI4の可変レートバージョンです。これは、シングルチャネル動作のために指定されています。サンプルは、最上位ビットから始まるオクテットにパックされています。最後のサンプルは、最後のオクテットを満たしていない場合は、最後のオクテットは1ビットで埋めています。このパディングは、有効なコードワードとは区別されます。受信機は、パケット内のサンプルの明示的な数が存在しないため、パディングを検出する必要があります。
It uses the following encoding:
これは、次のエンコーディングを使用しています：
DVI4 codeword VDVI bit pattern
_______________________________
0 00
1 010
2 1100
3 11100
4 111100
5 1111100
6 11111100
7 11111110
8 10
9 011
10 1101
11 11101
12 111101
13 1111101
14 11111101
15 11111111
The following sections describe the video encodings that are defined in this memo and give their abbreviated names used for identification. These video encodings and their payload types are listed in Table 5.
以下のセクションでは、このメモで定義され、識別のために使用彼らの略称を与えるされているビデオ符号化を記述しています。これらのビデオのエンコーディングとそのペイロードタイプは、表5に列挙されています。
All of these video encodings use an RTP timestamp frequency of 90,000 Hz, the same as the MPEG presentation time stamp frequency. This frequency yields exact integer timestamp increments for the typical 24 (HDTV), 25 (PAL), and 29.97 (NTSC) and 30 Hz (HDTV) frame rates and 50, 59.94 and 60 Hz field rates. While 90 kHz is the RECOMMENDED rate for future video encodings used within this profile, other rates MAY be used. However, it is not sufficient to use the video frame rate (typically between 15 and 30 Hz) because that does not provide adequate resolution for typical synchronization requirements when calculating the RTP timestamp corresponding to the NTP timestamp in an RTCP SR packet. The timestamp resolution MUST also be sufficient for the jitter estimate contained in the receiver reports.
これらのビデオエンコーディングのすべてが90,000 Hzで、MPEGプレゼンテーションタイムスタンプの周波数と同じのRTPタイムスタンプの周波数を使用します。この周波数は、正確な整数のタイムスタンプの典型的な24（HDTV）用の増分、25（PAL）、及び29.97（NTSC）、30ヘルツ（HDTV）フレームレートと50、59.94および60Hzのフィールドレートが得られます。 90 kHzのは、このプロファイル内で使用される将来のビデオエンコーディングの推奨量ですが、他のレートを使用することができます。しかし、RTCPのSRパケットでNTPタイムスタンプに対応するRTPタイムスタンプを計算するときには、典型的な同期要件のために十分な解像度を提供しないため、ビデオフレームレート（典型的には15〜30 Hz）を使用するのに十分ではありません。タイムスタンプの分解能は、受信機レポートに含まれるジッタ推定のために十分でなければなりません。
For most of these video encodings, the RTP timestamp encodes the sampling instant of the video image contained in the RTP data packet. If a video image occupies more than one packet, the timestamp is the same on all of those packets. Packets from different video images are distinguished by their different timestamps.
これらのビデオエンコーディングのほとんどは、RTPタイムスタンプは、RTPデータパケットに含まれるビデオ画像のサンプリングの瞬間をコードしています。ビデオ画像が複数のパケットを占有している場合は、タイムスタンプは、それらのパケットの全てで同じです。異なる映像からのパケットは、それらの異なるタイムスタンプによって区別されます。
Most of these video encodings also specify that the marker bit of the RTP header SHOULD be set to one in the last packet of a video frame and otherwise set to zero. Thus, it is not necessary to wait for a following packet with a different timestamp to detect that a new frame should be displayed.
これらのビデオエンコーディングのほとんどは、RTPヘッダのマーカービットは、ビデオフレームの最後のパケットで1に設定し、そうでない場合はゼロに設定されるように指定します。したがって、新しいフレームが表示されるべきであることを検出するために、異なるタイムスタンプと、次のパケットを待つ必要はありません。
The CELL-B encoding is a proprietary encoding proposed by Sun Microsystems. The byte stream format is described in RFC 2029 [18].
CELL-B符号化は、Sun Microsystems社によって提案された独自の符号化です。バイトストリームフォーマットは、RFC 2029 [18]に記載されています。
The encoding is specified in ISO Standards 10918-1 and 10918-2. The RTP payload format is as specified in RFC 2435 [19].
エンコードはISO規格10918-1と10918から2に指定されています。 RFC 2435 [19]で指定されるようにRTPペイロードフォーマットです。
The encoding is specified in ITU-T Recommendation H.261, "Video codec for audiovisual services at p x 64 kbit/s". The packetization and RTP-specific properties are described in RFC 2032 [20].
符号化は、ITU-T勧告H.261、「P×64キロビット/秒でオーディオビジュアルサービスのためのビデオコーデック」で指定されています。パケット及びRTP固有のプロパティは、RFC 2032 [20]に記載されています。
The encoding is specified in the 1996 version of ITU-T Recommendation H.263, "Video coding for low bit rate communication". The packetization and RTP-specific properties are described in RFC 2190 [21]. The H263-1998 payload format is RECOMMENDED over this one for use by new implementations.
符号化は、ITU-T勧告H.263、「低ビットレート通信用ビデオ符号化」1996年版で指定されています。パケット及びRTP固有のプロパティは、RFC 2190 [21]に記載されています。 H263-1998ペイロードフォーマットは、新しい実装で使用するために、この1の上に推奨されます。
The encoding is specified in the 1998 version of ITU-T Recommendation H.263, "Video coding for low bit rate communication". The packetization and RTP-specific properties are described in RFC 2429 [22]. Because the 1998 version of H.263 is a superset of the 1996 syntax, this payload format can also be used with the 1996 version of H.263, and is RECOMMENDED for this use by new implementations. This payload format does not replace RFC 2190, which continues to be used by existing implementations, and may be required for backward compatibility in new implementations. Implementations using the new features of the 1998 version of H.263 MUST use the payload format described in RFC 2429.
符号化は、ITU-T勧告H.263、「低ビットレート通信用ビデオ符号化」1998年版で指定されています。パケット及びRTP固有のプロパティは、RFC 2429 [22]に記載されています。 H.263の1998年版が1996構文のスーパーセットであるため、このペイロード形式はまた、H.263の1996バージョンで使用することができ、かつ新しい実装することにより、この使用することをお勧めします。このペイロードフォーマットは、既存の実装で使用され続け、そして新しい実装で下位互換性のために必要とされ得るRFC 2190、置き換えられません。 H.263の1998バージョンの新機能を使用して実装は、RFC 2429で説明ペイロードフォーマットを使用しなければなりません。
MPV designates the use of MPEG-1 and MPEG-2 video encoding elementary streams as specified in ISO Standards ISO/IEC 11172 and 13818-2, respectively. The RTP payload format is as specified in RFC 2250 [14], Section 3.
MPVは、MPEG-1の使用を指定して、それぞれ、ISO規格ISO / IEC 11172および13818-2で指定されているMPEG-2ビデオエレメンタリストリームを符号化します。 RFC 2250 [14]、セクション3で指定されるようにRTPペイロードフォーマットです。
The MIME registration for MPV in RFC 3555 [7] specifies a parameter that MAY be used with MIME or SDP to restrict the selection of the type of MPEG video.
RFC 3555におけるMPVのMIME登録[7] MPEGビデオの種類の選択を制限するMIMEまたはSDPと共に使用することができるパラメータを指定します。
MP2T designates the use of MPEG-2 transport streams, for either audio or video. The RTP payload format is described in RFC 2250 [14], Section 2.
MP2Tは、オーディオまたはビデオのどちらかのために、MPEG-2トランスポートストリームの使用を指定します。 RTPペイロードフォーマットは、RFC 2250 [14]、セクション2に記載されています。
The encoding is implemented in the program `nv', version 4, developed at Xerox PARC by Ron Frederick. Further information is available from the author:
符号化は、ロンフレデリックによってゼロックスPARCで開発されたプログラム `NV」、バージョン4に実装されています。さらに詳しい情報は、著者から入手できます。
Ron Frederick Blue Coat Systems Inc. 650 Almanor Avenue Sunnyvale, CA 94085 United States EMail: ronf@bluecoat.com
ロン・フレデリック・ブルーコートシステムズ社650 Almanorアベニューサニーベール、CA 94085米国電子メール：ronf@bluecoat.com
Tables 4 and 5 define this profile's static payload type values for the PT field of the RTP data header. In addition, payload type values in the range 96-127 MAY be defined dynamically through a conference control protocol, which is beyond the scope of this document. For example, a session directory could specify that for a given session, payload type 96 indicates PCMU encoding, 8,000 Hz sampling rate, 2 channels. Entries in Tables 4 and 5 with payload type "dyn" have no static payload type assigned and are only used with a dynamic payload type. Payload type 2 was assigned to G721 in RFC 1890 and to its equivalent successor G726-32 in draft versions of this specification, but its use is now deprecated and that static payload type is marked reserved due to conflicting use for the payload formats G726-32 and AAL2-G726-32 (see Section 4.5.4). Payload type 13 indicates the Comfort Noise (CN) payload format specified in RFC 3389 [9]. Payload type 19 is marked "reserved" because some draft versions of this specification assigned that number to an earlier version of the comfort noise payload format. The payload type range 72-76 is marked "reserved" so that RTCP and RTP packets can be reliably distinguished (see Section "Summary of Protocol Constants" of the RTP protocol specification).
表4および5は、RTPデータヘッダのPTフィールドに、このプロファイルの静的ペイロードタイプ値を定義します。また、範囲96から127でペイロードタイプ値は、この文書の範囲を超えて会議制御プロトコルを介して動的に定義されるかもしれません。例えば、セッションディレクトリは、特定のセッションのために、ペイロードタイプ96はPCMUエンコード、8,000 Hzのサンプリングレート、2つのチャネルを示していると指定することができます。ペイロードタイプ「DYN」と表4と5のエントリは、割り当てられた静的なペイロードタイプを持たないだけダイナミックペイロードタイプと共に使用されます。ペイロードタイプ2は、RFC 1890年に、この仕様のドラフトバージョンでその等価後継G726-32にG721に割り当てられていたが、原因ペイロードフォーマットG726-32ための競合使用に予約され、その使用が廃止され、その静的ペイロードタイプがマークされていますそして、AAL2-G726-32（4.5.4項を参照してください）。ペイロードタイプ13 [9] RFC 3389で指定されたコンフォートノイズ（CN）ペイロードフォーマットを示しています。本明細書の一部ドラフトバージョンが快適雑音ペイロードフォーマットの以前のバージョンにその番号が割り当てられているので、ペイロードタイプ19は「予約済み」とマークされています。ペイロードタイプの範囲72-76 RTCPとRTPパケットを確実に識別することができるように（RTPプロトコル仕様のセクション「プロトコル定数の概要」を参照）、「予約済み」とマークされています。
The payload types currently defined in this profile are assigned to exactly one of three categories or media types: audio only, video only and those combining audio and video. The media types are marked in Tables 4 and 5 as "A", "V" and "AV", respectively. Payload types of different media types SHALL NOT be interleaved or multiplexed within a single RTP session, but multiple RTP sessions MAY be used in parallel to send multiple media types. An RTP source MAY change payload types within the same media type during a session. See the section "Multiplexing RTP Sessions" of RFC 3550 for additional explanation.
オーディオのみ、唯一のビデオとオーディオとビデオを組み合わせたもの：現在、このプロファイルで定義されたペイロードタイプは、正確に3つのカテゴリの1つまたはメディアタイプに割り当てられます。メディアタイプは、それぞれ、表4および表5の「A」、「V」などと「AV」でマークされています。異なるメディアタイプのペイロードタイプは、インターリーブまたは、単一のRTPセッション内で多重化が、複数のRTPセッションが複数のメディアタイプを送信するために並行して使用することができることがないものとします。 RTPソースは、セッション中に同じメディアタイプ内のペイロードタイプを変更することがあります。追加説明については、RFC 3550のセクション「多重RTPセッション」を参照してください。
PT encoding media type clock rate channels
name (Hz)
___________________________________________________
0 PCMU A 8,000 1
1 reserved A
2 reserved A
3 GSM A 8,000 1
4 G723 A 8,000 1
5 DVI4 A 8,000 1
6 DVI4 A 16,000 1
7 LPC A 8,000 1
8 PCMA A 8,000 1
9 G722 A 8,000 1
10 L16 A 44,100 2
11 L16 A 44,100 1
12 QCELP A 8,000 1
13 CN A 8,000 1
14 MPA A 90,000 (see text)
15 G728 A 8,000 1
16 DVI4 A 11,025 1
17 DVI4 A 22,050 1
18 G729 A 8,000 1
19 reserved A
20 unassigned A
21 unassigned A
22 unassigned A
23 unassigned A
dyn G726-40 A 8,000 1
dyn G726-32 A 8,000 1
dyn G726-24 A 8,000 1
dyn G726-16 A 8,000 1
dyn G729D A 8,000 1
dyn G729E A 8,000 1
dyn GSM-EFR A 8,000 1
dyn L8 A var. var.
dyn RED A (see text)
dyn VDVI A var. 1
Table 4: Payload types (PT) for audio encodings
表4：オーディオ符号化のためのペイロードタイプ（PT）
PT encoding media type clock rate
name (Hz)
_____________________________________________
24 unassigned V
25 CelB V 90,000
26 JPEG V 90,000
27 unassigned V
28 nv V 90,000
29 unassigned V
30 unassigned V
31 H261 V 90,000
32 MPV V 90,000
33 MP2T AV 90,000
34 H263 V 90,000
35-71 unassigned ?
72-76 reserved N/A N/A
77-95 unassigned ?
96-127 dynamic ?
dyn H263-1998 V 90,000
Table 5: Payload types (PT) for video and combined encodings
表5：ビデオと組み合わせエンコーディングのためのペイロードタイプ（PT）
Session participants agree through mechanisms beyond the scope of this specification on the set of payload types allowed in a given session. This set MAY, for example, be defined by the capabilities of the applications used, negotiated by a conference control protocol or established by agreement between the human participants.
セッション参加者は、特定のセッションで許可されたペイロードタイプのセットでこの仕様の範囲を超えたメカニズムによって同意するものとします。このセットは、例えば、会議制御プロトコルによって交渉又はヒトの参加者間の合意によって確立された、使用するアプリケーションの能力によって定義することができます。
Audio applications operating under this profile SHOULD, at a minimum, be able to send and/or receive payload types 0 (PCMU) and 5 (DVI4). This allows interoperability without format negotiation and ensures successful negotiation with a conference control protocol.
このプロファイルの下で動作するオーディオアプリケーションは、最低でも、ペイロードタイプ0（PCMU）及び5（DVI4）を送信及び/又は受信することができるべきです。これは、形式交渉なしで相互運用性を可能にし、会議制御プロトコルで成功した交渉を保証します。
Under special circumstances, it may be necessary to carry RTP in protocols offering a byte stream abstraction, such as TCP, possibly multiplexed with other data. The application MUST define its own method of delineating RTP and RTCP packets (RTSP [23] provides an example of such an encapsulation specification).
特殊な状況下では、おそらく他のデータと多重化TCPのようなバイトストリームの抽象化を、提供するプロトコルでRTPを運ぶために必要があるかもしれません。アプリケーションは、RTP及びRTCPパケットを（RTSP [23]そのようなカプセル化仕様の例を提供する）描写の独自の方法を定義しなければなりません。
As specified in the RTP protocol definition, RTP data SHOULD be carried on an even UDP port number and the corresponding RTCP packets SHOULD be carried on the next higher (odd) port number.
RTPプロトコル定義で指定されているように、RTPデータもUDPポート番号に担持されるべきであり、対応するRTCPパケットは、次の上位（奇数）ポート番号で実行されるべきです。
Applications operating under this profile MAY use any such UDP port pair. For example, the port pair MAY be allocated randomly by a session management program. A single fixed port number pair cannot be required because multiple applications using this profile are likely to run on the same host, and there are some operating systems that do not allow multiple processes to use the same UDP port with different multicast addresses.
このプロファイルの下で動作するアプリケーションは、そのようなUDPポートのペアを使用するかもしれません。例えば、ポートのペアは、セッション管理プログラムによりランダムに割り当てることができます。このプロファイルを使用して、複数のアプリケーションが同じホスト上で実行する可能性がある、と複数のプロセスが異なるマルチキャストアドレスと同じUDPポートを使用することはできませんいくつかのオペレーティングシステムがあるので、単一の固定ポート番号のペアを必要とすることはできません。
However, port numbers 5004 and 5005 have been registered for use with this profile for those applications that choose to use them as the default pair. Applications that operate under multiple profiles MAY use this port pair as an indication to select this profile if they are not subject to the constraint of the previous paragraph. Applications need not have a default and MAY require that the port pair be explicitly specified. The particular port numbers were chosen to lie in the range above 5000 to accommodate port number allocation practice within some versions of the Unix operating system, where port numbers below 1024 can only be used by privileged processes and port numbers between 1024 and 5000 are automatically assigned by the operating system.
ただし、ポート番号5004と5005は、デフォルトのペアとしてそれらを使用することを選択し、それらのアプリケーションのために、このプロファイルで使用するために登録されています。彼らは前の段落の制約を受けていない場合は、複数のプロファイルの下で動作するアプリケーションは、このプロファイルを選択するための指標として、このポートのペアを使用するかもしれません。アプリケーションは、デフォルトである必要はないとポートのペアを明示的に指定することを要求することができます。特定のポート番号が1024未満のポート番号が1024と5000の間で特権プロセスとポート番号だけを使用することができるのUnixオペレーティング・システムの一部のバージョン内のポート番号の割り当ての練習に対応するために5000以上の範囲にあるように選択された自動的に割り当てられオペレーティングシステムによる。
This RFC revises RFC 1890. It is mostly backwards-compatible with RFC 1890 except for functions removed because two interoperable implementations were not found. The additions to RFC 1890 codify existing practice in the use of payload formats under this profile. Since this profile may be used without using any of the payload formats listed here, the addition of new payload formats in this revision does not affect backwards compatibility. The changes are listed below, categorized into functional and non-functional changes.
このRFCは、二つの相互運用可能な実装が見つからなかったので、それが除去機能を除いてほとんどRFC 1890との下位互換性があるRFC 1890を修正します。 RFC 1890への追加は、このプロファイルの下のペイロードフォーマットの使用中の既存の慣行を成文化。このプロファイルは、ここに記載されているペイロード形式のいずれかを使用せずに使用することができるので、この改正で新しいペイロードフォーマットの追加は、下位互換性に影響を与えません。変更は、下記の機能的および非機能的な変更に分類されます。
Functional changes:
機能の変更：
o Section 11, "IANA Considerations" was added to specify the registration of the name for this profile. That appendix also references a new Section 3 "Registering Additional Encodings" which establishes a policy that no additional registration of static payload types for this profile will be made beyond those added in this revision and included in Tables 4 and 5. Instead, additional encoding names may be registered as MIME subtypes for binding to dynamic payload types. Non-normative references were added to RFC 3555 [7] where MIME subtypes for all the listed payload formats are registered, some with optional parameters for use of the payload formats.
O部11は、「IANAの考慮事項は、」このプロファイルの名前の登録を指定するために追加されました。それ付録では、このプロファイルの静的なペイロードタイプの追加の登録が代わりに表4および表5に、この改正で追加されたものを超えて行われておらず、含まれることをポリシーを確立し、追加のエンコーディング名「追加のエンコーディングを登録する」新しいセクション3を参照しますダイナミックペイロードタイプへの結合のためのMIMEサブタイプとして登録してもよいです。非引用規格は、RFC 3555に追加された[7]にリストされたすべてのペイロードフォーマットのMIMEサブタイプが登録される場合、ペイロード・フォーマットを使用するための任意のパラメータを持ついくつかの。
o Static payload types 4, 16, 17 and 34 were added to incorporate IANA registrations made since the publication of RFC 1890, along with the corresponding payload format descriptions for G723 and H263.
O静的ペイロードタイプ4、16、17及び34は、G723およびH263のための対応するペイロード・フォーマットの説明と一緒に、RFC 1890の出版以降に行われたIANA登録を組み込むように添加しました。
o Following working group discussion, static payload types 12 and 18 were added along with the corresponding payload format descriptions for QCELP and G729. Static payload type 13 was assigned to the Comfort Noise (CN) payload format defined in RFC 3389. Payload type 19 was marked reserved because it had been temporarily allocated to an earlier version of Comfort Noise present in some draft revisions of this document.
ワーキンググループディスカッションに続いてO、静的ペイロードタイプ12及び18は、QCELPとG729のための対応するペイロード・フォーマットの説明と一緒に添加しました。静的ペイロードタイプ13は、それが一時的にこの文書の一部ドラフトリビジョンのノイズ存在コンフォートの以前のバージョンに割り当てられていたので、3389ペイロードタイプ19を予約マークされたRFCに定義されたコンフォートノイズ（CN）ペイロードフォーマットに割り当てました。
o The payload format for G721 was renamed to G726-32 following the ITU-T renumbering, and the payload format description for G726 was expanded to include the -16, -24 and -40 data rates. Because of confusion regarding draft revisions of this document, some implementations of these G726 payload formats packed samples into octets starting with the most significant bit rather than the least significant bit as specified here. To partially resolve this incompatibility, new payload formats named AAL2-G726-16, -24, -32 and -40 will be specified in a separate document (see note in Section 4.5.4), and use of static payload type 2 is deprecated as explained in Section 6.
G721のためのペイロードフォーマットoをITU-Tリナンバリング以下G726-32に改名し、そしてG726のためのペイロード・フォーマットの説明は-16、-24及び-40のデータレートを含むように拡張しました。このため、文書の草案の改正に関する混乱のため、これらのG726ペイロードフォーマットのいくつかの実装では、最上位ビットではなく、ここで指定された最下位ビットで始まるオクテットにサンプルを詰め。部分的に別の文書で指定されAAL2-G726-16、-24、-32、-40という名前のこの非互換性、新しいペイロードフォーマットを解決するには（セクション4.5.4で注意を参照）、および静的なペイロードタイプ2の使用が推奨されていません第6節で説明したように。
o Payload formats G729D and G729E were added following the ITU-T addition of Annexes D and E to Recommendation G.729. Listings were added for payload formats GSM-EFR, RED, and H263-1998 published in other documents subsequent to RFC 1890. These additional payload formats are referenced only by dynamic payload type numbers.
OペイロードフォーマットG729DとG729Eは勧告G.729に附属書D及びEのITU-Tの添加後に添加しました。リスティングは、ペイロードフォーマットGSM-EFR、REDのために添加し、そしてH263-1998は、これらの追加のペイロードフォーマットのみダイナミックペイロードタイプ番号によって参照されるRFC 1890に続いて他の文書に掲載されました。
o The descriptions of the payload formats for G722, G728, GSM, VDVI were expanded.
G722、G728、GSM、VDVIのペイロード・フォーマットの記述を拡張した、O。
o The payload format for 1016 audio was removed and its static payload type assignment 1 was marked "reserved" because two interoperable implementations were not found.
oを1016オーディオのためのペイロード・フォーマットを除去し、2つの相互運用可能な実装が見つからなかったため、その静的ペイロードタイプ割当1「Reserved」のマークしました。
o Requirements for congestion control were added in Section 2.
輻輳制御のためのO要件は、セクション2で添加しました。
o This profile follows the suggestion in the revised RTP spec that RTCP bandwidth may be specified separately from the session bandwidth and separately for active senders and passive receivers.
Oこのプロファイルは、RTCP帯域幅がアクティブ送信者とパッシブ受信機のために別々にセッション帯域幅とは別に指定することができることを改訂RTP仕様で提案に従います。
o The mapping of a user pass-phrase string into an encryption key was deleted from Section 2 because two interoperable implementations were not found.
2つの相互運用可能な実装が見つからなかったため、O、暗号化キーへのユーザーパスフレーズ文字列のマッピングは、第2節から削除されました。
o The "quadrophonic" sample ordering convention for four-channel audio was removed to eliminate an ambiguity as noted in Section 4.1.
O 4チャンネルオーディオのための「quadrophonic」サンプルの順序規則は、4.1節で述べたように曖昧さを排除するために削除されました。
Non-functional changes:
非機能の変更：
o In Section 4.1, it is now explicitly stated that silence suppression is allowed for all audio payload formats. (This has always been the case and derives from a fundamental aspect of RTP's design and the motivations for packet audio, but was not explicit stated before.) The use of comfort noise is also explained.
O 4.1節では、今で明示的に無音抑制がすべてのオーディオペイロード形式のために許可されていることが述べられています。 （これは常にそうでしおよびRTPの設計の基本的な側面とパケットオーディオのための動機に由来しますが、前に述べた明示的ではなかったしました。）コンフォート・ノイズの使用も説明されています。
o In Section 4.1, the requirement level for setting of the marker bit on the first packet after silence for audio was changed from "is" to "SHOULD be", and clarified that the marker bit is set only when packets are intentionally not sent.
セクション4.1中のOは、オーディオ沈黙後の最初のパケットのマーカビットの設定に対する要求レベルは「は」する「である」から、パケットを意図的に送信されない場合、マーカビットのみ設定されていることが明らかになりました。
o Similarly, text was added to specify that the marker bit SHOULD be set to one on the last packet of a video frame, and that video frames are distinguished by their timestamps.
O同様に、テキストは、マーカービットがビデオフレームの最後のパケット上のいずれかに設定する必要があり、そのビデオ・フレームは、それらのタイムスタンプによって区別されることを指定するために添加しました。
o RFC references are added for payload formats published after RFC 1890.
O RFCの参照は、RFC 1890の後に発表されたペイロードフォーマットのために追加されます。
o The security considerations and full copyright sections were added.
セキュリティ上の考慮事項と完全な著作権のセクションoを追加されました。
o According to Peter Hoddie of Apple, only pre-1994 Macintosh used the 22254.54 rate and none the 11127.27 rate, so the latter was dropped from the discussion of suggested sampling frequencies.
OアップルのピーターHoddieによると、唯一の事前1994 Macintoshは11127.27率22254.54率とどれを使用するので、後者は提案サンプリング周波数の議論から削除されました。
o Table 1 was corrected to move some values from the "ms/packet" column to the "default ms/packet" column where they belonged.
Oテーブル1は、彼らが所属し、「デフォルトのMS /パケット」の欄に「MS /パケット」欄からいくつかの値を移動するために修正されました。
o Since the Interactive Multimedia Association ceased operations, an alternate resource was provided for a referenced IMA document.
インタラクティブ・マルチメディア協会は動作を停止するので、O、代替リソースは、参照IMA文書に供しました。
o A note has been added for G722 to clarify a discrepancy between the actual sampling rate and the RTP timestamp clock rate.
O注実際のサンプリングレート及びRTPタイムスタンプのクロック速度との相違を明確にするためにG722を追加しました。
o Small clarifications of the text have been made in several places, some in response to questions from readers. In particular:
Oテキストの小さな明確化は、一部の読者からの質問に応じて、いくつかの場所で行われています。特に：
- A definition for "media type" is given in Section 1.1 to allow the explanation of multiplexing RTP sessions in Section 6 to be more clear regarding the multiplexing of multiple media.
- 「メディアタイプ」の定義は、複数のメディアの多重化に関するより明確にするために、セクション6で多重RTPセッションの説明を可能にするために、セクション1.1に記載されています。
- The explanation of how to determine the number of audio frames in a packet from the length was expanded.
- 長さからパケット内のオーディオフレームの数を決定する方法の説明が拡大しました。
- More description of the allocation of bandwidth to SDES items is given.
- SDESアイテムへの帯域の割り当ての詳細な説明が与えられます。
- A note was added that the convention for the order of channels specified in Section 4.1 may be overridden by a particular encoding or payload format specification.
- ノートは、セクション4.1で指定されたチャネルの順序の規則は、特定の符号化またはペイロードフォーマット仕様によって上書きされてもよいことを添加しました。
- The terms MUST, SHOULD, MAY, etc. are used as defined in RFC 2119.
- RFC 2119で定義されるように用語は、等SHOULD、MAYは、使用されなければなりません。
o A second author for this document was added.
Oこの文書の第二著者が追加されました。
Implementations using the profile defined in this specification are subject to the security considerations discussed in the RTP specification [1]. This profile does not specify any different security services. The primary function of this profile is to list a set of data compression encodings for audio and video media.
本明細書で定義されたプロファイルを使用して実装はRTP仕様[1]で説明したセキュリティ上の考慮の対象となっています。このプロファイルは、任意の異なるセキュリティ・サービスを指定していません。このプロファイルの主な機能は、オーディオおよびビデオメディアのためのデータ圧縮符号化方式のセットをリストすることです。
Confidentiality of the media streams is achieved by encryption. Because the data compression used with the payload formats described in this profile is applied end-to-end, encryption may be performed after compression so there is no conflict between the two operations.
メディアストリームの機密性は、暗号化によって達成されます。このプロファイルで説明ペイロードフォーマットに使用されるデータ圧縮は、エンドツーエンドで適用されるので、二つの操作の間に競合がないように、暗号化は、圧縮後に行ってもよいです。
A potential denial-of-service threat exists for data encodings using compression techniques that have non-uniform receiver-end computational load. The attacker can inject pathological datagrams into the stream which are complex to decode and cause the receiver to be overloaded.
潜在的なサービス拒否の脅威は、不均一な受信端計算負荷を有する圧縮技術を使用してデータ・エンコーディングのために存在します。攻撃者が復号及び受信機が過負荷にさせるのに複雑であるストリームに病理学的なデータグラムを注入することができます。
As with any IP-based protocol, in some circumstances a receiver may be overloaded simply by the receipt of too many packets, either desired or undesired. Network-layer authentication MAY be used to discard packets from undesired sources, but the processing cost of the authentication itself may be too high. In a multicast environment, source pruning is implemented in IGMPv3 (RFC 3376) [24] and in multicast routing protocols to allow a receiver to select which sources are allowed to reach it.
任意のIPベースのプロトコルと同様に、いくつかの状況では、受信機は、所望のまたは望ましくないのいずれかで、あまりに多くのパケットを受信することによって簡単にオーバーロードされてもよいです。ネットワーク層認証は、望ましくないソースからのパケットを破棄するために使用することができるが、認証自体の処理コストが高すぎるかもしれません。マルチキャスト環境では、ソース・プルーニングは、受信機は、それに到達するために許可されているソースを選択できるようにするためのIGMPv3（RFC 3376）[24]およびマルチキャストルーティングプロトコルに実装されます。
The RTP specification establishes a registry of profile names for use by higher-level control protocols, such as the Session Description Protocol (SDP), RFC 2327 [6], to refer to transport methods. This profile registers the name "RTP/AVP".
RTP仕様は、輸送方法を参照するために、[6]、セッション記述プロトコル（SDP）のような、より高いレベルの制御プロトコル、RFC 2327によって使用するためのプロファイル名のレジストリを確立します。このプロファイルは、名前「RTP / AVP」を登録します。
Section 3 establishes the policy that no additional registration of static RTP payload types for this profile will be made beyond those added in this document revision and included in Tables 4 and 5. IANA may reference that section in declining to accept any additional registration requests. In Tables 4 and 5, note that types 1 and 2 have been marked reserved and the set of "dyn" payload types included has been updated. These changes are explained in Sections 6 and 9.
第3節では、このプロファイルの静的なRTPペイロードタイプの追加登録はIANAは、追加登録要求を受け入れるように低下でそのセクションを参照することができる。この文書改訂に加えたものを超えてなされず、表4および5に含まれるポリシーを確立します。表4および5に、タイプ1及び2は予約マークされていると「DYN」ペイロード・タイプのセットが更新されている含まれていることに注意してください。これらの変更は、セクション6,9で説明されています。
[1] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", RFC 3550, July 2003.
[1] Schulzrinneと、H.、Casner、S.、フレデリック、R.とV. Jacobson氏、 "RTP：リアルタイムアプリケーションのためのトランスポートプロトコル"、RFC 3550、2003年7月。
[2] Bradner, S., "Key Words for Use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[2]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[3] Apple Computer, "Audio Interchange File Format AIFF-C", August 1991. (also ftp://ftp.sgi.com/sgi/aiff-c.9.26.91.ps.Z).
[3]アップルコンピュータ、 "オーディオ交換ファイル形式AIFF-C"、1991年8月（もftp://ftp.sgi.com/sgi/aiff-c.9.26.91.ps.Z）。
[4] Braden, R., Clark, D. and S. Shenker, "Integrated Services in the Internet Architecture: an Overview", RFC 1633, June 1994.
[4]ブレーデン、R.、クラーク、D.とS. Shenker、 "インターネットアーキテクチャにおける統合サービス：概要"、RFC 1633、1994年6月。
[5] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z. and W. Weiss, "An Architecture for Differentiated Service", RFC 2475, December 1998.
[5]ブレイク、S.、ブラック、D.、カールソン、M.、デイヴィス、E.、王、Z.とW.ワイス、 "差別化サービスのためのアーキテクチャ"、RFC 2475、1998年12月。
[6] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998.
[6]ハンドレー、M.およびV. Jacobsonの "SDP：セッション記述プロトコル"、RFC 2327、1998年4月。
[7] Casner, S. and P. Hoschka, "MIME Type Registration of RTP Payload Types", RFC 3555, July 2003.
[7] Casner、S.とP. Hoschka、RFC 3555、2003年7月 "RTPペイロードタイプのMIMEタイプ登録を"。
[8] Freed, N., Klensin, J. and J. Postel, "Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures", BCP 13, RFC 2048, November 1996.
[8]解放され、N.、Klensin、J.およびJ.ポステル、 "多目的インターネットメール拡張（MIME）パート4：登録手順"、BCP 13、RFC 2048、1996年11月。
[9] Zopf, R., "Real-time Transport Protocol (RTP) Payload for Comfort Noise (CN)", RFC 3389, September 2002.
[9] Zopf、R.、 "コンフォートノイズ（CN）のためのリアルタイム転送プロトコル（RTP）ペイロード"、RFC 3389、2002年9月。
[10] Deleam, D. and J.-P. Petit, "Real-time implementations of the recent ITU-T low bit rate speech coders on the TI TMS320C54X DSP: results, methodology, and applications", in Proc. of International Conference on Signal Processing, Technology, and Applications (ICSPAT) , (Boston, Massachusetts), pp. 1656--1660, October 1996.
[10] Deleam、D.およびJ.-P. PROCで、プチ、「結果、方法論、およびアプリケーションTI TMS320C54X DSPに関する最近のITU-Tの低ビットレートの音声符号器のリアルタイムの実装」。信号処理、技術、および応用に関する国際会議（ICSPAT）、（ボストン、マサチューセッツ州）、頁。1656--1660、1996年10月の。
[11] Mouly, M. and M.-B. Pautet, The GSM system for mobile communications Lassay-les-Chateaux, France: Europe Media Duplication, 1993.
[11] Mouly、M.およびM.-B. Pautet、モバイル通信Lassayレシャトー、フランスのためのGSMシステム：ヨーロッパメディア複製、1993。
[12] Degener, J., "Digital Speech Compression", Dr. Dobb's Journal, December 1994.
[12] Degener、J.、 "デジタル音声圧縮"、博士ドッブのジャーナル、1994年12月。
[13] Redl, S., Weber, M. and M. Oliphant, An Introduction to GSM Boston: Artech House, 1995.
[13] REDL、S.、ウェーバー、M.およびM.オリファント、GSMボストンへの紹介：アーテック・ハウス、1995。
[14] Hoffman, D., Fernando, G., Goyal, V. and M. Civanlar, "RTP Payload Format for MPEG1/MPEG2 Video", RFC 2250, January 1998.
[14]ホフマン、D.、フェルナンド、G.、Goyal氏、V.とM. Civanlar、 "MPEG1 / MPEG2ビデオのためのRTPペイロードフォーマット"、RFC 2250、1998年1月。
[15] Jayant, N. and P. Noll, Digital Coding of Waveforms--Principles and Applications to Speech and Video Englewood Cliffs, New Jersey: Prentice-Hall, 1984.
[15]ジャヤント、N.およびP.ノル、波形のデジタルコーディング - 音声とビデオイングルウッドクリフ、ニュージャージー州への原理と応用：プレンティスホール、1984。
[16] McKay, K., "RTP Payload Format for PureVoice(tm) Audio", RFC 2658, August 1999.
[16]マッケイ、K.、 "PureVoice（tm）のためのRTPペイロードフォーマットのオーディオ"、RFC 2658、1999年8月。
[17] Perkins, C., Kouvelas, I., Hodson, O., Hardman, V., Handley, M., Bolot, J.-C., Vega-Garcia, A. and S. Fosse-Parisis, "RTP Payload for Redundant Audio Data", RFC 2198, September 1997.
[17]パーキンス、C.、Kouvelas、I.、ホドソン、O.、ハードマン、V.、ハンドレー、M.、Bolot、J.-C.、ベガ・ガルシア、A.及びS.フォッシー-Parisis、 "冗長音声データのRTPペイロード」、RFC 2198、1997年9月。
[18] Speer, M. and D. Hoffman, "RTP Payload Format of Sun's CellB Video Encoding", RFC 2029, October 1996.
[18]シュペーア、M.とD.ホフマン、 "SunのCELLBビデオエンコーディングのRTPペイロードフォーマット"、RFC 2029、1996年10月。
[19] Berc, L., Fenner, W., Frederick, R., McCanne, S. and P. Stewart, "RTP Payload Format for JPEG-Compressed Video", RFC 2435, October 1998.
[19] Berc、L.、フェナー、W.、フレデリック、R.、McCanne、S.とP.スチュワート、 "JPEG圧縮ビデオのためのRTPペイロードフォーマット"、RFC 2435、1998年10月。
[20] Turletti, T. and C. Huitema, "RTP Payload Format for H.261 Video Streams", RFC 2032, October 1996.
[20] Turletti、T.とC.のHuitema、 "H.261ビデオストリームのためのRTPペイロードフォーマット"、RFC 2032、1996年10月。
[21] Zhu, C., "RTP Payload Format for H.263 Video Streams", RFC 2190, September 1997.
[21]朱、C.、 "H.263ビデオストリームのためのRTPペイロードフォーマット"、RFC 2190、1997年9月。
[22] Bormann, C., Cline, L., Deisher, G., Gardos, T., Maciocco, C., Newell, D., Ott, J., Sullivan, G., Wenger, S. and C. Zhu, "RTP Payload Format for the 1998 Version of ITU-T Rec. H.263 Video (H.263+)", RFC 2429, October 1998.
[22]ボルマン、C.、クライン、L.、Deisher、G.、ガルドス、T.、Maciocco、C.、ニューウェル、D.、オット、J.、サリバン、G.、ウェンガー、S.及びC.朱、RFC 2429、1998年10月 "ITU-T勧告H.263ビデオ（H.263 +）の1998年バージョンのためのRTPペイロードフォーマット"。
[23] Schulzrinne, H., Rao, A. and R. Lanphier, "Real Time Streaming Protocol (RTSP)", RFC 2326, April 1998.
[23] SchulzrinneとH.とラオとA.とR. Lanphier、 "リアルタイムストリーミングプロトコル（RTSP）"、RFC 2326、1998年4月。
[24] Cain, B., Deering, S., Kouvelas, I., Fenner, B. and A. Thyagarajan, "Internet Group Management Protocol, Version 3", RFC 3376, October 2002.
[24]カイン、B.、デアリング、S.、Kouvelas、I.、フェナー、B.とA. Thyagarajan、 "インターネットグループ管理プロトコル、バージョン3"、RFC 3376、2002年10月。
Note: Several sections below refer to the ITU-T Software Tool Library (STL). It is available from the ITU Sales Service, Place des Nations, CH-1211 Geneve 20, Switzerland (also check http://www.itu.int). The ITU-T STL is covered by a license defined in ITU-T Recommendation G.191, "Software tools for speech and audio coding standardization".
注：以下のいくつかのセクションでは、ITU-Tのソフトウェアツールライブラリ（STL）を参照してください。これは、ITU販売サービス、場所デナシオン、CH-1211ジュネーブ20、スイス（もhttp://www.itu.intを確認してください）から入手可能です。 ITU-TのSTLは、ITU-T勧告G.191で定義されているライセンス、「スピーチおよびオーディオコーディング標準化のためのソフトウェアツール」で覆われています。
DVI4
DVICH
An archived copy of the document IMA Recommended Practices for Enhancing Digital Audio Compatibility in Multimedia Systems (version 3.0), which describes the IMA ADPCM algorithm, is available at:
文書のアーカイブコピーIMAは、IMA ADPCMアルゴリズムを記述するマルチメディアシステムにおける強化デジタルオーディオ互換（バージョン3.0）、のためのプラクティスを推奨で入手できます。
http://www.cs.columbia.edu/~hgs/audio/dvi/
ｈっｔｐ：／／ｗっｗ。ｃｓ。こぅｍびあ。えづ／〜ｈｇｓ／あうぢお／ｄゔぃ／
An implementation is available from Jack Jansen at
実装がでジャック・ヤンセンから入手可能です。
ftp://ftp.cwi.nl/local/pub/audio/adpcm.shar
ｆｔｐ：／／ｆｔｐ。ｃうぃ。んｌ／ぉかｌ／ぷｂ／あうぢお／あｄｐｃｍ。しゃｒ
G722
Juhai
An implementation of the G.722 algorithm is available as part of the ITU-T STL, described above.
G.722アルゴリズムの実装は、上記ITU-TのSTLの一部として利用可能です。
G723
Juhaa
The reference C code implementation defining the G.723.1 algorithm and its Annexes A, B, and C are available as an integral part of Recommendation G.723.1 from the ITU Sales Service, address listed above. Both the algorithm and C code are covered by a specific license. The ITU-T Secretariat should be contacted to obtain such licensing information.
G.723.1アルゴリズムおよびその付属書A、B、及びCを規定する基準Cコードの実装は、ITU販売サービス、上記アドレスから勧告G.723.1の一体部分として利用可能です。アルゴリズムとCコードの両方が特定のライセンスでカバーされています。 ITU-T事務局は、このようなライセンス情報を取得するために連絡しなければなりません。
G726
G726
G726 is specified in the ITU-T Recommendation G.726, "40, 32, 24, and 16 kb/s Adaptive Differential Pulse Code Modulation (ADPCM)". An implementation of the G.726 algorithm is available as part of the ITU-T STL, described above.
G726は、ITU-T勧告G.726、 "40、32、24、及び16キロバイト/秒適応差分パルス符号変調（ADPCM）" で指定されています。 G.726アルゴリズムの実装は、上記ITU-TのSTLの一部として利用可能です。
G729
Juhas
The reference C code implementation defining the G.729 algorithm and its Annexes A through I are available as an integral part of Recommendation G.729 from the ITU Sales Service, listed above. Annex I contains the integrated C source code for all G.729 operating modes. The G.729 algorithm and associated C code are covered by a specific license. The contact information for obtaining the license is available from the ITU-T Secretariat.
Iを介してG.729アルゴリズムとその附属書Aを規定する基準Cコードの実装は、上記ITU販売サービス、から勧告G.729の一体部分として利用可能です。附属書Iには、すべてのG.729の動作モードのための統合されたCソース・コードが含まれています。 G.729アルゴリズムと関連するCコードは、特定のライセンスによって覆われています。ライセンスを取得するための連絡先情報は、ITU-T事務局から入手可能です。
GSM
GSM
A reference implementation was written by Carsten Bormann and Jutta Degener (then at TU Berlin, Germany). It is available at
リファレンス実装は、カールステンボルマンと（その後TUベルリン、ドイツ）ユッタ・デッジナーによって書かれました。それはで利用可能です
http://www.dmn.tzi.org/software/gsm/
ｈっｔｐ：／／ｗっｗ。ｄｍん。ｔじ。おｒｇ／そｆとぁれ／ｇｓｍ／
Although the RPE-LTP algorithm is not an ITU-T standard, there is a C code implementation of the RPE-LTP algorithm available as part of the ITU-T STL. The STL implementation is an adaptation of the TU Berlin version.
RPE-LTPアルゴリズムは、ITU-T規格ではありませんが、ITU-TのSTLの一部として利用可能なRPE-LTPアルゴリズムのCコードの実装があります。 STLの実装では、TUベルリンのバージョンの適応です。
LPC
LPC
An implementation is available at
実装は、提供されています
ftp://parcftp.xerox.com/pub/net-research/lpc.tar.Z
ｆｔｐ：／／ぱｒｃｆｔｐ。ぇろｘ。こｍ／ぷｂ／ねｔーれせあｒｃｈ／ｌｐｃ。たｒ。Ｚ
PCMU, PCMA
PCMU、BCMA
An implementation of these algorithms is available as part of the ITU-T STL, described above.
これらのアルゴリズムの実装は、上記ITU-TのSTLの一部として利用可能です。
The comments and careful review of Simao Campos, Richard Cox and AVT Working Group participants are gratefully acknowledged. The GSM description was adopted from the IMTC Voice over IP Forum Service Interoperability Implementation Agreement (January 1997). Fred Burg and Terry Lyons helped with the G.729 description.
シモン・カンポス、リチャード・コックスとAVT作業部会の参加者の意見と慎重に検討を深く感謝しています。 GSMの記述は、IPフォーラムサービス相互運用性の実装合意書（1997年1月）の上にIMTC声から採用されました。フレッドブルクとテリー・ライオンズは、G.729の説明を手伝ってくれました。
The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat.
IETFは、そのような権限下で、ライセンスがたりないかもしれない可能性があるためにどの本書または程度に記載されている技術の実装や使用に関係すると主張される可能性があります任意の知的財産やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能。また、そうした権利を特定するために取り組んできたことを表していないん。スタンダードトラックおよび標準関連文書における権利に関するIETFの手続きの情報は、BCP-11に記載されています。権利の主張のコピーは、出版のために利用可能とライセンスの保証が利用できるようにする、または本仕様の実装者または利用者が、そのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますIETF事務局から。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director.
IETFは、その注意にこの標準を実践するために必要な場合があり技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 IETF専務に情報を扱ってください。
Henning Schulzrinne Department of Computer Science Columbia University 1214 Amsterdam Avenue New York, NY 10027 United States
ヘニングSchulzrinneとコンピュータサイエンスコロンビア大学の学部1214年アムステルダムアベニュー、ニューヨーク、NY 10027米国
EMail: schulzrinne@cs.columbia.edu
メールアドレス：schulzrinne@cs.columbia.edu
Stephen L. Casner Packet Design 3400 Hillview Avenue, Building 3 Palo Alto, CA 94304 United States
スティーブンL. Casnerパケットデザイン3400ヒルビュー・アベニュー、3パロアルト、CA 94304米国の構築
EMail: casner@acm.org
メールアドレス：casner@acm.org
Copyright (C) The Internet Society (2003). All Rights Reserved.
著作権（C）インターネット協会（2003）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の制限は永久で、インターネット学会やその後継者や譲渡者によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。