[要約] RFC 4749は、G.729.1オーディオコーデックのRTPペイロード形式に関する仕様です。このRFCの目的は、G.729.1コーデックを使用して音声を効率的に伝送するための標準化とガイドラインの提供です。
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
G.729.1オーディオコーデックのRTPペイロード形式
Status of this Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（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).
International Telecommunication Union（ITU-T）推奨G.729.1 [1]は、推奨事項G.729 [9]オーディオコーデックのスケーラブルで広帯域拡張です。このドキュメントは、G.729.1エンコードされたオーディオ信号のリアルタイムトランスポートプロトコル（RTP）にパケット化するためのペイロード形式を指定します。
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.
ペイロード形式自体については、セクション5で説明されています。メディアタイプの登録と、SDPを使用したG.729.1の使用の詳細については、セクション6に記載されています。
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].
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「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 Annex A、およびG.729 Annex Bと相互運用可能な8-32 kbpsスケーラブルワイドバンド（50-7000 Hz）音声およびオーディオコーディングアルゴリズムです。これにより、ナローバンドからワイドバンドテレフォニーへのスムーズな移行が可能になります。
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番目の層が狭帯域の品質を向上させます。上層層は、14〜32 kbpsの広帯域オーディオ（50〜7000 Hz）を提供し、2 kbpsの粒度が優雅な品質の改善を可能にします。理解可能なスピーチをデコードするには、コアレイヤーのみが必須です。上層層は、品質の向上と広帯域の拡大を提供します。
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 msフレームで動作し、デフォルトのサンプリングレートは16 kHzです。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で説明します。双方向ユニキャストG.729.1トラフィックにのみ役立つことに注意してください。Aは、BANDのMBSをBに送信する場合、Bが送信ビットレートを変更するように要求する場合、BからAのストリームに関係する場合に関係します。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.
RTPタイムスタンプクロック周波数は、デフォルトのサンプリング周波数：16 kHzと同じです。
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には、すべてのビットレートで8 kHzのサンプリングされた入力/出力信号で動作する機能もあります。ビットストリームには影響しません。デコーダーは、エンコーダの入力での元の信号のサンプリングレートに関する先験的な知識を必要としません。したがって、デバイスの実装とオーディオアコースティック機能に応じて、エンコーダーの入力および/またはデコーダーの出力は8 kHzで構成できます。ただし、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つのフレームの持続時間は20ミリ秒で、16 kHzの320サンプルに対応しています。したがって、タイムスタンプは、連続したフレームごとに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は、相手に受け取ることができる最大ビットレートを相手に伝えるために使用されます。エンコーダーは、受信した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値が以前の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.
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.
ペイロードのオーディオデータには、同じビットレートで1つ以上の連続したオーディオフレームが含まれています。オーディオフレームは、時間の順に詰め込まれています。つまり、最初は最も古いです。
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:
セクション5.3の表に従って、1つのフレームのサイズはFTフィールドで与えられ、実際のフレーム数はオーディオデータパーツのサイズから簡単に推測できます。
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].
この登録は、RFC 4288 [6]で定義されたテンプレートを使用して、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：セッションの絶対最大コーデックビットレート、1秒あたりのビット。許容値は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：レシーバーとしてサポートされている現在の最大コーデックビットレートは、1秒あたりビットです。許容値は、MBSがMaxbitrate以下でなければならないという制約とともに、Maxbitrateパラメーターと同じセットにあります。MBSパラメーターが省略されている場合、MaxBitrate値に設定されます。したがって、MBSとMaxbitrateの両方が省略されている場合、どちらも32000に設定されます。MBSパラメーターは、RFC 4749のセクション5.2の表に従って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 [5]のセクション6を参照してください。
maxptime: the maximum length of time (in milliseconds) that can be encapsulated in a packet. See Section 6 of RFC 4566 [5]
Maxptime：パケットにカプセル化できる最大時間（ミリ秒単位）。RFC 4566 [5]のセクション6を参照してください
Encoding considerations: This media type is framed and contains binary data; see Section 4.8 of RFC 4288 [6].
考慮事項のエンコーディング：このメディアタイプはフレーム化されており、バイナリデータが含まれています。RFC 4288 [6]のセクション4.8を参照してください。
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
詳細については、人とメールアドレスをお問い合わせ：Aurelien Sollaud、Aurelien.sollaud@orange-ftgroup.com
Intended usage: COMMON
意図された使用法：共通
Restrictions on usage: This media type depends on RTP framing, and hence is only defined for transfer via RTP [3].
使用に関する制限：このメディアタイプはRTPフレーミングに依存するため、RTPを介した転送のみが定義されます[3]。
Author: Aurelien Sollaud
著者：Aurelien Sollaud
Change controller: IETF Audio/Video Transport working group delegated from the IESG
Change Controller：IETFオーディオ/ビデオトランスポートワーキンググループは、IESGから委任されました
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:
メディアタイプの仕様に掲載されている情報には、セッション説明プロトコル（SDP）[5]のフィールドへの特定のマッピングがあります。これは、RTPセッションを説明するために一般的に使用されます。SDPがG.729.1コーデックを採用するセッションを指定するために使用される場合、マッピングは次のとおりです。
o The media type ("audio") goes in SDP "m=" as the media name.
o メディアタイプ（ "Audio"）は、メディア名として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」は、それぞれSDP「A = PTIME」と「A = MaxPtime」属性に移動します。
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 残りのパラメーターは、Parameter = valueペアのセミコロン分離リストとしてメディアタイプの文字列から直接コピーすることにより、SDP "a = 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 A = 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、初期MBは8 kbpsに設定されています。これは、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
The following considerations apply when using SDP offer-answer procedures [8] to negotiate the use of G.729.1 payload in RTP:
rtpでのG.729.1ペイロードの使用を交渉するために、SDPオファーアンドワープロシージャ[8]を使用する場合、以下の考慮事項が適用されます。
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.
o G.729.1はG.729の拡張であるため、オファーは「M = Audio」ラインでG.729サポートを発表する必要があり、G.729.1が優先されます。これにより、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
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]).
AnswererがG.729.1をサポートしている場合、ペイロードタイプ98をその回答に維持し、G.729.1を使用して会話が行われます。それ以外の場合、回答者がG.729のみをサポートする場合、その回答にペイロードタイプ18のみを残し、会話はG.729を使用して行われます（G.729のペイロード形式はRFCのセクション4.5.6で定義されます。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 Annex Bをサポートしていることに注意してください。したがって、付録Bは宣伝できます（デフォルトでは、nexb = 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」パラメーターは双方向です。オファーが上顎の値を設定する場合、回答者は小さい値または等しい値で返信する必要があります。セッションの実際の最大ビットレートは最小になります。
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.
o 「maxbitrate」の受信価値が8000〜32000の間であるが、許容値設定ではない場合は、最も近い低い有効な値として読み取る必要があります。受信価値が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.
o 「MBS」の受信価値が8000以上であるが、許容値設定ではない場合は、最も近い低い有効な値として読み取る必要があります。受信価値が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.
o Recvonlyストリームの場合、「MBS」パラメーターは、MBSを送信者に通信する唯一の方法です。これは、RTPストリームがないためです。したがって、少しレートの変更を要求するには、受信者はSIP Re Inviteのようなバンド外のメカニズムを使用する必要があります。
Some special rules apply for multicast:
いくつかの特別なルールがマルチキャストに適用されます：
o The "mbs" parameter MUST NOT be used.
o
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 [10]やRTSP [11]などのSDPの宣言的使用の場合、次の考慮事項が適用されます。
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は、メディアサブタイプとしてAudio/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] International Telecommunications Union、「G.729ベースの埋め込み可変ビットレートコーダー：G.729と相互運用可能な8-32 KBIT/SスケーラブルワイドバンドコーダーBitStream、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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[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.、Frederick、R。、およびV. Jacobson、「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] Handley、M.、Jacobson、V。、およびC. Perkins、「SDP：セッション説明プロトコル」、RFC 4566、2006年7月。
[6] Freed, N. and J. Klensin, "Media Type Specifications and Registration Procedures", BCP 13, RFC 4288, December 2005.
[6] Freed、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] Rosenberg、J。およびH. Schulzrinne、「セッション説明プロトコル（SDP）を備えたオファー/回答モデル」、RFC 3264、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] International Telecommunications Union、「コンジュゲート構造代数型コード発現線形予測（CS-Acelp）を使用した8 kbit/sでの発話のコーディング」、ITU-T推奨G.729、1996年3月。
[10] Handley, M., Perkins, C., and E. Whelan, "Session Announcement Protocol", RFC 2974, October 2000.
[10] Handley、M.、Perkins、C。、およびE. Whelan、「セッションアナウンスプロトコル」、RFC 2974、2000年10月。
[11] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time Streaming Protocol (RTSP)", RFC 2326, April 1998.
[11] Schulzrinne、H.、Rao、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.、McGrew、D.、Naslund、M.、Carrara、E。、およびK. Norrman、「セキュアリアルタイム輸送プロトコル（SRTP）」、RFC 3711、2004年3月。
Author's Address
著者の連絡先
Aurelien Sollaud France Telecom 2 avenue Pierre Marzin Lannion Cedex 22307 France
Aurelien Sollaud France Telecom 2 Avenue Pierre Marzin Lannion Cedex 22307 France
Phone: +33 2 96 05 15 06
EMail: aurelien.sollaud@orange-ftgroup.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
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.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。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）によって提供されます。