RFC5391 日本語訳
5391 RTP Payload Format for ITU-T Recommendation G.711.1. A. Sollaud. November 2008. (Format: TXT=26304 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group A. Sollaud Request for Comments: 5391 France Telecom Category: Standards Track November 2008
Sollaudがコメントのために要求するワーキンググループA.をネットワークでつないでください: 5391年のフランス電子通信カテゴリ: 標準化過程2008年11月
RTP Payload Format for ITU-T Recommendation G.711.1
ITU-T推薦G.711.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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (c) 2008 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright(c)2008IETF Trustと人々はドキュメントとして作者を特定しました。 All rights reserved。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
事実上、このドキュメントはこのドキュメントの公表の日付にIETF Documents( http://trustee.ietf.org/ ライセンスインフォメーション)へのBCP78とIETF TrustのLegal Provisions Relatingを受けることがあります。 このドキュメントに関して権利と制限について説明するとき、慎重にこれらのドキュメントを再検討してください。
Abstract
要約
This document specifies a Real-time Transport Protocol (RTP) payload format to be used for the ITU Telecommunication Standardization Sector (ITU-T) G.711.1 audio codec. Two media type registrations are also included.
このドキュメントは、G.711.1オーディオコーデック2つのメディアがタイプするITU Telecommunication Standardization Sector(ITU-T)に使用されて、また、登録証明書が含まれているということになるようにレアル-時間Transportプロトコル(RTP)ペイロード形式を指定します。
Sollaud Standards Track [Page 1] RFC 5391 RTP Payload Format for G.711.1 November 2008
Sollaud規格は2008年11月にG.711.1のためにRFC5391RTP有効搭載量形式を追跡します[1ページ]。
Table of Contents
目次
1. Introduction ....................................................2
2. Background ......................................................2
3. RTP Header Usage ................................................3
4. Payload Format ..................................................4
4.1. Payload Header .............................................4
4.2. Audio Data .................................................5
5. Payload Format Parameters .......................................6
5.1. PCMA-WB Media Type Registration ............................7
5.2. PCMU-WB Media Type Registration ............................8
5.3. Mapping to SDP Parameters ..................................9
5.3.1. Offer-Answer Model Considerations ...................9
5.3.2. Declarative SDP Considerations .....................11
6. G.711 Interoperability .........................................11
7. Congestion Control .............................................12
8. Security Considerations ........................................12
9. IANA Considerations ............................................12
10. References ....................................................13
10.1. Normative References .....................................13
10.2. Informative References ...................................13
1. 序論…2 2. バックグラウンド…2 3. RTPヘッダー用法…3 4. 有効搭載量形式…4 4.1. 有効搭載量ヘッダー…4 4.2. オーディオデータ…5 5. 有効搭載量形式パラメタ…6 5.1. PCMA-WBメディアは登録をタイプします…7 5.2. PCMU-WBメディアは登録をタイプします…8 5.3. SDPパラメタに写像します。9 5.3.1. 申し出答えモデル問題…9 5.3.2. 叙述的なSDP問題…11 6. G.711相互運用性…11 7. 混雑コントロール…12 8. セキュリティ問題…12 9. IANA問題…12 10. 参照…13 10.1. 標準の参照…13 10.2. 有益な参照…13
1. Introduction
1. 序論
The ITU Telecommunication Standardization Sector (ITU-T) Recommendation G.711.1 [ITU-G.711.1] is an embedded wideband extension of the Recommendation G.711 [ITU-G.711] audio codec. This document specifies a payload format for packetization of G.711.1 encoded audio signals into the Real-time Transport Protocol (RTP).
ITU Telecommunication Standardization Sector(ITU-T)推薦G.711.1[ITU-G.711.1]はRecommendation G.711[ITU-G.711]オーディオコーデックの埋め込まれた広帯域拡大です。このドキュメントはコード化されたオーディオがレアル-時間Transportプロトコル(RTP)に示すG.711.1のpacketizationにペイロード形式を指定します。
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 [RFC2119].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[RFC2119]で説明されるように本書では解釈されることであるべきですか?
2. Background
2. バックグラウンド
G.711.1 is a G.711 embedded wideband speech and audio coding algorithm operating at 64, 80, and 96 kbps. At 64 kbps, G.711.1 is fully interoperable with G.711. Hence, an efficient deployment in existing G.711-based Voice over IP (VoIP) infrastructures is foreseen.
G.711.1によるG.711が広帯域スピーチ、64、80歳のアルゴリズム操作をコード化するオーディオ、および96キロビット毎秒を埋め込んだということです。 64キロビット毎秒では、G.711.1はG.711と共に完全に共同利用できます。 したがって、既存のG.711ベースのボイス・オーバー IP(VoIP)インフラストラクチャにおける効率的な展開は見通されます。
The codec operates on 5-ms frames, and the default sampling rate is 16 kHz. Input and output at 8 kHz are also supported for narrowband modes.
コーデックは5-msフレームを作動させます、そして、デフォルト標本抽出率は16kHzです。 また、8kHzでの入出力は狭帯域モードのために支持されます。
Sollaud Standards Track [Page 2] RFC 5391 RTP Payload Format for G.711.1 November 2008
Sollaud規格は2008年11月にG.711.1のためにRFC5391RTP有効搭載量形式を追跡します[2ページ]。
The encoder produces an embedded bitstream structured in three layers corresponding to three available bit rates: 64, 80, and 96 kbps. The bitstream can be truncated at the decoder side or by any component of the communication system to adjust, "on the fly", the bit rate to the desired value.
エンコーダは3つの有効なビット伝送速度に対応する3つの層で構造化された埋め込まれたbitstreamを生産します: 64、80、および96キロビット毎秒。 bitstreamはデコーダ側において、または、通信系のどんな部品でも先端を切られて、適応できます、「急いで」、目標値へのビット伝送速度。
The following table gives more details on these layers.
以下のテーブルはこれらの層に関するその他の詳細を与えます。
+-------+------------------------+----------+
| Layer | Description | Bit rate |
+-------+------------------------+----------+
| L0 | G.711 compatible | 64 kbps |
| L1 | narrowband enhancement | 16 kbps |
| L2 | wideband enhancement | 16 kbps |
+-------+------------------------+----------+
+-------+------------------------+----------+ | 層| 記述| ビット伝送速度| +-------+------------------------+----------+ | L0| G.711互換性があります。| 64キロビット毎秒| | L1| 狭帯域増進| 16キロビット毎秒| | L2| 広帯域増進| 16キロビット毎秒| +-------+------------------------+----------+
Table 1: Layers description
テーブル1: 記述を層にします。
The combinations of these three layers results in the definition of four modes, as per the following table.
これらの3の組み合わせは以下のテーブルに従って4つのモードの定義における結果を層にします。
+------+----+----+----+------------+----------+
| Mode | L0 | L1 | L2 | Audio band | Bit rate |
+------+----+----+----+------------+----------+
| R1 | x | | | narrowband | 64 kbps |
| R2a | x | x | | narrowband | 80 kbps |
| R2b | x | | x | wideband | 80 kbps |
| R3 | x | x | x | wideband | 96 kbps |
+------+----+----+----+------------+----------+
+------+----+----+----+------------+----------+ | モード| L0| L1| L2| オーディオバンド| ビット伝送速度| +------+----+----+----+------------+----------+ | R1| x| | | 狭帯域| 64キロビット毎秒| | R2a| x| x| | 狭帯域| 80キロビット毎秒| | R2b| x| | x| 広帯域| 80キロビット毎秒| | R3| x| x| x| 広帯域| 96キロビット毎秒| +------+----+----+----+------------+----------+
Table 2: Modes description
テーブル2: モード記述
3. RTP Header Usage
3. RTPヘッダー用法
The format of the RTP header is specified in [RFC3550]. The payload format defined in this document uses the fields of the header in a manner consistent with that specification.
RTPヘッダーの形式は[RFC3550]で指定されます。 本書では定義されたペイロード書式はその仕様と一致した方法でヘッダーの分野を使用します。
marker (M):
G.711.1 does not define anything specific regarding Discontinuous
Transmission (DTX), a.k.a. silence suppression. Codec-independent
mechanisms may be used, like the generic comfort-noise payload
format defined in [RFC3389].
マーカー(M): G.711.1はDiscontinuous Transmission(DTX)、通称沈黙抑圧に関して特定のものは何も定義しません。 コーデックから独立しているメカニズムは[RFC3389]で定義された一般的な安らぎ雑音ペイロード書式のように使用されるかもしれません。
For applications that send either no packets or occasional
comfort-noise packets during silence, the first packet of a
talkspurt -- that is, the first packet after a silence period
during which packets have not been transmitted contiguously --
沈黙の間、どんなパケットも時々の安らぎ雑音パケットのどちらかも送らないでください、talkspurtの最初のパケット--それがそうするアプリケーション、沈黙の期間の後のパケットが近接して伝えられていない最初のパケットのために--
Sollaud Standards Track [Page 3] RFC 5391 RTP Payload Format for G.711.1 November 2008
Sollaud規格は2008年11月にG.711.1のためにRFC5391RTP有効搭載量形式を追跡します[3ページ]。
SHOULD be distinguished by setting the marker bit in the RTP data
header to one. The marker bit in all other packets is zero. The
beginning of a talkspurt MAY be used to adjust the playout delay
to reflect changing network delays. Applications without silence
suppression MUST set the marker bit to zero.
SHOULD、RTPデータヘッダーにマーカービットをはめ込むことによって、1つに区別されてください。 他のすべてのパケットのマーカービットはゼロです。 talkspurtの始まりは、ネットワーク遅延を変えながら反射するように再生遅れを調整するのに使用されるかもしれません。 沈黙抑圧のないアプリケーションはマーカービットをゼロに設定しなければなりません。
payload type (PT):
The assignment of an RTP payload type for this packet format is
outside the scope of this 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 5.3).
ペイロードタイプ(太平洋標準時の): このパケット・フォーマットのためのRTPペイロードタイプの課題は、このドキュメントの範囲の外にあって、ここで指定されないでしょう。 このペイロード形式が使用されているRTPプロフィールが、このコーデックのためにペイロードタイプを選任するか、またはペイロードタイプによってダイナミックに制限されていることになっていると指定する(セクション5.3を見る)と予想されます。
timestamp:
The RTP timestamp clock frequency is the same as the default
sampling frequency: 16 kHz.
タイムスタンプ: RTPタイムスタンプクロック周波数はデフォルトサンプリング周波数と同じです: 16kHz
G.711.1 has also the capability to operate with 8-kHz sampled
input/output signals. 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.711.1には、8kHzの抽出された入力/出力信号で作動する能力があります。 それはbitstreamに影響しません、そして、デコーダはエンコーダの入力のときにオリジナルの信号の標本抽出率に関する先験的な知識を必要としません。 したがって、8kHzで装置の実現とオーディオの音の能力、エンコーダの入力、そして/または、デコーダの出力によるのを構成できます。 しかしながら、いつも16kHzのRTPクロックレートを使用しなければなりません。
The duration of one frame is 5 ms, corresponding to 80 samples at
16 kHz. Thus, the timestamp is increased by 80 for each
consecutive frame.
1個のフレームの持続時間は16kHzで80個のサンプルに対応する5msです。 したがって、タイムスタンプはそれぞれの連続したフレームあたり80増加します。
4. Payload Format
4. 有効搭載量形式
The complete payload consists of a payload header of 1 octet, followed by one or more consecutive G.711.1 audio frames of the same mode.
完全なペイロードは同じモードの1個以上の連続したG.711.1オーディオフレームが支えた1つの八重奏のペイロードヘッダーから成ります。
The mode may change between packets, but not within a packet.
モードは、パケットの間で変化しますが、パケットの中で変化するかもしれないというわけではありません。
4.1. Payload Header
4.1. 有効搭載量ヘッダー
The payload header is illustrated below.
ペイロードヘッダーは以下で例証されます。
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|0 0 0 0 0| MI |
+-+-+-+-+-+-+-+-+
0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |0 0 0 0 0| MI| +-+-+-+-+-+-+-+-+
Sollaud Standards Track [Page 4] RFC 5391 RTP Payload Format for G.711.1 November 2008
Sollaud規格は2008年11月にG.711.1のためにRFC5391RTP有効搭載量形式を追跡します[4ページ]。
The five most significant bits are reserved for further extension and MUST be set to zero and MUST be ignored by receivers.
5つの最上位ビットをさらなる拡大のために予約されて、ゼロに設定しなければならなくて、受信機で無視しなければなりません。
The Mode Index (MI) field (3 bits) gives the mode of the following frame(s) as per the table:
Mode Index(MI)分野(3ビット)はテーブルに従って以下のフレームのモードを与えます:
+------------+--------------+------------+
| Mode Index | G.711.1 mode | Frame size |
+------------+--------------+------------+
| 1 | R1 | 40 octets |
| 2 | R2a | 50 octets |
| 3 | R2b | 50 octets |
| 4 | R3 | 60 octets |
+------------+--------------+------------+
+------------+--------------+------------+ | モードインデックス| G.711.1モード| フレーム・サイズ| +------------+--------------+------------+ | 1 | R1| 40の八重奏| | 2 | R2a| 50の八重奏| | 3 | R2b| 50の八重奏| | 4 | R3| 60の八重奏| +------------+--------------+------------+
Table 3: Modes in payload header
テーブル3: ペイロードヘッダーのモード
All other values of MI are reserved for future use and MUST NOT be used.
MIの他のすべての値を今後の使用のために予約されて、使用しなければならないというわけではありません。
Payloads received with an undefined MI value MUST be discarded.
未定義のMI値で受け取られた有効搭載量を捨てなければなりません。
If a restricted mode-set has been set up by the signaling (see Section 5), payloads received with an MI value not in this set MUST be discarded.
制限されたモードセットがシグナリングによって設立されたなら(セクション5を見てください)、このセットでMI値で受け取られたペイロードを捨ててはいけません。
4.2. Audio Data
4.2. オーディオデータ
After this payload header, the consecutive audio frames are packed in order of time, that is, oldest first. All frames MUST be of the same mode, indicated by the MI field of the payload header.
このペイロードヘッダーの後に、連続したオーディオフレームはすなわち、時間、最も古い1番目の順に梱包されます。 すべてのフレームがペイロードヘッダーのMI分野によって示された同じモードのものであるに違いありません。
Within a frame, layers are always packed in the same order: L0 then L1 for mode R2a, L0 then L2 for mode R2b, L0 then L1 then L2 for mode R3. This is illustrated below.
フレームの中では、層は同次でいつも梱包されます: モードR2aのためのL0の当時のL1、モードR2bのためのL0の当時のL2、モードR3のためのL0の当時のL1当時のL2。 これは以下で例証されます。
Sollaud Standards Track [Page 5] RFC 5391 RTP Payload Format for G.711.1 November 2008
Sollaud規格は2008年11月にG.711.1のためにRFC5391RTP有効搭載量形式を追跡します[5ページ]。
+-------------------------------+
R1 | L0 |
+-------------------------------+
+-------------------------------+ R1| L0| +-------------------------------+
+-------------------------------+--------+
R2a | L0 | L1 |
+-------------------------------+--------+
+-------------------------------+--------+ R2a| L0| L1| +-------------------------------+--------+
+-------------------------------+--------+
R2b | L0 | L2 |
+-------------------------------+--------+
+-------------------------------+--------+ R2b| L0| L2| +-------------------------------+--------+
+-------------------------------+--------+--------+
R3 | L0 | L1 | L2 |
+-------------------------------+--------+--------+
+-------------------------------+--------+--------+ R3| L0| L1| L2| +-------------------------------+--------+--------+
The size of one frame is given by the mode, as per Table 3, and the actual number of frames is easy to infer from the size of the audio data part:
Table3に従ってモードで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.
完全なフレームだけを考えなければなりません。 それで、分割への残りが上にあれば、容認されたペイロードの対応する残っているバイトを無視しなければなりません。
5. Payload Format Parameters
5. 有効搭載量形式パラメタ
This section defines the parameters that may be used to configure optional features in the G.711.1 RTP transmission.
このセクションはG.711.1 RTPトランスミッションにおけるオプション機能を構成するのに使用されるかもしれないパラメタを定義します。
Both A-law and mu-law G.711 are supported in the core layer L0, but there is no interoperability between A-law and mu-law. So two media types with the same parameters will be defined: audio/PCMA-WB for A-law core, and audio/PCMU-WB for mu-law core. This is consistent with the audio/PCMA and audio/PCMU media types separation for G.711 audio.
A-法とμ法のG.711の両方がL0コア層の中で支持されますが、A-法とμ法の間には、相互運用性が全くありません。 それで、同じパラメタがある2つのメディアタイプが定義されるでしょう: A-法のコアへのオーディオ/PCMA-WB、およびμ法のコアへのオーディオ/PCMU-WB。 これはオーディオ/PCMAと一致しています、そして、オーディオ/PCMUメディアはG.711オーディオのための分離をタイプします。
The parameters are defined here as part of the media subtype registrations for the G.711.1 codec. A mapping of the parameters into the Session Description Protocol (SDP) [RFC4566] 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.711.1コーデックのためのメディア「副-タイプ」登録証明書の一部とパラメタを定義します。また、Session記述プロトコル(SDP)[RFC4566]へのパラメタに関するマッピングをSDPを使用するそれらのアプリケーションに提供します。 MIMEかSDPを使用しない制御プロトコルでは、その制御プロトコルと共に使用される適切な形式にメディア型引数を写像しなければなりません。
Sollaud Standards Track [Page 6] RFC 5391 RTP Payload Format for G.711.1 November 2008
Sollaud規格は2008年11月にG.711.1のためにRFC5391RTP有効搭載量形式を追跡します[6ページ]。
5.1. PCMA-WB Media Type Registration
5.1. PCMA-WBメディアは登録をタイプします。
This registration is done using the template defined in [RFC4288] and following [RFC4855].
この登録は[RFC4288]で定義されて、[RFC4855]に続いて、テンプレートを使用し終わっています。
Type name: audio
型名: オーディオ
Subtype name: PCMA-WB
Subtypeは以下を命名します。 PCMA-Wb
Required parameters: none
必要なパラメタ: なし
Optional parameters:
任意のパラメタ:
mode-set: restricts the active codec mode set to a subset of all
modes. Possible values are a comma-separated list of modes
from the set: 1, 2, 3, 4 (see Mode Index in Table 3 of RFC
5391). The modes are listed in order of preference; first is
preferred. If mode-set is specified, frames encoded with modes
outside of the subset MUST NOT be sent in any RTP payload. If
not present, all codec modes are allowed.
モードセット: 活動的なコーデックモードセットをすべてのモードの部分集合に制限します。 可能な値はセットからのモードのコンマで切り離されたリストです: 1、2、3、4(モードがRFC5391のテーブル3で索引をつけるのを見ます)。 モードは好みの順に記載されています。 1番目は好まれます。 モードセットが指定されるなら、どんなRTPペイロードにもモードが部分集合の外にある状態でコード化されたフレームを送ってはいけません。 プレゼントでないなら、すべてのコーデックモードが許容されています。
ptime: the recommended length of time (in milliseconds)
represented by the media in a packet. It should be an integer
multiple of 5 ms (the frame size). See Section 6 of RFC 4566.
ptime: パケットにメディアによって表されたお勧めの長さの時間(ミリセカンドによる)。 それは5ms(フレーム・サイズ)の整数倍数であるべきです。 RFC4566のセクション6を見てください。
maxptime: the maximum length of time (in milliseconds) that can
be encapsulated in a packet. It should be an integer multiple
of 5 ms (the frame size). See Section 6 of RFC 4566.
maxptime: パケットで要約できる最大の長さの時間(ミリセカンドによる)。 それは5ms(フレーム・サイズ)の整数倍数であるべきです。 RFC4566のセクション6を見てください。
Encoding considerations: This media type is framed and contains
binary data. See Section 4.8 of RFC 4288.
問題をコード化します: このメディアタイプは、縁どられて、2進のデータを含んでいます。 RFC4288のセクション4.8を見てください。
Security considerations: See Section 8 of RFC 5391.
セキュリティ問題: RFC5391のセクション8を見てください。
Interoperability considerations: none
相互運用性問題: なし
Published specification: RFC 5391
広められた仕様: RFC5391
Applications that 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
意図している用法: 一般的
Sollaud Standards Track [Page 7] RFC 5391 RTP Payload Format for G.711.1 November 2008
Sollaud規格は2008年11月にG.711.1のためにRFC5391RTP有効搭載量形式を追跡します[7ページ]。
Restrictions on usage: This media type depends on RTP framing, and
hence is only defined for transfer via RTP.
用法における制限: このメディアタイプは、RTP縁どりによって、したがって、転送のためにRTPを通して定義されるだけです。
Author: Aurelien Sollaud
以下を書いてください。 Aurelien Sollaud
Change controller: IETF Audio/Video Transport working group delegated
from the IESG
コントローラを変えてください: IESGから代表として派遣されたIETF Audio/ビデオTransportワーキンググループ
5.2. PCMU-WB Media Type Registration
5.2. PCMU-WBメディアは登録をタイプします。
This registration is done using the template defined in [RFC4288] and following [RFC4855].
この登録は[RFC4288]で定義されて、[RFC4855]に続いて、テンプレートを使用し終わっています。
Type name: audio
型名: オーディオ
Subtype name: PCMU-WB
Subtypeは以下を命名します。 PCMU-Wb
Required parameters: none
必要なパラメタ: なし
Optional parameters:
任意のパラメタ:
mode-set: restricts the active codec mode-set to a subset of all
modes. Possible values are a comma-separated list of modes
from the set: 1, 2, 3, 4 (see Mode Index in Table 3 of RFC
5391). The modes are listed in order of preference; first is
preferred. If mode-set is specified, frames encoded with modes
outside of the subset MUST NOT be sent in any RTP payload. If
not present, all codec modes are allowed.
モードセット: 活動的なコーデックモードセットをすべてのモードの部分集合に制限します。 可能な値はセットからのモードのコンマで切り離されたリストです: 1、2、3、4(モードがRFC5391のテーブル3で索引をつけるのを見ます)。 モードは好みの順に記載されています。 1番目は好まれます。 モードセットが指定されるなら、どんなRTPペイロードにもモードが部分集合の外にある状態でコード化されたフレームを送ってはいけません。 プレゼントでないなら、すべてのコーデックモードが許容されています。
ptime: the recommended length of time (in milliseconds)
represented by the media in a packet. It should be an integer
multiple of 5 ms (the frame size). See Section 6 of RFC 4566.
ptime: パケットにメディアによって表されたお勧めの長さの時間(ミリセカンドによる)。 それは5ms(フレーム・サイズ)の整数倍数であるべきです。 RFC4566のセクション6を見てください。
maxptime: the maximum length of time (in milliseconds) that can
be encapsulated in a packet. It should be an integer multiple
of 5 ms (the frame size). See Section 6 of RFC 4566.
maxptime: パケットで要約できる最大の長さの時間(ミリセカンドによる)。 それは5ms(フレーム・サイズ)の整数倍数であるべきです。 RFC4566のセクション6を見てください。
Encoding considerations: This media type is framed and contains
binary data. See Section 4.8 of RFC 4288.
問題をコード化します: このメディアタイプは、縁どられて、2進のデータを含んでいます。 RFC4288のセクション4.8を見てください。
Security considerations: See Section 8 of RFC 5391.
セキュリティ問題: RFC5391のセクション8を見てください。
Interoperability considerations: none
相互運用性問題: なし
Published specification: RFC 5391
広められた仕様: RFC5391
Applications that use this media type: Audio and video conferencing
tools.
このメディアタイプを使用するアプリケーション: オーディオとビデオ会議ツール。
Sollaud Standards Track [Page 8] RFC 5391 RTP Payload Format for G.711.1 November 2008
Sollaud規格は2008年11月にG.711.1のためにRFC5391RTP有効搭載量形式を追跡します[8ページ]。
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.
用法における制限: このメディアタイプは、RTP縁どりによって、したがって、転送のためにRTPを通して定義されるだけです。
Author: Aurelien Sollaud
以下を書いてください。 Aurelien Sollaud
Change controller: IETF Audio/Video Transport working group delegated
from the IESG
コントローラを変えてください: IESGから代表として派遣されたIETF Audio/ビデオTransportワーキンググループ
5.3. Mapping to SDP Parameters
5.3. パラメタをSDPに写像します。
The information carried in the media type specification has a specific mapping to fields in the Session Description Protocol (SDP) [RFC4566], which is commonly used to describe RTP sessions. When SDP is used to specify sessions employing the G.711.1 codec, the mapping is as follows:
仕様が特定のマッピングを持っているメディアタイプで運ばれた情報はSessionで記述プロトコル(SDP)[RFC4566]をさばきます。(それは、RTPセッションについて説明するのに一般的に使用されます)。 SDPがいつG.711.1コーデックを使うセッション、マッピングを指定するのにおいて使用されているかは、以下の通りです:
o The media type ("audio") goes in SDP "m=" as the media name.
o メディアタイプ(「オーディオ」)はメディア名としてSDP「m=」に行きます。
o The media subtype ("PCMA-WB" or "PCMU-WB") goes in SDP "a=rtpmap"
as the encoding name. The RTP clock rate in "a=rtpmap" MUST be
16000 for G.711.1.
o メディア「副-タイプ」(「PCMA-Wb」か「PCMU-Wb」)はコード化名としてSDP"a=rtpmap"に入ります。 "a=rtpmap"のRTPクロックレートはG.711.1のための16000でなければなりません。
o The parameter "mode-set" goes in the SDP "a=fmtp" attribute by
copying it as a "mode-set=<value>" string.
o 「モードに設定された=<値>」ストリングとしてそれをコピーすることによって、「モードセット」というパラメタはSDP"a=fmtp"属性に入ります。
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"属性に入ります。
5.3.1. Offer-Answer Model Considerations
5.3.1. 申し出答えモデル問題
The following considerations apply when using SDP offer-answer procedures [RFC3264] to negotiate the use of G.711.1 payload in RTP:
RTPにおけるG.711.1ペイロードの使用を交渉するのに、SDP申し出答え手順[RFC3264]を用いるとき、以下の問題は適用されます:
o Since G.711.1 is an extension of G.711, the offerer SHOULD
announce G.711 support in its "m=audio" line, with G.711.1
preferred. This will allow interoperability with both G.711.1 and
G.711-only capable parties. This is done by offering the PCMA
media subtype in addition to PCMA-WB, and/or PCMU in addition to
PCMU-WB.
o G.711.1がG.711の拡大であるので、G.711.1が好まれている状態で、申出人SHOULDは「m=オーディオ」の線でG.711サポートを発表します。 これはG.711.1とG.711だけの両方がある相互運用性に有能なパーティーを許容するでしょう。 PCMA-WBに加えたPCMAメディア「副-タイプ」、そして/または、PCMU-WBに加えたPCMUを提供することによって、これをします。
Sollaud Standards Track [Page 9] RFC 5391 RTP Payload Format for G.711.1 November 2008
Sollaud規格は2008年11月にG.711.1のためにRFC5391RTP有効搭載量形式を追跡します[9ページ]。
Below is an example part of such an offer, for A-law:
以下に、A-法のためのそのような申し出の例の部分があります:
m=audio 54874 RTP/AVP 96 8
a=rtpmap:96 PCMA-WB/16000
a=rtpmap:8 PCMA/8000
オーディオの54874RTP/AVP96 8m=a=rtpmap: 96PCMA-WB/16000a=rtpmap: 8PCMA/8000
As a reminder, the payload format for G.711 is defined in Section
4.5.14 of [RFC3551].
思い出させるものと、G.711のためのペイロード書式は.14セクション4.5[RFC3551]で定義されます。
o The "mode-set" parameter is bi-directional; i.e., the restricted
mode-set applies to media both to be received and sent by the
declaring entity. If a mode-set was supplied in the offer, the
answerer MUST return either the same mode-set or a subset of this
mode-set. The answerer MAY change the preference order. If no
mode-set was supplied in the offer, the anwerer MAY return a mode-
set to restrict the possible modes. In any case, the mode-set in
the answer then applies for both offerer and answerer. The
offerer MUST NOT send frames of a mode that has been removed by
the answerer.
o 「モードセット」パラメタは双方向です。 すなわち、制限されたモードセットは宣言実体によってともに受け取られて、送られるのにメディアに申し込みます。 申し出でモードセットを供給したなら、answererは同じモードセットかこのモードセットの部分集合のどちらかを返さなければなりません。 answererは好みの命令を変えるかもしれません。 申し出でモードセットを全く供給しなかったなら、anwererは、可能なモードを制限するためにモードセットを返すかもしれません。 どのような場合でも、そして、答えにおけるモードセットは申出人とanswererの両方に申し込みます。 申出人はanswererによって取り除かれたモードのフレームを送ってはいけません。
For multicast sessions, if "mode-set" is supplied in the offer,
the answerer SHALL only participate in the session if it supports
the offered mode-set.
マルチキャストセッションのために、申し出で「モードセット」を供給するなら、提供されたモードセットを支える場合にだけ、answerer SHALLはセッションのときに参加します。
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 [RFC3264]. The "maxptime"
parameter MUST be handled in the same way.
o 多くの場合、パラメタの"ptime"と"maxptime"は相互運用性に影響しないでしょう。 "ptime"パラメタのSDP申し出答え取り扱いは[RFC3264]で説明されます。 同様に、"maxptime"パラメタを扱わなければなりません。
o Any unknown parameter in an offer MUST be ignored by the receiver
and MUST NOT be included in the answer.
o 申し出におけるどんな未知のパラメタも、受信機で無視しなければならなくて、答えに含まれてはいけません。
Below are some example parts of SDP offer-answer exchanges.
以下に、SDP申し出答え交換のいくつかの例の部品があります。
o Example 1
o 例1
Offer: G.711.1 all modes, with G.711 fallback, prefers mu-law
m=audio 54874 RTP/AVP 96 97 0 8
a=rtpmap:96 PCMU-WB/16000
a=rtpmap:97 PCMA-WB/16000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
以下を提供してください。 G.711.1、すべてのモードがG.711後退でオーディオの54874μ法のm=RTP/AVPを好む、96 97、0 8a=rtpmap、: 96PCMU-WB/16000a=rtpmap: 97PCMA-WB/16000a=rtpmap: 0PCMU/8000a=rtpmap: 8PCMA/8000
Answer: all modes accepted, both mu- and A-law.
m=audio 59452 RTP/AVP 96 97
a=rtpmap:96 PCMU-WB/16000
a=rtpmap:97 PCMA-WB/16000
以下に答えてください。 96 97a=rtpmap: 96PCMU-WB/16000a=rtpmap: すべてのモードが受け入れて、オーディオの59452A-法μとmの両方=RTP/AVPは97PCMA-WB/16000です。
Sollaud Standards Track [Page 10] RFC 5391 RTP Payload Format for G.711.1 November 2008
Sollaud規格は2008年11月にG.711.1のためにRFC5391RTP有効搭載量形式を追跡します[10ページ]。
o Example 2
o 例2
Offer: G.711.1 all modes, with G.711 fallback, prefers A-law
m=audio 54874 RTP/AVP 96 97 8 0
a=rtpmap:96 PCMA-WB/16000
a=rtpmap:97 PCMU-WB/16000
以下を提供してください。 G.711.1、すべてのモードがG.711後退でオーディオの54874A-法のm=RTP/AVPを好む、96 97、8 0a=rtpmap、: 96PCMA-WB/16000a=rtpmap: 97PCMU-WB/16000
Answer: wants only A-law mode R3
m=audio 59452 RTP/AVP 96
a=rtpmap:96 PCMA-WB/16000
a=fmtp:96 mode-set=4
以下に答えてください。 A-法のモードR3m=オーディオの59452RTP/AVP96a=rtpmapだけ: 96PCMA-WB/16000a=fmtp: 96モードに設定された=4が欲しいです。
o Example 3
o 例3
Offer: G.711.1 A-law with two modes, R2b and R3, with R3 preferred
m=audio 54874 RTP/AVP 96
a=rtpmap:96 PCMA-WB/16000
a=fmtp:96 mode-set=4,3
以下を提供してください。 G.711.1の2つのモード、R2b、およびR3、オーディオの54874R3都合のよいm=RTP/AVPに伴う1法の96a=rtpmap: 96PCMA-WB/16000a=fmtp: 96モードに設定された=4、3
Answer: accepted
m=audio 59452 RTP/AVP 96
a=rtpmap:96 PCMA-WB/16000
a=fmtp:96 mode-set=4,3
以下に答えてください。 受け入れられたm=オーディオの59452RTP/AVP96a=rtpmap: 96PCMA-WB/16000a=fmtp: 96モードに設定された=4、3
If the answerer had wanted to restrict to one mode, it would have
answered with only one value in the mode-set, for example mode-
set=3 for mode R2b.
answererがモードを1つに制限したかったなら、モードセットにおける1つの値だけで答えたでしょうに、例えば、モードはモードR2bに=3を設定しました。
5.3.2. Declarative SDP Considerations
5.3.2. 叙述的なSDP問題
For declarative use of SDP, nothing specific is defined for this payload format. The configuration given by the SDP MUST be used when sending and/or receiving media in the session.
SDPの叙述的な使用において、特定のものは何もこのペイロード形式のために定義されません。 セッションのときに発信するとき、使用される、そして/または、メディアを受け取ることであるSDP MUSTによって与えられた構成。
6. G.711 Interoperability
6. G.711相互運用性
The L0 layer of G.711.1 is fully interoperable with G.711, and is embedded in all modes of G.711.1. This provides an easy G.711.1 - G.711 transcoding process.
G.711.1のL0層は、G.711と共に完全に共同利用できて、G.711.1のすべてのモードに埋め込まれています。 これは簡単なG.711.1を提供します--G.711コード変換の過程。
A gateway or any other network device receiving a G.711.1 packet can easily extract a G.711-compatible payload, without the need to decode and re-encode the audio signal. It simply has to take the audio data of the payload, and strip the upper layers (L1 and/or L2), if any.
G.711.1パケットを受けるゲートウェイかいかなる他のネットワーク装置も容易にG.711コンパチブルペイロードを抽出できます、音声信号を解読して、再コード化する必要性なしで。 それは、単に、ペイロードに関するオーディオデータを取って、もしあれば、上側の層(L1、そして/または、L2)を剥取らなければなりません。
If a G.711.1 packet contains several frames, the concatenation of the L0 layers of each frame will form a G.711-compatible payload.
G.711.1パケットがいくつかのフレームを含んでいると、それぞれのフレームのL0層の連結はG.711コンパチブルペイロードを形成するでしょう。
Sollaud Standards Track [Page 11] RFC 5391 RTP Payload Format for G.711.1 November 2008
Sollaud規格は2008年11月にG.711.1のためにRFC5391RTP有効搭載量形式を追跡します[11ページ]。
7. Congestion Control
7. 輻輳制御
Congestion control for RTP SHALL be used in accordance with [RFC3550] and any appropriate profile (for example, [RFC3551]).
RTP SHALLのために混雑を制御します。[RFC3550]とあらゆる適切なプロフィール(例えば、[RFC3551])に従って、使用されてください。
The embedded nature of G.711.1 audio data can be helpful for congestion control, since a coding mode with a lower bit rate can be selected when needed. This property is usable only when multiple modes have been negotiated (either no "mode-set" parameter in the SDP or a "mode-set" with at least two modes).
輻輳制御において、G.711.1オーディオデータの埋め込まれた本質は役立っている場合があります、必要であると下側のビット伝送速度があるコード化モードを選択できるので。 複数のモードが交渉されたときだけ(SDPで「モードセット」パラメタがない少なくとも2つのモードがある「モードセット」)、この特性は使用可能です。
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 [RFC3550] and any appropriate profile (for example, [RFC3551]).
この仕様に基づき定義されたペイロード書式を使用するRTPパケットはRTP仕様[RFC3550]とどんな適切なプロフィール(例えば、[RFC3551])でも議論した総合証券問題を受けることがあります。
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 the Secure Real-time Transport Protocol (SRTP) [RFC3711], MAY be used.
この形式がコード化されたスピーチ/オーディオを輸送するとき、主な安全保障問題はスピーチ/オーディオ自体の秘密性、保全保護、および認証を含んでいます。 ペイロード形式自体には、どんな内蔵のセキュリティーメカニズムもありません。Secureレアル-時間Transportプロトコルなどの適当な外部のどんなメカニズム(SRTP)[RFC3711]も使用されるかもしれません。
This payload format and the G.711.1 encoding do not exhibit any significant non-uniformity in the receiver-end computational load, and thus they are unlikely to pose a denial-of-service threat due to the receipt of pathological datagrams. In addition, they do not contain any type of active content such as scripts.
このペイロード形式とG.711.1コード化は受信端末のコンピュータの負荷における少しの重要な非の一様性も示しません、そして、その結果、彼らは病理学的なデータグラムの領収書によるサービスの否定の脅威を引き起こしそうにはありません。さらに、それらはアクティブな内容のスクリプトなどの少しのタイプも含んでいません。
9. IANA Considerations
9. IANA問題
Two new media subtypes (audio/PCMA-WB and audio/PCMU-WB) have been registered by IANA. See Sections 5.1 and 5.2.
2つのニューメディア血液型亜型(オーディオ/PCMA-WBとオーディオ/PCMU-WB)がIANAによって登録されました。 セクション5.1と5.2を見てください。
Sollaud Standards Track [Page 12] RFC 5391 RTP Payload Format for G.711.1 November 2008
Sollaud規格は2008年11月にG.711.1のためにRFC5391RTP有効搭載量形式を追跡します[12ページ]。
10. References
10. 参照
10.1. Normative References
10.1. 引用規格
[ITU-G.711.1] International Telecommunications Union, "Wideband
embedded extension for G.711 pulse code modulation",
ITU-T Recommendation G.711.1, March 2008.
[ITU-G.711.1] 国際Telecommunications Union、「G.711パルス符号変調のための広帯域の埋め込まれた拡大」、ITU-T Recommendation G.711.1、2008年3月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer
Model with Session Description Protocol (SDP)", RFC
3264, June 2002.
[RFC3264] ローゼンバーグとJ.とH.Schulzrinne、「セッション記述プロトコル(SDP)がある申し出/答えモデル」、RFC3264、2002年6月。
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, July 2003.
[RFC3550] Schulzrinne、H.、Casner、S.、フレディリック、R.、およびV.ジェーコブソン、「RTP:」 「リアルタイムのアプリケーションのためのトランスポート・プロトコル」、STD64、RFC3550、2003年7月。
[RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio
and Video Conferences with Minimal Control", STD 65,
RFC 3551, July 2003.
[RFC3551] Schulzrinne、H.、およびS.Casner、「オーディオのためのRTPプロフィールと最小量があるテレビ会議システムは制御します」、STD65、RFC3551、2003年7月。
[RFC4288] Freed, N. and J. Klensin, "Media Type Specifications
and Registration Procedures", BCP 13, RFC 4288,
December 2005.
解放された[RFC4288]とN.とJ.Klensin、「メディアは仕様と登録手順をタイプする」BCP13、RFC4288、2005年12月。
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP:
Session Description Protocol", RFC 4566, July 2006.
[RFC4566] ハンドレー、M.、ジェーコブソン、V.、およびC.パーキンス、「SDP:」 「セッション記述プロトコル」、RFC4566、2006年7月。
[RFC4855] Casner, S., "Media Type Registration of RTP Payload
Formats", RFC 4855, February 2007.
[RFC4855] Casner、S.、「メディアはRTP有効搭載量形式の登録をタイプする」RFC4855、2007年2月。
10.2. Informative References
10.2. 有益な参照
[ITU-G.711] International Telecommunications Union, "Pulse code
modulation (PCM) of voice frequencies", ITU-T
Recommendation G.711, November 1988.
[ITU-G.711] 1988年11月の国際Telecommunications Union、「音声周波数のパルス符号変調(PCM)」ITU-T Recommendation G.711。
[RFC3389] Zopf, R., "Real-time Transport Protocol (RTP) Payload
for Comfort Noise (CN)", RFC 3389, September 2002.
[RFC3389]Zopf、R.、「安らぎ雑音(CN)のためのリアルタイムのトランスポート・プロトコル(RTP)有効搭載量」、RFC3389、2002年9月。
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and
K. Norrman, "The Secure Real-time Transport Protocol
(SRTP)", RFC 3711, March 2004.
[RFC3711] 2004年のBaugher、M.、マグリュー、D.、ジーター、M.、カラーラ、E.、およびK.Norrman、「安全なリアルタイムのトランスポート・プロトコル(SRTP)」、RFC3711行進。
Sollaud Standards Track [Page 13] RFC 5391 RTP Payload Format for G.711.1 November 2008
Sollaud規格は2008年11月にG.711.1のためにRFC5391RTP有効搭載量形式を追跡します[13ページ]。
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 14]
Sollaud標準化過程[14ページ]
一覧
スポンサーリンク
