Network Working Group A. Sollaud
Request for Comments: 4749 France Telecom
Category: Standards Track October 2006
RTP Payload Format for the G.729.1 Audio Codec
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 (2006).
著作権（C）インターネット協会（2006）。
Abstract
抽象
This document specifies a Real-time Transport Protocol (RTP) payload format to be used for the International Telecommunication Union (ITU-T) G.729.1 audio codec. A media type registration is included for this payload format.
この文書では、国際電気通信連合（ITU-T）G.729.1オーディオコーデックを使用するリアルタイムトランスポートプロトコル（RTP）ペイロード形式を指定します。メディアタイプ登録は、このペイロード形式のために含まれています。
Table of Contents
目次
1. Introduction ....................................................2
2. Background ......................................................2
3. Embedded Bit Rates Considerations ...............................3
4. RTP Header Usage ................................................3
5. Payload Format ..................................................4
5.1. Payload Structure ..........................................4
5.2. Payload Header: MBS Field ..................................4
5.3. Payload Header: FT Field ...................................6
5.4. Audio Data .................................................6
6. Payload Format Parameters .......................................7
6.1. Media Type Registration ....................................7
6.2. Mapping to SDP Parameters ..................................8
6.2.1. Offer-Answer Model Considerations ...................9
6.2.2. Declarative SDP Considerations .....................11
7. Congestion Control .............................................11
8. Security Considerations ........................................11
9. IANA Considerations ............................................12
10. References ....................................................12
10.1. Normative References .....................................12
10.2. Informative References ...................................12
The International Telecommunication Union (ITU-T) recommendation G.729.1 [1] is a scalable and wideband extension of the recommendation G.729 [9] audio codec. This document specifies the payload format for packetization of G.729.1 encoded audio signals into the Real-time Transport Protocol (RTP).
国際電気通信連合（ITU-T）勧告G.729.1 [1]勧告G.729 [9]オーディオコーデックの拡張性と広帯域拡張です。この文書では、リアルタイムトランスポートプロトコル（RTP）にG.729.1エンコードされたオーディオ信号のパケットのペイロード形式を指定します。
The payload format itself is described in Section 5. A media type registration and the details for the use of G.729.1 with SDP are given in Section 6.
ペイロードフォーマット自体は、メディアタイプ登録とSDPとのG.729.1の使用に関する詳細はセクション6に記載されているセクション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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますRFC 2119に記載されるように解釈される[2]。
G.729.1 is an 8-32 kbps scalable wideband (50-7000 Hz) speech and audio coding algorithm interoperable with G.729, G.729 Annex A, and G.729 Annex B. It provides a standardized solution for packetized voice applications that allows a smooth transition from narrowband to wideband telephony.
G.729.1は、パケット化音声アプリケーションのための標準化されたソリューションを提供するG.729、G.729付属書A、およびG.729付属書Bとの相互運用性8-32 kbpsのスケーラブルなワイドバンド（50から7000ヘルツ）音声及びオーディオ符号化アルゴリズムでありますすなわち、狭帯域から広帯域電話へのスムーズな移行を可能にします。
The most important services addressed are IP telephony and videoconferencing, either for enterprise corporate networks or for mass market (like Public Switched Telephone Network (PSTN) emulation over DSL or wireless access). Target devices can be IP phones or other VoIP handsets, home gateways, media gateways, IP Private Branch Exchange (IPBX), trunking equipment, voice messaging servers, etc.
（公衆交換電話網DSLまたは無線アクセスオーバー（PSTN）のエミュレーションをスイッチのように）対処し、最も重要なサービスは、エンタープライズ企業ネットワークのためか、マス市場向けのいずれか、IP電話やビデオ会議です。ターゲットデバイスは、IP電話や他のVoIPハンドセット、ホームゲートウェイ、メディア・ゲートウェイ、IP構内交換機（IPBX）、トランキング機器、音声メッセージングサーバなどをすることができ
For all those applications, the scalability feature allows tuning the bit rate versus quality trade-off, possibly in a dynamic way during a session, taking into account service requirements and network transport constraints.
これらすべてのアプリケーションでは、スケーラビリティ機能は、アカウントサービスの要件とネットワークトランスポートの制約を考慮して、おそらくセッション中に動的な方法では、高品質のトレードオフのビットレートを調整することができます。
The G.729.1 coder produces an embedded bitstream structured in 12 layers corresponding to 12 available bit rates between 8 and 32 kbps. The first layer, at 8 kbps, is called the core layer and is bitstream compatible with the ITU-T G.729/G.729A coder. At 12 kbps, a second layer improves the narrowband quality. Upper layers provide wideband audio (50-7000 Hz) between 14 and 32 kbps, with a 2 kbps granularity allowing graceful quality improvements. Only the core layer is mandatory to decode understandable speech; upper layers provide quality enhancement and wideband enlargement.
G.729.1コーダは8と32 kbpsの間の12の利用可能なビットレートに対応した12層で構成埋め込まれたビットストリームを生成します。第一層は、8 kbpsで、コア層と呼ばれ、ITU-T G.729 / G.729Aコーダと互換性ビットストリームです。 12 kbpsで、第二層は、狭帯域品質を向上させることができます。上位層は、優雅な品質改善を可能にする2 Kbpsの粒度で、14と32 kbpsの間の広帯域オーディオ（50から7000 Hz）を提供します。のみコア層は理解音声をデコードするために必須です。上位層は、品質向上と広帯域の拡大を提供しています。
The codec operates on 20-ms frames, and the default sampling rate is 16 kHz. Input and output at 8 kHz are also supported, at all bit rates.
コーデックは、20ミリ秒のフレームで動作し、既定のサンプリングレートは16kHzです。 8 kHzで入力と出力は、すべてのビットレートで、サポートされています。
The embedded property of G.729.1 streams provides a mechanism to adjust the bandwidth demand. At any time, a sender can change its sending bit rate without external signalling, and the receiver will be able to properly decode the frames. It may help to control congestion, since the bandwidth can be adjusted by selecting another bit rate.
G.729.1ストリームの組み込みプロパティは、帯域幅の需要を調整するためのメカニズムを提供します。任意の時点で、送信者は、外部のシグナリングなしに、その送信ビットレートを変更することができ、受信機は、適切にフレームを復号することができるであろう。これは、帯域幅が別のビットレートを選択することによって調整することができるので、輻輳を制御するのに役立ち得ます。
The ability to adjust the bandwidth may also help when having a fixed bandwidth link dedicated to voice calls, for example in a residential or trunking gateway. In that case, the system can change the bit rates depending on the number of simultaneous calls. This will only impact the sending bandwidth. In order to adjust the receiving bandwidth as well, we introduce an in-band signalling to request the other party to change its own sending bit rate. This in-band request is called MBS, for Maximum Bit rate Supported. It is described in Section 5.2. Note that it is only useful for two-way unicast G.729.1 traffic, because when A sends an in-band MBS to B in order to request that B modify its sending bit rate, it concerns the stream from B to A. If there is no G.729.1 stream in the reverse direction, the MBS will have no effect.
音声通話に専用の固定帯域幅リンクを持ったときに、帯域幅を調整する能力はまた、住宅やトランキングゲートウェイでは、たとえば、役立つかもしれません。その場合、システムは同時コール数に応じてビットレートを変更することができます。これは、送信帯域幅に影響を与えます。同様に受信帯域幅を調整するために、我々は独自の送信ビットレートを変更するには、相手を要求するために、シグナリングインバンド紹介します。最大ビットレートがサポートされているため、このインバンド要求は、MBSと呼ばれています。これは、5.2節に記載されています。 Aは、Bは、その送信ビットレートを変更することを要求するためにBにインバンドMBSを送信する場合があった場合、それはBからAへのストリームに関するので、それは、双方向ユニキャストG.729.1トラフィックに対してのみ有用であることに注意してください逆方向にはG.729.1ストリームはありません、MBSは効果がありません。
The format of the RTP header is specified in RFC 3550 [3]. This payload format uses the fields of the header in a manner consistent with that specification.
RTPヘッダのフォーマットは、RFC 3550で指定されている[3]。このペイロードフォーマットは、その仕様と一致する方法で、ヘッダのフィールドを使用します。
The RTP timestamp clock frequency is the same as the default sampling frequency: 16 kHz.
16 kHzの：RTPタイムスタンプのクロック周波数は、既定のサンプリング周波数と同じです。
G.729.1 has also the capability to operate with 8 kHz sampled input/ output signals at all bit rates. It does not affect the bitstream, and the decoder does not require a priori knowledge about the sampling rate of the original signal at the input of the encoder. Therefore, depending on the implementation and the audio acoustic capabilities of the devices, the input of the encoder and/or the output of the decoder can be configured at 8 kHz; however, a 16 kHz RTP clock rate MUST always be used.
G.729.1は、すべてのビットレートで8kHzでサンプリングされた入力/出力信号で動作する能力を有します。これは、ビットストリームに影響を与えない、及びデコーダは、エンコーダの入力における元の信号のサンプリングレートについての先験的な知識を必要としません。したがって、実装およびデバイスのオーディオ音響機能に応じて、エンコーダおよび/またはデコーダの出力の入力は8kHzで構成することができます。しかし、16 kHzのRTPクロックレートを常に使用しなければなりません。
The duration of one frame is 20 ms, corresponding to 320 samples at 16 kHz. Thus the timestamp is increased by 320 for each consecutive frame.
1つのフレームの持続時間は、16 kHzで320個のサンプルに対応し、20ミリ秒です。従って、タイムスタンプは、各連続フレーム320だけ増加されます。
The M bit MUST be set to zero in all packets.
Mビットは、すべてのパケットにゼロに設定しなければなりません。
The assignment of an RTP payload type for this packet format is outside the scope of the document, and will not be specified here. It is expected that the RTP profile under which this payload format is being used will assign a payload type for this codec or specify that the payload type is to be bound dynamically (see Section 6.2).
このパケットフォーマットのためのRTPペイロードタイプの割り当ては、文書の範囲外であり、ここで指定されません。なお、このペイロード・フォーマットが使用されている下RTPプロファイルがこのコーデックのためのペイロードタイプを割り当てるか、ペイロードタイプ（セクション6.2を参照）を動的に結合されるように指定することが期待されます。
The complete payload consists of a payload header of 1 octet, followed by zero or more consecutive audio frames at the same bit rate.
完全なペイロードは、同じビットレートでゼロまたはそれ以上の連続したオーディオフレームに続く1つのオクテットのペイロードヘッダ、から成ります。
The payload header consists of two fields: MBS (see Section 5.2) and FT (see Section 5.3).
MBS（第5.2節を参照）、FT（セクション5.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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MBS | FT | |
+-+-+-+-+-+-+-+-+ +
: zero or more frames at the same bit rate :
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
MBS (4 bits): maximum bit rate supported. Indicates a maximum bit rate to the encoder at the site of the receiver of this payload. The value of the MBS field is set according to the following table:
MBS（4ビット）：最大ビットレートがサポートされています。このペイロードの受信機のサイトでエンコーダへの最大ビットレートを示します。 MBSフィールドの値は、以下の表に従って設定されています。
+-------+--------------+
| MBS | max bit rate |
+-------+--------------+
| 0 | 8 kbps |
| 1 | 12 kbps |
| 2 | 14 kbps |
| 3 | 16 kbps |
| 4 | 18 kbps |
| 5 | 20 kbps |
| 6 | 22 kbps |
| 7 | 24 kbps |
| 8 | 26 kbps |
| 9 | 28 kbps |
| 10 | 30 kbps |
| 11 | 32 kbps |
| 12-14 | (reserved) |
| 15 | NO_MBS |
+-------+--------------+
The MBS is used to tell the other party the maximum bit rate one can receive. The encoder MUST NOT exceed the sending rate indicated by the received MBS. Note that, due to the embedded property of the coding scheme, the encoder can send frames at the MBS rate or any lower rate. As long as it does not exceed the MBS, the encoder can change its bit rate at any time without previous notice.
MBSは、最大ビットレートの1を受け取ることができ、相手に伝えるために使用されています。エンコーダは、受信されたMBSで示される送信レートを超えてはなりません。符号化方式の埋め込み性に起因する、なお、エンコーダは、MBSレートまたは任意のより低いレートでフレームを送信することができます。であればMBSを超えないように、エンコーダは、予告なしにいつでも、そのビットレートを変更することができます。
Note that the MBS is a codec bit rate; the actual network bit rate is higher and depends on the overhead of the underlying protocols.
MBSは、コーデックのビットレートであることに留意されたいです。実際のネットワークのビットレートが高く、基本的なプロトコルのオーバーヘッドに依存します。
The MBS received is valid until the next MBS is received, i.e., a newly received MBS value overrides the previous one.
受信されたMBSは、次のMBSを受信するまで、すなわち、新たに受信したMBS値が前のものを上書き有効です。
If a payload with a reserved MBS value is received, the MBS MUST be ignored.
予約MBS値を持つペイロードを受信した場合、MBSは無視しなければなりません。
The MBS field MUST be set to 15 for packets sent to a multicast group and MUST be ignored on packets received from a multicast group.
MBSフィールドは、マルチキャストグループに送信されたパケットのために15に設定しなければならなくて、マルチキャストグループから受信したパケットに無視しなければなりません。
The MBS field MUST be set to 15 in all packets when the actual MBS value is sent through non-RTP means. This is out of the scope of this specification.
実際のMBS値は非RTP手段を介して送信されるときMBSフィールドは、すべてのパケットに15に設定しなければなりません。これは、この仕様書の範囲外です。
See Sections 3 and 7 for more details on the use of MBS for congestion control.
輻輳制御のためのMBSの使用の詳細については、セクション3と7を参照してください。
FT (4 bits): Frame type of the frame(s) in this packet, as per the following table:
FT（4ビット）：このパケットの中のフレーム（複数可）のフレームタイプ、次の表の通り。
+-------+---------------+------------+
| FT | encoding rate | frame size |
+-------+---------------+------------+
| 0 | 8 kbps | 20 octets |
| 1 | 12 kbps | 30 octets |
| 2 | 14 kbps | 35 octets |
| 3 | 16 kbps | 40 octets |
| 4 | 18 kbps | 45 octets |
| 5 | 20 kbps | 50 octets |
| 6 | 22 kbps | 55 octets |
| 7 | 24 kbps | 60 octets |
| 8 | 26 kbps | 65 octets |
| 9 | 28 kbps | 70 octets |
| 10 | 30 kbps | 75 octets |
| 11 | 32 kbps | 80 octets |
| 12-14 | (reserved) | |
| 15 | NO_DATA | 0 |
+-------+---------------+------------+
The FT value 15 (NO_DATA) indicates that there is no audio data in the payload. This MAY be used to update the MBS value when there is no audio frame to transmit. The payload will then be reduced to the payload header.
FT値15（NO_DATA）はペイロードには音声データが存在しないことを示しています。これは、送信すべき音声フレームがない場合MBS値を更新するために使用され得ます。ペイロードは、次に、ペイロードヘッダに低減されます。
If a payload with a reserved FT value is received, the whole payload MUST be ignored.
予約済みFT値を持つペイロードを受信した場合、全体のペイロードは無視しなければなりません。
Audio data of a payload contains one or more consecutive audio frames at the same bit rate. The audio frames are packed in order of time, that is, oldest first.
ペイロードの音声データは、同じビットレートで一の以上の連続したオーディオフレームが含まれています。オーディオフレームはつまり、古い順、時間順にパックされています。
The size of one frame is given by the FT field, as per the table in Section 5.3, and the actual number of frames is easy to infer from the size of the audio data part:
1つのフレームのサイズは、5.3節の表に従って、FTフィールドによって与えられ、フレームの実際の数は、オーディオデータ部のサイズから推測することは容易です。
nb_frames = (size_of_audio_data) / (size_of_one_frame).
nb_frames =（size_of_audio_data）/（size_of_one_frame）。
Only full frames must be considered. So if there is a remainder to the division above, the corresponding remaining bytes in the received payload MUST be ignored.
唯一のフルフレームが考慮されなければなりません。上記分割に余りがある場合に、受信したペイロードに対応する残りのバイトは無視しなければなりません。
Note that if FT=15, there will be no audio frame in the payload.
FT = 15と、ペイロードには音声フレームが存在しないことに注意してください。
This section defines the parameters that may be used to configure optional features in the G.729.1 RTP transmission.
このセクションでは、G.729.1 RTP送信でオプション機能を設定するために使用することができるパラメータを定義します。
The parameters are defined here as part of the media subtype registration for the G.729.1 codec. A mapping of the parameters into the Session Description Protocol (SDP) [5] is also provided for those applications that use SDP. In control protocols that do not use MIME or SDP, the media type parameters must be mapped to the appropriate format used with that control protocol.
パラメータは、G.729.1コーデックのメディアサブタイプ登録の一部としてここで定義されています。セッション記述プロトコル（SDP）[5]また、SDPを使用するアプリケーションのために提供されるにパラメータのマッピング。 MIMEまたはSDPを使用しない制御プロトコルでは、メディアタイプパラメータは、その制御プロトコルで使用される適切なフォーマットにマッピングされなければなりません。
This registration is done using the template defined in RFC 4288 [6] and following RFC 3555 [7].
この登録は、[6] RFC 4288で定義されたテンプレートを使用し、RFC 3555 [7]下記行われます。
Type name: audio
型名：オーディオ
Subtype name: G7291
サブタイプ名：G7291
Required parameters: none
必須パラメータ：なし
Optional parameters:
オプションのパラメータ：
maxbitrate: the absolute maximum codec bit rate for the session, in bits per second. Permissible values are 8000, 12000, 14000, 16000, 18000, 20000, 22000, 24000, 26000, 28000, 30000, and 32000. 32000 is implied if this parameter is omitted. The maxbitrate restricts the range of bit rates which can be used. The bit rates indicated by FT and MBS fields in the RTP packets MUST NOT exceed maxbitrate.
maxBitrate：bps単位セッションの絶対最大コーデック・ビット・レート、。このパラメータが省略された場合、許容値は8000、12000、14000、16000、18000、20000、22000、24000、26000、28000、30000、および32000 32000が暗示されています。 maxBitrateを使用することができるビットレートの範囲を制限します。 RTPパケットでFTとMBSフィールドで示されるビットレートはのmaxBitrateを超えてはなりません。
mbs: the current maximum codec bit rate supported as a receiver, in bits per second. Permissible values are in the same set as for the maxbitrate parameter, with the constraint that mbs MUST be lower or equal to maxbitrate. If the mbs parameter is omitted, it is set to the maxbitrate value. So if both mbs and maxbitrate are omitted, they are both set to 32000. The mbs parameter corresponds to a MBS value in the RTP packets as per table in Section 5.2 of RFC 4749. Note that this parameter may be dynamically updated by the MBS field of the RTP packets sent; it is not an absolute value for the session.
MBS：bps単位で受信機としてサポートされている現在の最大コーデック・ビット・レート、。許容値は、MBSが低いかのmaxBitrateに等しくなければならない制約と、のmaxBitrateパラメータの同じセットです。 MBSのパラメータが省略された場合、それはのmaxBitrate値に設定されています。両MBSとのmaxBitrateが省略されている場合、それらは両方ともMBSパラメータを32000に設定され、このパラメータを動的MBSフィールドによって更新されてもよいことはRFCのセクション5.2 4749.注テーブルに従ってRTPパケット内のMBS値に対応送信されたRTPパケットの。それはセッションのための絶対値ではありません。
ptime: the recommended length of time (in milliseconds) represented by the media in a packet. See Section 6 of RFC 4566 [5].
PTIME：時間（ミリ秒）の推奨長パケットにおけるメディアによって表されます。 RFC 4566のセクション6 [5]を参照してください。
maxptime: the maximum length of time (in milliseconds) that can be encapsulated in a packet. See Section 6 of RFC 4566 [5]
maxptime：時間（ミリ秒）の最大長パケットにカプセル化することができます。 [5] RFC 4566のセクション6を参照してください。
Encoding considerations: This media type is framed and contains binary data; see Section 4.8 of RFC 4288 [6].
エンコードの考慮事項：このメディアタイプは、フレームとバイナリデータが含まれています。 RFC 4288のセクション4.8 [6]を参照してください。
Security considerations: See Section 8 of RFC 4749
セキュリティの考慮事項：RFC 4749のセクション8を参照してください。
Interoperability considerations: none
相互運用性に関する注意事項：なし
Published specification: RFC 4749
公開された仕様：RFC 4749
Applications which use this media type: Audio and video conferencing tools.
このメディアタイプを使用するアプリケーション：オーディオおよびビデオ会議ツール。
Additional information: none
追加情報：なし
Person & email address to contact for further information: Aurelien Sollaud, aurelien.sollaud@orange-ftgroup.com
人と詳細のために連絡する電子メールアドレス：オーレリアンSollaud、aurelien.sollaud@orange-ftgroup.com
Intended usage: COMMON
意図している用法：COMMON
Restrictions on usage: This media type depends on RTP framing, and hence is only defined for transfer via RTP [3].
使用上の制限：このメディアタイプは、RTP [3]を介してRTPフレーミングに依存し、したがってのみ転送のために定義されています。
Author: Aurelien Sollaud
著者：オーレリアンSollaud
Change controller: IETF Audio/Video Transport working group delegated from the IESG
変更コントローラ：IESGから委任IETFオーディオ/ビデオ輸送ワーキンググループ
The information carried in the media type specification has a specific mapping to fields in the Session Description Protocol (SDP) [5], which is commonly used to describe RTP sessions. When SDP is used to specify sessions employing the G.729.1 codec, the mapping is as follows:
メディアタイプ仕様で搬送される情報は、[5]、一般にRTPセッションを記述するために使用されるセッション記述プロトコル（SDP）内のフィールドに特定のマッピングを有します。 SDPがG.729.1コーデックを使用するセッションを指定するために使用される場合、以下のように、マッピングは次のとおりです。
o The media type ("audio") goes in SDP "m=" as the media name.
Oメディアタイプ（「オーディオ」）は、メディア名としてSDP「m =」に進みます。
o The media subtype ("G7291") goes in SDP "a=rtpmap" as the encoding name. The RTP clock rate in "a=rtpmap" MUST be 16000 for G.729.1.
Oメディアサブタイプ（「G7291」）は、符号化名としてSDPの「a = rtpmap」に進みます。 「A = rtpmap」のRTPクロックレートは、G.729.1のために16000でなければなりません。
o The parameters "ptime" and "maxptime" go in the SDP "a=ptime" and "a=maxptime" attributes, respectively.
Oパラメータの "PTIME" と "maxptime" は、それぞれ、 "A = PTIME" と "A = maxptimeは" 属性SDPに行きます。
o Any remaining parameters go in the SDP "a=fmtp" attribute by copying them directly from the media type string as a semicolon separated list of parameter=value pairs.
oを任意の残りのパラメータは、SDPのパラメータ=値のペアをセミコロンで区切ったリストで、メディアタイプ文字列から直接それらをコピーして「=のfmtp」属性を行きます。
Some example SDP session descriptions utilizing G.729.1 encodings follow.
G.729.1エンコーディングを利用するいくつかの例SDPセッション記述が続きます。
Example 1: default parameters
例1：デフォルトのパラメータ
m=audio 53146 RTP/AVP 98 a=rtpmap:98 G7291/16000
M =オーディオ53146 RTP / AVP 98 = rtpmap：98 G7291 / 16000
Example 2: recommended packet duration of 40 ms (=2 frames), maximum bit rate is 12 kbps, and initial MBS set to 8 kbps. It could be a loaded PSTN gateway which can operate at 12 kbps but asks to initially reduce the bit rate to 8 kbps.
実施例2：40ミリ秒（= 2つのフレーム）の推奨パケット持続時間、最大ビットレートは12 kbpsの、8 kbpsに設定された初期MBSあります。それは12 kbpsで動作するが、最初は8 kbpsにビットレートを低減するように要求することができるロードPSTNゲートウェイとすることができます。
m=audio 51258 RTP/AVP 99 a=rtpmap:99 G7291/16000 a=fmtp:99 maxbitrate=12000; mbs=8000 a=ptime:40
M =オーディオ51258 RTP / AVP 99 = rtpmap：99 G7291 / 16000 =のfmtp：99のmaxBitrate = 12000。 MBS = 8000 = PTIME：40
The following considerations apply when using SDP offer-answer procedures [8] to negotiate the use of G.729.1 payload in RTP:
SDPオファー・アンサー・プロシージャを使用する場合、次の考慮事項[8] RTPにおけるG.729.1ペイロードの使用を交渉するために適用されます。
o Since G.729.1 is an extension of G.729, the offerer SHOULD announce G.729 support in its "m=audio" line, with G.729.1 preferred. This will allow interoperability with both G.729.1 and G.729-only capable parties.
G.729.1はG.729の拡張であるため、O、申出が好ましいG.729.1と、その「M =オーディオ」ラインにG.729サポートを発表するべきです。これは、G.729.1とG.729のみの対応の当事者の双方との相互運用が可能になります。
Below is an example of such an offer:
以下は、そのようなオファーの例です。
m=audio 55954 RTP/AVP 98 18 a=rtpmap:98 G7291/16000 a=rtpmap:18 G729/8000
M =オーディオ55954 RTP / AVP 98 18 = rtpmap：98 G7291 / 16000 = rtpmap：18 G729 / 8000
If the answerer supports G.729.1, it will keep the payload type 98 in its answer, and the conversation will be done using G.729.1. Else, if the answerer supports only G.729, it will leave only the payload type 18 in its answer, and the conversation will be done using G.729 (the payload format for G.729 is defined in Section 4.5.6 of RFC 3551 [4]).
回答がG.729.1をサポートしている場合、それはその答えにペイロードタイプ98を維持する、との会話は、G.729.1を使用して行われます。回答だけG.729をサポートしていればそうで、G.729のためのペイロードフォーマットは、RFCのセクション4.5.6で定義されている（それはその答えにのみペイロードタイプ18を残すだろう、との会話は、G.729を使用して行われます3551 [4]）。
Note that when used at 8 kbps in G.729-compatible mode, the G.729.1 decoder supports G.729 Annex B. Therefore, Annex B can be advertised (by default, annexb=yes for G729 media type; see Section 4.1.9 of RFC 3555 [7]).
G.729互換モードで8 kbpsで使用される場合、G.729.1デコーダためG.729付属書Bをサポートすることに留意されたい、付録Bは、デフォルトで、annexb = YES G729メディアタイプのために（アドバタイズすることができ、セクション4.1を参照してください。 RFC 3555の9 [7]）。
o The "maxbitrate" parameter is bi-directional. If the offerer sets a maxbitrate value, the answerer MUST reply with a smaller or equal value. The actual maximum bit rate for the session will be the minimum.
O「のmaxBitrate」パラメータが双方向です。オファーはのmaxBitrate値を設定した場合、回答は、より小さいまたは等しい値で応答しなければなりません。セッションの実際の最大ビットレートは最小となります。
o If the received value for "maxbitrate" is between 8000 and 32000 but not in the permissible values set, it SHOULD be read as the closest lower valid value. If the received value is lower than 8000 or greater than 32000, the session MUST be rejected.
「のmaxBitrate」の受信値は8000と32000の間にある場合、Oが、設定された許容値で、それが最も近い下の有効な値として読まれるべきではありません。受け取った値が8000より低いか、32000より大きい場合、セッションは拒絶しなければなりません。
o The "mbs" parameter is not symmetric. Values in the offer and the answer are independent and take into account local constraints. One party MUST NOT start sending frames at a bit rate higher than the "mbs" of the other party. The parameter allows announcing this value, prior to the sending of any packet, to prevent the remote sender from exceeding the MBS at the beginning of the session.
O「MBS」パラメータが対称ではありません。提供中の値との回答は独立しており、アカウントのローカルな制約を考慮に入れます。一方の当事者が他の当事者の「MBS」よりも高いビットレートでフレームの送信を開始してはなりません。パラメータは、セッションの開始時にMBSを超え、リモート送信者を防ぐために、以前の任意のパケットの送信には、この値を発表することができます。
o If the received value for "mbs" is greater or equal to 8000 but not in the permissible values set, it SHOULD be read as the closest lower valid value. If the received value is lower than 8000, the session MUST be rejected.
「MBS」の受信値が大きいか、または8000に等しくなく、設定可能な値である場合、O、それが最も近いより低い有効な値として読まれるべきです。受け取った値が8000未満である場合、セッションは拒絶しなければなりません。
o The parameters "ptime" and "maxptime" will in most cases not affect interoperability. The SDP offer-answer handling of the "ptime" parameter is described in RFC 3264 [8]. The "maxptime" parameter MUST be handled in the same way.
Oパラメータの「PTIME」と「maxptimeは、」ほとんどの場合、相互運用性には影響しません。 「PTIME」パラメータのSDPオファーアンサー取り扱いはRFC 3264に記述されている[8]。 「maxptime」パラメータは同じように扱われなければなりません。
o Any unknown parameter in an offer MUST be ignored by the receiver and MUST NOT be included in the answer.
Oのオファー内の任意の未知パラメータは、受信機によって無視されなければならないとの答えに含んではいけません。
Some special rules apply for mono-directional traffic:
いくつかの特別なルールは、単方向のトラフィックに適用されます。
o For sendonly streams, the "mbs" parameter is useless and SHOULD NOT be used.
O sendonlyの流れについては、「MBS」パラメータは無用であるため、使用しないでください。
o For recvonly streams, the "mbs" parameter is the only way to communicate the MBS to the sender, since there is no RTP stream towards it. So to request a bit rate change, the receiver will need to use an out-of-band mechanism, like a SIP RE-INVITE.
それに向かって何のRTPストリームが存在しないため、Oがrecvonlyストリームの場合、「MBS」パラメータは、送信者にMBSを通信するための唯一の方法は、あります。だから、ビットレートの変更を要求するために、受信機は、SIP RE-INVITEのように、アウトオブバンドメカニズムを使用する必要があります。
Some special rules apply for multicast:
いくつかの特別な規則は、マルチキャストのために適用されます。
o The "mbs" parameter MUST NOT be used.
O「MBS」パラメータを使用してはいけません。
o The "maxbitrate" parameter becomes declarative and MUST NOT be negotiated. This parameter is fixed, and a participant MUST use the configuration that is provided for the session.
O「のmaxBitrate」パラメータは、宣言になり、交渉してはいけません。このパラメータは固定されており、参加者はセッションのために提供された構成を使用しなければなりません。
For declarative use of SDP such as in SAP [10] and RTSP [11], the following considerations apply:
そのようなSAPのようなSDPの宣言的使用のための[10]とRTSP [11]、次の考慮事項が適用されます。
o The "mbs" parameter MUST NOT be used.
O「MBS」パラメータを使用してはいけません。
o The "maxbitrate" parameter is declarative and provides the parameter that SHALL be used when receiving and/or sending the configured stream.
O「のmaxBitrate」パラメータが宣言され、受信及び/又は構成されたストリームを送信するときに使用しなければならないパラメータを提供します。
Congestion control for RTP SHALL be used in accordance with RFC 3550 [3] and any appropriate profile (for example, RFC 3551 [4]). The embedded and variable bit rates capability of G.729.1 provides a mechanism that may help to control congestion; see Section 3 for more details.
RTPのための輻輳制御は、RFC 3550 [3]は、任意の適切なプロファイルに従って使用しなければならない（例えば、RFC 3551 [4]）。 G.729.1の埋め込み及び可変ビットレート能力は、輻輳を制御するために役立つことができる機構を提供します。詳細は、3章を参照してください。
The number of frames encapsulated in each RTP payload influences the overall bandwidth of the RTP stream, due to the header overhead. Packing more frames in each RTP payload can reduce the number of packets sent and hence the header overhead, at the expense of increased delay and reduced error robustness.
各RTPペイロードにカプセル化されたフレームの数は、ヘッダーオーバーヘッドに、RTPストリームの全体的な帯域幅に影響を与えます。各RTPペイロードに複数のフレームをパッキング増加遅延および減少エラー耐性を犠牲にし、ヘッダオーバヘッドしたがって送られたパケットの数を減らすことができます。
RTP packets using the payload format defined in this specification are subject to the general security considerations discussed in the RTP specification [3] and any appropriate profile (for example, RFC 3551 [4]).
本明細書で定義されたペイロードフォーマットを使用して、RTPパケットは、RTP仕様[3]と、任意の適切なプロファイルで議論一般的なセキュリティの考慮の対象となっている（例えば、RFC 3551 [4]）。
As this format transports encoded speech/audio, the main security issues include confidentiality, integrity protection, and authentication of the speech/audio itself. The payload format itself does not have any built-in security mechanisms. Any suitable external mechanisms, such as SRTP [12], MAY be used.
この形式は、符号化された音声/オーディオを転送するように、メインのセキュリティ問題は、音声/オーディオ自体の機密性、完全性保護、および認証が含まれます。ペイロード形式自体は、任意の組み込みのセキュリティメカニズムを持っていません。そのようなSRTP [12]などの任意の適切な外部機構を使用することができます。
This payload format and the G.729.1 encoding do not exhibit any significant non-uniformity in the receiver-end computational load and thus are unlikely to pose a denial-of-service threat due to the receipt of pathological datagrams.
このペイロード形式とG.729.1のエンコードは、受信エンド計算負荷に重大な不均一性を示し、したがって、病理学的データグラムの受信に起因するサービス拒否脅威を与える可能性は低いですしないでください。
IANA has registered audio/G7291 as a media subtype; see Section 6.1.
IANAは、メディアサブタイプとしてオーディオ/ G7291が登録されています。 6.1節を参照してください。
[1] International Telecommunications Union, "G.729 based Embedded Variable bit-rate coder: An 8-32 kbit/s scalable wideband coder bitstream interoperable with G.729", ITU-T Recommendation G.729.1, May 2006.
[1]国際電気通信連合、「G.729ベースの組込み可変ビットレートコーダ：8-32キロビット/秒スケーラブル広帯域符号化ビットストリームG.729との相互運用性」、ITU-T勧告G.729.1、2006年5月。
[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] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
[3] Schulzrinneと、H.、Casner、S.、フレデリック、R.、およびV.ヤコブソン、 "RTP：リアルタイムアプリケーションのためのトランスポートプロトコル"、STD 64、RFC 3550、2003年7月。
[4] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video Conferences with Minimal Control", STD 65, RFC 3551, July 2003.
[4] Schulzrinneと、H.とS. Casner、 "最小量のコントロールがあるオーディオとビデオ会議システムのためのRTPプロフィール"、STD 65、RFC 3551、2003年7月。
[5] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
[5]ハンドリー、M.、ヤコブソン、V.、およびC.パーキンス、 "SDP：セッション記述プロトコル"、RFC 4566、2006年7月。
[6] Freed, N. and J. Klensin, "Media Type Specifications and Registration Procedures", BCP 13, RFC 4288, December 2005.
[6]解放され、N.とJ. Klensin、 "メディアタイプの仕様と登録手順" を、BCP 13、RFC 4288、2005年12月。
[7] Casner, S. and P. Hoschka, "MIME Type Registration of RTP Payload Formats", RFC 3555, July 2003.
[7] Casner、S.とP. Hoschka、 "RTPペイロード形式のMIMEタイプ登録"、RFC 3555、2003年7月。
[8] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.
[8]ローゼンバーグ、J.、およびH. Schulzrinneと、RFC 3264 "セッション記述プロトコル（SDP）とのオファー/アンサーモデル" 2002年6月。
[9] International Telecommunications Union, "Coding of speech at 8 kbit/s using conjugate-structure algebraic-code-excited linear-prediction (CS-ACELP)", ITU-T Recommendation G.729, March 1996.
[9]国際電気通信連合、ITU-T勧告G.729、1996年3月 "8キロビットにおける音声の符号化は、/共役構造代数符号励振線形予測（CS-ACELP）を使用してS"。
[10] Handley, M., Perkins, C., and E. Whelan, "Session Announcement Protocol", RFC 2974, October 2000.
[10]ハンドレー、M.、パーキンス、C.、およびE.ウィーラン、 "セッション告知プロトコル"、RFC 2974、2000年10月。
[11] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time Streaming Protocol (RTSP)", RFC 2326, April 1998.
[11] SchulzrinneとH.とラオとA.、およびR. Lanphier、 "リアルタイムのストリーミングプロトコル（RTSP）"、RFC 2326、1998年4月。
[12] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004.
[12] Baugher、M.、マグリュー、D.、Naslund、M.、カララ、E.、およびK. Norrman、 "セキュアリアルタイム転送プロトコル（SRTP）"、RFC 3711、2004年3月。
Author's Address
著者のアドレス
Aurelien Sollaud France Telecom 2 avenue Pierre Marzin Lannion Cedex 22307 France
オーレリアンSollaudフランステレコム2大通りピエールMarzin 22307ラニオンセデックスフランス
Phone: +33 2 96 05 15 06 EMail: aurelien.sollaud@orange-ftgroup.com
電話：+33 2 96 05 15 06 Eメール：aurelien.sollaud@orange-ftgroup.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
著作権（C）インターネット協会（2006）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights 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; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFCエディタ機能のための資金は、IETF管理サポート活動（IASA）によって提供されます。