RFC4749 日本語訳
4749 RTP Payload Format for the G.729.1 Audio Codec. A. Sollaud. October 2006. (Format: TXT=28838 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group A. Sollaud Request for Comments: 4749 France Telecom Category: Standards Track October 2006
Sollaudがコメントのために要求するワーキンググループA.をネットワークでつないでください: 4749年のフランス電子通信カテゴリ: 標準化過程2006年10月
RTP Payload Format for the G.729.1 Audio Codec
G.729.1オーディオコーデックのためのRTP有効搭載量形式
Status of this Memo
この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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2006).
Copyright(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オーディオコーデックメディアが登録をタイプするということであるTransportプロトコル(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
1. 序論…2 2. バックグラウンド…2 3. ビット伝送速度問題を埋め込みます…3 4. RTPヘッダー用法…3 5. 有効搭載量形式…4 5.1. 有効搭載量構造…4 5.2. 有効搭載量ヘッダー: mb分野…4 5.3. 有効搭載量ヘッダー: フィート、分野…6 5.4. オーディオデータ…6 6. 有効搭載量形式パラメタ…7 6.1. メディアは登録をタイプします…7 6.2. SDPパラメタに写像します。8 6.2.1. 申し出答えモデル問題…9 6.2.2. 叙述的なSDP問題…11 7. 混雑コントロール…11 8. セキュリティ問題…11 9. IANA問題…12 10. 参照…12 10.1. 標準の参照…12 10.2. 有益な参照…12
Sollaud Standards Track [Page 1] RFC 4749 RTP Payload Format for G.729.1 October 2006
Sollaud規格は2006年10月にG.729.1のためにRFC4749RTP有効搭載量形式を追跡します[1ページ]。
1. Introduction
1. 序論
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]オーディオコーデックのスケーラブル、そして、広帯域拡大です。このドキュメントはコード化されたオーディオがレアル-時間Transportプロトコル(RTP)に示すG.729.1のpacketizationにペイロード形式を指定します。
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].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[2]で説明されるように本書では解釈されることであるべきですか?
2. Background
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と共に共同利用できる8-32のキロビット毎秒のスケーラブルな広帯域(50-7000Hz)スピーチとオーディオ符号化アルゴリズムです、G.729 Annex A、そして、G.729 Annex B.Itは狭帯域から広帯域電話までのスムーズな移行を許容するpacketized音声アプリケーションの標準液を提供します。
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.
記述される中で最も重要なサービスは、企業企業ネットワークか大衆市場へのIP電話技術とテレビ会議(DSLの上のPublic Switched Telephone Network(PSTN)エミュレーションやワイヤレス・アクセスのような)です。 対象装置は、IP電話や他のVoIP受話器、家のゲートウェイ、メディアゲートウェイ、IP兵士の支店Exchange(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符号化器は12の有効なビット伝送速度8〜32キロビット毎秒に対応する12個の層で構造化された埋め込まれたbitstreamを生産します。 初層は、8キロビット毎秒でコア層と呼ばれて、ITU-T G.729/G.729A符号化器とのコンパチブルbitstreamです。 12キロビット毎秒では、2番目の層は狭帯域品質を改良します。 上側の層は広帯域オーディオ(50-7000Hz)に14〜32キロビット毎秒を供給します、2キロビット毎秒粒状が優雅な品質改良を許容していて。 コア層だけが理解できるスピーチを解読するために義務的です。 上側の層は上質の増進と広帯域拡大を提供します。
Sollaud Standards Track [Page 2] RFC 4749 RTP Payload Format for G.729.1 October 2006
Sollaud規格は2006年10月にG.729.1のためにRFC4749RTP有効搭載量形式を追跡します[2ページ]。
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フレームを作動させます、そして、デフォルト標本抽出率は16kHzです。 また、8kHzでの入出力はすべてのビット伝送速度で支持されます。
3. Embedded Bit Rates Considerations
3. 埋め込まれたビット伝送速度問題
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.
また、帯域幅を調整する能力は、固定帯域幅リンクを音声通話に捧げさせるのを助けるかもしれません、例えば、住宅か中継方式ゲートウェイで。 その場合、システムは同時の呼び出しの数に応じたビット伝送速度を変えることができます。 これは送付帯域幅に影響を与えるだけでしょう。 また、受信帯域幅を調整するために、私たちはそれ自身の送付ビット伝送速度を変えるよう相手に要求するバンドにおける合図を導入します。 バンドにおけるこの要求はMaximum BitレートSupportedのためにMBSと呼ばれます。 それはセクション5.2で説明されます。 それが単に両用ユニキャストG.729.1交通の役に立つというメモ、AがBが送付ビット伝送速度を変更するよう要求するためにバンドにおけるMBSをBに送るとき、反対の方向にはG.729.1の流れが全くないのがBからA.Ifまでの流れに関係があるので、MBSが効き目がないでしょう。
4. RTP Header Usage
4. RTPヘッダー用法
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ヘッダーの形式はRFC3550[3]で指定されます。 このペイロード形式はその仕様と一致した方法でヘッダーの分野を使用します。
The RTP timestamp clock frequency is the same as the default sampling frequency: 16 kHz.
RTPタイムスタンプクロック周波数はデフォルトサンプリング周波数と同じです: 16kHz
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抽出された入力/出力信号でビット伝送速度を操作する能力があります。 それはbitstreamに影響しません、そして、デコーダはエンコーダの入力のときにオリジナルの信号の標本抽出率に関する先験的な知識を必要としません。 したがって、8kHzで装置の実現とオーディオの音の能力、エンコーダの入力、そして/または、デコーダの出力によるのを構成できます。 しかしながら、いつも16kHzの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個のフレームの持続時間は16kHzで320個のサンプルに対応する20msです。 したがって、タイムスタンプはそれぞれの連続したフレームあたり320増加します。
Sollaud Standards Track [Page 3] RFC 4749 RTP Payload Format for G.729.1 October 2006
Sollaud規格は2006年10月にG.729.1のためにRFC4749RTP有効搭載量形式を追跡します[3ページ]。
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を見る)と予想されます。
5. Payload Format
5. 有効搭載量形式
5.1. Payload Structure
5.1. 有効搭載量構造
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).
ペイロードヘッダーは2つの分野から成ります: mb(セクション5.2を見る)とフィート(セクション5.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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MBS | FT | |
+-+-+-+-+-+-+-+-+ +
: zero or more frames at the same bit rate :
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | mb| フィート| | +-+-+-+-+-+-+-+-+ + : ゼロか以上が同じビット伝送速度で縁どっています: : : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
5.2. Payload Header: MBS Field
5.2. 有効搭載量ヘッダー: mb分野
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分野の値は設定されます:
Sollaud Standards Track [Page 4] RFC 4749 RTP Payload Format for G.729.1 October 2006
Sollaud規格は2006年10月にG.729.1のためにRFC4749RTP有効搭載量形式を追跡します[4ページ]。
+-------+--------------+
| 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 |
+-------+--------------+
+-------+--------------+ | mb| 最大ビット伝送速度| +-------+--------------+ | 0 | 8キロビット毎秒| | 1 | 12キロビット毎秒| | 2 | 14キロビット毎秒| | 3 | 16キロビット毎秒| | 4 | 18キロビット毎秒| | 5 | 20キロビット毎秒| | 6 | 22キロビット毎秒| | 7 | 24キロビット毎秒| | 8 | 26キロビット毎秒| | 9 | 28キロビット毎秒| | 10 | 30キロビット毎秒| | 11 | 32キロビット毎秒| | 12-14 | (予約される)です。 | | 15 | _mbがありません。| +-------+--------------+
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.
aに従ったペイロードは受け取られたMBS値、MBS MUSTを予約しました。無視されます。
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.
非RTP手段で実際のMBS値を送るとき、すべてのパケットの15にMBS分野を設定しなければなりません。 この仕様の範囲の外にこれはあります。
See Sections 3 and 7 for more details on the use of MBS for congestion control.
MBSの輻輳制御の使用に関するその他の詳細に関してセクション3と7を見てください。
Sollaud Standards Track [Page 5] RFC 4749 RTP Payload Format for G.729.1 October 2006
Sollaud規格は2006年10月にG.729.1のためにRFC4749RTP有効搭載量形式を追跡します[5ページ]。
5.3. Payload Header: FT Field
5.3. 有効搭載量ヘッダー: フィートはさばきます。
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 |
+-------+---------------+------------+
+-------+---------------+------------+ | フィート| レートをコード化します。| フレーム・サイズ| +-------+---------------+------------+ | 0 | 8キロビット毎秒| 20の八重奏| | 1 | 12キロビット毎秒| 30の八重奏| | 2 | 14キロビット毎秒| 35の八重奏| | 3 | 16キロビット毎秒| 40の八重奏| | 4 | 18キロビット毎秒| 45の八重奏| | 5 | 20キロビット毎秒| 50の八重奏| | 6 | 22キロビット毎秒| 55の八重奏| | 7 | 24キロビット毎秒| 60の八重奏| | 8 | 26キロビット毎秒| 65の八重奏| | 9 | 28キロビット毎秒| 70の八重奏| | 10 | 30キロビット毎秒| 75の八重奏| | 11 | 32キロビット毎秒| 80の八重奏| | 12-14 | (予約される)です。 | | | 15 | _データがありません。| 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(いいえ_DATA)は、ペイロードにはオーディオデータが全くないのを示します。 これは、伝えるオーディオフレームが全くないとき、MBS値をアップデートするのに使用されるかもしれません。 そして、ペイロードはペイロードヘッダーに変えられるでしょう。
If a payload with a reserved FT value is received, the whole payload MUST be ignored.
予約されたFT値に従ったペイロードが受け取られているなら、全体のペイロードを無視しなければなりません。
5.4. Audio Data
5.4. オーディオデータ
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個以上の連続したオーディオフレームを含んでいます。 オーディオフレームはすなわち、時間、最も古い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におけるテーブルに従ってFT分野で1個のフレームのサイズを与えます、そして、フレームの実数はオーディオデータ部分のサイズから推論しやすいです:
nb_frames = (size_of_audio_data) / (size_of_one_frame).
Nb_フレームは(_オーディオ_データのサイズ_)/(_1_フレームのサイズ_)と等しいです。
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.
完全なフレームだけを考えなければなりません。 それで、分割への残りが上にあれば、容認されたペイロードの対応する残っているバイトを無視しなければなりません。
Sollaud Standards Track [Page 6] RFC 4749 RTP Payload Format for G.729.1 October 2006
Sollaud規格は2006年10月にG.729.1のためにRFC4749RTP有効搭載量形式を追跡します[6ページ]。
Note that if FT=15, there will be no audio frame in the payload.
ペイロードにはオーディオフレームが全くFT=15であるなら、ないことに注意してください。
6. Payload Format Parameters
6. 有効搭載量形式パラメタ
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コーデックのためのメディア「副-タイプ」登録の一部とパラメタを定義します。また、Session記述プロトコル(SDP)[5]へのパラメタに関するマッピングをSDPを使用するそれらのアプリケーションに提供します。 MIMEかSDPを使用しない制御プロトコルでは、その制御プロトコルと共に使用される適切な形式にメディア型引数を写像しなければなりません。
6.1. Media Type Registration
6.1. メディアは登録をタイプします。
This registration is done using the template defined in RFC 4288 [6] and following RFC 3555 [7].
この登録はRFC4288[6]で定義されて、RFC3555[7]に続いて、テンプレートを使用し終わっています。
Type name: audio
型名: オーディオ
Subtype name: G7291
Subtypeは以下を命名します。 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は使用できるビット伝送速度の範囲を制限します。 ビット伝送速度は、FTとMBSでRTPパケットの分野が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.
mb: 受信機としてbpsで支持された現在の最大のコーデックビット伝送速度。 許容値は同じセットでmaxbitrateパラメタに似ています、mbがmaxbitrateと下側である、または等しいに違いないという規制で。 mbパラメタが省略されるなら、それはmaxbitrate値に設定されます。 それで、mbとmaxbitrateの両方が省略されるなら、それらはともに32000に設定されます。 mbパラメタはRFC4749のセクション5.2におけるテーブルに従ってRTPパケットのMBS値に対応しています。 パケットが送ったRTPのMBS分野でダイナミックにこのパラメタをアップデートするかもしれないことに注意してください。 それはセッションのための絶対値ではありません。
ptime: the recommended length of time (in milliseconds) represented
by the media in a packet. See Section 6 of RFC 4566 [5].
ptime: パケットにメディアによって表されたお勧めの長さの時間(ミリセカンドによる)。 RFC4566[5]のセクション6を見てください。
Sollaud Standards Track [Page 7] RFC 4749 RTP Payload Format for G.729.1 October 2006
Sollaud規格は2006年10月にG.729.1のためにRFC4749RTP有効搭載量形式を追跡します[7ページ]。
maxptime: the maximum length of time (in milliseconds) that can be
encapsulated in a packet. See Section 6 of RFC 4566 [5]
maxptime: パケットで要約できる最大の長さの時間(ミリセカンドによる)。 RFC4566のセクション6を見てください。[5]
Encoding considerations: This media type is framed and contains
binary data; see Section 4.8 of RFC 4288 [6].
問題をコード化します: このメディアタイプは、縁どられて、2進のデータを含んでいます。 RFC4288[6]のセクション4.8を見てください。
Security considerations: See Section 8 of RFC 4749
セキュリティ問題: RFC4749のセクション8を見てください。
Interoperability considerations: none
相互運用性問題: なし
Published specification: RFC 4749
広められた仕様: RFC4749
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
詳細のために連絡する人とEメールアドレス: 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
コントローラを変えてください: IESGから代表として派遣されたIETF Audio/ビデオTransportワーキンググループ
6.2. Mapping to SDP Parameters
6.2. パラメタをSDPに写像します。
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:
仕様が特定のマッピングを持っているメディアタイプで運ばれた情報はSession記述プロトコル(SDP)で[5]をさばきます。([5]は、RTPセッションについて説明するのに一般的に使用されます)。 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"はそれぞれSDP"a=ptime"と"a=maxptime"属性に入ります。
Sollaud Standards Track [Page 8] RFC 4749 RTP Payload Format for G.729.1 October 2006
Sollaud規格は2006年10月にG.729.1のためにRFC4749RTP有効搭載量形式を追跡します[8ページ]。
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"a=fmtp"属性に入ります。
Some example SDP session descriptions utilizing G.729.1 encodings follow.
G.729.1 encodingsを利用するいくつかの例のSDPセッション記述が続きます。
Example 1: default parameters
例1: デフォルトパラメタ
m=audio 53146 RTP/AVP 98
a=rtpmap:98 G7291/16000
オーディオの53146RTP/AVP98m=a=rtpmap: 98G7291/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: 40ms(2個のフレームと等しい)のお勧めのパケット持続時間、最大のビット伝送速度は12キロビット毎秒であり、初期のMBSは8キロビット毎秒にセットしました。 それは、12キロビット毎秒で作動できる積み込まれたPSTNゲートウェイであるかもしれませんが、初めは8キロビット毎秒にビット伝送速度を減少させるように頼みます。
m=audio 51258 RTP/AVP 99
a=rtpmap:99 G7291/16000
a=fmtp:99 maxbitrate=12000; mbs=8000
a=ptime:40
オーディオの51258RTP/AVP99m=a=rtpmap: 99 G7291/16000 a=fmtp: 99maxbitrate=12000。 8000mb=a=ptime: 40
6.2.1. Offer-Answer Model Considerations
6.2.1. 申し出答えモデル問題
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の拡大であるので、G.729.1が好まれている状態で、申出人SHOULDは「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
オーディオの55954RTP/AVP98 18m=a=rtpmap: 98G7291/16000 a=rtpmap: 18G729/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を使用し終わるでしょう。 answererがG.729だけを支持すると、ほかに、答えでペイロードタイプ18だけを出るでしょう、そして、会話はG.729を使用し終わるでしょう。(G.729のためのペイロード書式は.6セクション4.5RFC3551[4])で定義されます。
Sollaud Standards Track [Page 9] RFC 4749 RTP Payload Format for G.729.1 October 2006
Sollaud規格は2006年10月にG.729.1のためにRFC4749RTP有効搭載量形式を追跡します[9ページ]。
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]).
8キロビット毎秒にG.729-コンパチブル・モードで使用されると、G.729.1デコーダがG.729 Annex B.Thereforeを支持するというメモ、Annex Bの広告を出すことができます。(デフォルトで、annexb=はいはG729メディアのためにタイプします;、.9セクション4.1RFC3555[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値を設定するなら、answererは、より小さいか等しい値で返答しなければなりません。 セッションのための実際の最大のビット伝送速度は最小限になるでしょう。
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にもかかわらず、許容値セットでないのにおけるそれは最も近いとしての読書が下側の有効な値であったならSHOULDであるというわけではありませんか? 容認された値が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 「mb」パラメタは左右対称ではありません。 申し出と答えにおける値は、独立していて、地方の規制を考慮に入れます。 パーティーが送付フレームを始めてはいけない人は少し相手の「mb」より高く評価します。 パラメタで、どんなパケットの発信の前にもリモート送付者がセッションの始めに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 「mb」容認された値が、より大きいか、そして、同輩が許容値ではなく、8000にセットして、それはSHOULDです。有効値が最も近くに下ろされるので、読まれてください。 容認された値が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申し出答え取り扱いはRFC3264[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の流れに、「mb」パラメタが役に立たない、SHOULD NOT、使用されてください。
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に関しては、流れ、「mb」パラメタはMBSを送付者に伝える唯一の方法です、RTPの流れが全くそれに向かっていないので。 要求しばらくレート変化とそのように、受信機はSIP RE-INVITEのようなバンドで出ているメカニズムを使用する必要があるでしょう。
Sollaud Standards Track [Page 10] RFC 4749 RTP Payload Format for G.729.1 October 2006
Sollaud規格は2006年10月にG.729.1のためにRFC4749RTP有効搭載量形式を追跡します[10ページ]。
Some special rules apply for multicast:
いくつかの特別な規則がマルチキャストに申し込みます:
o The "mbs" parameter MUST NOT be used.
o 「mb」パラメタを使用してはいけません。
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"パラメタは、叙述的になって、交渉されてはいけません。 このパラメタは固定されています、そして、関係者はセッションのために提供される構成を使用しなければなりません。
6.2.2. Declarative SDP Considerations
6.2.2. 叙述的なSDP問題
For declarative use of SDP such as in SAP [10] and RTSP [11], the following considerations apply:
SDPのSAP[10]やRTSP[11]などの叙述的な使用のために、以下の問題は申し込まれます:
o The "mbs" parameter MUST NOT be used.
o 「mb」パラメタを使用してはいけません。
o The "maxbitrate" parameter is declarative and provides the
parameter that SHALL be used when receiving and/or sending the
configured stream.
o "maxbitrate"パラメタは、叙述的であり、構成された流れを受ける、そして/または、送るとき、使用されていた状態でSHALLがあるパラメタを提供します。
7. Congestion Control
7. 輻輳制御
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 SHALLに、RFC3550[3]とあらゆる適切なプロフィールに従って、使用されてください。輻輳制御、(例えば、RFC3551[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ペイロードで、より多くのフレームを梱包すると、送られたパケットの数としたがって、ヘッダーオーバーヘッドを下げることができます、増加する遅れと減少している誤り丈夫さを犠牲にして。
8. Security Considerations
8. セキュリティ問題
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]とどんな適切なプロフィールでも議論した総合証券問題を条件としています。(例えば、RFC3551[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]などの適当な外部のどんなメカニズムも使用されるかもしれません。
Sollaud Standards Track [Page 11] RFC 4749 RTP Payload Format for G.729.1 October 2006
Sollaud規格は2006年10月にG.729.1のためにRFC4749RTP有効搭載量形式を追跡します[11ページ]。
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コード化は、受信端末のコンピュータの負荷で少しの重要な非の一様性も示さないで、その結果、病理学的なデータグラムの領収書のためサービスの否定の脅威を引き起こしそうにはありません。
9. IANA Considerations
9. IANA問題
IANA has registered audio/G7291 as a media subtype; see Section 6.1.
IANAはメディア「副-タイプ」としてオーディオ/G7291を登録しました。 セクション6.1を見てください。
10. References
10. 参照
10.1. Normative References
10.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] 国際Telecommunications Union、「G.729はEmbedded Variableビット伝送速度符号化器を基礎づけました」。 「G.729があるbitstream共同利用できる8-32kbit/sスケーラブルな広帯域符号化器」、ITU-T Recommendation 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.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、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.、フレディリック、R.、およびV.ジェーコブソン、「RTP:」 「リアルタイムのアプリケーションのためのトランスポート・プロトコル」、STD64、RFC3550、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プロフィールと最小量があるテレビ会議システムは制御します」、STD65、RFC3551、2003年7月。
[5] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006.
[5] ハンドレー、M.、ジェーコブソン、V.、およびC.パーキンス、「SDP:」 「セッション記述プロトコル」、RFC4566、2006年7月。
[6] Freed, N. and J. Klensin, "Media Type Specifications and
Registration Procedures", BCP 13, RFC 4288, December 2005.
解放された[6]とN.とJ.Klensin、「メディアは仕様と登録手順をタイプする」BCP13、RFC4288、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の種類登録」、RFC3555、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、「セッション記述プロトコル(SDP)がある申し出/答えモデル」、RFC3264、2002年6月。
10.2. Informative References
10.2. 有益な参照
[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] 国際Telecommunications Union、「接合の構造の興奮している代数的なコードの直線的な予測(CS-ACELP)を使用する8kbit/sでのスピーチのコード化」、ITU-T Recommendation G.729(1996年3月)。
[10] Handley, M., Perkins, C., and E. Whelan, "Session Announcement
Protocol", RFC 2974, October 2000.
[10] ハンドレーとM.とパーキンス、C.とE.ウィーラン、「セッション発表プロトコル」、RFC2974、2000年10月。
Sollaud Standards Track [Page 12] RFC 4749 RTP Payload Format for G.729.1 October 2006
Sollaud規格は2006年10月にG.729.1のためにRFC4749RTP有効搭載量形式を追跡します[12ページ]。
[11] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time Streaming
Protocol (RTSP)", RFC 2326, April 1998.
1998年4月の[11]SchulzrinneとH.とラオ、A.とR.Lanphier、「リアルタイムのストリーミングのプロトコル(RTSP)」RFC2326。
[12] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)",
RFC 3711, March 2004.
2004年の[12]Baugher、M.、マグリュー、D.、ジーター、M.、カラーラ、E.、およびK.Norrman、「安全なリアルタイムのトランスポート・プロトコル(SRTP)」、RFC3711行進。
Author's Address
作者のアドレス
Aurelien Sollaud France Telecom 2 avenue Pierre Marzin Lannion Cedex 22307 France
Aurelien Sollaudフランステレコム2大通りピアーMarzin Lannion Cedex22307フランス
Phone: +33 2 96 05 15 06 EMail: aurelien.sollaud@orange-ftgroup.com
以下に電話をしてください。 +33 2 96 05 15 06はメールされます: aurelien.sollaud@orange-ftgroup.com
Sollaud Standards Track [Page 13] RFC 4749 RTP Payload Format for G.729.1 October 2006
Sollaud規格は2006年10月にG.729.1のためにRFC4749RTP有効搭載量形式を追跡します[13ページ]。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2006).
Copyright(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
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はどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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 Editor機能のための基金はIETF Administrative Support Activity(IASA)によって提供されます。
Sollaud Standards Track [Page 14]
Sollaud標準化過程[14ページ]
一覧
スポンサーリンク
